Sandbox & Test Data
The card step in sandbox is the production pipeline: real capture, real redaction, real checks. There is no reserved value that dictates a card outcome, so you test it by photographing a card.
Sandbox access, credentials and result delivery are the identity integration's β see the identity Sandbox & Test Data.
What to Scan
A physical card, held in front of the phone's camera. A card shown on another device's screen is what payment_card_scene_clear and payment_card_authentic exist to catch, so it is not a test of the card step.
You have two options:
| Card | Use it for |
|---|---|
| The printed specimen below | Running the whole flow, tokenizing included, without a real card |
| A card of your own | Checking how the checks read a genuine card |
A reserved identity document number from the identity sandbox ends the session at creation, so a session using one never reaches the card step. Use a real capture of your identity document when you test the card.
The Specimen Card
A front and a back of an invented card, shown small on purpose: print it and photograph the paper. A photo of a screen is what payment_card_scene_clear refuses.
Download to print: front Β· back
What to expect from it:
| Row | Expect |
|---|---|
payment_card_authentic | A printed specimen may read as not genuine. Use a card of your own to see this row pass |
payment_card_name_match | Fails: the specimen carries an invented name, which is not the name on your identity document |
payment_card_token_match | Can pass: tokenize the number as read β see below |
Token Match in Sandbox
In tokenize mode, payment_card_token_match passes only when the tokenized card agrees with the photographed one:
- The last four digits of the number you tokenize must be the last four left visible on the photographed card. Confirm the number as read on the confirm screen; changing it to a different card's number fails the row with
last_four_mismatch. - The confirmed name must match the name on your identity document or the name read from the card. The specimen's printed name passes this half, because it matches the card.
The full rule is on Checks.
The Gateway's Test Cards
The gateway's test card numbers govern what the gateway does with a token afterwards: approval, decline, 3D Secure challenge. They decide nothing in the card step, which reads only what it photographed.
The specimen prints one of the gateway's test card numbers, one without 3D Secure. A token from the specimen therefore behaves in the gateway's sandbox as that test card does.
When a Card Check Fails
The session still completes, unless the holder ran out of card attempts:
| What fails | Session | paymentCard block |
|---|---|---|
payment_card_scene_clear or payment_card_readable | The holder retakes the card. Out of card attempts, the session ends failed | Absent β no token was requested |
payment_card_authentic or payment_card_name_match | completed, the row charged against trustIndex | Present on a tokenize session |
payment_card_token_match | completed, the row charged against trustIndex | Present |
Next Steps
- Checks β what each card row decides
- Widget Flow β the confirm screen and Scan again
- Tokenizing Cards β using the token afterwards
