Skip to main content
O POST /financial/checkout com payment_method: credit_card não aceita o número do cartão. Ele exige um card_code, gerado pelo Icarus, o serviço de tokenização de front-end da Ticto. O Icarus roda no browser do comprador: captura os dados do cartão, criptografa com o SDK da adquirente, grava o cartão tokenizado no core de pagamentos da Ticto e devolve apenas um código opaco. O PAN e o CVV nunca chegam ao seu backend, o que mantém sua integração fora do escopo PCI-DSS.
1

Carregue o script na sua página de checkout

Quando o script termina de inicializar, ele expõe window.Ticto e dispara o evento ticto:ready. Aguarde esse evento antes de chamar qualquer função.
2

Informe a origem Nexus

Isso faz o core de pagamentos vincular o comprador e o cartão ao seu cliente de API. Sem essa chamada o cartão é gravado com origem padrão e pode não ser encontrado no checkout.
3

Tokenize o cartão

Chame window.Ticto.encryptCard com os dados do cartão, do titular e do comprador, mais o offer_code da oferta que será cobrada. O código da oferta define quais adquirentes o produtor tem habilitadas.
4

Use o card_code no checkout

Em caso de sucesso o retorno é { code, customer_code }. Envie code como card_code no POST /financial/checkout. O customer_code pode substituir o objeto customer, já que o comprador foi criado durante a tokenização.

Parâmetros de encryptCard

Todos os campos de cartão devem ser enviados como string, inclusive número, mês, ano e CVV.
string
required
Nome impresso no cartão.
string
required
Número do cartão, só dígitos.
string
required
Mês de validade com dois dígitos. Ex.: "12".
string
required
Ano de validade. Ex.: "2030".
string
required
CVV.
string
required
Nome do titular.
string
E-mail do titular. Se omitido, o Icarus usa customerData.email.
object
required
{ type: "CPF" | "CNPJ", number: "<documento>" }.
object
required
Dados do comprador usados para criar o cliente no core de pagamentos: name, email, cpf, cnpj, type (person ou company) e is_foreign (boolean). Envie cpf ou cnpj e deixe o outro como string vazia.
string
required
Código da oferta que será cobrada. Alternativa: userCode com o code do produtor. Pelo menos um dos dois é obrigatório.

Retorno

string
Código do cartão tokenizado. É o card_code do checkout.
string
Código do comprador criado ou reaproveitado no core de pagamentos. Pode ser enviado como customer_code no checkout.
array
Presente apenas em falha. Lista de objetos { message }. Quando existe, code não vem.

Cartões de teste do tokenizador

No ambiente de testes o Icarus usa a adquirente em modo sandbox. Use titular APRO, validade futura, CVV 123 e um CPF válido algoritmicamente:
O script deve ser carregado diretamente do domínio da Ticto e executado no browser do comprador. Não faça proxy do script nem envie os dados do cartão para o seu servidor para chamar o Icarus de lá: isso quebra a premissa PCI-DSS da integração.
O checkout também aceita o campo card_token, um formato legado (JSON em base64 com tokens PagSeguro e MercadoPago gerados pelo próprio parceiro). Novas integrações devem usar card_code via Icarus.