Card Checks
The card step publishes its rows in the same checks array as the identity checks, with group: "payment_card". They are read exactly as every other row — see Reading checks[].
The Checks
| Check | What it decides | Statuses | Present |
|---|---|---|---|
payment_card_scene_clear | No phone, monitor or screen is visible on either side of the card. It reads the whole frame, so a display behind the card trips it too | passed, failed | Every card session |
payment_card_readable | A cardholder name was read from the card, or the card carries none. A card with no printed name passes. A printed name that could not be read fails, and so does an identity document photographed in place of a card | passed, failed, not_evaluated | Every card session |
payment_card_authentic | A forensic review of both sides finds a genuine physical card, not a screen, a printout, a photocopy or an altered image. detail names each side's verdict | passed, failed, undetermined, not_evaluated | Every card session, unless Inyo has switched the review off for your tenant |
payment_card_name_match | The cardholder name matches the name on the identity document, scored against your account's name-match threshold | passed, failed, undetermined | When a name was read from the card, or the card carries none |
payment_card_token_match | The tokenized card is the photographed one, held by the person verified — see Token match | passed, failed, undetermined, not_evaluated | Tokenize sessions that reached the token step |
Every card row is high severity by default. Like any severity, it is configurable for your account.
Rows by session mode
| Mode | Rows |
|---|---|
Verification only (capture) | payment_card_scene_clear, payment_card_readable, payment_card_authentic, payment_card_name_match |
Tokenize (capture + tokenize) | The same four, plus payment_card_token_match |
A session that never reached the card step — the holder stopped earlier, or the session expired — carries no card rows, and an absent card row charges nothing.
Reading the Rows
{ "name": "payment_card_name_match", "status": "undetermined", "group": "payment_card", "severity": "high", "reason": "payment_card_carries_no_name", "detail": "this card carries no cardholder name to compare" }
Every row has the six fields every check has: name, status, group, severity, reason, detail. There is no score.
reason | On | Meaning |
|---|---|---|
payment_card_carries_no_name | payment_card_name_match, undetermined | The card prints no cardholder name, so there was nothing to compare. Charged as an adverse finding: a nameless card does not clear the name comparison |
no_identity_name | payment_card_name_match, undetermined | No name was read from the identity document. That cost is already carried by document_readable |
review_inconclusive, review_incomplete | payment_card_authentic, undetermined | A side could not be judged, or could not be reviewed |
last_four_mismatch | payment_card_token_match, failed | The tokenized card's last four differ from the photographed card's |
name_mismatch | payment_card_token_match, failed | The confirmed name matches neither the identity document nor the card |
card_unreadable | payment_card_token_match, undetermined | The photographed card could not be compared with the tokenized one |
provider_unavailable and the other provider reasons | Any row that can be not_evaluated | The service behind the check could not answer — see Session Results |
payment_card_token_match is the one card row that carries a reason on failed: it fails two ways, and reason says which.
No card row carries the card number or the cardholder name. detail is fixed wording, and nothing in the result carries more of the number than paymentCard.lastFour.
Token Match
payment_card_token_match compares what was tokenized with what was photographed. It runs once the widget hands Inyo360 the token, and makes two comparisons:
| Compared | Against | Agrees when |
|---|---|---|
| The last four digits of the tokenized card, as the widget reported them | The digits left visible on the stored card photos, read again from either side | They are the same four digits on at least one side |
| The cardholder name the holder confirmed | The name on the identity document, then the name read from the card | It matches either one, at your account's name-match threshold |
Either comparison disagreeing fails the row. Neither disagreeing, but one unable to run — no four digits readable on either photo, or no name to compare against — makes it undetermined with card_unreadable.
What a Failing Row Does
Two rows are checked as soon as both sides arrive, and a failure sends the holder back to retake the card:
| Row | The holder is told |
|---|---|
payment_card_scene_clear fails | The photo looks like a picture of a screen, and to photograph the physical card |
payment_card_readable fails | The card could not be read, or it looks like an identity document rather than a payment card |
Each retake costs one card attempt. The card has its own allowance, the same size as the document's and the selfie's — see Capture Retries. Exhausting it ends the session failed, as exhausting any allowance does.
The other rows never send the holder back. A failing payment_card_authentic, payment_card_name_match or payment_card_token_match is scored with the rest of the session: the session completes, the row is charged against trustIndex, and under managed decisioning it counts toward decision like any other row. A tokenize session keeps its paymentCard block whatever those rows say, so read them before you charge the token.
Next Steps
- Results — the
paymentCardblock - Data Handling — what the checks are run on
- Session Results —
trustIndex,decisionand the identity rows