Skip to main content

Testing in Staging

Before moving to production, you should systematically test every part of your integration in the staging environment. This guide walks through what to test and how to test it, including specific test amounts that trigger different behaviors.

Verify SSO with Multiple Users​

Start by confirming that authentication works correctly for different users:

  1. Generate SSO tokens for at least two different test users on your backend.

  2. Load the SDK with the first user's token. It should initialize without errors and show the gift card store.

  3. Load the SDK with the second user's token. Verify each user gets their own session with their own identity and transaction history.

  4. Test with an invalid or expired token. The SDK should show an error page, confirming your SSO endpoint correctly rejects bad tokens.

Test UPI Payments (Native Apps)​

If you configured UPI Intent for your native app, test the payment flow on real devices:

  • iOS: Open the SDK, select a brand, choose a denomination, and proceed to payment. UPI app icons (GPay, PhonePe, etc.) should appear. Tap one to verify the app opens.
  • Android: Same flow. The system UPI app chooser should appear when the user initiates a UPI payment.

Note that actual payment completion in staging uses test money, but the UPI app switching behavior can be verified visually.

Test Coins Integration​

If you implemented coins, test the full coins flow:

  1. Open the SDK. The user's coin balance should be displayed (from your /balance API).

  2. Select a brand and proceed to checkout. Enable coin usage in the checkout flow.

  3. Complete the purchase. Verify your /debit API was called with the correct userId, coins amount, and referenceId.

  4. Check that the user's coin balance decreased by the correct amount.

To test coin reversal, you can trigger a failure scenario (see test amounts below). When a purchase fails after coins are debited, Hubble will call your /reverse API.

Verifying Idempotency

To test idempotency, you can simulate a network retry by calling your debit endpoint twice with the same referenceId. The second call should return the same response without deducting coins again. This is critical to verify before going to production.

Test Brands and Special Amounts​

The staging environment has specific brands and amounts configured for testing different outcomes.

Two Types of Failures​

In a gift card purchase, there are two distinct stages where things can go wrong:

  1. Payment Failure: The payment itself fails (e.g., insufficient funds, UPI timeout, bank decline). The user's money is not deducted. No voucher generation is attempted.

  2. Voucher Generation Failure: The payment succeeds (money is deducted), but the gift card could not be generated by the brand's backend. The user has paid but did not receive a voucher. This requires a refund or retry.

These are fundamentally different scenarios. A payment failure is relatively benign (no money moved), but a voucher generation failure requires careful handling — the user has been charged and expects either a gift card or a refund.

Test Brands​

BrandExpected Behavior
FlipkartOrders complete with SUCCESS status
MyntraOrders complete with FAILED status

Testing Payment Failure​

To test payment failure, use the special amount ₹813 on EatSure. This triggers an immediate payment failure at the payment step — no money is deducted and no voucher generation is attempted.

Amount (₹)BrandResult
813EatSureImmediate payment failure (order fails instantly)

Verify that your integration correctly shows the failure to the user, fires the appropriate SDK events, and does not deduct any coins (if applicable).

Testing Voucher Generation Failure​

To test voucher generation failure, make a purchase on Myntra with any normal amount (not 813). The payment will succeed, but the voucher generation will fail.

Testing Brand with Zero Discount​

This lets you test what the purchase experience looks like when there is no discount applied — important because some of your brands in production may also have zero discount.

BrandResult
EatSure/NykaaPurchase completed successfully with zero discount applied.

Testing Events​

To confirm SDK events are reaching your analytics system:

  1. Open the SDK in your staging environment and perform actions (browse brands, start a payment, complete a test purchase).

  2. In your browser's developer console (or native log output), verify that "analytics" type messages are being received with the correct event names and properties.

  3. Check your analytics dashboard (Mixpanel, CleverTap, Amplitude, etc.) to confirm events appear with the expected properties.

  4. Pay special attention to critical events: payment_success, payment_fail, and voucher_generation_fail. These should appear after you complete test purchases using the test brands (Flipkart, Myntra).

To verify deep links work correctly:

  1. Construct a deep link URL to a specific brand:

    /buy/{brandId}?clientId=...&appSecret=...&token=...

  2. Load the URL in your WebView or iframe and confirm it opens directly to the brand purchase page (not the home screen).

  3. Test with query parameters: add amount=500 and verify the amount is pre-filled. Add coupon=TESTCODE and verify the coupon is applied.

  4. Test the other routes (/search, /transactions, /help) to confirm they navigate correctly.

Testing Webhooks​

To verify webhook delivery and signature validation:

  1. Ensure your staging webhook URL is registered with the Hubble team (this is separate from your SSO URL registration).

  2. Make a test purchase using a test brand. After the order completes (or fails), you should receive a webhook POST to your endpoint.

  3. Verify the X-Verify signature by computing HMAC-SHA256 of the raw body and comparing with the header value. Log both the received and computed signatures during testing.

  4. Test both success and failure scenarios:

    • Use Flipkart for a successful order (COMPLETED webhook)
    • Use Myntra for a failed voucher generation (FAILED webhook)

  5. Confirm your endpoint returns 200 for valid requests and properly rejects requests with invalid signatures.

Use a Request Logger for Debugging

During webhook testing, consider using a request logging tool (like a simple Express middleware that logs headers and body) to capture the raw webhook payload. This helps debug signature verification issues and confirms the exact payload format Hubble sends.

Testing Coupons​

If you're using the Coupon API:

  1. Create a test coupon in the staging environment using the Coupon API.

  2. Open the SDK and navigate to a brand purchase page.

  3. Apply the coupon code and verify the discount is correctly applied.

  4. Complete the purchase and verify the coupon usage is tracked.

Environment-Specific Coupons

Coupons are environment-specific — a coupon created in staging will not exist in production and vice versa. Always test your coupons in staging first.

Testing Cohorts​

If you're using user cohorts:

  1. Configure a test cohort using the Cohort Configuration API.

  2. Update your SSO endpoint to return the cohort identifier for test users.

  3. Open the SDK and verify the user sees the correct brand catalog and discount percentages for their cohort.

  4. Test with different cohort assignments to confirm each cohort receives the correct configuration.

Debugging SSO Failures​

In the staging environment, the SDK displays a Debug Info panel directly on the error screen. The debug panel shows:

  • Base URL — The URL Hubble called. Verify this matches the integration base URL you registered with Hubble.
  • Method — Should be POST.
  • Partner Response Status — The HTTP status code your endpoint returned (e.g., 401, 403, 500).
  • Partner Response — The response body your endpoint returned.
  • Curl Command — A ready-to-use curl command that reproduces the exact request Hubble made to your endpoint.
Debug Panel Location

The debug panel is only shown in the staging environment. In production, users see a generic error page without debug information.

How to Use the Debug Screen​

  • Copy the Curl Command and run it in your terminal. This reproduces the exact request Hubble made. If your endpoint returns an error, you now have a reproducible test case.
  • Check the Partner Response Status. If the API response is anything other than 200, the issue usually lies in your backend and you should verify your implementation.
  • Check the Base URL. If this does not match your expected SSO endpoint, the wrong integration base URL was registered with Hubble. Contact the Hubble team to correct it.
  • If the status is 200 but login still fails, check the Partner Response body. Your endpoint may be returning userId: null or a malformed JSON structure.