Testing

The FTD stand-in processor

A sandbox MID can run the FTD processor, which decides by itself and calls no network:

A payment is approved only if it is the first deposit for that e-mail on that MID and the amount is under 50.00.
Otherwise it is declined (50-Declined when it is a first deposit over the limit, 02-Declined for a repeat).
It does not support refunds.

Use a fresh email for each approval test, and an amount of 50.00 or more to force a decline.

The World Acquiring sandbox

A sandbox MID on World Acquiring talks to the processor’s real test environment, so these cards behave as listed. Use expiry 12/2027 and CVC 212 with all of them, and send amounts with two decimals.

Card number	Flow	Result
`4000000000000002`	No 3-D Secure	Approved
`4000000000000010`	3-D Secure challenge	Approved
`4000000000000011`	3-D Secure challenge	Declined
`4000000000000003`	3-D Secure challenge	Approved with OTP `123456`, declined with any other OTP

A 3-D Secure card returns IN PROGRESS with a redirectUrl; see 3-D Secure.
Refunds in this sandbox are approved only for the amounts 2.33 and 6.66; any other amount is declined. Make the original payment 2.33 or 6.66 to see an approved refund.

The CyberSource sandbox

A sandbox MID on CyberSource talks to the processor’s real test environment. Every payment returns IN PROGRESS with a redirectUrl to the 3-D Secure page (see 3-D Secure), even when the shopper is not challenged. Use CVC 123 and an expiry of January three years from now (01/2029 in 2026) with all of them.

Card number	What the shopper sees	Result
`4111111111111111`	No challenge	Approved
`4000000000002503`	Challenge; the test bank page shows the code to enter (`1234`)	Approved
`4000000000002370`	Challenge that fails	Declined
`4000000000002925`	No challenge, authentication fails	Declined
`4000000000002537`	No challenge, authentication rejected	Declined
`4000000000002313`	No challenge, authentication unavailable	Declined (“3-D Secure authentication was not available.”)
`4000000000002990`	Authentication not available for the card	Declined (same message)

A payment whose 3-D Secure authentication failed or was unavailable is declined before any charge is attempted, and your postback arrives with DECLINED.
Refunds are accepted as PENDING: the call answers success: true, message: "PENDING" and the refund becomes REFUNDED a few minutes later (look it up or wait for the postback). A second refund of the same payment is refused until it settles.

Test checklist

Approved and declined payments update your order
IN PROGRESS with redirectUrl redirects the shopper
Your postback handler is idempotent and answers 2xx
A duplicate referenceCode is handled
A timeout on create leads to a lookup, not a second charge
A PENDING refund settles and you see it by lookup or postback
With the widget: an expired session (30 minutes) asks for a new one
The API key is read from the environment, not source