Existem diversos modelos de marketplace, alguns permitem que o cliente possa fazer o checkout com vários produtos de vários vendedores diferentes (como um shopping). Outros, como a Apple Store ou Android Market, permite que vários vendedores exponham seus produtos e o cliente comprará uma aplicação de cada vez.

Para essa implementação usaremos a operação Pay da API Adaptive Payments para criar os pagamentos:

Existem 3 tipos de pagamentos possíveis: Simple, Parallel, and Chained.

1. Simple

Os pagamentos simples são aqueles feitos diretamente, do pagador para o recebedor. Essa é a forma tradicional em um e-commerce, temos uma loja e vendemos nossos próprios produtos, o cliente escolhe os produtos e faz o checkout.

2. Parallel

Os pagamentos paralelos são aqueles feitos, simultaneamente, para vários vendedores. É adequado em casos de shoppings, onde o cliente compra produtos de vários vendedores ou em empresas de turismo, onde um pacote envolve transporte aéreo, hospedagem, translado, etc.

3. Chained

Os pagamentos encadeados são aqueles feitos para um recebedor primário que distribui o pagamento para 1 ou mais recebedores. É adequado em casos de app store como Apple Store, Android Market e outros. Ao fazer o pagamento, o pagador fica sabendo da existência apenas do recebedor primário, ele não sabe quantos nem quais os valores que os recebedores secundários receberão naquela transação.

Como o objetivo desse tutorial é falar sobre marketplaces, vamos falar apenas dos pagamentos Parallel e Chained e como implementá-los.

Operação Pay

Para implementarmos um pagamento paralelo ou encadeado, utilizamos a operação Pay da API Adaptive Payments e enviamos os seguintes campos:

• actionType

  O campo actionType define o tipo de ação que será executada pela operação. Ele pode receber os seguintes valores:

  • PAY
  • CREATE
  • PAY_PRIMARY

• receiverList.receiver(0).email

  O campo receiverList.receiver(0).email define o email do recebedor

• receiverList.receiver(0).amount

  O campo receiverList.receiver(0).amount define o valor que o recebedor receberá.

• currencyCode

  O campo currencyCode define a moeda da transação.

• cancelUrl

  O campo cancelUrl define a URL de cancelamento.

• returnUrl

  O campo returnUrl define a URL de retorno.

• requestEnvelope.errorLanguage

  O campo requestEnvelope.errorLanguage define o idioma da mensagem de erro, mas somente en_US é aceito.

Independentemente do tipo do pagamento, todos os campos acima são obrigatórios. As diferenças começam quando vamos definir um pagamento paralelo ou encadeado.

Para o pagamento paralelo, basta que especifiquemos os vários recebedores, como abaixo:

Utilizando cURL, a requisição de um pagamento paralelo fica assim:

A resposta será:

responseEnvelope.timestamp=2012-01-26T07%3A01%3A36.552-08%3A00&responseEnvelope.ack=Success&responseEnvelope.correlationId=bb7dd4899585c&responseEnvelope.build=2486531&payKey=AP-0FV93927SY5646252&paymentExecStatus=CREATED

Como o responseEnvelope.ack retornou como Success, pegamos o payKey para direcionar o cliente à página de pagamentos do PayPal:

https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_ap-payment&paykey=AP-0FV93927SY5646252

O cliente verá a seguinte informação na tela de pagamento:

Como podemos ver na imagem, ao criar um pagamento paralelo, o cliente vê os dois recebedores na lista e os valores que cada um está recebendo.

Por outro lado, se fizermos a mesma requisição, porém definindo o recebedor primário:

O cliente verá a seguinte informação na tela de pagamento:

No histórico de transações do cliente, ele verá:

O Vendedor 1 (primário) verá a seguinte informação em seu histórico:

O Vendedor 2 verá a seguinte informação em seu histórico:

Nos próximos artigos vamos falar sobre a integração em linguagens específicas, o primeiro  será em C#.

Nota: Os códigos de exemplo são meramente ilustrativos, com o intuito de demonstrar a facilidade de integração com a API. Apesar de funcionarem segundo a proposta do tutorial, devem ser tratados como exemplos e não como código de produção.