Scaling a Game Top-Up Platform to ₹1.5 Cr: Multi-gateway payments and automation

Selling digital goods like game top-ups presents a unique scaling challenge. Unlike physical items, delivery must be instant. Gaps in transaction sync or delay in automated fulfillment immediately triggers customer panic and support backlogs.

We built a platform that processed over ₹1.5 Crore in sales by combining multiple payment gateways with API-based automated order fulfillment. Here are the core patterns we implemented to keep the system robust.

1. Multi-Gateway Failovers

Relying on a single payment gateway is a single point of failure. Gateways frequently experience API downtime, rate limits, or processing freezes.

We integrated Razorpay, PhonePe, and PayPal, allowing the admin dashboard to assign specific gateways to different packages. If one gateway fails, the checkout system dynamically switches to the backup gateway, preventing lost sales.

2. Automated API Fulfillment

Manual code deliveries at 2am don't scale. For automated games and packages, order success webhooks trigger instant backend requests to the game's API provider (e.g. online games and digital content delivery networks).

The credits are injected directly into the user's game account within seconds of payment approval, eliminating human delay entirely.

3. The Idempotency Lock Pattern

Webhooks are retried by payment gateways if your server doesn't respond fast enough. This can lead to race conditions where the same payment triggers duplicate coin injections.

We solved this by using an atomic Redis lock on the transaction hash. When a webhook arrives, the backend tries to set a key in Redis with a short expiry. If the key is already set, the second process is discarded.

async function handlePaymentSuccess(transactionId, amount) {
  const lockKey = `lock:payment:${transactionId}`;
  const isLocked = await redis.set(lockKey, 'processing', 'NX', 'EX', 10);
  
  if (!isLocked) {
    throw new Error('Duplicate transaction request blocked.');
  }
  
  // Proceed to request upstream game fulfillment API
  const delivery = await upstreamApi.injectCredits(transactionId, amount);
  return delivery;
}

4. State Machine for Order Lifecycles

An order must transit cleanly through a series of steps to prevent inconsistencies. We modeled transactions as a state machine: PENDING → PAID → FULFILLING → FULFILLED.

If the upstream provider's API returns a temporary timeout, the state transitions to 'FAILED_RETRIABLE', adding the order back to a queue for exponential backoff retries.

5. Essential Best Practices

• Process each payment webhook exactly once by tracking transaction hashes in Redis.
• Support standard API retries safely without triggering duplicate recharge deliveries.
• Verify webhook signatures logo-signatures rigorously to ensure fake payloads cannot trigger account recharges.

In instant digital commerce, delivery delay is a conversion killer. Automate the route from checkout confirmation to game account injection.

How do you prevent duplicate payments in a game top-up platform?

Use an idempotency lock: an atomic Redis SET NX on the transaction hash before processing a payment webhook. If the key already exists, the retry is discarded instead of triggering a second credit injection - combined with multi-gateway failover and a PENDING to PAID to FULFILLED order state machine to keep every transaction consistent.