Data Handling
The card step handles the card in three places: the holder's device, the Inyo360 server, and, in tokenize mode, the payments gateway's tokenizer. This page says what each one receives and what is kept.
What Reaches Inyo360
The widget photographs the front of the card, then the back.
| Stage | What happens |
|---|---|
| On the device | Where the browser can run the card reader, the widget blacks out every digit of the card number except the last four, and the security code, before the photo is sent. A browser that cannot run it sends the photo as taken |
| On arrival | The photo reaches the Inyo360 server in memory. It is not written anywhere until the server has read it |
| On the server | The server reads every photo again, whatever the device did, with a reader that runs on Inyo360's own servers. It blacks out anything the device missed: every digit of the card number beyond the last four, the security code, and any other run of three or more digits on the card. One expiry date is kept |
| Before storage | Only the redacted photo is stored, and only the redacted photo is shown to any check |
It fails closed. A photo the server cannot read is refused, nothing of it is stored, and the holder is asked to take it again. A pair of photos in which the card number cannot be found on either side is not kept either, and the holder starts again from the front.
What Inyo360 Stores
Two redacted stills, one of each side. Each keeps the card face, the last four digits of the card number, the expiry date and the printed cardholder name. Every other digit of the number, and the security code, is blacked out.
On a tokenize session, a token record, written once per session:
| Field | Source |
|---|---|
| Token | The gateway's token, relayed by the widget |
| Kind | one_time or recurring, as the session asked for |
| Last four | The last four digits of the tokenized card, as the widget reported them |
| Expiry month | The month and year the holder confirmed |
| Holder name | The cardholder name the holder confirmed |
The last four are recorded as the widget reported them. Inyo360 does not take them from the gateway; it compares them with the digits left on the stored stills, and that comparison is the payment_card_token_match row.
The paymentCard result block carries only the token, its kind, the last four and when it was recorded. The expiry month and the holder name stay with Inyo360.
What Your Systems Never Receive
The card number and the security code. In tokenize mode the holder confirms the card's details on the widget's confirm screen. The number and the security code then go from the holder's browser to the gateway's tokenizer, and nowhere else.
What comes back to Inyo360 is the token, its kind, the last four, the expiry month and year, and the confirmed name. The Inyo360 token step has no field for the number or the security code, and refuses a request that carries anything it does not name.
What reaches you is the result: check rows, and on a tokenize session the paymentCard block. Neither carries more than the last four digits of the card number, and neither carries the card photos.
For the tokenizer's own handling of card data, see the gateway's Tokenizing Cards.
Next Steps
- Results — the
paymentCardblock and what is stored beside it - Checks — what each card check reads
- Widget Flow — the same path from the holder's side