Test mode

Test mode lets you exercise every branch of a payment’s lifecycle without moving real money. Authenticate with a sk_test_… key (see Authentication); test responses carry "livemode": false.

Triggering outcomes by amount

In test mode the outcome is driven by the last two digits of the amount (in minor units). This lets you deterministically reproduce declines and async states from a plain curl.

Amount ends in	Rail	Simulated outcome
05	Card	Decline — intent moves to failed (insufficient_funds)
15	ACH	Pending — intent rests in processing while it “settles”
anything else	Card / ACH	Approved / normal progression

For example, committing a card intent for 1005 yields a declined, failed intent; 1000 succeeds and becomes committed.

Declines are not errors

A decline is a normal business outcome, not an HTTP error. You’ll get a 200/201 with the intent in a failed state — not a 4xx/5xx. Inspect status to branch. Transport failures reaching the processor return 502 and are retryable.

Test and live data are separate

Test and live share the same code paths and object shapes, so anything you build against test keys behaves identically live. The only differences are that no money moves and no real bank/card network is contacted.

The data is genuinely partitioned, not just labelled. A sk_test_ key cannot read, list, or modify anything created with a sk_live_ key, and vice versa — attempting it returns 404, the same as any other nonexistent resource. Intent IDs do not collide across modes, so there is no risk of a test call touching live data by accident.