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
Pay API Operation
Pay Summary
76 August 7, 2012 Adaptive Payments Developer Guide
When the payment is complete, PayPal sends an IPN message to the URL specified in the
ipnNotificationUrl field of the Pay request.
Additional Notes About the Pay API Operation
1. With parallel payments, fund transfers to some receivers may occur before others.
Therefore, set reverseAllParallelPaymentsOnError to true. In the event of an
error, this setting guarantees that transfers to all receivers are reversed and all funds are
returned to the sender. If reverseAllParallelPaymentsonError is disabled,
completed transfers are not reversed and funds that have already been transferred are no
longer available to the sender.
2. You can specify your own unique tracking ID in the trackingID field and use this value
to obtain information about a payment or to request a refund. The tracking ID is provided
as a convenience in cases when you already maintain an ID that you want to associate with
a payment. You can also track payments using the payKey.
3. You can use the Pay API operation to make unilateral payments under limited
circumstances. A unilateral payment is a payment that is made to a receiver who does not
have a PayPal account. Unilateral payments can be used with simple or parallel payments
that are implicit or preapproved. Unilateral payments are not designed to be used with
chained payments or payments that require manual approval through the web flow.
When you send a unilateral payment, you send a payment request that includes an email
address for a receiver, and this email address is not linked to a registered PayPal account.
The receiver receives an email notifying the receiver to create an account and claim the
payment.
PayPal holds a payment to a receiver whose email address is not yet registered or
confirmed until the receiver creates a PayPal account and confirms the email address. If a
refund specifies a receiver whose email address is not yet registered or confirmed, the
payment to the receiver is canceled.
4. For a guest payment, do not set the sender’s email address or the preapproval key.
Specifying the sender’s email address prevents the sender from choosing the guest payment
option. Implicit approval and preapproval options are not allowed. Each receiver of a guest
payment must be a verified PayPal business or premier account holder.
5. You can specify a value for either senderEmail or one of the SenderIdentifier
fields. If you use SenderIdentifier to identify the sender, you can only specify
sender.email or set sender.useCredentials to true, but not both;
sender.phone is reserved for future use.
6. Specify senderEmail or sender.email to set up a payment where the sender and the
API caller are the same (implicit approval) or for a preapproved payment.
7. If senderEmail or sender.email is specified in the request, the email address must be
registered with paypal.com. If you do not include one of these fields in the payment
request, the sender can either log in using an existing account that is not associated with a
receiver or create a new account during the payment flow.