Chained Payments in PayPal are deprecated, is there a way to implement this feature?
An example is a user pays for a service but the app takes 10% of every transaction.
Related
I'm trying to implement a recurring subscription to a website using PayPal Express Checkout Recurring Payments. One requirement is that creating the initial subscription should be as quick as possible: once the customer confirms the purchase, the merchant should receive the money and activate the subscription in a couple of minutes tops.
As far as I understand, I have the following options to go with:
use CreateRecurringPaymentsProfile only, with billing starting now
use CreateRecurringPaymentsProfile with initial payment, starting now
use DoExpressCheckoutPayment followed by CreateRecurringPaymentsProfile starting now + 1 billing period
Initial testing in the sandbox has shown that plain CreateRecurringPaymentsProfile schedules payments once a day, which rules this option out. Option 2 (Recurring Payments Profile with an initial payment) looked promising -- payments usually went through in a couple of seconds -- until the initial payments started being delayed by half an hour or more.
So, a couple of questions:
What is the intented way to implement on-line recurring payments via PayPal?
Does the sandbox share payment scheduling behavior with the live site?
What is the intented way to implement on-line recurring payments via PayPal?
Answer:The recurring payment via Express Checkout is a good way.
The subscription button via Website Payments Standard is also a good way which is more easy to implement.
Does the sandbox share payment scheduling behavior with the live site?
Answer:yes, sandbox has the same payment scheduling behavior as live.
BTW, if you want initial payment be charged right away, you should use Option 3, initial payment will be changed right away after DoExpressCheckoutPayment.
Option 2 only guarantee initial payment be charged in 24 hours.
i am creating a small marketplace where sellers can sell their products and receive payments to their PayPal account directly from the buyer.
i've previously been using "website payments standard" but am looking to switch to the express checkout API to generate a one-time payment token each time someone purchases something and which then allows buyer#email.com to send a payment directly to seller#email.com without the involvement of my PayPal account.
is that possible?
i've only found one option in the documentation at https://developer.paypal.com/docs/classic/api/merchant/SetExpressCheckout_API_Operation_NVP/ called "PAYMENTREQUEST_n_SELLERPAYPALACCOUNTID", but is that the correct way to send the entire payment from the buyer to the seller without any amount going to me?
also, do i NEED to have my own "USER" and "PWD" to generate an API token each time if I am receiving no payment mysefl?
Think you are looking for Adaptive payments.
Adaptive payments handles payments between a sender of a payment and one or more receivers of the payment. You are an application owner, such as a merchant that owns a website, the owner of a widget on a social networking site, the provider of a payment application on mobile phones, and so on. Your application is the caller of Adaptive Payments API operations.
So, in general if you want to act as API caller and to felicitate the money transfer between buyer and seller, Adaptive payment is the way to go.
Steps to go live with Adaptive Payments
We are setting up our marketplace transactions with PayPal and thus want to use chained payments for simple processing and to prevent being a funds aggregator.
As we want to capture buyers payment method once (upfront) and allow them to buy services from sellers later without entering their payment details every time, PayPal has 2 options: 1) pre-approvals, or 2) billing agreements.
However since buyers should also be able to pay with credit card, we can only use option 2) billing agreements.
Is our understanding correct that billing agreements are not compatible with chained payments?
Also, if they are not compatible, how can we go about it to allow for:
- Users to pay with credit card
- Not have them enter the credit card details every time at the time of purchase
- Use chained payments (prevent funds aggregation which would happen if we receive funds first and payout in a second operation)?
Thanks!
Preapproved Payments is part of the Adaptive Payments platform. Depending on what you're doing with the transaction when the time comes to submit a payment with a preapproval profile you may use a simple payment, parallel payment, or chained payment.
What you're after, billing agreements, is part of the Express Checkout API or Payments Pro. The actual term for what you'll be working with is Reference Transactions.
If you process a credit card directly over Payments Pro (either sale or auth) then you can simply use that transaction ID you get back with the DoReferenceTransaction API at any point in the future to process another transaction automatically.
If you process the original sale or authorization with Express Checkout, that's where you need to include billing agreement parameters in your SetExpressCheckout request to create that billing agreement, but then you'd still use the DoReferenceTransaction API to process future payments.
Quick question about the notify_url HTML variable (from PayPal Payments Standard). I am specifying the URL as a variable that is sent to PayPal via a redirect URL for a recurring payment setup (all is working as expected when setting up the recurring payment).
But I am wondering, when PayPal goes to actually process a payment in the future (actual recurring payment), will it use the same URL for the IPN notification that was used during the recurring payment setup?
I have multiple IPN scripts, one for regular payments and one for recurring payments - I want to be sure that each future recurring payment uses a specific IPN script.
Cheers!
First, for the sake of terminology, if you're using HTML buttons then you're using Standard Subscriptions, not Recurring Payments. Technically, they're the same thing, but Recurring Payments is API based and IPN data is different for Standard Subscriptions vs. Recurring Payments. Just keep that in mind when searching for information about the two.
As for the IPN's, unfortunately, it will not continue to use that same URL. You'll need to make sure that IPN is configured in the PayPal account profile in order for future transactions related to the profile to trigger IPN's.
This goes for both Standard Subscriptions and Recurring Payments API transactions.
A proposed scenario is, assume the shopping cart site, where buyer has to pay for a product. The sold product costs will be transferred to the respective merchant. Here, the website owner has to be paid(commission) for the purchased product.
Is it possible in Paypal? Right now, I am using Paypal checkout. Your ideas/suggestions would be helpful. Please do it.
There are a number of ways you could set this up.
You could use the Adaptive Payments platform, specifically the Pay API, to create parallel or chained payments so that multiple receivers can receive money within the same transaction.
You can also do a parallel payment with Express Checkout, but you can't do a chained payment.
The main difference is that with parallel payments the buyer will see the split during checkout. With a chained payment you can hide that so they only see the primary receiver. Also, chained payments can be delayed so you can trigger the commission to be paid at a later time if necessary (for example, waiting for services to be completed.)
Another way you could do this is to use Payments Standard, Express Checkout, or Payments Pro, and let the payment go entirely to a single account. Then setup a Pay API request to submit payment to the secondary receiver, or use the MassPay API. This could be setup within an IPN solution so the entire thing is automated. In this case you'd basically be building what the adaptive payments platform does for you, but it would give you a little bit more freedom over everything in the application.