Developer's Guide
Table Of Contents
- Adaptive Payments Developer Guide
- Contents
- What’s New?
- Introducing Adaptive Payments
- Adaptive Payments Actors and Objects
- Simple, Parallel, and Chained Payments
- Payment Approval
- Adaptive Payments Service Permissions
- Explicit Approval Payment Flow
- Preapproved Payments Flow
- Implicit Approval Payments Flow
- Embedded Payments
- Embedded Payment Flow Presentations
- Kinds of Embedded Payments
- Embedded Payments Implementation Basics
- Embedded Payment Experience
- Preapprove Future Payments Checkbox
- Shipping Address Information
- Embedded Payment Experience
- Setting Up Web Pages to Invoke the Embedded Payment Flow Using a Lightbox
- Setting Up Web Pages to Invoke the Embedded Payment Flow Using a Minibrowser
- Displaying and Collecting Shipping Addresses
- Guest Payments
- Fee Payment Configuration
- Getting Started
- Pay API Operation
- PaymentDetails API Operation
- ExecutePayment API Operation
- GetPaymentOptions API Operation
- SetPaymentOptions API Operation
- Preapproval API Operation
- PreapprovalDetails API Operation
- CancelPreapproval API Operation
- ConvertCurrency API Operation
- Refund API Operation
- GetFundingPlans API Operation
- GetShippingAddresses API Operation
- Adaptive Payment Commands and Redirects
- Instant Payment Notifications
- Older Versions of the Adaptive Payments API
- 1.8.0 Features
- 1.7.0 Features
- 1.6.0 Features
- New API Operations for Version 1.6.0
- Changes to PayRequest Fields for Version 1.6.0
- Changes to PayResponse Fields for Version 1.6.0
- Changes to ExecutePaymentRequest Fields for Version 1.6.0
- Changes to GetPaymentOptionsResponse Fields for Version 1.6.0
- Changes to SetPaymentOptionsRequest Fields for Version 1.6.0
- Changes to PreapprovalRequest Fields for Version 1.6.0
- Changes to Address Structure for Version 1.6.0
- Changes to DisplayOptions Structure for Version 1.6.0
- New CurrencyConversion Structure for Version 1.6.0
- New InvoiceData Structure for Version 1.6.0
- New InvoiceItem Structure for Version 1.6.0
- New SenderOptions Structure for Version 1.6.0
- New SenderIdentifier Structure for Version 1.6.0
- New AccountIdentifier Structure for Version 1.6.0
- New ReceiverOptions Structure for Version 1.6.0
- New ReceiverIdentifier Structure for Version 1.6.0
- Additional Error Messages for Version 1.6.0
- 1.5.0 Features
- 1.4.0 Features
- 1.3.0 Features
- 1.2.0 Features
- 1.1.0 Features
- Revision History
- Index
Introducing Adaptive Payments
Simple, Parallel, and Chained Payments
20 August 7, 2012 Adaptive Payments Developer Guide
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: