Test value tables

Send one of these and the sandbox takes the matching path. Send anything else and it takes the ordinary one. These work in sandbox only. In production the same fields carry real data and the values below mean nothing.

​

Creating a business

The outcome follows from the business’s tax identifier — the ein you send when you create a sub-client.

​

Paying out

The outcome follows from the cents of the amount, whatever the whole part is — 10.03, 1250.03 and 7.03 all take the same path. .04 is the one that proves a refusal can arrive after the payment was accepted: the call answers as taken, and the payout turns FAILED seconds later. An integration that tells its customer the money is on its way at acceptance is the one this catches.

​

Depositing

The outcome follows from the amount you simulate. The amount is compared as a decimal, not as text, so 11, "11", 11.0 and "11.00" are the same value and all take the returned path. Simulate a deposit is the call. On a fiat account the deposit is complete on arrival; on a crypto one it settles first.

​

What these are not

They are not a mode you switch on, and there is no flag that makes the sandbox behave “normally” again — a value either matches one of the rows above or it does not. They are also not a substitute for handling the real thing. A rejection you forced is the same rejection your customer will meet; a rejection you never forced is a branch you have never run.