• Choose a category
• All
• Classic-Fiction

By Root 156 0

can see who those recipients are. Parallel payments are commonly used in aggregated shopping, and allow a customer to order from multiple vendors with a single shopping cart.

Figure 4-2. Adaptive Payments owner as intermediary workflow: parallel

Another way in which your application can function as an intermediary is facilitating a chained payment, outlined in Figure 4-3. In a chained transaction, your application receives the payment, and the funds are then split between multiple recipients on the backend. In a chained setup, your application can take a percentage off the top and then disperse the remaining funds to the other recipients. You can even set up what is called a delayed chained payment. This can be used when your secondary receivers are required to ship goods, for example, before they receive their payment for the transaction.

Figure 4-3. Adaptive Payments owner as intermediary workflow: chained

And finally, your application also can be the sender of the transaction, outlined in Figure 4-4. This could be used to facilitate commission payments to your sales reps, for example.

Figure 4-4. Adaptive Payments application as sender

So, as you can see from these workflow diagrams and notes, Adaptive Payments is probably the most powerful payment method PayPal provides to application developers.

Payment Approval and Payment Flows

Once a payment transaction via your application has been submitted, the sender of the payment must take an additional step and approve the transfer of funds. This can be one of four different payment approval types: Explicit, Preapproved, Implicit, or Guest Payments.

Explicit Payments

Explicit Payments require the sender to log into PayPal.com and approve each individual payment. This is the traditional method for paying via PayPal and is the only option a sender has, unless he has previously set up a preapproval agreement with you, or unless the sender is also the application provider. You can control the interaction between your application and PayPal during the transaction process by providing URLs for redirecting the sender, dependent on the situation. Figure 4-5 outlines an Explicit Payment flow, which consists of the following steps:

Figure 4-5. Explicit Payment flow

Your application sends a Pay request to PayPal.

PayPal responds with a key that you use to redirect the sender to PayPal.

You redirect the sender to PayPal.com.

The sender approves the transfer of the payment, and PayPal redirects the sender to a URL you specify.

PayPal sends both you and the sender an email summarizing the payment that was made.

Preapproved Payments

Preapproved Payments require senders to log into PayPal.com and set up preapprovals for future payments, for example, payments to a supplier they use frequently. Once the preapproval is set up, payments automatically are considered approved, and the sender will not have to log in to approve payments to that vendor in the future. During the preapproval setup process, the sender can specify the following:

Duration of the preapproval, including the start date and end date. This comes in handy if you are paying a specific vendor for supplies on a particular project that has a known start and end date, for example.

The maximum amount being approved at one time.

The maximum number of payments allowed for the vendor.

Figure 4-6 outlines a Preapproved Payment flow, which consists of the following steps:

Your application sends a preapproval request to PayPal.

PayPal responds with a key, called a preapproval key, that you use in redirecting the sender to PayPal. If the preapproval has already been established, you will use this key to complete payments automatically on the sender’s behalf.

You redirect the sender to PayPal.

After the sender approves the preapproval, PayPal redirects the sender to a URL you specify.

PayPal sends both you and the sender an email summarizing the payment that was made.

Once the sender approves the preapproval setup, you can make