The checkout problem that every merchant knows
There is a moment in online checkout that every merchant has learned to fear: redirection. The user is ready to pay, clicks to confirm — and suddenly leaves the merchant's environment, goes to the bank's website or app, authenticates, confirms, and returns. Every additional step is an opportunity for abandonment. Every context switch is friction that converts into a lost sale.
Pix solved part of this problem. With the QR Code, payment became faster and cheaper. But the typical flow still requires the user to copy the code, open their bank app, paste it, and confirm — or scan the QR on another device. It works. But it is not seamless.
The PISP (Payment Initiation Service Provider) — is the next level of this evolution. It is the infrastructure that allows Pix payments to happen within the merchant's customer journey, without redirection to the bank, without context switching, and without unnecessary friction. And it is measurably changing conversion rates.
This article explains what a PISP is, how it works in the context of Open Finance Brazil, who can be a payment initiator, how revenue models are structured — and why this topic is at the center of the next round of innovation in digital payments in Brazil.
📌 Content Context: This article is part of a series of contents about Pix Direto. If you are evaluating the complete infrastructure to participate in the Pix ecosystem — including direct participation in SPI, operating costs, and regulatory requirements — we recommend the main guide: Direct Pix: what it is, how it works, and when it is worth it.
O que é o ITP — Iniciador de Transação de Pagamento
O ITP é uma categoria regulatória criada pelo Banco Central dentro do framework do Open Finance Brasil. Em termos simples: é a instituição ou empresa autorizada a iniciar pagamentos em nome do cliente, sem que esse cliente precise ir até o banco para fazer isso.
Tecnicamente, o ITP não movimenta dinheiro — ele instrui o banco do pagador a fazê-lo. O ITP acessa, com consentimento explícito do usuário, a conta bancária do pagador via APIs do Open Finance, e envia a instrução de débito para que o banco processe e liquide o pagamento via SPI.
É uma separação de responsabilidades que não existia antes do Open Finance: a função de 'quem inicia o pagamento' foi desacoplada da função de 'quem detém a conta'. Isso abre um espaço competitivo inteiramente novo — onde fintechs, plataformas de e-commerce e empresas de tecnologia podem oferecer experiências de pagamento sem precisar ser um banco.
💡 Analogia útil: Pense no ITP como um procurador autorizado: o dono da conta deu permissão para que outra entidade (o ITP) instrua o banco a fazer um pagamento específico, em um valor específico, para um destinatário específico. O banco executa — mas a instrução veio do ITP, não do correntista diretamente.
ITP no Open Finance Brasil: como o framework habilita a iniciação
Open Finance Brasil is the regulatory system that defines the rules for sharing data and financial services between authorized institutions, with the customer's consent. The ITP operates within this framework — using Open Finance's standardized APIs to access accounts and initiate payments in an interoperable manner across different institutions.
The consent layer
Consent is the heart of the ITP model. Before any payment initiation, the user must explicitly authorize the ITP to access their account and initiate transactions on their behalf. This consent is granular — defining the value, recipient, and expiration date — and can be revoked by the user at any time.
From a product standpoint, the design of the consent journey is one of the main differentiators for conversion. Poorly explained consents or confusing authentication processes lead to abandonment at the most critical step of checkout. ITPs that master the consent UX have a real competitive advantage.
FAPI and initiation security
Open Finance Brasil requires ITPs to implement the FAPI (Financial-grade API) profile for authentication and authorization. FAPI is a security profile built on top of OAuth 2.0 and OpenID Connect, with additional security requirements specific to financial applications — including channel-bound tokens, asymmetric key pairs, and request integrity verification.
For engineering teams, correctly implementing FAPI is a non-negotiable requirement for ITP certification. Security implementation errors in this layer have direct regulatory consequences.
Interoperability between institutions
One of the most powerful aspects of the ITP model in Open Finance is interoperability: the ITP can initiate payments from accounts at any institution participating in Open Finance Brasil — not just those with which it has a direct contract. This means that a certified ITP can, in theory, serve payers from any bank or fintech in the country, using the same standardized technical flow.
🔗 Technical infrastructure: The payment initiated by the ITP is settled via SPI — the same settlement system that supports all Pix payments. To understand how the SPI, DICT, and PI Account work in this process, read the article SPI, DICT, and PI Account: the infrastructure behind Pix Direto explained.
ITP vs. Participante Direto do Pix: qual a diferença?
One of the most common confusions about the Pix ecosystem is treating PISP (ITP) and direct participant as equivalent or mutually exclusive concepts. They are not. They are different roles, with different requirements and different use cases — and an institution can be both at the same time.
Dimension | PISP (Initiator) | Pix Direct Participant |
|---|---|---|
Main function | Initiating Pix transactions on behalf of the payer | Settling Pix transactions in the SPI (Instant Payment System) |
Connection to SPI | Not mandatory — uses another participant's infrastructure | Mandatory — has its own PI Account in the SPI |
BC (Central Bank) Authorization | Yes — as a Payment Transaction Initiator (ITP/PISP) | Yes — as a Pix direct participant |
Settlement responsibility | No — settlement is the responsibility of the payer's direct participant | Yes — settles directly in the SPI |
Access to account data | Via Open Finance, with user consent | Via PI account and customer agreements |
Revenue model | Fee per initiated transaction (charged to the merchant/recipient) | Fee from indirect participants + operational savings |
Infrastructure required | Open Finance APIs + consent + strong authentication | SPI + DICT + RSFN + FRAUD + PI Account |
Implementation complexity | Moderate — less than the direct model | High — 12 to 24-month project |
Ideal for | E-commerce platforms, payment fintechs, marketplaces | Digital banks, large-scale fintechs, BaaS providers |
The most important practical distinction: being a PISP does not require being a Pix direct participant. The PISP instructs the payer's bank to make the payment — but whoever actually connects to the SPI and settles is the payer's bank (which must be a direct participant). The PISP operates at the initiation layer, not the settlement layer.
This significantly lowers the barrier to entry for companies that want to offer advanced payment experiences via Pix without needing to build the full infrastructure of direct participation in the SPI.
📊 For those who are deciding: If the goal is to create a superior checkout experience with Pix — with no redirection, high conversion — the way to go is PISP. If the goal is complete infrastructure autonomy, structural reduction of transactional costs, or becoming a BaaS platform, the path is direct participation. The articles Direct Pix vs. Indirect Pix and How to become a direct participant in Pix go deeper into this decision.
A jornada sem redirecionamento: o fluxo do ITP na prática
O que torna o ITP transformador para o checkout não é a tecnologia em si — é a experiência que ela viabiliza. A jornada sem redirecionamento é o que diferencia o modelo ITP do Pix via QR Code convencional.
Etapa | O que acontece |
|---|---|
Seleção do método de pagamento | Pagador seleciona 'Pix via Open Finance' ou equivalente no checkout do lojista. |
Consentimento do pagador | O ITP solicita consentimento do pagador para acessar sua conta e iniciar o pagamento. O pagador autoriza — sem sair da interface do lojista. |
Autenticação na instituição detentora | O pagador autentica na sua instituição financeira (banco do pagador) via deeplink ou redirecionamento mínimo. Este é o único ponto de contato com o banco do pagador. |
Iniciação da transação pelo ITP | O ITP envia a instrução de pagamento à instituição detentora da conta do pagador, via APIs do Open Finance Brasil. |
Processamento pelo banco do pagador | A instituição detentora debita a conta do pagador e envia a mensagem de débito ao SPI, liquidando na Conta PI da instituição recebedora. |
Confirmação ao ITP e ao lojista | O SPI confirma a liquidação. O ITP notifica o lojista em tempo real. O pagador vê a confirmação na interface do lojista. |
O que muda na experiência do usuário
No fluxo convencional com QR Code, o usuário faz entre 5 e 8 ações: copia o código, abre o app do banco, navega até a área de Pix, cola o código, confere os dados, confirma, volta para o site do lojista. Cada ação é uma oportunidade de distração, desistência ou erro.
No fluxo com ITP, após o consentimento inicial (que pode ser persistido para compras futuras), o usuário faz 2 a 3 ações: seleciona o método, autentica no banco via deeplink, confirma. O controle da jornada permanece, na maior parte do tempo, no ambiente do lojista.
Para plataformas mobile — onde a maioria das compras online acontece no Brasil — a diferença é ainda mais pronunciada. A troca de contexto entre apps é um dos maiores geradores de abandono no checkout mobile. O ITP reduz essa troca ao mínimo necessário.
Pix via ITP vs. cartão de crédito: a comparação que importa para o lojista
Para a maioria dos lojistas, a comparação relevante não é ITP vs. QR Code — é ITP vs. cartão de crédito. O cartão ainda domina o e-commerce brasileiro em volume, mas sua posição está sendo desafiada à medida que o Pix melhora a experiência de checkout.
Critério | Checkout tradicional (cartão / Pix QR redirecionado) | Checkout via ITP (sem redirecionamento) |
|---|---|---|
Etapas de redirecionamento | 2–3 (site → banco → site) | 0 — fluxo nativo na interface do lojista |
Autenticação do pagador | No ambiente do banco (saída da jornada) | Na interface do lojista, via deeplink ou QR nativo |
Taxa de abandono estimada | 15–35% (cada redirecionamento aumenta o abandono) | Redução de 30–60% vs. fluxo com redirecionamento |
Confirmação em tempo real | Depende do banco emissor | Sim — liquidação via SPI em segundos |
Experiência mobile | Fragmentada — troca de apps | Fluida — fluxo no mesmo app |
Custo para o lojista | Fee do gateway + fee da bandeira (cartão) | Fee do ITP — geralmente menor que cartão |
Chargeback / disputa | Possível (cartão de crédito) | Não aplicável — liquidação definitiva no SPI |
Dados disponíveis ao lojista | Limitados — dependem do gateway | Confirmação de pagamento + dados do pagador (com consentimento) |
O argumento do custo
A taxa de processamento de cartão de crédito no Brasil varia entre 1,5% e 3,5% por transação, dependendo do segmento, volume e negociação com a adquirente. O fee típico de um ITP fica entre 0,5% e 1,5% — representando uma economia de custo de processamento que, em grandes volumes, é significativa.
Para segmentos com ticket médio alto — como viagens, eletrônicos e serviços — essa diferença de custo pode representar dezenas de pontos base de margem por transação. Lojistas que processam R$ 10 milhões por mês com uma economia de 1 ponto percentual poupam R$ 100 mil mensais em custo de processamento.
O argumento da conversão
O argumento financeiro do ITP não é apenas custo — é conversão. Uma melhoria de 5 pontos percentuais na taxa de conversão do checkout em uma operação de R$ 10 milhões mensais vale muito mais do que a economia de fee. E os dados disponíveis de mercado apontam consistentemente para melhoras de conversão de 20% a 60% em comparação com fluxos que exigem múltiplos redirecionamentos.
O argumento do chargeback
O cartão de crédito permite chargeback — o cliente pode contestar uma cobrança e receber o valor de volta, às vezes sem o lojista ter chance de resposta efetiva. O Pix via ITP não tem chargeback: a liquidação é definitiva e irrevogável. Para setores com alta incidência de fraude de chargeback — como games, ingressos e serviços digitais — essa característica tem valor operacional e financeiro direto.
Quem pode ser ITP: requisitos e processo de autorização
Being an PISP is not just a technical decision — it is a regulatory decision. The Central Bank defines the eligibility criteria, the authorization process, and the ongoing compliance obligations for PISPs.
Requirement | Description | Status |
|---|---|---|
BC Authorization | The institution must be authorized by the Central Bank as a Payment Initiation Service Provider (PISP). A specific category within Open Finance Brazil. | Mandatory |
Open Finance Certification | Compliance with the technical standards of Open Finance Brazil, including APIs, security profiles, and interoperability certifications. | Mandatory |
Strong User Authentication | Implementation of multi-factor authentication for consent and payment initiation, in accordance with FAPI (Financial-grade API) standards. | Mandatory |
Consent Management | In-house system for collecting, storing, and revoking user consents, in compliance with LGPD and Open Finance regulation. | Mandatory |
Agreement with Account Holder | Contract with the institution holding the payer's account to enable initiation. In practice, interoperability via Open Finance. | Required to operate |
High-Availability Infrastructure | SLA appropriate for the volume of initiated transactions — does not require 99.5% like a direct Pix participant, but must be robust. | Regulatory |
Privacy Policy and LGPD | Proper processing of account and transaction data accessed via Open Finance, with a clear legal basis. | Mandatory |
The authorization process
Authorization as an PISP follows the standard Central Bank process for payment institutions: submission of a formal request, review of technical and organizational documentation, evaluation of operational capacity, and, if approved, authorization to begin operations.
The timeframe varies but is typically shorter than the direct Pix participation process — because the PISP does not need an Instant Payment Account (Conta PI) in the SPI nor the ISO 20022 messaging integrations. The mandatory technical scope is significantly smaller, which reduces the implementation timeline and cost.
PISP and Direct Participation: can they coexist?
Yes — and for many large-scale fintechs, this combination is the strongest strategic position. An institution that is a direct Pix participant and also an PISP has full control over the payment experience: it settles transactions directly in the SPI and can still offer redirection-less checkout to partner merchants. It is the position of greatest autonomy and highest monetization potential in the ecosystem.
🔗 Direct participation requirements: If the strategy involves combining PISP with direct Pix participation, the technical and regulatory requirements of the direct model are detailed in the article How to become a direct participant in Pix: technical and regulatory requirements.
Modelos de receita do ITP: como monetizar a posição de iniciador
A posição de ITP cria uma camada de valor nova no ecossistema de pagamentos — e com ela, múltiplos modelos de monetização. A escolha do modelo certo depende do perfil da base de lojistas, do volume de transações e da estratégia competitiva da empresa.
Modelo | Como funciona | Dinâmica | Ideal para |
|---|---|---|---|
Fee por transação iniciada | O ITP cobra um valor fixo ou percentual por transação bem-sucedida, pago pelo lojista/recebedor. | Modelo mais comum. Competitivo vs. taxa de cartão (tipicamente 0,5–1,5% vs. 1,5–3,5% do cartão). | E-commerce, marketplaces, grandes lojistas |
Mensalidade de acesso à plataforma | Lojistas pagam uma mensalidade para acessar a solução de checkout ITP, com volume de transações incluído ou ilimitado. | Previsibilidade de receita. Funciona bem para segmentos com volume médio constante. | SaaS de pagamento, plataformas de gestão |
Revenue share com adquirentes | O ITP distribui o fluxo de pagamentos e recebe uma parcela do fee de processamento. | Modelo de parceria. Menor margem por transação, mas menor custo de aquisição. | Fintechs com base de lojistas estabelecida |
Freemium com conversão | Acesso básico gratuito com cobrança a partir de determinado volume ou para features avançadas. | Funciona bem para captura de base de lojistas. Exige produto forte para conversão. | Startups de pagamento em crescimento |
Dados e analytics | O ITP oferece relatórios e insights transacionais premium para lojistas, como produto complementar pago. | Modelo emergente. Alta margem, mas exige maturidade de dados e consentimento explícito. | Plataformas com grande base de lojistas |
O ITP como produto de plataforma
Para fintechs e empresas de tecnologia financeira, o ITP não é apenas uma feature de checkout — é uma plataforma. Ao centralizar o fluxo de iniciação de pagamentos de múltiplos lojistas, o ITP acumula dados transacionais que viabilizam produtos complementares: analytics de comportamento de compra, scoring de crédito baseado em fluxo de pagamento, ofertas personalizadas no momento da compra.
Esse potencial de plataforma é o que diferencia ITPs que constroem posições competitivas duráveis daqueles que ficam presos na commodity de 'mais um gateway de Pix'.
Embedded Finance e ITP: o Pix nativo em plataformas não-financeiras
Um dos desenvolvimentos mais significativos habilitados pelo ITP é a integração nativa de pagamentos Pix em plataformas que não são, primariamente, financeiras — marketplaces, ERPs, plataformas de gestão de negócios, aplicativos de delivery, sistemas de agendamento.
O modelo de embedded finance com ITP funciona assim: a plataforma não-financeira (o marketplace, o ERP, o app de delivery) se torna um ITP — ou integra um ITP via white-label — e passa a oferecer pagamentos Pix como feature nativa, dentro da sua própria interface, sem redirecionar o usuário para outro ambiente.
Por que isso importa para plataformas
Para uma plataforma de marketplace, por exemplo, manter o usuário no ambiente próprio durante o pagamento reduz a fricção e aumenta a percepção de controle. Mais importante: permite que a plataforma veja e processe os dados da transação em tempo real, viabilizando confirmação instantânea de pedido, liberação automática de produto digital e conciliação sem dependência de terceiros.
O papel do ITP no split de pagamentos
Marketplaces e plataformas multi-vendor têm uma necessidade específica: dividir automaticamente o valor de uma transação entre múltiplos recebedores — a plataforma e os vendedores. O Pix via ITP é um caminho eficiente para implementar esse split, especialmente quando combinado com a infraestrutura de participação direta no SPI, que permite maior flexibilidade na definição das regras de divisão.
💡 Oportunidade de produto: O split de pagamentos via Pix é um dos casos de uso mais demandados por marketplaces e plataformas multi-vendor no Brasil — e ainda relativamente subatendido pelo mercado. ITPs que resolvem esse caso de uso com UX superior e custo competitivo têm um diferencial de produto claro.
O que vem depois: Pix Automático, recorrência e o próximo ciclo
O ITP como descrito neste artigo é a versão atual — iniciação de pagamento único, com consentimento por transação ou por período definido. Mas o ecossistema está evoluindo em direções que ampliam significativamente o escopo do que é possível.
Pix Automático e recorrência
O Pix Automático — a funcionalidade de débito recorrente via Pix — permite que o usuário autorize cobranças periódicas sem precisar confirmar cada transação individualmente. Para ITPs, isso abre o mercado de assinaturas, mensalidades e cobranças recorrentes — um segmento que hoje é dominado pelo cartão de crédito, mas que tem custo de processamento significativamente mais alto.
O Pix Automático, quando combinado com a jornada de consentimento do ITP no Open Finance, cria uma experiência de assinatura que pode ser iniciada no checkout, gerenciada pelo cliente e executada automaticamente — sem redirecionamentos e com custo de processamento menor que o cartão.
Tokenização e pagamentos por aproximação
A tokenização de contas bancárias — que permite pagamentos via NFC sem expor os dados da conta — é o próximo passo na convergência entre pagamentos presenciais e o ecossistema Open Finance. ITPs que investirem cedo em tokenização e pagamentos por aproximação via Pix estarão posicionados para capturar o mercado presencial à medida que essa infraestrutura amadurece.
Drex e o futuro do SPI
O Drex — o Real Digital — está sendo desenvolvido pelo Banco Central como uma infraestrutura de liquidação de próxima geração, baseada em tecnologia de registro distribuído. Embora ainda em fase de piloto e com prazo de adoção em aberto, ele representa uma evolução da mesma infraestrutura SPI que suporta o Pix hoje. ITPs e participantes diretos que entendem profundamente essa infraestrutura estarão melhor posicionados para migrar quando o Drex se tornar operacional.
Conclusão: o ITP como posição estratégica, não apenas feature
The Payment Transaction Initiator is not a niche product — it is an infrastructure layer being built at the heart of the Brazilian financial ecosystem. And, unlike many financial innovations that promise more than they deliver, the ITP already has real use cases, measurable conversion metrics, and revenue models that make economic sense.
For Product Managers and Analysts at fintechs, platforms, and e-commerce companies, the relevant question is not 'will the ITP matter?' — it is 'what is our position in this ecosystem, and are we building it far enough in advance?'
The strongest ITP positions will not be occupied by those who arrive after the market has consolidated. They will be taken by those who understand the Open Finance architecture today, build the best consent and checkout UX, and accumulate the transactional data that enables next-generation products.
🚀 Explore the complete cluster: This is just one of our articles on Pix Direto. The complete guide — from the ecosystem to technical infrastructure, from actual costs to product models — is available across five interconnected articles. Start at the main hub: Pix Direto: what it is, how it works, and when it is worth it.
