bacen / pix-api

API Pix: a API do Arranjo de Pagamentos Instantâneos Brasileiro, Pix, criado pelo Banco Central do Brasil.
https://bacen.github.io/pix-api
2.36k stars 266 forks source link

[Dúvida] Processo de OnBoarding/Adesão do PIX em empresas de Adquirência #141

Closed filipehcds closed 3 years ago

filipehcds commented 4 years ago

Olá pessoal, gostaria de tirar algumas dúvidas se possível:

Considerem que uma empresa Adquirente/Credenciadora (Proprietária da famosa maquininha POS) seja um PSP Direto, ela irá disponibilizar a opção de pagamento por PIX em seus terminais (Atualmente Débito/Crédito, nova opção de pagamento por PIX) para seus respectivos ECs (Estabelecimento Comercial). No cenário mais simples, que é o cenário onde o lojista/EC irá receber os valores das vendas PIX direto na conta transacional desse PSP, será somente necessário o PSP gerar um QrCode Estático ou Dinâmico no POS desse EC para ele conseguir receber seus pagamentos em sua conta transacional, até ai ok. Agora considerem um cenário um pouco mais complexo, onde esse EC informa que ele quer transacionar PIX no POS desse PSP, mas ele não quer receber os valores na conta desse PSP (Responsável pelo POS) e sim no Banco XPTO (Que também é um PSP), aparentemente existem 2 formas de resolver essa solicitação:

1º opção - Esse lojista receber todas as suas transações PIX na Conta Transacional do PSP portador do POS, e talvez 1x ou 3x ao dia, esse PSP realizar um PIX para o Banco XPTO na conta que o EC informou que gostaria de receber os valores, isso resolve em partes, pois ele não irá receber os valores realtime que é um dos beneficios do PIX. 2º opção - Seria do PSP portador do POS, se integrar com a API de Recebimentos PIX do Banco XPTO para geração das Cobranças em nome daquele EC/Lojista, dessa forma, ela trabalharia como "Integrador/Proxy/Van", pois iria imprimir um QrCode Dinâmico no POS do Lojista que não foi gerado por ela, e sim pelo Banco XPTO usando a API de Recebimentos.

1º pergunta - A 2º opção é possível e/ou faz sentido? 2º pergunta - Sendo a 2º opção possível, o EC/Lojista iria precisar fazer o OnBoarding PIX tanto no PSP portador do POS (Para habilitar o PIX no terminal), como no PSP Banco XPTO para que esse envie as credenciais (ClientId/ClientSecret/CertificadomTLS) para o PSP portador do POS gerar cobranças em nome daquele EC/lojista, esse entendimento está correto? Obs: O PSP Portador do POS também irá utilizar outras operações da API, como a de webhook e long polling para verificar se o pagamento foi finalizado para só então emitir o comprovante de pagamento no POS. 3º pergunta - Supondo que 1000 ECs/Lojistas queiram receber as transações PIX no Banco XPTO através do POS, o Banco XPTO deverá fornecer 1000 clientsIds/clientSecrets ao PSP portador do POS (1 clientId por EC/Lojista), esse entendimento está correto? O Banco XPTO deverá também fornecer 1000 certificados mTLS para o PSP portador do POS ou só será necessário 1 único certificado mTLS para a conexão entre os PSPs independente do número de clientes? 4º pergunta - Supondo que um EC/Lojista seja de médio/grande porte e possua seu processo automatizado com alguma empresa de TefHouse/SoftwareHouse, como se daria toda essa integração? A meu ver, seria necessário o PSP Banco XPTO emitir credenciais da API de Recebimentos PIX para o PSP portador do POS, e por sua vez o PSP portador do POS emitir credenciais para o EC/Lojista para que esse entregue as credenciais para a SoftwareHouse, dessa forma o SoftwareHouse consome a API de Recebimentos do PSP portador do POS e esse consome a API de Recebimentos do PSP Banco XPTO, está correto esse entendimento? 5º pergunta - Ao inves do PSP portador do POS disponibilizar as credenciais direto para o EC/Lojista, ele pode enviar as credenciais direto para o Integrador? Ou seja, para a SoftwareHouse? Pois não são todos os ECs/Lojistas que possuem conhecimento especializado em lidar com essas credenciais (Que são informações sensiveis), e existe um certo receio do Lojista por exemplo querer enviar essas credenciais por e-mail ou algo do gênero. 6º pergunta - Similar a pergunta de número 3, quando o PSP portador do POS for emitir as credenciais de um EC/lojista e enviar para a SoftwareHouse, ela terá que emitir 1 certificado mTLS por EC/Lojista ou somente 1 certificado mTLS representando a SoftwareHouse e não o EC/Lojista? 7º pergunta - Esse integração entre PSPs (PSP portador do POS e PSP Banco XPTO) precisa acontecer via API de Recebimentos PIX ou pode acontecer através de API/Canal próprio? Pergunto isso para talvez tentar simplificar as notificações de pagamento emitidas pelo PSP Banco XPTO para o PSP portador do POS.

ninrod commented 4 years ago

1º pergunta - A 2º opção é possível e/ou faz sentido?

A opção 1) também é viável: os recursos já estão com o recebedor e a operação de mandar o dinheiro para outra conta é uma questão meramente de organização interna dos recursos do recebedor em que a instantaneidade pode não ser tão relevante.

Dito isto, a opção 2) faz bastante sentido e o arranjo foi pensado para que este tipo de operação seja viável. Tem que ser viável.

2º pergunta - Sendo a 2º opção possível, o EC/Lojista iria precisar fazer o OnBoarding PIX tanto no PSP portador do POS (Para habilitar o PIX no terminal), como no PSP Banco XPTO para que esse envie as credenciais (ClientId/ClientSecret/CertificadomTLS) para o PSP portador do POS gerar cobranças em nome daquele EC/lojista, esse entendimento está correto? Obs: O PSP Portador do POS também irá utilizar outras operações da API, como a de webhook e long polling para verificar se o pagamento foi finalizado para só então emitir o comprovante de pagamento no POS.

Correto. Entendo que no seu exemplo o TEF/Gateway e o PSP que é dono do TEF/Gateway fazem parte do mesmo grupo econômico. O onboarding nessa linha está mais facilitado. Além disso, teria que ser realizado o onboarding, naturalmente, no PSP XPTO.

3º pergunta - Supondo que 1000 ECs/Lojistas queiram receber as transações PIX no Banco XPTO através do POS, o Banco XPTO deverá fornecer 1000 clientsIds/clientSecrets ao PSP portador do POS (1 clientId por EC/Lojista), esse entendimento está correto?

Cada EC realizará seu próprio onboarding. O PSP XPTO não entrega credenciais ao POS e sim ao EC, que é o resource owner (o POS não é o resource owner). O EC, se quiser, e confiar, entrega ao POS. Cada EC pode obter 1 ou mais client_ids, dependendo de sua infra (e.g., 1 para o POS, 1 para o ERP, etc...)

O Banco XPTO deverá também fornecer 1000 certificados mTLS para o PSP portador do POS ou só será necessário 1 único certificado mTLS para a conexão entre os PSPs independente do número de clientes?

Entendo que cada EC terá seu próprio túnel mTLS com seu PSP e que "compartilhar" túneis mTLS não está aderente à especificação. Mas para ter 100% de certeza, vou validar esta questão.

4º pergunta - Supondo que um EC/Lojista seja de médio/grande porte e possua seu processo automatizado com alguma empresa de TefHouse/SoftwareHouse, como se daria toda essa integração? A meu ver, seria necessário o PSP Banco XPTO emitir credenciais da API de Recebimentos PIX para o PSP portador do POS, e por sua vez o PSP portador do POS emitir credenciais para o EC/Lojista para que esse entregue as credenciais para a SoftwareHouse, dessa forma o SoftwareHouse consome a API de Recebimentos do PSP portador do POS e esse consome a API de Recebimentos do PSP Banco XPTO, está correto esse entendimento?

A questão que tem que ser observada é que para acessar a API deve-se obter um canal mTLS e obter também credenciais válidas. A partir daí, como especificamente se dará a integração dos diferentes ECs com seus PSPs, direta ou indiretamente, é um cenário que tem que analisado caso a caso.

5º pergunta - Ao inves do PSP portador do POS disponibilizar as credenciais direto para o EC/Lojista, ele pode enviar as credenciais direto para o Integrador? Ou seja, para a SoftwareHouse? Pois não são todos os ECs/Lojistas que possuem conhecimento especializado em lidar com essas credenciais (Que são informações sensiveis), e existe um certo receio do Lojista por exemplo querer enviar essas credenciais por e-mail ou algo do gênero.

As credenciais são emitidas para proveito do Resource Owner e estão sob a responsabilidade do Resource Owner. Agora, se o resource owner quiser delegar esta questão para a software house, e se o PSP concordar com isso, esta é uma prerrogativa do resource owner. Vale ressaltar que o BCB não estabeleceu regramento específico para o onboarding, então cada PSP implementará o onboarding da forma como achar mais seguro e eficiente.

6º pergunta - Similar a pergunta de número 3, quando o PSP portador do POS for emitir as credenciais de um EC/lojista e enviar para a SoftwareHouse, ela terá que emitir 1 certificado mTLS por EC/Lojista ou somente 1 certificado mTLS representando a SoftwareHouse e não o EC/Lojista?

Entendo que é 1 certificado mTLS por EC, mas validarei a resposta.

7º pergunta - Esse integração entre PSPs (PSP portador do POS e PSP Banco XPTO) precisa acontecer via API de Recebimentos PIX ou pode acontecer através de API/Canal próprio? Pergunto isso para talvez tentar simplificar as notificações de pagamento emitidas pelo PSP Banco XPTO para o PSP portador do POS.

Via API Pix.

filipehcds commented 3 years ago

Obrigado pelas informações @ninrod

Entendo que cada EC terá seu próprio túnel mTLS com seu PSP e que "compartilhar" túneis mTLS não está aderente à especificação. Mas para ter 100% de certeza, vou validar esta questão.

Entendo que é 1 certificado mTLS por EC, mas validarei a resposta.

Fico no aguardo dessa validação pois ela é muito importante pra gente.

Imagine o seguinte fluxo de integração: SoftwareHouse -> PSP dono do POS (Adquirente) -> PSP Banco XPTO

Agora imagine que a SoftwareHouse precise gerar cobranças para 100.000 ECs, para isso acontecer, será necessário que esses 100.000 ECs façam o Onboarding no PSP Banco XPTO (Onde eles possuem a conta responsável por receber as transações PIX) e depois enviem/repassem essas credenciais para o PSP dono do POS, depois disso, será necessário que esses 100.000 ECs realizem um segundo Onboarding no PSP dono do POS (Onde eles possuem uma maquininha POS para transacionar PIX) e depois enviem/repassem essas credencias para a SoftwareHouse.

Acredito que nesse cenário, tenha ficado claro que serão necessárias 200.000 credenciais de acesso (clientId/clientSecret) e porque 200.000? 100.000 emitidas pelo PSP Banco XPTO para uso no PSP Adquirente e 100.000 emitiadas pelo PSP Adquirente para uso na SoftwareHouse, certo? A pergunta é, será necessário também emitir 200.000 certificados mTLS ou somente 1 por integrador? Ou seja.. Comunicação entre a SoftwareHouse <-> PSP Adquirente utilizando apenas 1 certificado mTLS.. Comunicação entre o PSP Adquirente <-> PSP Banco XPTO utilizando apenas 1 certificado mTLS..

Porque veja, se 100.000 ECs fossem estabelecer conexões/integrações distintas com um PSP, com certeza faria sentido existirem 100.000 certificados mTLS, entretanto nesse caso as 100.000 integrações serão feitas pela mesma empresa/integrador, então dificultaria um pouco o processo se para cada conexão.. fosse necessário aplicar uma lógica de usar o certificado X, Y ou Z..

Não sei se consegui ser claro/objetivo na minha explicação mas me avise se precisar de mais insumos/informações.

rubenskuhl commented 3 years ago

Com Client Credential Flow, eu não vejo como ser diferente de ter 1 certificado por EC. Me parece que o caso de uso acima tem mais jeito do já proposto uso de Auth Code Flow, vide #83 .

filipehcds commented 3 years ago

Com Client Credential Flow, eu não vejo como ser diferente de ter 1 certificado por EC. Me parece que o caso de uso acima tem mais jeito do já proposto uso de Auth Code Flow, vide #83 .

Estou acompanhando bem de perto essa thread do Authorization Code Flow e espero que no futuro (curto prazo) a API comece a trabalhar com ambos os Grants (Client Credentials e Authorization Code) mesmo, dessa forma iria facilitar e muito essas integrações onde existem parceiros tecnologicos atuando em nome de um EC, isso sem contar do OpenBanking onde existe a necessidade de uma Third Party Provider (TPP) solicitar a concessão de um EC e/ou Cliente Final para efetuar um pagamento, gerar uma cobrança, verificar o status de um pagamento, etc..

Na minha visão o correto seria: Client Credentials Flow -> Sendo utilizado diretamente pelo EC/Lojista = 1 Credencial/Certificado para cada EC/Lojista Authorization Code Flow -> Sendo utilizado pelas SoftwareHouse/EmpresasDeAdquirencia/Conciliadoras/Etc.. = 1 Credencial/Certificado por Integradora, onde essa, pode gerenciar os dados de N ECs/Lojistas

ninrod commented 3 years ago

@filipehcds , o pessoal contribuiu com pontos bem interessantes nessa thread que você citou e faz sentido mesmo.

O OpenBanking vai abrir essa questão de qualquer maneira. Vamos ficar atentos para essa discussão.

filipehcds commented 3 years ago

@ninrod você pode só verificar essa última questão pra mim?

Entendo que cada EC terá seu próprio túnel mTLS com seu PSP e que "compartilhar" túneis mTLS não está aderente à especificação. Mas para ter 100% de certeza, vou validar esta questão.

Entendo que é 1 certificado mTLS por EC, mas validarei a resposta.

Porque precisamos dessa informação? Estamos em contato com vários Bancos e todos tiveram o entendimento de gerarem 1 unico certificado pra gente (PSP Adquirente) para gerarmos Cobranças em nome de vários ECs/Lojistas, várias empresas estão indo nessa linha de raciocinio, precisamos saber se essa linha será permitida pelo Bacen para iniciarmos as integrações.

ninrod commented 3 years ago

@filipehcds , tenho as respostas pra vocês.

1º pergunta - A 2º opção é possível e/ou faz sentido?

A opção 1) também é viável: os recursos já estão com o recebedor e a operação de mandar o dinheiro para outra conta é uma questão meramente de organização interna dos recursos do recebedor em que a instantaneidade pode não ser tão relevante.

@filipehcds, apenas complementando a minha resposta, embora a opção 1) seja tecnicamente viável de fato, recomendo cautela em chamar essa forma de operar de "Pix". Eu recomendo consultar o DECEM para verificar se essa forma de operar seria permitida e se for permitida, se realmente deveria-se chamar isto de "Pix" e não de "AdquirenteInstaPay".

Entendo que é 1 certificado mTLS por EC, mas validarei a resposta.

@filipehcds, no caso que você levantou nada impediria de ser utilizado 1 mTLS apenas.

Apenas confirmando o entendimento:

  1. Você está falando de um gateway que teria 200k clientes. 100k clientes teriam contas no PSP XPTO e 100k clientes teriam conta no PSP do próprio gateway.
  2. no total, este gateway teria que gerenciar 200k client_ids e, consequentemente, 200k access tokens.
  3. a comunicação "gateway" -> "api pix do PSP XPTO" utilizaria apenas um túnel mTLS e não 100k túneis mTLS.

Se este for o cenário, sim, pode ser assim, desde que o PSP XPTO concorde com isso.

filipehcds commented 3 years ago

@ninrod Obrigado novamente pelas respostas.

@filipehcds, apenas complementando a minha resposta, embora a opção 1) seja tecnicamente viável de fato, recomendo cautela em chamar essa forma de operar de "Pix". Eu recomendo consultar o DECEM para verificar se essa forma de operar seria permitida e se for permitida, se realmente deveria-se chamar isto de "Pix" e não de "AdquirenteInstaPay".

Exato, não vamos mais seguir com a abordagem 1 (De receber em nossa conta transacional e depois fazer N pix no final do dia para o domicilio bancário do EC) exatamente para não tirar um dos beneficios do PIX que é o recebimento em tempo real.

Apenas confirmando o entendimento:

Você está falando de um gateway que teria 200k clientes. 100k clientes teriam contas no PSP XPTO e 100k clientes teriam conta no PSP do próprio gateway. no total, este gateway teria que gerenciar 200k client_ids e, consequentemente, 200k access tokens. a comunicação "gateway" -> "api pix do PSP XPTO" utilizaria apenas um túnel mTLS e não 100k túneis mTLS. Se este for o cenário, sim, pode ser assim, desde que o PSP XPTO concorde com isso.

É quase isso, seria assim:

Para a integração fluir, será necessário:

E pra finalizar, referente a RFC 8705 (OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens) especificada em https://www.rfc-editor.org/rfc/rfc8705.html que o Bacen pediu que fosse seguido pelas participantes..

dmkamers commented 3 years ago

@filipehcds focando na opção 2, e o cenário que você descreveu, e dois certificados TLS (um para cada cliente da API, o banco XPTO e o Adquirente), parece tudo certo. Quanto ao processo de distribuição de credenciais entre o PSP servidor da API Pix e os respectivos clientes (ECs), este processo de onboarding especificamente não está especificado de forma detalhada. Fica a cargo do PSP servidor da API Pix em acordo com seus clientes. Podes resumir e reformular, se está tudo claro, ou resta dúvida específica?

filipehcds commented 3 years ago

Obrigado pelas informações @dmkamers , não resta mais nenhuma dúvida, estou encerrando a issue, obrigado novamente.