Gateway de pagamento no seu software em 90 dias: indicar, integrar ou embutir?

Entre 2024 e 2025, o Pix passou de R$ 26,24 trilhões para R$ 35,36 trilhões movimentados, e de 63,5 bilhões para 79,8 bilhões de operações, segundo dados do Banco Central publicados pela Gazeta do Povo. No mesmo período, os pagamentos de pessoas físicas para empresas chegaram a 43% das transações Pix em 2025, quatro pontos acima de 2024, de acordo com o Relatório de Gestão do Pix resumido pelo The Shift.

Em novembro de 2025, a Resolução BCB nº 522, cujo texto está na LegisWeb, delimitou o papel do subcredenciador. Para quem vende ERP, isso encerra a fase em que o gateway de pagamento era problema só do cliente. A pergunta agora é qual modelo adotar e como integrar sem criar uma fila de chamados.

Esta matéria compara os três caminhos com critérios de corte, pensando no desenvolvedor que vai escrever a integração e em quem decide o modelo de negócio.

01 O dinheiro dos clientes já circula pelo seu ERP, com ou sem gateway de pagamento

O Pix é o principal meio de recebimento para quase seis em cada 10 donos de pequenos negócios, e 53% deles usam Pix para pagar fornecedores, contra 23% de boleto e 8% de cartão de crédito, segundo a pesquisa Hábitos Financeiros do Sebrae. O dado mede pequenos negócios; não descreve médias e grandes empresas, que podem ter outro perfil de carteira.

No cartão, as compras remotas somaram R$ 979,4 bilhões em 2024, alta de 17,9%, conforme a Abecs. O pagamento recorrente chegou a R$ 106 bilhões, 38,6% acima de 2023, segundo o InfoMoney. Recorrência é exatamente o que um ERP de assinaturas, escolas ou academias emite todo mês.

"O balanço do setor em 2024 reforça uma tendência de crescimento na indústria de meios eletrônicos de pagamento"

Giancarlo Greco, presidente da Abecs (Associação Brasileira das Empresas de Cartões de Crédito e Serviços) e CEO da Elo — Panorama Abecs

Uma simulação com premissas explícitas

Considere uma software house hipotética com 400 clientes ativos, cada um emitindo em média 300 cobranças por mês. Suponha que 25% deles adotem o gateway de pagamento embutido no primeiro ano e que o contrato com o parceiro preveja repasse de R$ 0,50 por cobrança paga, valor fictício usado só para a conta. Suponha ainda que todas as cobranças sejam pagas, o que não acontece na vida real.

Mude qualquer premissa e o número muda. Adoção de 10% derruba o resultado para R$ 6.000; inadimplência de 15% tira outros R$ 2.250 do cenário original. Não é previsão de ganho: é o formato da conta que você deve refazer com os dados da sua base.

Na prática: antes de escolher modelo, levante quantas cobranças sua base emite por mês e quanto disso é Pix, boleto e cartão. É esse volume que paga, ou não, a integração.

02 Indicar, integrar ou embutir: três modelos de gateway de pagamento com riscos diferentes

Indicar. Você recomenda um gateway de pagamento ao cliente e recebe comissão, se houver acordo. A integração fica com o cliente ou não acontece, e o financeiro continua dando baixa na mão. Custo de engenharia quase nulo, mas o pagamento segue fora do seu produto.

Integrar. Você constrói conectores com um ou mais provedores, e o cliente contrata direto com eles. A receita vem da mensalidade do módulo. O suporte da integração é seu; o da transação, do provedor. Cada conector novo multiplica a manutenção.

Embutir. O pagamento vira função nativa: a software house tem contrato com um parceiro, os clientes são habilitados por dentro do ERP e a receita pode incluir repasse por transação. Exige mais engenharia, mais suporte e contrato bem escrito.

Na prática: a diferença entre os modelos não é só receita; é quem atende o telefone quando um pagamento não baixa.

03 Embutir pagamentos muda o produto, o suporte e o comercial ao mesmo tempo

No produto: a cobrança tem estados, e o ERP precisa conhecê-los

Toda cobrança passa por estados: criada, pendente, paga, vencida, cancelada, estornada; no cartão, também autorizada, capturada e em chargeback. O erro mais comum é tratar a resposta síncrona da API como verdade final. Quem confirma o pagamento é o webhook do gateway de pagamento, e o sistema precisa recebê-lo fora de ordem, duplicado ou atrasado.

Esse último passo é o que transforma pagamento em conciliação de recebimentos sem planilha. A documentação da API para desenvolvedores da McpfPay é um ponto de partida para comparar como cada provedor trata eventos, reenvios e estados. Se o modelo prevê repasse automático entre partes, avalie também o split de pagamento já no desenho do banco de dados.

No suporte: o chamado muda de natureza

Com pagamento embutido, "o cliente pagou e não baixou" cai no seu helpdesk. Defina antes quem responde por quê: falha de processamento de webhook é sua; liquidação atrasada é do parceiro. Um log de eventos visível ao suporte nível 1 encurta esse atendimento.

No comercial: custo vira argumento, e precisa de número com origem

O vendedor vai ouvir "quanto custa". Parte do custo do cartão nem é do gateway de pagamento: a tarifa de intercâmbio média do crédito foi de 1,68% no 4º trimestre de 2024, ante 1,62% um ano antes, e as do débito e do pré-pago ficaram em 0,49% e 0,70%, segundo estatísticas do Banco Central publicadas pelo TI Inside. É um componente, não a taxa total que o lojista paga. Para valores da McpfPay, a referência é a página de preços e taxas da McpfPay.

Outro requisito comercial: o parcelado sem juros respondeu por 41% do valor pago no crédito em 2024, segundo o InfoMoney. Para quem vende produto de ticket alto, parcelamento é especificação do módulo, não detalhe.

Na prática: trate o webhook como fonte da verdade, a idempotência como obrigação e o log de eventos como ferramenta do suporte.

04 Para oferecer pagamento sem virar instituição financeira, o dinheiro não deve passar pela sua conta

A Resolução BCB nº 522, de 10/11/2025, define o subcredenciador como o participante que habilita o lojista a aceitar pagamentos, mas não participa da liquidação como credor perante o emissor, conforme o texto publicado na LegisWeb. Muitos gateways e subadquirentes ocupam esse papel. No desenho mais comum, a software house que embute pagamentos não o ocupa: quem habilita e liquida é o parceiro; o seu sistema orquestra.

Um roteiro de início que mantém a software house como orquestradora:

1. Escolha um parceiro que assuma cadastro e verificação dos clientes, liquidação e conta de destino dos valores.
2. Comece por Pix e boleto, que concentram o recebimento dos pequenos negócios segundo o Sebrae.
3. Pilote com um grupo pequeno de clientes, de segmentos diferentes.
4. Instrumente webhooks, deduplicação e reconciliação diária antes de escalar.
5. Formalize em contrato o modelo de receita e as responsabilidades de suporte de cada parte.
6. Só depois acrescente cartão parcelado e cobrança recorrente.

Na prática: seu sistema emite, acompanha e baixa; o parceiro regulado habilita e liquida. Mantenha essa fronteira por escrito.

05 Escolha do gateway de pagamento: qual modelo serve à sua software house

Escolha indicar se sua base tem poucas cobranças por cliente, o time de engenharia está comprometido com o roadmap principal e você não quer suporte financeiro no helpdesk.

Escolha integrar se seus clientes já têm provedores próprios, exigem liberdade de escolha e você consegue manter poucos conectores bem testados, cobrando o módulo à parte.

Escolha embutir se sua base emite volume recorrente relevante, a simulação com seus números fecha, você tem como manter webhooks, reconciliação e logs, e aceita ser a primeira linha de atendimento quando um pagamento não baixa.

Na prática: o volume de cobranças da base e a capacidade de sustentar suporte financeiro decidem o modelo, não a vontade de ter uma nova linha de receita.