Back to blog

Payment Risk Screening for Digital Reseller Stores

FazerCards
Payment Risk Screening for Digital Reseller Stores

A digital gift card or game top-up store has one property that sets it apart from nearly every other e-commerce niche: the goods are delivered instantly and irreversibly. The moment a code lands in your customer's inbox or your bot dispatches it to a Telegram chat, it is gone — no warehouse to reclaim it from, no courier to intercept. That asymmetry makes payment risk screening a first-order operational concern, not a nice-to-have. This guide walks through the layer-by-layer approach — from velocity rules to BIN validation to proxy signals — and shows exactly where each control fits in a reseller's day-to-day workflow.

Why Digital Goods Attract Fraud

When fraudsters look for a target, they want fast redemption and low detectability. Digital gift cards score high on both: a stolen card converts into usable value within minutes. Three main fraud patterns hit digital reseller stores:

  • Card testing — a fraudster runs small transactions to verify a batch of stolen card numbers before reselling them. Your store becomes the validation environment.
  • Carding for inventory — using verified stolen cards to buy high-value gift cards at your margin and flip them instantly elsewhere.
  • Account takeover — using stolen credentials to drain a customer's stored balance through your platform.

Each pattern leaves a distinct signal footprint. The rest of this guide matches controls to each one.

Layer 1: Velocity Controls

Many Orders from One IP in a Short Window

  • Symptom: Three or more completed orders from the same IP within ten minutes, or a sudden burst after a long quiet period.
  • Likely real cause: Card testing or bulk carding. Legitimate buyers rarely need more than one or two gift card orders in quick succession.
  • How to verify: Compare the IP's order count in the last five minutes against your 90-day average for any single IP. A 10x spike is anomalous.

Velocity rules to set in your storefront:

  • Max 3 orders per IP in any 10-minute window (start conservative; tune up for verified power users via an allow-list)
  • Max 2 orders per BIN + user-agent combination per hour
  • Hard limit: 1 successful gift card order per email address per product type per 24 hours for accounts under 7 days old

Multiple Account Registrations from One Device

  • Symptom: Several new accounts created within hours from the same device fingerprint or IP block.
  • Likely real cause: Account-per-card schemes, where each stolen card gets its own account to bypass per-account limits.
  • How to verify: Track distinct accounts per IP, email domain, and device fingerprint over a rolling 24-hour window. Legitimate office networks share IPs but show varied device fingerprints; fraud clusters reuse the same fingerprint.

Layer 2: BIN Validation

Card Country Does Not Match the Customer Location

  • Symptom: The BIN country (first six digits of the card number) is Germany, the buyer IP resolves to Vietnam, and the registered profile lists a third country.
  • Likely real cause: Stolen card data. The real cardholder is overseas; the fraudster is using the card number locally or through a VPN.
  • How to verify: Run a BIN lookup on every card payment and cross-reference the issuing country with the IP geolocation and profile address. A three-way mismatch is a strong fraud signal.

BIN-based rules to implement:

  • Flag orders where the BIN country differs from IP geolocation by more than one continent (adjacent-country mismatches, like a Ukrainian buyer on a Polish card, are often legitimate)
  • Route all flagged BIN-mismatch orders to 3D Secure authentication before fulfillment
  • Ask your payment processor or acquirer for the current list of high-fraud BIN ranges and block them

Layer 3: IP and Proxy Signals

Order Placed from a Datacenter or VPN IP

  • Symptom: The order IP resolves to an AWS, DigitalOcean, or Cloudflare WARP range, or to a known Tor exit node.
  • Likely real cause: A fraudster masking their real geolocation. Legitimate buyers virtually never purchase gift cards from datacenter IPs.
  • How to verify: Look up the Autonomous System Number of the IP. Datacenter and VPN ranges are published in threat-intelligence feeds. Compare against your normal order-IP distribution to confirm the anomaly.

Controls to put in place:

  • Require email or SMS OTP for datacenter and VPN IPs before order fulfillment
  • Block Tor exit nodes outright — very few legitimate purchases arrive through Tor
  • Use an IP reputation score from your payment processor or a dedicated fraud API and set an automatic review threshold

Layer 4: Device Fingerprinting

Even when a fraudster rotates IPs and registers fresh email addresses, the device often stays the same. A browser fingerprint combines OS version, fonts, canvas rendering output, and browser plugins into a stable identifier that survives cookie clearing.

  • Set a fingerprint at account creation and at first payment; store it against the account record.
  • Flag immediately when an existing account switches to a fingerprint that matches another account's previously flagged order.
  • Require reverification when the fingerprint changes significantly — a new browser major version is expected, but a completely different operating system is a red flag.

The Procurement Side: Removing Card Risk at the Source

All of the layers above protect your revenue from customer-facing fraud. There is a separate risk that many resellers overlook: the funding side of your own supplier account. If you top up your wholesale balance with a credit or debit card, you carry chargeback exposure on that side too — a bank dispute can freeze your supplier balance at the worst possible moment during a peak sales period.

FazerCards accepts Binance Pay and USDT (TRC20, BEP20, TON, Aptos) as funding methods — there is no card involved on the procurement side. Crypto transactions are final on-chain: no issuing bank, no dispute window, no freeze on your working balance. This does not eliminate customer-facing fraud (you still need all the layers above), but it removes one of the nastiest operational failure modes: a procurement hold triggered by a bank dispute on your funding card. The crypto payment guide for resellers explains how FazerCards funding works in practice. Pairing crypto procurement with real-time webhook delivery closes the last manual gap — if order completion fires a webhook to your system instantly, there is no window where a customer receives a code before your database logs the event.

Implementation Checklist

  1. Enable velocity rules: max 3 orders per IP per 10 minutes; max 2 per BIN + user-agent per hour; max 1 per email per product type per day for accounts under 7 days old.
  2. Integrate a BIN lookup on every card payment and route three-way country mismatches to 3D Secure or manual review.
  3. Subscribe to an IP reputation feed; block Tor exits and add a step-up verification step for datacenter and VPN IPs.
  4. Deploy browser fingerprinting at account creation and first payment; store fingerprint IDs on every order record.
  5. Set an order-value threshold for step-up authentication — new accounts above a defined amount trigger email or SMS OTP before fulfillment.
  6. Wire up webhooks from your supplier so delivery events update your database in real time and close the replay-attack window.
  7. Switch your FazerCards balance funding to crypto (Binance Pay or USDT) to eliminate card chargeback exposure on the procurement side.
  8. Run a weekly review of flagged orders; tune velocity and fingerprint thresholds against real false-positive rates rather than guessing.

FAQ

Does Velocity Limiting Block Legitimate Bulk Buyers?

Yes, initially. The fix is an allow-list for verified power users — customers who have completed KYC or maintained a clean order record for 90-plus days. Apply the strictest velocity limits to accounts under 7 days old and progressively relax them for established accounts. This gives new accounts a friction layer while keeping your best customers frictionless.

Can I Rely Entirely on My Payment Processor's Built-in Fraud Tools?

You should layer both. Processor rules such as Stripe Radar are strong at catching known card-fraud patterns across millions of merchants. Your own rules catch product-specific signals the processor never sees — for example, the combination of a new account, a VPN IP, and a high-denomination gift card SKU is something only your own scoring logic can detect specifically. Neither layer alone is sufficient for a digital goods store.

What Is the Right Response When I Flag a Legitimate Order?

Start in flag-and-review mode, not auto-block, during your first 30 days. Route flagged orders to a manual review queue with a target review time under 15 minutes, and build a simple approve-or-decline interface. Move to auto-block only after your false-positive rate on flagged orders has stayed below 2% for at least two consecutive weeks. The cost of a wrongly blocked order is low if you can clear it quickly; the cost of auto-blocking legitimate buyers is lost revenue and damaged trust.

How Does Crypto Procurement Reduce Card Risk on the Supply Side?

When you fund a supplier account with a credit card, the issuing bank can dispute that charge and freeze the credited balance — sometimes weeks after the funding event and with no warning. Crypto funding is settled on-chain the moment it confirms: no bank, no dispute window, no balance hold. Your FazerCards balance stays accessible through every sales cycle regardless of what your bank's fraud systems decide. Start with a free 5-day Gold trial — no card or KYC required — to see how the platform operates with crypto procurement and full API access from day one.