O que vocΓͺ procura?Comunidade
Pegar o publicKey da conta pertencente ao aplicativo
Usando o método split de pagamento preciso dividir uma quantidade do valor recebido para a minha conta, desta forma no payload eu tenho que enviar o vendedor principal da transação primaryReceiver.publicKey e o secundario receiver[1].publicKey, isso esta claro.
A minha conta é a conta onde tem o aplicativo que vou fazer o processo de autorização para poder pegar a publicKey do primaryReceiver.
PorΓ©m, a receiver[1].publicKey Γ© a minha conta onde tem o aplicativo, a questΓ£o Γ© onde eu pego a minha publickKey.
Abri varios chamados junto o pagseguro referente a isso, e eles me passaram algumas informação que não ajudaram, então para esclarecer a dúvida vamos ao exemplo:
1Β° Conta minha
email minhaconta@gmail.com
contΓ©m o aplicativo
2Β° Conta do josΓ©
email josΓ©@gmail.com
A 1° Conta tem a aplicação, logo a 2° conta precisa autorizar a 1° conta.
ApΓ³s a 1Β° conta dar permissΓ£o, a 2Β° conta consegue fazer as requests e saber qual Γ© a publicKey da 2Β°conta.
Até aqui é bem bÑsico, agora vamos para a transação porque jÑ sei a publicKey da 2° conta.
Eu abro a transação normalmente onde quem é o responsavel pela transação é a 2° conta
desta forma insiro a publicKey dele no primaryReceiver
AtΓ© aqui tudo bem, apartir de agora preciso saber onde eu busco a publicKey da 1Β° Conta para inserir ela no receiver[1], lembrando que a 1Β° Γ© a mesma do aplicativo.
Onde eu busco essa informação ?
OlΓ‘, Ruan! Tudo bem?
No processo de split, o primaryReceiver sempre serÑ a conta associada a aplicação, portanto esse parÒmetro pode ser removido do payload.
Apenas os sellers devem ser declarados nos parΓ’metros receiver[n].publicKey.
Caso fique mais alguma dúvida, estou à disposição!
Certo, mais que inicia a transação é o meu cliente, conforme a documentação o primaryReceiver é o responsÑvel pela transação, ele pode fazer alteraçáes e incluindo o estorno que é importante no meu caso.
Neste caso se eu não informar o primaryReceiver, como padrão vai ser a aplicação, como ficaria o estorno e outros processos ?
Na documentação o primaryReceiver Γ© responsΓ‘vel pela transação, dessa forma que vocΓͺ me informou a aplicação no caso (eu) ficaria responsΓ‘vel pela transação, dessa forma meu cliente que serΓ‘ informado no receiver[n].publicKey. nΓ£o vai conseguir fazer os processos de estorno / cancelamento etc ...
Conforme a documentação:
O split de pagamento possibilita a divisΓ£o do valor de um determinado checkout entre diversos vendedores, podendo "splitar" tanto o valor lΓquido da transação quanto taxa, tarifa e taxa de parcelamento.
Em um split de pagamento, sempre existirΓ‘ o vendedor primΓ‘rio e vendedor(es) secundΓ‘rios(s)
Consideramos como vendedor primÑrio, aquele que serÑ responsÑvel pela transação, ou seja, o primÑrio quem aparecerÑ para comprador no momento do checkout, receberÑ as disputas e farÑ cancelamentos.
Os vendedores secundÑrios, receberão uma porcentagem do valor da transação e poderão ou não pagar uma porcentagem da taxa, tarifa e taxa de parcelamento.
Obs: Eu não quero me deixar responsÑvel pela transação, quero que meu cliente continue o responsÑvel pela transação, desta forma ela vai poder manipular a transação normal.
Basicamente a questΓ£o Γ© !
Somos uma plataforma, onde para cada pedido eu quero receber uma taxa da transação, não queremos ser sellers primÑrios nem secundarios nem responsÑvel pela transação.
Oi, Ruan! Tudo bem?
Pelo que estou entendendo, e pode me corrigir se eu estiver errada, no seu cenÑrio quem deveria ter a aplicação criada seria o seu lojista por ser o primÑrio da transação. Sempre o primÑrio é responsÑvel pela transação.
No split, para que vocΓͺ possa receber uma taxa da transação, vocΓͺ precisa participar dela ou como primΓ‘rio ou como secundΓ‘rio. No seu modelo de negΓ³cio, vocΓͺ deveria participar como secundΓ‘rio dessa transação.
Em um cenΓ‘rio de cancelamento, existem formas diferentes dele acontecer: todos podem ser penalizados por aquele cancelamento (inclusive o PagSeguro nos cenΓ‘rios de taxas reembolsΓ‘veis) proporcionalmente ou apenas um recebedor especΓfico.
Abraço!
Boa tarde, tem como ser feito o vendedor primario ser meu cliente, eu ter uma conta minha como aplicação e uma outra conta minha como vendedor, nesse cenÑrio :
1Β° conta Γ© do meu cliente
2Β° conta Γ© uma da minha empresa
3°conta é minha aplicação
eu enviar no primaryReceiver a 1° conta , no receiver[n].publicKey colocar a 2° conta, porém usar as chaves da aplicação que estão na 3° conta ?
Isso pode ser feito ou seria uma gambiarra ?
Lembrando que toda a transação fica de responsabilidade do meu cliente 1° conta, porém caso ele fizer um estorno ex: compra de 10 reais ficaria 9 reais para a 1° conta e apenas 1 real para a 2° conta.
se ele fizer um estorno, o ideal Γ© sair R$ 9 da 1Β° e R$ 1 da 2Β°, porΓ©m se a conta 1Β° nΓ£o tiver saldo como ficaria ? obs: ele tiraria da segunda ??
Além dessa ultima pergunta minha das 3 contas, gostaria de saber também se a conta da aplicação tem limite de contas autorizadas por ela ??
Oi, Ruan! Tudo bem?
Infelizmente ainda não temos essa funcionalidade de split disponibilizada para nossos clientes. Vamos considerar o seu cenÑrio como um feedback para nossas priorizaçáes. Obrigada por compartilhar sua dúvida conosco!
Nesse momento, apenas a regra que comentei com vocΓͺ anteriormente funciona, ou seja: o primΓ‘rio precisa ser o dono da aplicação.
Sobre a segunda pergunta, a conta da aplicação não um tem limite de contas autorizadas por ela.
Abraço.
ο»Ώ