Sandbox

Test mode lets you build and verify your entire 3-D Secure integration against a
sandbox that behaves like production — without touching a real card, issuer, or
Directory Server. You send and receive the same request and response shapes you'll use in production, but responses are pre-determined and instant, keyed off a small set of test cards.

✅
Going live is a config change, not a rewrite
The test endpoints mirror the production ones field-for-field. Once your
integration works in test mode, switching to production is just a matter of swapping your mTLS client certificate and your base paths (/test/v1/... → /api/v1/...). No payload changes.

Test vs. production endpoints

Test	Production	Purpose
`POST /test/v1/version`	`POST /api/v1/version`	Discover supported 3DS versions
`POST /test/v1/authenticate`	`POST /api/v1/authenticate`	Authenticate a cardholder
`POST /test/v1/result`	`POST /api/v1/result`	Retrieve the final result after a challenge

Each test endpoint accepts and returns exactly the same JSON as its production
counterpart. The only differences are the path prefix and that responses are
generated from the test cards below instead of a live issuer.

📘
Same auth model
Test endpoints still require mTLS and the X-Tenant-Id header, so you
exercise the real security handshake during integration. You'll swap the
certificate for your production one when you go live.

Test cards

The response you get from Authenticate is determined entirely by the card number (acctNumber) you send in your request. Different PANs are used to test different flows:

PAN	Outcome	What happens
`4200000000000002`	Frictionless success	Returns `transStatus: Y` with an `authenticationValue` and `eci`. Authentication completes with no challenge.
`4200000000000004`	Challenge required	Returns `transStatus: C` with an `acsURL`. Drive the browser challenge, then poll Result.
`4000000000002000`	Card not enrolled	Returns a `400` error indicating the card is not in a valid 3DS range.

All test cards use 3DS version 2.2.0.

Completing a challenge

When you use the challenge card (4200000000000004), the authenticate response includes an acsURL pointing at a sandbox ACS that stands in for the issuer's real ACS. Post the base64-encoded CReq there (see Challenge Request) to receive an HTML challenge form.

In test mode the challenge passcode is:

Entering 1234 produces a successful challenge. Result then returns transStatus: Y with the authentication value.
Any other passcode, or cancelling, produces a failed challenge. Result returns transStatus: N.

Typical integration runs

Version — call /test/v1/version with a test PAN to confirm version
discovery.
Frictionless — call /test/v1/authenticate with 4200000000000002 and
verify you read authenticationValue and eci correctly.
Challenge — call /test/v1/authenticate with 4200000000000004, drive the
challenge with passcode 1234, then call /test/v1/result and confirm the
final transStatus.
Error handling — call /test/v1/authenticate with 4000000000002000 and
confirm your error handling for an unenrolled card.

Once all four behave as expected, support will guide you through the creation of your production mTLS certificate and you can move your calls from /test/v1/... to /api/v1/....