Game Top-up Checkout Timed Out? Verify Payment Before Crediting

Which timeout are you investigating?

A browser timeout, the merchant’s reservation deadline and the provider’s payment expiry are different events. This guide addresses a digital-goods order whose local checkout has closed while its payment outcome is uncertain. It does not claim that a provider-expired QR or VA remains payable.

Midtrans documents a payment lifecycle including pending, settlement and expire, and describes delayed or out-of-order notifications. Those are Midtrans product terms, not PAYJN status names. Map your approved integration’s own states before implementing this workflow.

Five checks before delivering a late top-up

1. Freeze the fulfilment decision for this order. Keep the original order ID, player/account identifier, SKU, intended quantity, IDR amount, provider payment ID, instruction expiry and timestamps with timezone. Restrict access to player information.
2. Retrieve the authoritative payment outcome using the provider’s approved server-side query or authenticated notification process. If a notification conflicts with your record, query again through the documented procedure. A success page or screenshot alone is insufficient.
3. Match the payment reference, amount and currency to the intended order. Check whether the player created a replacement order. One receipt cannot fund two purchases; two distinct confirmed payments require two separate reconciliation records.
4. Check fulfilment eligibility separately. Is the original item still available? Is the player account unchanged? Is the promotion over? If automatic delivery is no longer appropriate, place the confirmed payment in an exception queue and approve delivery or a supported refund under the agreed policy.
5. Commit the payment allocation and fulfilment instruction atomically where possible. Use a unique fulfilment key per order. If the game server times out, query delivery history before retrying an item grant; a payment webhook retry must not create another grant.

Hypothetical late-confirmation case

At 14:00 WIB, a player opens an IDR 100,000 checkout. The game closes its local reservation at 14:05. At 14:06, the backend receives a notification and confirms through the provider that the original payment succeeded. These times and amounts are invented, not channel timing promises.

Keep the verified receipt linked to the original order. If the original item can still be delivered under policy and no delivery exists, issue one fulfilment instruction. If it cannot, record the exception and arrange the approved resolution. Do not mark the receipt as unpaid merely because the browser reservation ended. If the provider instead reports the payment as expired or unresolved, do not infer a successful receipt.

A launch-test checklist for engineering and support

• Local checkout closes before a genuine success notification arrives; verified payment is reconciled without an automatic second charge.
• A pending notification arrives after a confirmed success; the application does not roll the order back to unpaid.
• The notification and a reconciliation job run together; only one item grant is issued.
• The game server accepts a grant but its response is lost; delivery history is checked before retry.
• The customer creates a second checkout, or two confirmed receipts arrive; each payment and fulfilment decision remains traceable.
• A paid order is no longer fulfilable; support records the approved refund or other resolution without inventing a provider refund capability.

Frequently asked questions

Should support ask the player to pay again?

Resolve the first payment outcome before giving new payment instructions. Otherwise a delayed successful payment may create an avoidable second payment.

Is this the same as duplicate webhook handling?

No. Duplicate handling protects a repeated event. This workflow also resolves a verified payment against a closed checkout and a possibly changed digital-goods entitlement.

Does this confirm PAYJN accepts every game?

No. Disclose the real product and any wagering, prizes or cash-redeemable features. Business and channel eligibility need separate approval.

Sources and related checks

Supplier sources checked on 8 November 2026. The fulfilment queue and game-ledger controls above are proposed merchant design practices. Confirm current provider rules and PAYJN-approved methods before testing; no supplier relationship, refund route or settlement time is implied.

• Midtrans — transaction status cycle
• Midtrans — notification verification and ordering
• Midtrans — notification and status reconciliation
• Indonesia payment integration enquiries
• Duplicate webhook protection
• VA amount mismatch reconciliation