• Choose a category
• All
• Classic-Fiction

Your application sends a Pay request to PayPal that includes a preapproval key identifying the payment agreement.

PayPal responds with a payment key that you can use for other API functions.

Figure 4-6. Preapproved Payment flow

Figure 4-7. Preapproved Payment direct sending

Implicit Payments

Implicit Payments are payments sent directly by your application in which the sender and API caller are using the same PayPal account. Since your account is the one sending the payments, no approval is necessary for the payment transaction. Figure 4-8 outlines an Implicit Payment:

Your application sends a Pay request to PayPal.

PayPal responds with a key to use for other API operations.

Figure 4-8. Implicit Payment flow

Guest Payments

Adaptive Payments also supports Guest Payments, where the sender can pay using her credit card, similar to using Direct Payment. The recipient must have either a business- or premier-level PayPal account. Guest Payments are handled in the same manner as Explicit Payments, except that the sender provides credit card information directly on the PayPal payment screen.

Adaptive Payments API Operations in Depth

In the remaining pages of this chapter, we look at the following Adaptive Payments API operations in depth:

Pay API

SetPaymentOptions API

ExecutePayment API

A complete list of all the defined Adaptive Payments API operations can be found at http://developer.paypal.com or http://x.com.

Pay API Operation

All payments made via Adaptive Payments have the same required fields. These are outlined in Table 4-3.

Table 4-3. Common required fields

Field Description

actionType Will be one of three possible values:

PAY: Use this value if not using the request in combination with ExecutePaymentRequest.

CREATE: Use to set up payment instructions with a SetPaymentOptions request and then execute at a later time with an ExecutePaymentRequest.

PAY_PRIMARY: Used for chained payments only. This allows you to delay payments to secondary receivers at the time of the transaction and process only the primary receiver. To process the secondary payments, initiate ExecutePaymentRequest and pass the pay key obtained from the PayResponse.

receiverList .receiver(n).email The receiver’s email address.

receiverList .receiver(n).amount The amount to be credited to the receiver’s account.

currencyCode The code for the currency in which the payment is made. You can specify only one currency, regardless of the number of receivers.

cancelUrl The URL for sender redirection if the sender cancels the payment approval. This value is required, but used only for explicit payments.

returnUrl The URL for sender redirection after completion of the payment. This value is required, but used only for explicit payments.

requestEnvelope.errorLanguage The code for the language used when returning errors (must be en_US ).

If you are performing a parallel payment, you must provide the additional fields outlined in Table 4-4.

Table 4-4. Parallel payments fields

Field Description

receiverList.receiver(n).email The email address for each receiver. n is an integer between 0 and 5 , allowing for a maximum of six receivers.

receiverList.receiver(n).amount The amount to send to each corresponding receiver.

If you are performing a chained payment, you must provide the additional fields outlined in Table 4-5.

Table 4-5. Chained payments fields

Field Description

receiverList.receiver(n).email The email address for each receiver. n is an integer between 0 and 5 , for a total of one primary receiver and one to five secondary receivers.

receiverList.receiver(n).amount The amount to send to each corresponding receiver.

receiverList.receiver(n).primary Set this value to true to indicate that this is a chained payment. Only one receiver can be the primary receiver.

As discussed previously, a payment requires explicit approval by default. To initiate the approval process, your