Test Your Integration

Use the staging environment to exercise every payment outcome — approvals, declines, and timeouts — before going live. Test against each payment method enabled for your merchant configuration, and verify your webhook handling and timeout behaviour as part of the run, not just the happy path.

Test data and payment simulators are environment- and country-specific. The values below cover Indonesia; equivalents for other markets, along with simulator access, are provided during onboarding.

Indonesia

Cards

Use these test cards in staging to trigger specific payment outcomes. Use any future expiry date and any 3-digit CVV. When the issuer challenge (OTP) screen appears, enter 1234.

Outcome	Card number
00 — Approved (with challenge)	4512 4900 0000 0907
05 — Do not honour	4512 4900 0000 0931
51 — Insufficient funds	4512 4900 0000 0949
62 — Restricted card	4512 4900 0000 0956

The declined cards are the simplest way to verify your failure handling end-to-end: the failure webhook, the error_message on the charge, and your customer-facing result page.

Virtual account

1. In the payment UI, select Virtual Account, choose a bank, and confirm. The UI displays a virtual account number with a countdown timer.
2. Copy the virtual account number.
3. Simulate the bank transfer in the test-bank simulator (link provided during onboarding), using the inquiry-then-pay flow.
4. Confirm your backend receives the completed webhook and your result page shows the approval.

To test the timeout path, let the countdown expire without paying.

QRIS

1. Select QRIS and confirm. The UI displays a QR code with a countdown timer.
2. Capture the QR code (a screenshot works) and submit it to the QR payment simulator (link provided during onboarding).
3. Confirm the result as above.

Wallets

1. Select Wallet and choose a wallet type. You are redirected to the wallet's own staging login.
2. Use the wallet's built-in test accounts to complete or fail the payment — each wallet provides test accounts for specific outcomes.
3. Confirm the result as above. Wallet payment windows vary widely — see wallet timeouts for why this matters to your timeout configuration.

What to verify

For every payment method, confirm that:

• An approved payment produces a completed webhook, your backend confirms it via GET /charge/{charge_id}, and the order is fulfilled exactly once (run the same webhook twice to prove idempotency).
• A declined payment produces a failure webhook, the order is released, and the customer sees a sensible message from error_message.
• An abandoned payment (close the window mid-flow) leaves the order held until your timeout elapses, then releases it.
• The redirect back to your result page displays correctly for both outcomes — without your backend depending on it.