Testing data

Sandbox runs on pk_test_ / sk_test_ keys and never touches real money. Which test cards work depends on the gateway behind your workspace — a Stripe card is rejected on an NMI workspace and vice versa.

Which gateway am I on?

Call GET /tokenization-key with a publishable key — the response carries processor_type. Then use the matching table below.

If Smart Routing is enabled, a single POST /charges can land on either gateway depending on the card BIN — the response processorType tells you where it went. See Charges.

Paysio (NMI) cards

Also covers the paysio white-label gateway. Use expiry 10/29 (any future date works) and CVV 999.

Paysio (NMI) ACH and outcome triggers

Save a bank account with type: "bank_account" on POST /customers/:id/payment-methods, then debit it with rail: "ach" on POST /charges.

On NMI the amount drives the outcome — the card number itself almost always approves:

Stripe cards

Any future expiry and any CVC (4 digits for Amex). Card number drives the outcome.

Stripe workspaces are card-only on Paysio — bank_account payment methods and rail: "ach" charges route through NMI or Debit & Payouts instead. For reference, Stripe's own ACH sandbox uses routing number 110000000 with account 000123456789 (success), 000222222227 (insufficient funds), 000111111113 (account closed), 000111111116 (no account), and 000333333335 (debit not authorized).

Debit & Payouts cards

Any future expiry and any CVC. Funds availability is what an POST /account-checks reports for a payout to that card.

Credit cards are accepted for charges but never for payouts: POST /account-checks returns ACCOUNT_NOT_ELIGIBLE and the saved method reports payout_eligible: false. Send a complete US billing address with every card — a card saved without a billing postal code cannot be paid out to later.

For ACH and RTP, use routing number (ABA) 021000021 with any 4–17 digit account number.

Payout failure triggers

Sandbox keys the payout outcome off the amount. Send one of these amounts (in cents) to POST /payouts and the matching failure arrives asynchronously on the payout.failed webhook with that error_code. Any other amount settles normally to payout.paid.

// Trigger a declined payout (M003)
POST /payouts
{
  "customer_id": "customer-uuid",
  "payment_method_id": "instrument-id",
  "amount": 53,
  "rail": "card"
}

// → 200 { "status": "pending", ... }
// → webhook payout.failed { "error_code": "M003", "error_message": "Declined" }

ACH debits return asynchronously with standard NACHA return codes — R01 insufficient funds, R02 account closed, R03 no account, R04 invalid account number, R07 authorization revoked, R08 payment stopped, R10 not authorized, R16 account frozen — delivered as payment.disputed with dispute_kind: "ach_return". RTP failures use ISO reason codes such as AC04 (account closed), AM04 (insufficient funds), and NOAT (account does not support this message type).

3-D Secure test cards

Paysio runs 3DS through its own authentication service, independent of the gateway that authorizes the charge, so 3DS has its own card set. These PANs pick the authentication outcome. Use any future expiry and any CVC.

Full flow and the fields to forward on the charge: 3D Secure.