Adquirentes e roteamento
O crpay fala com quatro adquirentes. Você cadastra as suas credenciais em cada uma que pretende usar, e integra uma única vez — o formato da requisição e da resposta é o mesmo independentemente de qual processa a cobrança.
| Adquirente | Credenciais necessárias |
|---|---|
| Cielo | merchantId, merchantKey |
| Rede | merchantKey (o token de integração, em base64) |
| Stone | secretKey |
| GetNet | username, password, merchantId, terminalId |
As credenciais são cadastradas pela equipe crpay no seu onboarding. Depois de gravadas não são recuperáveis — nem por nós. A consulta devolve apenas uma máscara com os últimos quatro caracteres.
Por que isso importa
Trocar de adquirente normalmente significa reescrever a integração: outro formato de requisição, outros códigos de erro, outro fluxo de estorno.
No crpay, é mudança de configuração. O seu código não muda.
Preferência por bandeira
Você pode definir qual adquirente processa cada bandeira. É comum ter taxas diferentes por bandeira em cada adquirente, e essa configuração deixa você aproveitar isso sem tocar no código:
visa → Cielo
mastercard → Rede
demais → Cielo
Ordem de fallback
Cada regra aceita mais de uma adquirente, em ordem de preferência:
visa → Cielo, depois Rede
A Cielo é tentada primeiro. A Rede só é tentada quando a Cielo comprova que não processou a transação — conexão recusada, DNS que não resolve, host inalcançável.
Quando a próxima adquirente NÃO é tentada
Esta parte é a que protege o seu cliente, e é deliberada:
| Situação | Tenta a próxima? | Por quê |
|---|---|---|
| Cartão recusado | Não | A outra adquirente recusaria igual. E a mesma compra tentada em várias adquirentes em sequência é o padrão que os antifraudes classificam como teste de cartão — isso queima a reputação do seu estabelecimento. |
| Sem resposta da adquirente | Não | Não se sabe se ela processou. Tentar a próxima cobraria o portador duas vezes. A cobrança fica em unknown e é resolvida pela conciliação. |
| Adquirente comprovadamente fora do ar | Sim | É o único caso em que há certeza de que a transação não foi criada. |
Ou seja: o fallback existe para indisponibilidade, não para insistir num cartão recusado.
Consultando a configuração
A adquirente que processou cada cobrança vem na resposta, junto das referências para conciliação com o extrato dela:
"acquirer": {
"name": "cielo",
"payment_id": "0f4e...",
"tid": "1006993069...",
"nsu": "674532",
"authorization_code": "123456"
}
E o histórico de tentativas fica em GET /v1/payments/{id}/events — é lá que se vê que uma
cobrança passou pela segunda adquirente porque a primeira estava fora do ar.
Diferenças que o crpay resolve para você
Cada adquirente tem particularidades que deixam de ser problema seu:
- Identificador da transação — a Cielo usa um
PaymentId, a Rede usatid, a Stone usa o id da cobrança, a GetNet usatransactionID. Você usa sempre oiddo crpay. - Formato do valor — algumas esperam centavos, outras reais com decimais, e a GetNet usa formatos diferentes entre cobrar e estornar. Você envia sempre inteiro em centavos.
- Códigos de erro — cada uma tem a sua tabela. Você recebe sempre o mesmo conjunto de códigos normalizados. Ver Erros.
- Estorno parcial — o suporte e o formato variam. No crpay é sempre
amountem centavos, com o saldo controlado do nosso lado.