Test mode & test cards

Test mode is a fully isolated environment that mirrors live: same API surface, same webhook payloads, same dashboard UI, separate everything else. New accounts start in test mode and stay there until your business is approved for live payments.

Test mode is where you build, test, and break things. Nothing you do in test mode touches a real card, your live customers, or your live balance.

What's separate, what's the same

When you graduate to live mode, you don't change your code. You just swap your test keys for live keys and set up live webhook endpoints.

What you can test

• Card payments with predictable success and failure outcomes (see the table below).
• 3D Secure flows, including success, failure, cancellation, and timeout (via the ACS emulator).
• Refunds, full or partial, from the dashboard or the API.
• Webhooks to a real or local endpoint, including retries and replay from the dashboard.
• The full hosted checkout, drop-in, and Elements UI end to end.
• Payouts, simulated on the test schedule.

Test cards

XPay accepts four test cards in test mode. The card number determines the issuer and the brand; the expiry date determines the payment outcome.

Any other card number is rejected in test mode. The international card is the one to use when you want to test the international fee tier.

Payment outcome by expiry

In test mode the expiry date decides whether the payment succeeds or fails, and how it fails. The card number itself does not.

Use 01/39 for the happy path. Use the others to validate how your code handles real-world failures: the Payment Intent moves to payment_failed, the Charge gets a failure_code, and you receive the matching webhooks (payment_intent.payment_failed, charge.failed).

CVV outcome by CVV value

The CVV controls the CVV match result reported on the resulting Charge.

Use 100 unless you're testing CVV-mismatch handling.

3D Secure in test mode

Every test payment runs the full 3D Secure 2 challenge flow through XPay's sandbox emulator. After you submit the card form, an ACS (Access Control Server) page pops up where you choose the authentication outcome:

• Success. Finishes the payment along the happy path.
• Rejected. The issuer denies the challenge. The payment fails with authentication_required or card_declined depending on the bank's response.
• Cancelled. The customer dismisses the challenge.
• Timeout. No response within the issuer's window.

This is how you test the 3DS-failure branches of your integration without finding a real failing card.

Where to next