Testing your integration

How the triggers work

Route a merchant to the sandbox processor, then provoke a case in one of two ways. Most cases key off the transaction amount: the cents pick the outcome, and the amount you send is otherwise ignored. The rest key off a value you already send anyway, such as the billing ZIP or the CVV.

When you need an outcome no amount produces, send a control field instead. Control fields go on the transaction as a custom field or an extra property, are matched without regard to case, and outrank the amount triggers. Every one of them is listed at the bottom of this page.

Nothing on this page reaches a card network or moves money, and none of it is available on a merchant routed to a live processor.

Start here: one guaranteed case each way

If you only wire up two tests per flow, wire up these. Each pair is guaranteed to succeed and to fail respectively, and neither depends on anything about the card you send.

Card authorization

The cents of the transaction amount select the outcome. These apply to Visa, Mastercard, Amex and Discover; a brand the sandbox does not recognise approves everything.

Partial approval and prepaid

Send a prepaid indicator of P (or a partial-authorization indicator of true) and the exact amount selects the outcome. This is how you exercise a partial approval, which is the case most integrations get wrong.

Prepaid balance responses

Send a prepaid indicator of B and the exact amount selects which balances come back, including negative ones.

ACH debits and returns

A transaction carrying check data runs on the ACH rail, where the cents of the amount select the NACHA return. An ACH return is reported as a decline with the return code and reason on the response.

Processor failover

The sandbox can report that it did not process a transaction at all, which is what makes the gateway attempt its one-shot authorization failover. Nothing is charged either way.

Address verification (AVS)

The billing ZIP selects the AVS response code. The code comes back on the transaction whatever your own AVS policy then does with it.

Cardholder verification (CVV)

The CVV selects the cardholder-verification response code. Any CVV without a trigger of its own comes back as a mismatch, so an arbitrary value is a usable negative case.

Response modifiers

These amounts do not change whether a transaction approves. They change the shape of the response, which is what you want when the thing you are testing is your parser.

Response latency

Send loopback.latencyProfile with one of these names and the sandbox takes a realistic amount of time to answer. Each delay is sampled from a log-normal distribution fitted to the profile's median and 95th percentile, then capped at its 99th, so repeated calls vary the way a real processor does rather than pausing for a fixed interval.

Send loopback.latencyMs instead when you want an exact delay, or custom as the profile name together with the three percentile fields to fit your own distribution.

Control fields

Every field the sandbox reads. Send either spelling, on a transaction custom field or an extra property. A control field outranks the amount triggers above.