O layout padrão da API PIX terá suporte ao Marketplace/Split de pagamentos?

[gregowbr]

Olá gostaria de saber se a API PIX padrão terá suporte ao Marketplace/Split de pagamentos? Se sim, quando mais ou menos será implementada e de que forma?

Seria muito interessante que tivesse isso, por que isso faria todas as API Pix adotarem esse importante recurso, visto que a maioria das empresas hoje trabalham com divisão de pagamentos (SPLIT) com seus revendedores/clientes

Ex: Recebe 50,00 do PIX, mas na API já deixa pré-informado (R$ 15,00 vai pra a chave X, R$ 12,00 vai pra a chave Y e R$ 33,00 vai para a chave Y)

Isso dividiria automaticamente os pagamentos sem a necessidade de receber todo o valor em sua conta corrente para depois fazer o repasse, levando futuramente até problemas com a receita federal.

Obrigado!

[rubenskuhl]

Isso já foi levantado em outro issue e o BACEN achou a idéia interessante, mas ela ainda não está na agenda evolutiva, então ela não tem prazo e nem compromisso de que um dia exista.

Notar que na fase 3 do OpenBanking já haverá API padronizada de pagamento, então será possível receber e repassar instantaneamente de forma padronizada os splits. E mesmo antes disso, vários PSPs já tem/terão APIs não padronizadas de pagamento que podem ser usadas para operacionalizar isso.

Já há precedentes que os intermediários de pagamento usaram ao longo dos anos para não serem responsáveis tributários apenas por receberem uma quantia. É esperado que um intermediário tenha fluxo sainte quase igual ao entrante, exceto comissões.

[gregowbr]

Eu fiz essa mesma pergunta para o e-mail oficial do PIX e recebi um email de volta informando que se encontra sim na agenda evolutiva com prazo de implementação para o primeiro semestre de 2021, como você pode ver em anexo.
Só estou questionando agora para ter um pouco mais de detalhes com os desenvolvedores do PIX

[rubenskuhl]

O responsável pelo Pix no BACEN é o DECEM e não o DEINF, e nenhuma apresentação do DECEM já citou o recurso de split. Que bom que alguma área no BACEN disse que isso está na agenda evolutiva e deu um prazo, e espero que isso seja seguido, mas por enquanto ainda não apareceu na API.

Uma coisa que é complicada de lidar no caso de split é consentimento; o correntista que fez o cadastro da cobrança, em geral o marketplace, precisa informar as chaves e quanto cada chave vai receber daquela cobrança. O PSP valida a chave contra a lista de chaves detidas por aquele correntista e aceita ou não aceita a cobrança; mas e as chaves destinatárias ?

[franciscotfmc]

O responsável pelo Pix no BACEN é o DECEM e não o DEINF, e nenhuma apresentação do DECEM já citou o recurso de split. Que bom que alguma área no BACEN disse que isso está na agenda evolutiva e deu um prazo, e espero que isso seja seguido, mas por enquanto ainda não apareceu na API.

Uma coisa que é complicada de lidar no caso de split é consentimento; o correntista que fez o cadastro da cobrança, em geral o marketplace, precisa informar as chaves e quanto cada chave vai receber daquela cobrança. O PSP valida a chave contra a lista de chaves detidas por aquele correntista e aceita ou não aceita a cobrança; mas e as chaves destinatárias ?

Esse é um ótimo questionamento. O PSP não tem o que fazer, seria confiar e aceitar as chaves.
A menos que se dê as ferramentas para que o próprio EC implemente o rateio do lado dele.

#brainstorm: funcionalidade de envio de Pix via API
Nesse sentido imagino até funcionalidades de cadastrar previamente as chaves que possam "receber splits".

[rubenskuhl]

Bom, assumindo que as chaves já estejam validadas, como fazer uma cobrança com split ? Poderiam ser três novos escopos: cobsplit, cobvsplit e lotecobvsplit, equivalentes a cada um dos escopos hoje existentes, ou alterações nesses 3 escopos que permitiriam que ao invés de chave pudesse ser um array chavesplit (excludente com o parâmetro chave), onde haveria cada uma das chaves e o valor que cada uma vai receber. Uma das chaves tem que ser do correntista fazendo a transação, ao menos enquanto o AuthCodeFlow não for implementado.

Notar que eu mencionei valor; há diferentes regras de split no mercado, algumas com percentagem, valor mínimo, valor máximo etc., mas caberia a quem criou a cobrança já fazer a conta das regras de negócio para que o PSP não tenha que fazê-lo e haverem potenciais diferenças entre PSPs como critérios de arredondamento.

Qual a preferência de outros em termos novos escopos ou possíveis novos parâmetros ?

[ivanseidel]

Alem dos problemas já citados, o controle posterior se torna cada vez mais complexo pois deve lidar com mais status que o normal.

Uma sugestão para o recurso, seria apenas manter a "trilha do split". por exemplo:

• Transação de A para B, gera Identificador X
• Transação de B para C ("split"), é acompanhado do identificador de X (como campo "origem") e gera identificador Y
• Transação de B para D ("split"), é acompanhado do identificador de X (como campo "origem") e gera identificador Z

Dessa forma, um segundo passo possível, seria poder gerar transações baseadas em outras automaticamente. Seria mais um tipo de transação, por exemplo:

• Opção de pagamento instantâneo (existente)
• Opção de pagamento com vencimento (existente)
• Opção de pagamento baseado em outro pagamento (inexistente, que poderia ser baseado no identificador X, para realizar automaticamente um split)

Assim a API não precisaria saber o conceito de "Split", mas sim a cadeia de transações que devem ocorrer, simplificando significativamente o processo como um todo sem adotar novas entidades.

Penso assim pois como cliente, ele deve receber uma nota fisca integral pelo que pagou, e seria muito improvável receber 3 notas fiscais por 3 empresas ou até mesmo pessoas físicas (?) distintas. No final, seria basicamente uma automação e um record tracking de onde veio aquele valor financeiro, para possível ressarcimento futuro ou outras ações do BC.

[renatofrota]

Gostei da ideia de "pagamento baseado em outro pagamento" e entendo que os PSPs até já tem possibilidade de ofertar isso com os endpoints atuais, ficando a cargo do controle de qual operação gerou a(s) operação(ões) descendentes (claro que a API padronizada poderia contemplar isso).

Mas só estou fazendo esse comentário para esclarecer que não existe essa relação de 1:1 entre pagamento e nota fiscal. Um mesmo pagamento pode, sim, ser coberto por N notas diferentes. O fluxo do dinheiro não reflete na necessidade (ou não) de se ter uma nota fiscal vinculada.

[franciscotfmc]

Isso dividiria automaticamente os pagamentos sem a necessidade de receber todo o valor em sua conta corrente para
depois fazer o repasse, levando futuramente até problemas com a receita federal.

Esse é um ponto que gera uma boa discussão. Pensando rapidamente, o mais saudável seria que o extrato recebesse o crédito do valor bruto. Depois disso, automaticamente entrariam os débitos dos repasses para um ou mais favorecidos.

Entendo que as questões tributárias podem ser superadas de outras formas. Provavelmente há meios de se justificar, contabilmente, de que o valor bruto não faz parte do faturamento da empresa, e sim apenas uma porcentagem daquilo.

Faz sentido @gregowbr ?

[rubenskuhl]

Isso dividiria automaticamente os pagamentos sem a necessidade de receber todo o valor em sua conta corrente para
depois fazer o repasse, levando futuramente até problemas com a receita federal.

Esse é um ponto que gera uma boa discussão. Pensando rapidamente, o mais saudável seria que o extrato recebesse o crédito do valor bruto. Depois disso, automaticamente entrariam os débitos dos repasses para um ou mais favorecidos.

Entendo que as questões tributárias podem ser superadas de outras formas. Provavelmente há meios de se justificar, contabilmente, de que o valor bruto não faz parte do faturamento da empresa, e sim apenas uma porcentagem daquilo.

O ponto é se isso caracteriza ou não intermediação de valores financeiros. Pq se caracterizar, isso precisa estar refletido como um CNAE da empresa, e entra na regra do BACEN de que a partir de x volume precisa ser instituição de pagamento autorizada.

Pelas discussões bizantinas que já tivemos com autoridades tributárias, que inclusive foram parar no STF, te digo que seria mais saudável que o split já acontecesse antes do extrato. O que talvez requeira que o titular que apareça no Pix seja o da instituição de pagamento.

[franciscotfmc]

O ponto é se isso caracteriza ou não intermediação de valores financeiros. Pq se caracterizar, isso precisa estar refletido como
um CNAE da empresa, e entra na regra do BACEN de que a partir de x volume precisa ser instituição de pagamento autorizada.

Bem pontuado.

Pelas discussões bizantinas que já tivemos com autoridades tributárias, que inclusive foram parar no STF, te digo que seria mais saudável que o split já acontecesse antes do extrato. O que talvez requeira que o titular que apareça no Pix seja o da instituição de pagamento.

Fazer os repasses acontecerem antes do extrato, parece ser o melhor caminho mesmo, porém, fere um pouco o fluxo ideal de liquidação de um Pix, que é sempre endereçado para uma conta transacional. Os envios também sempre partem de uma conta transacional. Tecnicamente, a PACS.008 trafega com a informação dessas contas de origem/destino.

Talvez esse seja um desafio que possa até refletir em atualizações da mensageria do Pix, quando o assunto for trabalhado pelo BC.

[rubenskuhl]

O ponto é se isso caracteriza ou não intermediação de valores financeiros. Pq se caracterizar, isso precisa estar refletido como
um CNAE da empresa, e entra na regra do BACEN de que a partir de x volume precisa ser instituição de pagamento autorizada.

Bem pontuado.

Pelas discussões bizantinas que já tivemos com autoridades tributárias, que inclusive foram parar no STF, te digo que seria mais saudável que o split já acontecesse antes do extrato. O que talvez requeira que o titular que apareça no Pix seja o da instituição de pagamento.

Fazer os repasses acontecerem antes do extrato, parece ser o melhor caminho mesmo, porém, fere um pouco o fluxo ideal de liquidação de um Pix, que é sempre endereçado para uma conta transacional.

Mas se a conta for da própria instituição de pagamento, no extrato da IP aparecem o crédito é os débitos.
Exemplo:
Pix para titular "Instituição de Pagamento Ltda." com PSP "Instituição de Pagamento Ltda." e infoPagador "Beneficiários efetivos são Marketplace Ltda. e Vendedor Fulano de Tal".

No extrato da conta de "Instituição de Pagamento Ltda." aparece:

• Crédito Pix E2EID Exxxxxxx
• Transferência (interna/TED/Pix) para "Marketplace Ltda." da margem do marketplace
• Transferência (interna/TED/Pix) para "Vendedor Fulano de Tal" do valor recebido

No extrato da conta de "Marketplace Ltda." aparece:

• Crédito relativo à margem de marketplace no txid tttttttttt

No extrato da conta de "Vendedor Fulano de Tal" aparece:

• Crédito relativo ao produto com txid tttttttttt

Os envios também sempre partem de uma conta transacional. Tecnicamente, a PACS.008 trafega com a informação dessas contas de origem/destino.

Talvez esse seja um desafio que possa até refletir em atualizações da mensageria do Pix, quando o assunto for trabalhado pelo BC.

Depende da necessidade de automação que demandem marketplace e vendedor...