API v5 - MIT/CIT Transações card-on-file [MasterCard]
Introdução
A Mastercard implementou novas diretrizes para categorizar transações 'Card-on-File' com o objetivo de melhorar a transparência e a segurança em transações eletrônicas.
Essas mudanças são obrigatórias e introduzem os campos CIT (Cardholder Initiated Transaction) e MIT (Merchant Initiated Transaction), que devem ser incluídos em suas integrações para evitar multas e garantir conformidade.
Esses campos estão relacionados a transações recorrentes e a transações com credenciais armazenadas, sendo divididos em dois tipos:
- CIT (Cardholder Initiated Transaction ou Transação Iniciada pelo Portador);
- MIT (Merchant Initiated Transaction ou Transação Iniciada pelo Estabelecimento).
A principal diferença entre as duas é que:
- Na CIT, a transação ocorre com a presença do comprador durante a transação, enquanto a MIT ocorre sem a presença do portador;
- Toda transação MIT é uma transação 'Credential on File', ou seja, realizada com credenciais armazenadas de interações anteriores. Já uma transação CIT pode ser realizada com base em credenciais fornecidas pelo portador no momento da transação;
- Transações CIT devem sempre conter o CVV, enquanto transações MIT não precisam.
Atenção
Caso o lojista não realize transações iniciadas pelo estabelecimento, não é necessário que os campos indicados sejam enviados.
Campos Obrigatórios
Para cumprir essas novas diretrizes, adicionamos dois campos opcionais à Criação de Pedido específicos para os métodos de pagamento com cartão de crédito e débito:
initiated_type: (String) é usado apenas em transação avulsa iniciada pelo estabelecimento, desde que o estabelecimento trabalhe com algum dos cenários abaixo:
partial_shipment: Remessa Parcial - Quando um pedido é enviado em múltiplas entregas, cada remessa parcial é tratada como uma transação independente.related_or_delayed_charge: Cobrança Atrasada - Utilizado para cobranças relacionadas a uma transação anterior, como taxas adicionais ou ajustes.no_show: Multa - Aplicado em casos onde o cliente não comparece ou não cumpre uma reserva, resultando em uma multa.retry: Retentativa - Quando uma tentativa de transação falha e é reprocessada.- Esses cenários são práticas comuns na indústria. Caso a transação não se enquadre em nenhum dos tipos acima, não existe a necessidade do envio do campo initiated_type.
Caso utilize recorrência externa ao Pagar.me:
recurrence_model: (String) é para identificar o modelo de recorrência, desde que o estabelecimento trabalhe com algum dos modelos abaixo:
standing_order: Ordem Permanente - Pagamentos recorrentes programados sem um número definido de parcelas, como contas mensais.installment: Parcelamento - Transações divididas em múltiplas parcelas com um número definido de pagamentos.- Caso o estabelecimento trabalhe apenas com recorrência comum, ou seja, assinatura com valor e frequência fixa - utilizado para cobranças periódicas com um valor fixo, como assinaturas de serviços - não é necessário realizar o envio do recurrence_model, desde que realize corretamente o envio do recurrence_cycle nos seus pedidos.
Recorrência Interna Pagar.me
Nos casos de lojistas que utilizam o motor de recorrência do Pagar.me, já realizamos a gestão de MIT/CIT de forma transparente. Portanto, não é necessário o envio dessas informações.
Exemplo de Request para Criação de Pedido:
curl --request POST \
--url https: //api.pagar.me/core/v5/orders \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--data '
{
"customer": {
"phones": {
"home_phone": {
"country_code": "55",
"area_code": "21",
"number": "000000000"
}
},
"name": "Tony Stark",
"email": "[email protected]",
"type": "individual",
"document": "03154435026",
"document_type": "cpf"
},
"items": [
{
"amount": 2990,
"description": "Chaveiro do Tesseract",
"quantity": 1,
"code": 123
}
],
"payments": [
{
"payment_method": "credit_card",
"credit_card": {
"installments": 1,
"statement_descriptor": "AVENGERS",
"card": {
"number": "4000000000000010",
"holder_name": "Tony Stark",
"exp_month": 1,
"exp_year": 25,
"cvv": "351"
},
"initiated_type": "string", // Novo campo
"recurrence_model": "string" // Novo campo
}
}
]
}
'
curl --request POST \
--url https: //api.pagar.me/core/v5/orders \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--data '
{
"customer": {
"name": "Tony Stark",
"email": "[email protected]",
"type": "individual",
"document": "03154435026",
"document_type": "cpf"
},
"items": [
{
"amount": 2990,
"description": "Chaveiro do Tesseract",
"quantity": 1,
"code": 123
}
],
"payments": [
{
"payment_method": "credit_card",
"credit_card": {
"installments": 1,
"statement_descriptor": "AVENGERS",
"card": {
"number": "4000000000000010",
"holder_name": "Tony Stark",
"exp_month": 1,
"exp_year": 25,
"cvv": "351"
},
"initiated_type": "string", // Novo campo
"recurrence_model": "string" // Novo campo
}
}
]
}
'
Importante
O prazo final para ajuste de sua integração é 31 de outubro de 2024
Funcionalidade por Adquirentes
Caso sua empresa utilize a Stone como adquirente, a integração já está preparada para receber e repassar essas informações.
Se utilizar outra adquirente, recomendamos verificar com a mesma se está pronta para o recebimento e repasse dos dados exigidos pela Mastercard e os prazos de adequação.
Conclusão
A adoção dos novos campos MIT/CIT é fundamental para garantir a conformidade com as exigências da Mastercard e para aproveitar os benefícios dos programas de incentivo oferecidos.
Em caso de dúvidas, entre em contato com nosso time de atendimento ao cliente pelo e-mail [email protected], pelo chat na sua dashboard ou pelo telefone 4004-1330.