Checagens do Cartão

A etapa do cartão publica as suas linhas no mesmo array checks das checagens de identidade, com group: "payment_card". Elas são lidas exatamente como qualquer outra linha — veja Lendo checks[].

As Checagens

Checagem	O que decide	Status	Presente
`payment_card_scene_clear`	Nenhum telefone, monitor ou tela está visível em nenhum dos lados do cartão. Ela lê o quadro inteiro, então um display atrás do cartão também a dispara	`passed`, `failed`	Toda sessão com cartão
`payment_card_readable`	Um nome do titular foi lido do cartão, ou o cartão não traz nenhum. Um cartão sem nome impresso passa. Um nome impresso que não pôde ser lido falha, assim como um documento de identidade fotografado no lugar de um cartão	`passed`, `failed`, `not_evaluated`	Toda sessão com cartão
`payment_card_authentic`	Uma análise forense dos dois lados encontra um cartão físico genuíno, e não uma tela, uma impressão, uma fotocópia ou uma imagem alterada. `detail` nomeia o veredito de cada lado	`passed`, `failed`, `undetermined`, `not_evaluated`	Toda sessão com cartão, a menos que a Inyo tenha desativado a análise para o seu tenant
`payment_card_name_match`	O nome do titular corresponde ao nome no documento de identidade, pontuado contra o limiar de correspondência de nome da sua conta	`passed`, `failed`, `undetermined`	Quando um nome foi lido do cartão, ou o cartão não traz nenhum
`payment_card_token_match`	O cartão tokenizado é o fotografado, nas mãos da pessoa verificada — veja Correspondência do token	`passed`, `failed`, `undetermined`, `not_evaluated`	Sessões de tokenização que chegaram à etapa do token

Toda linha do cartão tem severidade high por padrão. Como qualquer severity, ela é configurável para a sua conta.

Linhas por modo de sessão

Modo	Linhas
Somente verificação (`capture`)	`payment_card_scene_clear`, `payment_card_readable`, `payment_card_authentic`, `payment_card_name_match`
Tokenização (`capture` + `tokenize`)	As mesmas quatro, mais `payment_card_token_match`

Uma sessão que nunca chegou à etapa do cartão — o titular parou antes, ou a sessão expirou — não traz linhas do cartão, e uma linha do cartão ausente não pesa em nada.

Lendo as Linhas

{ "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" }

Cada linha tem os seis campos que toda checagem tem: name, status, group, severity, reason, detail. Não há pontuação.

`reason`	Em	Significado
`payment_card_carries_no_name`	`payment_card_name_match`, `undetermined`	O cartão não imprime nome do titular, então não havia nada a comparar. Pesa como um achado adverso: um cartão sem nome não supera a comparação de nome
`no_identity_name`	`payment_card_name_match`, `undetermined`	Nenhum nome foi lido do documento de identidade. Esse custo já é carregado por `document_readable`
`review_inconclusive`, `review_incomplete`	`payment_card_authentic`, `undetermined`	Um lado não pôde ser julgado, ou não pôde ser analisado
`last_four_mismatch`	`payment_card_token_match`, `failed`	Os últimos quatro dígitos do cartão tokenizado diferem dos do cartão fotografado
`name_mismatch`	`payment_card_token_match`, `failed`	O nome confirmado não corresponde nem ao documento de identidade nem ao cartão
`card_unreadable`	`payment_card_token_match`, `undetermined`	O cartão fotografado não pôde ser comparado com o tokenizado
`provider_unavailable` e os outros motivos de provedor	Qualquer linha que possa ser `not_evaluated`	O serviço por trás da checagem não conseguiu responder — veja Resultados da Sessão

payment_card_token_match é a única linha do cartão que traz um reason em failed: ela falha de duas formas, e reason diz qual.

Nenhuma linha do cartão traz o número do cartão nem o nome do titular. detail tem redação fixa, e nada no resultado traz mais do número do que paymentCard.lastFour.

Correspondência do Token

payment_card_token_match compara o que foi tokenizado com o que foi fotografado. Ela roda assim que o widget entrega o token ao Inyo360, e faz duas comparações:

Comparado	Contra	Concorda quando
Os últimos quatro dígitos do cartão tokenizado, como o widget os informou	Os dígitos que ficaram visíveis nas fotos guardadas do cartão, lidos novamente de qualquer um dos lados	São os mesmos quatro dígitos em pelo menos um dos lados
O nome do titular que o titular confirmou	O nome no documento de identidade, e depois o nome lido do cartão	Corresponde a qualquer um dos dois, no limiar de correspondência de nome da sua conta

Qualquer uma das comparações discordando reprova a linha. Se nenhuma discorda, mas uma não pôde rodar — nenhum grupo de quatro dígitos legível em nenhuma das fotos, ou nenhum nome com que comparar —, ela fica undetermined com card_unreadable.

O Que uma Linha com Falha Faz

Duas linhas são checadas assim que os dois lados chegam, e uma falha manda o titular de volta para fotografar o cartão novamente:

Linha	O titular é informado
`payment_card_scene_clear` falha	Que a foto parece ser a imagem de uma tela, e que deve fotografar o cartão físico
`payment_card_readable` falha	Que o cartão não pôde ser lido, ou que parece ser um documento de identidade e não um cartão de pagamento

Cada nova foto custa uma tentativa do cartão. O cartão tem a sua própria cota, do mesmo tamanho da do documento e da selfie — veja Novas Tentativas de Captura. Esgotá-la termina a sessão como failed, como esgotar qualquer cota.

As outras linhas nunca mandam o titular de volta. Uma payment_card_authentic, payment_card_name_match ou payment_card_token_match com falha é pontuada com o restante da sessão: a sessão é concluída, a linha pesa contra o trustIndex e, sob decisionamento gerenciado, conta para a decision como qualquer outra linha. Uma sessão de tokenização mantém o seu bloco paymentCard seja o que for que essas linhas digam, então leia-as antes de cobrar o token.

Próximos Passos

Resultados — o bloco paymentCard
Tratamento de Dados — sobre o que as checagens são executadas
Resultados da Sessão — trustIndex, decision e as linhas de identidade