Adquirente, subcredenciador, gateway e PSP: entenda as diferenças e quem faz o quê em um pagamento

Quando uma compra com cartão é aprovada em poucos segundos, parece que existe apenas uma empresa “processando o pagamento”. Na prática, há uma cadeia com funções diferentes: alguém captura a intenção de compra, alguém transmite os dados, alguém habilita o estabelecimento, alguém se conecta ao arranjo, alguém emite o cartão, alguém decide pela autorização e, em seguida, diferentes participantes precisam registrar, compensar, liquidar, conciliar e eventualmente tratar estornos ou disputas. É justamente nessa cadeia que surgem termos como adquirente, credenciador, subcredenciador, gateway, PSP, bandeira e emissor.

Esses conceitos são frequentemente usados como se fossem sinônimos. Não são. A confusão é compreensível porque empresas do mercado costumam combinar mais de uma função dentro de uma mesma oferta comercial. Um fornecedor pode vender uma única integração e, por trás dela, reunir checkout, gateway, antifraude, credenciamento, conciliação e repasse. Para o lojista, tudo chega como “meu provedor de pagamento”. Para quem está desenhando arquitetura, negociando contrato, avaliando risco ou estruturando uma operação de maior porte, porém, saber qual papel cada participante exerce é fundamental.

Neste guia, vamos separar tecnologia de função regulatória e operacional, explicar a terminologia usada no Brasil e mostrar como essas camadas se relacionam em uma compra. O objetivo não é transformar o leitor em especialista jurídico, mas ajudá-lo a fazer perguntas melhores: quem habilita meu estabelecimento? Quem participa da liquidação? Quem apenas transmite mensagens? Quem decide se o cartão é aprovado? Quem guarda credenciais? Quem me deve o recebível? Quem responde por indisponibilidade, conciliação e suporte em cada etapa?

Comece pelo conceito de arranjo de pagamento

Antes de falar em adquirente ou gateway, vale entender o ambiente no qual eles operam. O Banco Central do Brasil descreve arranjo de pagamento como o conjunto de regras e procedimentos que disciplina a prestação de determinado serviço de pagamento ao público. Em cartões, o arranjo define regras de participação, segurança, liquidação, disputas e outras obrigações que permitem que diferentes empresas interoperem dentro de uma mesma lógica.

Uma bandeira de cartão é um exemplo de instituidor de arranjo. Ela estabelece regras para que emissores, credenciadores e demais participantes troquem mensagens e valores de maneira padronizada. Isso não significa que a bandeira seja quem concedeu o limite do cartão ao consumidor ou quem contratou diretamente o lojista. Ela organiza a rede e estabelece normas do ecossistema. O banco ou instituição que colocou o cartão nas mãos do cliente exerce outro papel: o de emissor.

O próprio Banco Central destaca que todos os envolvidos no pagamento precisam aderir e observar as regras aplicáveis ao arranjo em que participam. Na prática, isso cria uma cadeia de responsabilidades. Parte dos erros de interpretação nasce quando uma camada de software é tratada como se fosse, por definição, uma instituição que ocupa determinada posição formal no arranjo. A marca comercial e a interface que o lojista vê não bastam para concluir qual papel está sendo exercido em cada fluxo.

O que é um credenciador — ou adquirente?

No vocabulário brasileiro, “adquirente” é o termo de mercado tradicional para o que a regulação chama de credenciador. O Banco Central define credenciador como a instituição de pagamento que, sem gerenciar conta de pagamento, habilita estabelecimentos para aceitar determinado instrumento de pagamento e participa do processo de liquidação da transação como credor perante o emissor, de acordo com as regras do arranjo.

Essa parte “como credor perante o emissor” é uma diferença essencial. O credenciador não é apenas uma ponte de tecnologia. Ele ocupa uma posição própria na estrutura do arranjo e no fluxo financeiro. É comum que seja responsável pelo relacionamento de credenciamento, por requisitos operacionais específicos, por interfaces com o arranjo e por etapas de liquidação. Dependendo da arquitetura comercial, pode oferecer captura diretamente ou operar por meio de outros participantes e provedores.

Na prática, quando um e-commerce envia uma compra ao ecossistema de cartões, o credenciador é uma das entidades centrais no caminho até a rede da bandeira e o emissor. Mas isso não quer dizer que ele “aprova” a compra no sentido final. A decisão de autorizar ou recusar é normalmente do emissor, com base em regras, saldo ou limite, autenticação, risco e outros fatores. O credenciador encaminha e participa do processamento conforme o arranjo; o emissor responde pela autorização do instrumento que emitiu.

E o subcredenciador?

O Banco Central define subcredenciador como participante do arranjo que habilita usuário final recebedor para aceitar instrumento de pagamento, mas que não participa do processo de liquidação como credor perante o emissor. Essa definição é mais precisa do que a explicação simplificada de que um subcredenciador seria apenas “uma adquirente menor”. Ele exerce uma função própria dentro do modelo.

Em muitos negócios digitais, o subcredenciador funciona como facilitador de acesso ao ecossistema. Pode agregar estabelecimentos, simplificar onboarding e prover uma camada comercial, tecnológica e operacional para empresas que, de outra forma, precisariam manter relações mais fragmentadas. Por isso, no mercado brasileiro, também é comum ouvir “subadquirente”, embora a terminologia regulatória corrente use “subcredenciador”.

É importante acrescentar uma nuance regulatória: segundo as informações públicas do Banco Central, o subcredenciador não é uma modalidade de instituição de pagamento que dependa, por si só, de autorização do BC como um credenciador autorizado. Isso não significa ausência de regras. O subcredenciador participa do arranjo, deve observar direitos e deveres previstos em regulamentos e contratos aplicáveis, além de requisitos como controles internos, KYC e prevenção à lavagem de dinheiro conforme o contexto da operação. A análise concreta sempre depende das atividades efetivamente exercidas e da estrutura contratual.

Subcredenciador e marketplace são a mesma coisa?

Não. Esse é outro ponto que gera bastante confusão. Um marketplace pode, em determinado modelo, atuar também como subcredenciador, mas não se torna automaticamente um subcredenciador apenas por aproximar compradores e vendedores. O Banco Central esclarece que a caracterização depende da função desempenhada no fluxo de pagamentos.

Se uma plataforma apenas vende seu próprio produto ou serviço ao consumidor e depois remunera fornecedores de outra forma, a relação pode ser diferente de uma estrutura na qual a plataforma habilita recebedores, recebe e repassa valores de transações realizadas em favor desses recebedores. Em outras palavras, a natureza econômica e jurídica do fluxo importa mais do que o rótulo “marketplace”.

Para empresas de tecnologia, essa distinção tem impacto no desenho de produto. Uma funcionalidade de split, por exemplo, não deve ser tratada apenas como uma divisão matemática de valores. É necessário entender quem é o usuário final recebedor, quem está sendo habilitado, quem processa a transação, quem participa da liquidação e qual participante assume cada obrigação. Um desenho simples de interface pode esconder uma estrutura sofisticada por trás.

O que é um gateway de pagamento?

Gateway é uma função predominantemente tecnológica. Ele conecta o sistema no qual a venda nasce — e-commerce, aplicativo, ERP, marketplace, plataforma SaaS — aos serviços necessários para processar a transação. Recebe a intenção de pagamento, valida e organiza dados, encaminha mensagens, recebe respostas e devolve um resultado para a aplicação do cliente.

Em uma implementação moderna, o gateway costuma fazer muito mais do que “passar o cartão”. Pode oferecer API, checkout transparente, tokenização, cofres de credenciais, webhooks, normalização de respostas, logs, relatórios, roteamento entre provedores, mecanismos de idempotência e tratamento de falhas. Em algumas arquiteturas, também integra Pix, boleto, carteiras digitais e outros meios por uma interface comum.

A palavra importante é tecnologia. Ser gateway não transforma automaticamente uma empresa em credenciador ou subcredenciador. Da mesma forma, um credenciador pode oferecer um gateway próprio, e um PSP pode embutir uma função de gateway. A empresa contratante deve olhar para o escopo efetivo: quem presta a conectividade, quem habilita o lojista, quem liquida, quem movimenta recursos e quem assume obrigações previstas no arranjo.

O que significa PSP?

PSP é a sigla para Payment Service Provider, ou provedor de serviços de pagamento. Diferentemente de “credenciador”, que descreve uma função definida no ambiente regulatório brasileiro, PSP é um termo de mercado amplo. Dependendo do país, da empresa e do contexto, pode abranger combinações diferentes de tecnologia e serviços financeiros.

Um PSP pode oferecer uma integração única para múltiplos meios de pagamento, combinar gateway e checkout, integrar antifraude, oferecer ferramentas de conciliação, facilitar onboarding, conectar adquirentes e disponibilizar recursos para recorrência ou marketplaces. Alguns PSPs também exercem papéis regulados específicos; outros atuam principalmente como provedores tecnológicos. Por isso, a sigla não deve ser usada como atalho para inferir autorização, responsabilidade de liquidação ou enquadramento jurídico.

Ao avaliar um PSP, a pergunta correta não é “vocês são um PSP?”. É “quais atividades vocês realizam neste produto, quais são realizadas por parceiros e como cada parte aparece no contrato e no fluxo?”. Essa pergunta evita expectativas erradas sobre saldo, recebimento, chargeback, credenciamento, dados e suporte.

Onde entra o emissor?

O emissor é a instituição responsável por emitir o instrumento de pagamento ao usuário pagador. No cartão de crédito, é quem mantém a relação com o portador, estabelece limite, aplica políticas de risco e decide se determinada autorização será aprovada ou negada com base nos elementos disponíveis naquele momento.

Esse detalhe ajuda a desfazer um mito recorrente: o gateway ou o adquirente não consegue simplesmente “forçar” um emissor a aprovar uma compra. O ecossistema pode trabalhar para melhorar a qualidade da mensagem, utilizar tokenização, autenticação adequada, dados corretos, roteamento e tratamento inteligente de retentativas, mas a autorização final depende do emissor e das regras do arranjo.

Por isso, taxa de aprovação é um indicador coletivo. O resultado percebido pelo lojista pode ser influenciado por qualidade de dados, antifraude, configuração da integração, comportamento do consumidor, perfil da base, credenciais armazenadas, roteamento, tokenização, regras do adquirente e critérios do emissor. Culpar uma única camada sem separar os motivos de recusa costuma levar a soluções erradas.

E a bandeira?

A bandeira não é simplesmente “a empresa do cartão”. Ela institui e opera regras do arranjo, conecta participantes e define padrões para que uma credencial emitida por uma instituição possa ser aceita por estabelecimentos habilitados por outras. Visa e Mastercard são exemplos conhecidos, mas o conceito vale para diferentes arranjos.

No momento da compra, mensagens trafegam por essa rede para que o pedido de autorização chegue ao emissor e a resposta volte até o estabelecimento. Depois, as regras do arranjo também influenciam compensação, liquidação, disputas, monitoramento de risco, programas de integridade e requisitos técnicos.

Para o lojista, isso explica por que algumas regras não são “políticas inventadas pelo gateway”. Chargeback, autenticação, categorias de comércio, dados obrigatórios e programas de monitoramento podem derivar de regras dos arranjos e de participantes que precisam observá-las. O fornecedor deve explicar essas dependências com clareza, sem transformar a cadeia em uma caixa-preta.

Onde entra o antifraude?

Antifraude é outra camada que pode existir de forma independente ou integrada ao PSP. Seu papel é estimar risco antes ou durante o processamento e ajudar a decidir se determinada transação deve ser aprovada, revisada, autenticada, recusada ou encaminhada por uma política específica.

Para isso, sistemas de risco usam sinais como histórico do cliente, dispositivo, IP, velocidade de tentativas, divergências de cadastro, comportamento de navegação, valor, produto, geolocalização, relacionamento entre identidades e dados de transações anteriores. Soluções mais avançadas combinam regras com modelos estatísticos e aprendizado de máquina.

O cuidado é não confundir “antifraude aprovou” com “pagamento aprovado”. O antifraude pode considerar a compra aceitável, mas o emissor ainda pode recusá-la. O inverso também é verdadeiro: uma transação poderia ser autorizada pelo emissor, mas ser barrada por uma política interna do estabelecimento ou do provedor de risco. Por isso, os estados precisam ser separados na arquitetura e nos relatórios.

Uma transação completa, passo a passo

Imagine um cliente comprando em um e-commerce. Ele preenche o checkout e escolhe cartão. A aplicação cria o pedido e envia a intenção de pagamento ao gateway ou PSP. Se os dados sensíveis forem capturados por componentes seguros ou tokenizados, a aplicação pode trabalhar apenas com um token em vez de armazenar o número completo do cartão.

A camada de pagamento valida os parâmetros, aplica políticas técnicas e eventualmente consulta o antifraude. Depois, encaminha a autorização por uma rota elegível até o credenciador. O credenciador envia a mensagem ao arranjo, que a direciona ao emissor. O emissor avalia o pedido e devolve aprovação ou recusa. A resposta percorre o caminho inverso até o checkout.

Uma aprovação, porém, é apenas um estado. Dependendo do modelo, pode haver captura imediata ou posterior. Depois surgem agenda de recebíveis, liquidação, taxas, parcelamento, estorno, eventual antecipação e risco de disputa. Por isso, uma integração madura não deve enxergar o pagamento como uma única requisição HTTP, mas como um ciclo de vida.

Quem fica com o dinheiro?

Essa pergunta deveria aparecer em toda negociação de pagamentos. A resposta depende do modelo. Gateway, por definição tecnológica, não implica que o dinheiro transite por uma conta própria do provedor. Em outra arquitetura, um fornecedor que combina diferentes papéis pode participar de repasses ou manter relacionamento financeiro com o recebedor dentro da estrutura permitida.

O contrato deve deixar claro quem é o devedor do recebível em cada momento, qual participante realiza a liquidação, quais prazos se aplicam, como taxas são descontadas e o que ocorre em estornos, chargebacks, reservas ou antecipações. Relatórios comerciais simplificados não substituem essa compreensão.

Para o financeiro, o fluxo deve ser rastreável desde o pedido até o valor líquido recebido. Para jurídico e compliance, devem estar claros os papéis e parceiros. Para tecnologia, cada identificador precisa permitir correlacionar pedido, transação, autorização e liquidação. A mesma arquitetura precisa fazer sentido para essas três áreas.

Liquidação e recebíveis: por que a diferença importa

O Banco Central define recebíveis de arranjos de pagamento como direitos creditórios presentes ou futuros relacionados às obrigações de pagamento de credenciadores e subcredenciadores aos recebedores, no contexto aplicável. Em termos simples, são valores que o lojista tem a receber por vendas realizadas.

Isso mostra por que “processar” não é sinônimo de “liquidar”. Uma plataforma pode capturar e mostrar a compra no dashboard, enquanto outra entidade participa da liquidação. Para operações grandes, conhecer essa diferença é essencial para conciliação, cessão, antecipação, gestão de garantias e avaliação de risco de contraparte.

No Brasil, a infraestrutura de registro de recebíveis também adicionou uma camada importante de organização ao mercado. Para o lojista, o efeito prático é que a agenda de recebíveis pode ser objeto de operações financeiras e precisa estar consistente com vendas, cancelamentos, chargebacks e contratos. Um bom parceiro de pagamentos deve conseguir explicar como seus relatórios se conectam a esse ciclo.

Por que o termo “subadquirente” ainda aparece tanto?

O mercado brasileiro usou por muitos anos a expressão “subadquirente”, e ela continua bastante difundida em sites, contratos antigos, apresentações e conversas comerciais. O termo regulatório usado pelo Banco Central é “subcredenciador”. Em conteúdo educacional, vale reconhecer as duas expressões para que o leitor encontre o conceito que procura, mas utilizar a nomenclatura atual ao explicar o enquadramento.

Também é comum encontrar traduções de modelos estrangeiros, como payment facilitator, merchant acquirer, processor e merchant of record. Eles podem ter semelhanças funcionais, mas não devem ser transplantados automaticamente para o Brasil sem analisar regras locais. Um “PayFac” em uma apresentação internacional pode corresponder apenas parcialmente a um modelo brasileiro específico.

Essa cautela evita uma das maiores fontes de confusão em pagamentos: usar a mesma palavra para relações jurídicas diferentes ou palavras diferentes para funções semelhantes. O caminho mais seguro é descrever o fluxo antes de escolher o rótulo.

Um fornecedor pode exercer mais de uma função?

Sim. E é exatamente por isso que o mercado parece confuso. Uma empresa pode oferecer tecnologia de gateway e, em determinado produto, também atuar como participante comercial de outra camada ou integrar um credenciador parceiro. Outra pode ser um credenciador e oferecer sua própria API, checkout e antifraude. Um PSP pode montar uma experiência unificada sobre múltiplos parceiros.

Essa composição é positiva quando reduz complexidade para o cliente. O problema aparece quando a simplificação comercial impede entender responsabilidades. Um e-commerce de grande porte precisa saber quem recebe uma ocorrência de fraude, quem trata a indisponibilidade de uma rota, quem responde por um settlement divergente e qual entidade aparece como contraparte em cada documento.

A regra prática é separar “quem eu contrato na interface” de “quem exerce cada função no arranjo e no fluxo financeiro”. Um bom provedor consegue explicar ambos sem contradição.

Como comparar propostas de pagamento sem misturar papéis

Comece montando uma tabela de responsabilidades. Nas linhas, coloque captura, checkout, tokenização, antifraude, roteamento, credenciamento, autorização, liquidação, conciliação, antecipação, chargeback, suporte e compliance. Nas colunas, coloque os participantes. Em cada célula, marque quem executa, quem decide, quem é responsável contratualmente e quem fornece os dados.

Depois, desenhe o fluxo financeiro separado do fluxo de mensagens. No primeiro, mostre quem envia autorização para quem. No segundo, mostre quem deve valores, quando ocorre liquidação e quais descontos podem existir. É comum descobrir que os dois diagramas têm participantes semelhantes, mas relações diferentes.

Por fim, valide quais dependências são críticas. Se o fornecedor de gateway cair, o checkout para? Se uma adquirente ficar indisponível, existe outra rota? Se o antifraude demorar, a compra falha ou entra em revisão? Se um webhook não chegar, o sistema consegue consultar o estado? Essas perguntas transformam nomenclatura em arquitetura de negócio.

Qual modelo é melhor para um e-commerce?

Não existe resposta única. Uma pequena empresa pode preferir uma solução extremamente integrada, com onboarding simples e pouca operação interna. Um e-commerce médio pode buscar mais transparência e capacidade de conciliação. Uma plataforma com alto volume pode exigir multiadquirência, tokenização independente, regras por seller, observabilidade e contratos específicos.

A escolha deve considerar volume, ticket, recorrência, perfil de fraude, países, bandeiras, necessidade de split, velocidade de desenvolvimento, equipe financeira, tolerância a indisponibilidade e poder de negociação. Quanto maior a empresa, mais perigoso é selecionar apenas pela experiência inicial de integração.

Também vale separar o que é diferencial hoje do que será necessidade em dois anos. Migrar pagamentos em uma operação grande pode ser complexo. Se a arquitetura já nasce desacoplada, com IDs próprios, camada de abstração e dados conciliáveis, adicionar ou trocar parceiros se torna menos traumático.

O que perguntar antes de assinar um contrato

Pergunte diretamente qual entidade exercerá o credenciamento do seu estabelecimento e qual é o arranjo contratual envolvido. Pergunte se o fornecedor atua como gateway, subcredenciador, credenciador ou combinação dessas funções naquele produto específico. Não aceite apenas um organograma de marketing; peça explicação operacional.

Pergunte como ocorre liquidação, qual é a origem dos relatórios financeiros, quem trata divergências, qual o fluxo de chargeback e qual participante comunica eventos de risco. Entenda também como são armazenadas credenciais de cartão, qual o escopo PCI e se existe portabilidade de tokens em uma eventual migração.

No lado técnico, peça documentação de API, política de versionamento, idempotência, webhooks, SLA, histórico de incidentes e mecanismos de contingência. A qualidade da infraestrutura deve ser mensurável. No lado comercial, compare custo total e não apenas tarifa nominal.

O papel de uma camada de orquestração

À medida que a empresa conecta mais de um credenciador, antifraude ou meio de pagamento, cresce a necessidade de uma camada que padronize a complexidade. Payment orchestration é o nome dado a arquiteturas que centralizam integrações, regras, roteamento e observabilidade sobre diferentes provedores.

Essa camada pode decidir, por exemplo, que determinada bandeira só é elegível em um parceiro, que certo seller não está credenciado em outra rota ou que uma combinação de BIN, ticket e histórico apresenta melhor desempenho por um caminho específico. Também pode isolar falhas e simplificar a introdução de novos meios de pagamento.

Orquestração, entretanto, não muda automaticamente o papel jurídico dos participantes. Ela organiza tecnologia e decisão de rota. As obrigações de credenciamento, liquidação e arranjo continuam pertencendo às entidades que efetivamente exercem essas funções. Essa separação é saudável e deve aparecer na documentação.

Por que entender a cadeia melhora taxa de aprovação e operação

Quando o time não distingue as camadas, qualquer recusa vira “problema da adquirente” e qualquer inconsistência vira “problema do gateway”. Com uma taxonomia correta, é possível segmentar causas. Uma rejeição técnica pode ter surgido antes da autorização. Uma recusa pode ter vindo do emissor. Uma transação pode ter sido aprovada mas não capturada. Um repasse pode divergir por taxa, antecipação ou ajuste posterior.

Essa clareza melhora troubleshooting. Tecnologia sabe qual ID pesquisar. Risco identifica se a decisão veio do antifraude ou do emissor. Financeiro entende se está conciliando venda, captura ou liquidação. Atendimento consegue explicar ao consumidor se houve cobrança, reversão ou mera tentativa.

Em escala, essa organização não é burocracia: é performance operacional. Quanto menor o tempo necessário para localizar a origem de uma falha, menor o impacto financeiro e mais rápida a resposta ao cliente.

Conclusão

Adquirente, subcredenciador, gateway e PSP podem aparecer juntos na mesma jornada de compra, mas representam conceitos diferentes. Credenciador é uma função do arranjo de pagamentos ligada à habilitação de estabelecimentos e à participação na liquidação como credor perante o emissor. Subcredenciador habilita recebedores sem ocupar essa mesma posição perante o emissor. Gateway é uma camada tecnológica. PSP é um termo amplo de mercado que pode reunir várias dessas capacidades.

A melhor maneira de escolher um parceiro não é decorar siglas. É desenhar o fluxo. Quem recebe a requisição? Quem protege a credencial? Quem decide risco? Quem habilita o recebedor? Quem envia a autorização? Quem é a contraparte financeira? Quem liquida? Quem notifica um chargeback? Quem reconcilia? Quando essas respostas estão claras, arquitetura, contrato e operação começam a falar a mesma língua.

Para empresas em crescimento, essa clareza também abre espaço para estratégias mais sofisticadas: multiadquirência, roteamento, tokenização, observabilidade e conciliação centralizada. A infraestrutura de pagamentos deixa de ser uma caixa-preta e passa a ser tratada como parte do produto e da estratégia de receita.

FAQ

Adquirente e credenciador são a mesma coisa?

No mercado brasileiro, “adquirente” é a expressão tradicional para o papel que a regulação denomina credenciador. O credenciador habilita estabelecimentos e participa da liquidação da transação como credor perante o emissor, conforme as regras do arranjo.

Subadquirente e subcredenciador significam a mesma coisa?

“Subadquirente” continua sendo muito usado comercialmente, mas “subcredenciador” é a terminologia regulatória adotada pelo Banco Central para o participante que habilita recebedores sem participar da liquidação como credor perante o emissor.

Gateway de pagamento é uma instituição financeira?

Não necessariamente. Gateway descreve uma função tecnológica. O enquadramento jurídico de uma empresa depende das atividades que ela efetivamente executa, e não do uso da palavra gateway em sua marca ou produto.

Quem aprova uma compra no cartão?

A decisão final de autorização é normalmente do emissor do cartão, com base em limite ou saldo, risco, autenticação, regras e informações presentes na mensagem da transação.

Um PSP pode ser também subcredenciador?

Pode, dependendo do modelo. PSP é um termo amplo. É necessário verificar quais funções concretas a empresa desempenha no produto contratado e quais são executadas por parceiros.

A bandeira recebe o dinheiro do lojista?

A bandeira organiza o arranjo e a interoperabilidade entre participantes. O fluxo financeiro e as posições de credor/devedor dependem do papel dos emissores, credenciadores, subcredenciadores e demais participantes envolvidos.

Por que isso importa para o e-commerce?

Porque cada função afeta contratos, risco, conciliação, disponibilidade, custos e responsabilidades. Entender a cadeia facilita comparar fornecedores e resolver problemas operacionais.

Como a IOPAY pode ajudar

Pagamentos não deveriam ser uma caixa-preta. A IOPAY conecta tecnologia, APIs, checkout, observabilidade e diferentes capacidades de pagamentos em uma arquitetura pensada para empresas que precisam crescer com controle. Fale com nosso time e entenda como desenhar uma infraestrutura adequada ao seu modelo de negócio.

Referências

• Banco Central do Brasil — Diferença entre credenciadores e subcredenciadores: https://www.bcb.gov.br/meubc/faqs/p/qual-a-diferenca-entre-credenciadores-e-subcredenciadores
• Banco Central do Brasil — Instituições de pagamento: https://www.bcb.gov.br/estabilidadefinanceira/instituicaopagamento
• Banco Central do Brasil — Arranjos de pagamento: https://www.bcb.gov.br/estabilidadefinanceira/arranjospagamento/
• Banco Central do Brasil — Liquidação centralizada e subcredenciadores: https://www.bcb.gov.br/estabilidadefinanceira/faq-liquidacao-centralizada
• Banco Central do Brasil — Operação com recebíveis: https://www.bcb.gov.br/meubc/faqs/s/operacao-com-recebiveis
• Resolução BCB nº 150/2021, com alterações posteriores: https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?numero=150&tipo=Resolu%C3%A7%C3%A3o+BCB