Ofereça o meio de pagamento que encanta seus clientes

Integre o checkout preferido de quem mais consome na internet e crie uma experiência “WOW”!


Split de pagamento

A transação mais simples que pode ser gerada com as APIs da Wirecard possui um Pagador e um único Recebedor. Este é o padrão utilizado para as transações tradicionais no e-commerce.

A Wirecard permite que um pagamento realizado seja dividido (split) entre Contas Wirecard diferentes em tempo real. Este esquema viabiliza o uso da Wirecard como solução para Marketplaces/Plataformas por facilitar o pagamento da cadeia de envolvidos, permitindo o funcionamento de diversos modelos de negócios.

Os recebedores secundários (SECONDARY) não possuem relação com os compradores. Isto é, um comprador que realiza um pagamento, neste esquema, não “enxerga” o recebedor secundário na transação, nem a forma com que os pagamentos foram divididos entre as partes. Pode haver mais de um recebedor secundário por transação, mas apenas um recebedor primário (PRIMARY).

Abaixo um quadro comparativo com as características de cada papel assumido (recebedor Primário, secundário e comprador) em uma transação dividida.

Funcionalidade

Pagador

Recebedor Primário

Recebedor Secundário

Obrigatoriedade na transação

Sim

Sim

Não

Obrigatoriedade de Conta Wirecard

Não

Sim, conta de vendedor

Sim, conta de vendedor

Relacionamento comercial entre comprador e pagador

Sim

Sim

Não

Recebimento de e-mails

Não

Não

Não

Reembolsos

Pode solicitar

Pode realizar

Não realiza, mas tem saldo correspondente limitado

Reclamações e disputas

Pode abrir

Responde

Não responde, mas tem o saldo correspondente bloqueado/debitado

Contestações (chargebacks)

Pode abrir

Responde

Não responde, mas tem o saldo correspondente bloqueado/debitado

Relatórios transacionais

Visualiza apenas recebedor

Visualiza pagador e recebedores secundários

Visualiza pagador e recebedor primário

Tarifa Wirecard

Não paga

Paga por padrão

Paga se configurado

NF-e de serviços da Wirecard

Não recebe

Recebe por padrão

Recebe caso pague a tarifa Moip

Responsável Pelo Relacionamento Com o Comprador

Apesar do pagamento ser dividido em 2 (ou mais) partes, sempre uma delas, deve ser a parte responsável pela venda e pelo relacionamento com o consumidor final. Chamamos esta entidade de Recebedor primário. O tratamento de disputas, contestações e reembolsos, apenas pode ser realizado por ele. Da mesma forma, toda a comunicação recebida para o consumidor final, tais como e-mail e o nome na fatura do cartão, são identificados com os dados do recebedor primário. Plataformas de e-commerce e Marketplaces com a característica de “classificados” tendêm a optar por definir seus vendedores como Recebedores primários. Ao contrário, Marketplaces que queiram gerenciar o relacionamento com o consumidor, definem os vendedores como recebedores secundários tornando-os “fornecedores” dos produtos/serviços.

Para definir o seu usuário vendedor como “Recebedor primário” basta que você utilize o token Oauth dele para criar o pedido. Desta forma o seu usuário será o resource owner do pedido que foi criado. Para tornar o Marketplace o Recebedor primário, utilize o token do Marketplace na criação do pedido.

Fluxo do Split de Pagamento

Valor a Ser Dividido

As regras de divisão são configuradas por pedido. A divisão pode ser feita: 1) por meio de um valor percentual de 0 a 100% (exemplo: 20%) ou 2) por meio de um valor fixo (exemplo: R$5,00).

Responsável Pela Tarifa De Processamento De Pagamento Da Wirecard

A tarifa da Wirecard pode ser paga pelo responsável do negócio, ou uma das partes envolvidas no pagamento. Esta também é uma definição que varia de acordo com o modelo de negócios do Marketplace. Por padrão o Recebedor primário é o responsável pelo pagamento das tarifas. Para alterar esta configuração basta incluir a informação no JSON adicionando a flag feePayor como true no objeto receiver que será o pagador da taxa.

Updated 2 years ago

Split de pagamento


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.