Skip to main content

Fraud Protection

Every gift card purchase made through the Hubble SDK in production is screened by Hubble's fraud detection system before the user is asked to pay. It runs automatically on Hubble's side, so you don't need to build anything for it. It protects you and your users from account farming, stolen payment instruments, and automated abuse.

This page explains when the check runs, what it looks at, what your users see when a purchase is blocked, and how to whitelist your internal users so testing in production isn't blocked.

Production only

Fraud checks are enforced in production. Staging does not block transactions, so you can test freely there. Expect the stricter behaviour described on this page once you go live.

When the Check Runs​

The fraud check runs at the moment a user starts a purchase, before any payment is collected:

  1. The user picks a brand and amount and taps to pay.
  2. The SDK collects a device fingerprint from the user's device.
  3. Hubble evaluates the purchase against the signals below.
  4. If the purchase is cleared, checkout continues as normal. If it is flagged, the purchase is stopped and the user is never charged.

A second, lighter check runs on the payment instrument (UPI ID or card) once the user pays. If that check fails, the payment is refunded automatically.

What We Look At​

The check looks at signals from the user's device, network, and account history.

Once you're live in production, you can see more details, including the flags raised for each purchase, in the Fraud Analysis dashboard on the integration portal.

What Your Users See​

When a purchase is flagged, the user sees:

Transaction could not be processed. Please try again later.

No money is taken. We deliberately don't tell the user why, so that fraudsters can't learn which signal tripped. If a real user contacts you about this, look them up on the Fraud Analysis dashboard (see below) to see exactly what was flagged.

Avoiding False Positives​

Most legitimate users never notice the fraud check. A few integration choices make a big difference:

  • Use WKWebView on iOS. SFSafariViewController breaks device fingerprinting and causes purchases to be flagged. See the iOS guide.
  • Send a stable, unique userId per user. Reusing one ID for several people, or creating a new ID per session, looks like account farming.
  • Don't test production on emulators, rooted or jailbroken devices, or over a VPN. Use real, unmodified phones on a normal Indian mobile or Wi-Fi network, or whitelist your testers (below).

Fraud Analysis Dashboard​

Once you're live, the integration portal has a Fraud Analysis section for your SDK integration:

  • Overview: overall fraud rate and how many purchases were reviewed and flagged.
  • Month-by-month: how the fraud rate is trending.
  • Fraud reasons: which signals are flagging your users most often.
  • User lookup: enter a user's ID to see every fraud check recorded for them, newest first, with the reasons for each.

Access is controlled per team member with the View fraud analysis permission.

Whitelist Internal Users​

Your team's own accounts often look risky to fraud detection: one test phone shared by several people, test devices that are rooted, or a VPN on the office network. To stop these accounts from being blocked in production, whitelist them.

  1. Open your SDK integration in the integration portal.
  2. Go to Fraud Analysis → Whitelist users, or use the Whitelist your internal users card on the home page.
  3. Enter the user's ID and click Whitelist.

Things to know:

  • Use the same user ID you send in your SSO response, not a phone number or email.
  • The user must have opened the SDK at least once in production before they can be whitelisted.
  • Each integration can whitelist up to 10 users. Whitelisted users can't be removed from the portal, so reserve slots for long-lived internal accounts such as QA, support, and demo accounts.
  • It can take up to 5 minutes for a new whitelist entry to take effect.
  • Whitelisted users skip all device and account fraud checks. Only whitelist accounts your team controls.
tip

Whitelist your QA accounts right after you go live, before running the end-to-end production test.