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
Getting Started
Making a Parallel Payment (NVP)
70 August 7, 2012 Adaptive Payments Developer Guide
In this particular scenario, the paymentExecStatus variable is set to CREATED instead of
COMPLETED, which indicates that the payment has been created, but has not yet been executed.
Making a Parallel Payment (NVP)
A parallel payment is when a sender (whose account is debited) sends a single payment
(amount and currency) up to 6 receivers. The sender can see each payment to a receiver.
You send a PayRequest, specifying an amount to be paid for each receiver.
You receive a response with a pay key.
You must redirect the sender’s browser to PayPal to approve the payment.
In the example below, Paul makes a single payment of $14, which is split into a $9 payment to
Andrea and a $5 payment to Linda. The following event sequence takes place:
Pay Request for Parallel Payment
&actionType=PAY
&cancelUrl=http:\\example.com\cancel.htm
¤cyCode=USD
&receiverList.receiver(0).amount=9.00
&receiverList.receiver(0).email=andrea@example.com
&receiverList.receiver(1).amount=5.00
&receiverList.receiver(1).email=linda@example.com
&requestEnvelope.errorLanguage=en_US
&returnUrl=http:\\example.com\return.htm
Pay Response for Parallel Payment
responseEnvelope.timestamp=2009-11-03T08%3A12.937-07%3A00
&responseEnvelope.ack=Success
&responseEnvelope.correlationId=b1cc3eabfa4c1
&responseEnvelope.build=942345
&payKey=AP-688241038Y786593D
&paymentExecStatus=CREATED
The response includes a pay key, which is a token you use in subsequent calls to Adaptive
Payments APIs to identify this particular payment.
In this particular scenario, the paymentExecStatus variable is set to CREATED instead of
COMPLETED, which indicates that the payment has been created, but has not yet been executed.