Você integrou Pix e funcionou. Agora quer cartão — e descobre que é outro SDK, outro formato de erro, outro webhook e outro modelo de status. Na prática, um segundo projeto inteiro, com o custo de manutenção dobrado para sempre a partir daí.
O que você ganha
Por que usar
Um único recurso payment cobre os dois métodos: o mesmo formato de identificador, o mesmo par status/sub_status, o mesmo webhook. Quem já integrou Pix não reaprende nada para ligar cartão.
Antes: um SDK por método, cada um com o seu jeito de dizer que deu errado. Depois: Pix e cartão são o mesmo recurso, com o mesmo identificador e o mesmo par status/sub_status. A ponte é o contrato unificado — quem já integrou um não reaprende nada para ligar o outro.
Recusa genérica faz o sistema tentar de novo o que nunca vai passar. Isso consome limite do portador, irrita o comprador e piora a sua reputação com o emissor. Com o motivo estruturado, você retenta o que vale e para o que não vale.
Cartão liquida no próprio ledger de settlement, em base separada do saldo Pix. A separação é estrutural, não convenção de nome de coluna: erro de um lado não corrompe o fechamento do outro.
Recursos
Autorização, captura, cancelamento e estorno — total ou parcial.
Cartão liquida no seu próprio ledger de settlement, isolado do saldo Pix. Duas contabilidades que não se contaminam.
Motivo de recusa devolvido de forma estruturada, para você distinguir o que vale retentar do que nunca vai passar.
A referência da API está publicada e aberta. Se preferir conversar antes, um especialista responde em até 2 horas úteis.
