Test Cards

Visa

Use this card to simulate a successful payment:

Field	Value
Number	4111 1111 1111 1111
Expiry	Any future date (e.g. 12/30)
CVC	Any 3 digits (e.g. 123)

Card brand detection

The widget detects the card brand from the card number prefix:

Brand	Number prefix
Visa	4
Mastercard	51–55
American Express	34, 37
Discover	6011, 65
Diners Club	36, 38
JCB	35

BECS direct debit test accounts

For Australian bank account (BECS) payments:

Field	Value
BSB	062-000
Account number	Any number
Account name	Any name

Forcing payment outcomes

To force a specific outcome regardless of card details, set _sandbox_outcome in the payment intent’s metadata:

curl -X POST https://api.elasticpay.co/api/v1/payment_intents \
  -H "Authorization: Bearer sk_sandbox_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 1999,
    "currency": "AUD",
    "metadata": {"_sandbox_outcome": "decline"}
  }'

Value	Result
succeed	Payment succeeds (the default without an override)
decline	Payment fails with insufficient_funds
requires_action	Simulates a 3D Secure challenge
timeout	Payment fails with gateway_timeout

This works for any payment method and takes priority over card-number-based outcomes. Refunds have a parallel override — set "_sandbox_refund_outcome": "fail" in the refund request’s metadata to make the refund fail (refunds succeed by default).

Fixture tokens — server-side testing without the widget

For CI pipelines, server-side tests, and agents, you can skip the widget entirely: pass a fixture token as token_metadata.token when creating a payment method (sandbox keys only).

curl -X POST https://api.elasticpay.co/api/v1/payment_methods \
  -H "Authorization: Bearer pk_sandbox_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "card",
    "payment_method_data": {
      "token_metadata": {
        "type": "fixture",
        "token": "tok_sandbox_visa_succeed",
        "data": ""
      }
    }
  }'

Token	Brand	last4	Outcome when charged
tok_sandbox_visa_succeed	Visa	4242	Succeeds
tok_sandbox_visa_decline_insufficient_funds	Visa	0002	Declines — insufficient funds
tok_sandbox_visa_decline_card_lost	Visa	9987	Declines — card lost
tok_sandbox_visa_3ds_required	Visa	3155	Requires 3D Secure authentication
tok_sandbox_visa_timeout	Visa	0119	Fails — gateway timeout
tok_sandbox_mastercard_succeed	Mastercard	4444	Succeeds
tok_sandbox_amex_succeed	Amex	8431	Succeeds

The outcome travels with the saved payment method: every later charge against it resolves to that outcome, regardless of amount. That makes the declining tokens the right tool for testing recurring-billing failure handling — save a declining card, attach a payment plan, and advance a test clock to watch the dunning flow run.

Amount-based outcomes

When no metadata override or fixture outcome applies, the last two digits of the amount in cents select the outcome:

Amount ends in	Outcome
01	Declines — insufficient funds
02	Requires 3D Secure authentication
99	Fails — gateway timeout
anything else	Succeeds

For refunds, an amount ending in 03 fails; anything else succeeds.

Prefer _sandbox_outcome metadata or fixture tokens — they leave amounts free to carry realistic values, so a $19.99 subscription in a test stays $19.99. Watch for accidental triggers: a test amount of 1001 cents declines by design.

Outcome precedence

1. _sandbox_outcome in the payment intent’s metadata (per-charge override)
2. The saved payment method’s fixture outcome
3. Amount-based fallback
4. Default: succeed

Notes

Caution

Test card numbers only work with _sandbox_ keys. They will be rejected by live PSPs. Never use real card numbers in sandbox mode.

All test transactions use mocked PSP responses. Webhook events still fire normally in sandbox mode, giving you a realistic integration test environment.