What is Paypal Adaptive? | orderingonlinesystemhq

What is Paypal Adaptive?

Adaptive Payments Actors and Objects

Adaptive payments handles payments between a sender of a payment and one or more receivers of the payment. You are an application owner, such as a merchant that owns a website, the owner of a widget on a social networking site, the provider of a payment application on mobile phones, and so on. Your application is the caller of Adaptive Payments API operations.

Note: The application owner must have a PayPal Business account. Senders and receivers can have any PayPal account type. Senders and receivers are not required to have PayPal accounts initially. PayPal prompts a sender to create an account before a payment can be completed. A receiver must create an account to receive the funds after the payment completes.

With many applications, you may be both the application owner and a receiver. For example, as the owner of a website, you are the receiver of payments from the senders who are your customers. The following diagram shows the relationship between a sender, you as a receiver, and PayPal:


You are not required to be a receiver. For example, if you own a shopping cart, you are not required to receive payments directly. You can facilitate payments between the sender and receivers that provide the actual goods. The following diagram shows the relationship between a sender, you as an application owner that directs payments to receivers, and PayPal:


This diagram shows a payment in which the sender pays multiple receivers in a parallel payment. With parallel payments, the sender can see the transaction to each receiver.

The following diagram shows the relationship between a sender, you as an application owner that directs payments to receivers, and PayPal in a chained payment:


In a chained payment, the sender pays the primary receiver an amount, from which the primary receiver pays secondary receivers. The sender only knows about the primary receiver, not the secondary receivers. The secondary receivers only know about the primary receiver, not the sender.

The following diagram shows the relationship between you as both the sender and the application owner that directs payments to receivers:


For example, you might use this configuration in a sales commission application that transfers funds owed for commissions from your account to the accounts of your sales force.

Simple, Parallel, and Chained Payments

Adaptive Payments provides several kinds of payment: simple, parallel, and chained payments. You create each kind of payment with the Pay API.

  • Simple payments enable a sender to send a single payment to a single receiver. For example, your website can use an Adaptive Payments payment flow to transfer money resulting from a sale from your customer's PayPal account to your own account. This is the traditional kind of payment.
  • Parallel payments enable a sender to send a single payment to multiple receivers. For example, your application might be a shopping cart that enables a buyer to pay for items from several merchants with one payment. Your shopping cart allocates the payment to merchants that actually provided the items. PayPal then deducts money from the sender's account and deposits it in the receivers' accounts.
  • Chained payments enable a sender to send a single payment to a primary receiver. The primary receiver keeps part of the payment and pays secondary receivers the remainder. For example, your application could be an online travel agency that handles bookings for airfare, hotel reservations, and car rentals. The sender sees only you as the primary receiver. You allocate the payment for your commission and the actual cost of services provided by other receivers. PayPal then deducts money from the sender's account and deposits it in both your account and the secondary receivers' accounts.

    Note: Chained payments also include delayed chained payments, in which payments to secondary receivers can be delayed for up to 90 days.

Simple Payments

Simple payments enable a sender to send a single payment to a single receiver. This is sometimes considered a traditional payment, such as a payment from a buyer to a seller.

Scenarios involving simple payments might include the following scenarios:

  • Buyer makes a payment on a merchant's website.
  • Buyer makes a single payment for a cart of items from the same merchant.
  • Person on a social networking site makes a payment for a purchase to the receiver. For example, a sender sends money to pay for lunch at a restaurant.

In these cases, the sender sends a payment to a single receiver. The following example shows a sender making a simple payment:



Parallel Payments

A parallel payment is a payment from a sender that is split directly among 2-6 receivers. Technically, a parallel payment is a set of multiple payments made in a single Pay request.

Parallel payments are useful in cases when a buyer intends to make a single payment for items from multiple sellers. Examples include the following scenarios:

  • a single payment for multiple items from different merchants, such as a combination of items in your inventory and items that partners drop ship for you.
  • purchases of items related to an event, such as a trip that requires airfare, car rental, and a hotel booking.

In these cases, the sender knows the receivers and the amount paid to each one. The following example shows a sender paying 3 receivers in a single parallel payment:


Note: This scenario is an example only and does not take PayPal fees into account.

Chained Payments

A chained payment is a payment from a sender that is indirectly split among multiple receivers. It is an extension of a typical payment from a sender to a receiver, in which a receiver, known as the primary receiver, passes part of the payment to other receivers, who are called secondary receivers.

Note: The API caller must get permission from PayPal to use chained payments.

You can have at most one primary receiver and 1-9 secondary receivers. Chained payments are useful in cases when the primary receiver acts as an agent for other receivers. The sender deals only with the primary receiver and does not know about the secondary receivers, including how a payment is split among receivers. The following example shows a sender making a payment of $100:


In this example, the primary receiver receives $100 from the sender's perspective. The primary receiver actually receives only $10 and passes a total of $90 to secondary receivers, Receiver 2 and Receiver 3.

Note: This scenario is an example only and does not take PayPal fees into account.