Conformidade e Fraude
Verificação de Cartão de Pagamento
Saiba que o cartão com que o seu cliente paga corresponde à identidade que ele acabou de comprovar. Logo após a checagem de identidade, o cliente fotografa o cartão de pagamento no mesmo widget. O Inyo360 checa se o cartão é real e traz o nome dele, e pode entregar a você um token do gateway para esse cartão, para que você nunca precise construir um formulário de cartão.
Lido no dispositivo
Os dados do cartão são lidos pela câmera no próprio celular do cliente. O cliente os confere em vez de digitá-los. Como o titular vê
Mascarado antes do armazenamento
O número do cartão, exceto os últimos quatro dígitos, e o código de segurança são tarjados antes que qualquer foto seja guardada. Tratamento de dados
Checagens do cartão e do titular
O cartão é checado quanto a ser um cartão físico genuíno, e o seu nome é comparado com o documento de identidade que o cliente acabou de apresentar. As checagens
Tokenização sem formulário
O cliente confirma os dados lidos do cartão, e o gateway de pagamentos o tokeniza. Você recebe o token. Primeiros passos







Como Funciona
A etapa do cartão roda dentro do widget hospedado de identidade, depois das etapas do documento e da selfie. Ela faz parte da mesma sessão, e o seu desfecho chega no mesmo resultado e no mesmo webhook. O diagrama mostra a verificação com tokenização; no modo somente verificação não há as etapas de tokenização (5 a 7), o webhook traz apenas as checagens do cartão, e não há token para cobrar (9 e 10).
sequenceDiagram
autonumber
participant Y as Seu Sistema
participant I as Inyo360
participant C as Cliente
participant G as Gateway de Pagamentos
Y->>I: POST /v1/sessions<br/>paymentCard.tokenize
I-->>Y: widgetUrl
Y->>C: entrega o widgetUrl
C->>I: documento, selfie,<br/>cartão frente / verso
Note over C: confirma os dados do cartão
C->>G: tokeniza o cartão
G-->>C: token
C->>I: token
Note over I: Executa as checagens<br/>do cartão
I-->>Y: webhook assinado:<br/>checks + paymentCard
Y->>G: POST /v2/payment<br/>cardTokenId: token
G-->>Y: AUTHORIZED, CHALLENGE<br/>ou DECLINED
Leia payment_card_token_match antes de cobrar: ela confirma que o token é do cartão que o cliente fotografou. O token vai em sender.paymentMethod.cardTokenId quando você autoriza um pagamento com cartão, e um CHALLENGE segue o fluxo de 3D Secure do gateway.
Duas Formas de Integrar
Escolha uma por sessão: você adiciona um objeto à requisição da sessão, e os dois modos rodam no mesmo widget e chegam no mesmo resultado.
| Modo | Como funciona | Escolha esta opção quando |
|---|---|---|
| Verificação | Envie "paymentCard": {"capture": true}. O cliente fotografa o cartão, frente e verso. Você recebe as linhas do cartão em checks: o cartão está em quadro, legível e genuíno, e o seu nome corresponde ao documento de identidade. | Você quer saber se o cartão é real e pertence à pessoa, e coleta os dados de pagamento do seu próprio jeito. |
| Verificação e tokenização | Envie "paymentCard": {"capture": true, "tokenize": {}}. O cliente também confirma os dados lidos do cartão, e o Gateway de Pagamentos o tokeniza. Você recebe as mesmas linhas, mais uma que checa o token contra o cartão fotografado, e um bloco paymentCard com o token. | Você cobra pelo Gateway de Pagamentos e quer um token sem construir um formulário de cartão. |
Comece pelos Primeiros Passos.
Próximos Passos
| Página | O que aborda |
|---|---|
| Primeiros Passos | Os dois modos, e o caminho da sessão até o token |
| Sessões de Cartão | O objeto paymentCard em POST /v1/sessions |
| Fluxo do Widget | O que o cliente vê, e a sequência por trás disso |
| Resultados | O bloco paymentCard no resultado |
| Checagens | As linhas do cartão em checks |
| Tratamento de Dados | O que chega ao Inyo360, o que é guardado e o que você nunca recebe |
| Sandbox e Dados de Teste | Testes com um cartão-modelo para imprimir |
