Widget Flow
The card step runs inside the hosted widget, after the selfie, in the same session. You deliver the same widgetUrl — see Widget Delivery — and write no capture code for the card.
What the Holder Sees
| Screen | Verification only | Tokenize |
|---|---|---|
| Intro | Why the card is asked for, and that the number is blacked out except its last four digits, with the security code, before a photo is saved | Same |
| Front | A card-shaped frame with live guidance — closer, further, flat, inside the frame. On a browser that cannot read the card live, the widget takes a photo instead | Same |
| Back | A prompt to turn the card over, then the same frame for the back | Same |
| Confirm | — | The card's details, read on the device, to check and confirm — see The confirm screen |
| Checking | "Checking your payment card" while Inyo360 finishes the card checks | Same |
| Done | The widget's closing screen, or your redirectUrl in redirect mode | Same |
When a photo shows a screen, or the card cannot be read, the holder is sent back to retake it with a message saying why — see What a failing row does.
The Confirm Screen
Tokenize mode only. The screen opens as soon as the back is sent, with the four fields the device read from the card: number, expiry date, cardholder name and security code.
| Element | Behaviour |
|---|---|
| A field read with confidence | Shown with a tick |
| A field the read was unsure of, or missed | Highlighted. The holder checks it against the card, corrects or fills it in, and taps Confirm on that field |
| Number and security code | Masked: the code entirely, the number except its last four digits. A highlighted one is shown so it can be checked, and Show all reveals both |
| Continue | Enabled once every field is filled in and valid: a valid card number, an expiry date that has not passed, a name, and a security code of three digits, or four on a card that prints four |
| Scan again | Back to the front of the card, with nothing read or typed kept. Offered while the session still accepts new card photos |
On Continue, the widget hands the number, expiry and security code to the gateway's tokenizer, then gives Inyo360 the token and the confirmed name.
The card's photos stay the session's until a new front is kept, so a Scan again the holder abandons leaves the first card in place. A session records one token: once it is recorded, the card cannot be scanned again.
Behind the Screens
The end-to-end sequence, from creating the session to charging the token, is on Payment Card Verification. What happens on the way:
- Each card photo is redacted on the holder's device where the browser can, then read and redacted again on the Inyo360 server — see Data Handling.
- The fields on the confirm screen are read on the holder's device; the Inyo360 server returns no card field to the widget.
- While the holder confirms, Inyo360 checks the scene and that the card is readable.
- Inyo360 receives the token with the last four, the expiry and the confirmed name, never the card number or the security code.
- The forensic review, the name match and the token match run after the token arrives, and the session then ends once, with one result.
In verification-only mode the flow stops after the card photos: there is no confirm screen and no tokenizer, and the result carries no paymentCard block.
Next Steps
- Data Handling — what each arrow carries, and what is kept
- Checks — the rows the card step adds
- Results — the
paymentCardblock