I am looking for a payment processor that supports N-Payer->1-Payee.
As documented https://developer.paypal.com/docs/api/payments/#payment_create,
users make payment requests by providing the server with a payment object. Within the object, there is a payer field which specifies the source of the funds for the payment.
(Disclaimer: I work for Stripe.)
Stripe does not support this directly -- you'd have to create as many charges as there are payers.
Due to the way card payments work, I'd guess that all card processors have the same limitation, though maybe other processors have built features to better handle such payment flows.
Related
I am currently using the PayPal NVP API, using the DoDirectPayment method, to accept credit card payments. Is there a way to do something similar with ACH payments?
ACH can be used as a funding source by buyers paying via PayPal. I.e. they can have the bank added inside their PayPal account.
But if you want to more directly process ACH payments through your site and be responsible for waiting to see whether the payments go through or not (since ACH takes time), you will need something like the Payflow gateway and a relationship with an ACH processor such as NORWEST. That's just one common option I've heard of, there surely must be others. This is more a question for some Google research than Stack Overflow.
I am setting up a monthly automated backend process that will transfer money from a central account to thousands of PayPal accounts. The transactions will vary anywhere from $50 to $10,000. The key requirements here are:
Receiver must pay the fees
No user input required. By this, I mean this process should run without any kind of action on my end (I've noticed that some PayPal integrations require a redirect, approval on the sender side, etc.).
Here are the possible ways I see that you can send money using PayPal:
Mass Pay
Uses classic SOAP APIs. Sender must pay fee, so not an option
Payouts API
Uses new REST APIs. Sender must pay fee, so not an option
AdaptivePayments
Uses classic SOAP API. However, you can force the receiver to pay the fees.
Rest API Payments
See https://developer.paypal.com/docs/rest/api/payments/#payment
Uses REST API, which is good.
Can you force the receiver to pay the fee?
Can this be used without a web browser?
So, it seems like AdaptivePayments or REST API Payments are the only options that could work (there could be more, though). I'd obviously prefer to use the more modern REST API, especially for a new project, but if the functionality that I want to achieve is not possible, then I supposed I will have to use the classic Adaptive Payments option. Any insight would be greatly appreciated.
The only option that allows you to force the receiver to pay the fee is Adaptive Chained Payments, but that would not work for your situation. The type of payment you would be sending would be an Implicit Simple payment, which only allows the sender to pay the fee.
So, your best option would be to use the MassPay API, primarily because of the fee. For US payments, the fee is 2%, capped at $1 which is a significant saving over sending a regular payment at 2.9% + $0.30.
If the fee is that important, you could program it to reduce the amount you send by 2% or $1, whichever is higher.
I have an educational website that uses 'Stripe Connect' to accept payments from students, and split the payments between myself (the platform provider) and the teachers (content-creators).
Payments to teachers are currently handled through Stripe. Whenever a student purchases content, the teacher automatically receives the payment directly into their Stripe account. I retain a portion of the transaction directly into my Stripe account. It's an easy system and works nicely.
The problem is that students want to pay with PayPal.
So, I would like to add PayPal as a payment option for students, without forcing content-creators to connect two separate accounts--one for when viewers pay with PayPal, and another for when viewers pay with Stripe. The only idea I have so far, is to deposit all PayPal payments to one PayPal account, then manually "payout" teachers into their Stripe accounts every week.
But is there an automated way to do this? Stripe says they don't accept payments from PayPal.
Any ideas/help would be appreciated. Thanks!
Adaptive payments does support chained payments, as Andrew says in his answer; it would work very much like what you describe having set up with Stripe.
However, this will not meet your requirements of having both PayPal and Stripe payments arrive in a single teacher account. Unfortunately, Stripe & PayPal see each other as competitors and to my knowledge neither one has built a tidy product to consolidate "their" payments into the other company's account.
If you are willing to move away from Stripe, PayPal does provide many solutions that consolidate "raw" credit card payments and PayPal account payments into a single receiver account, including through Adaptive Payments as cited by Andrew.
I would add that Braintree, having been purchased by PayPal, provides perhaps the most Stripe-like integration for a product that would accomplish this goal. However, I do not believe that the Braintree SDK will do the chained payments for you; you might have to do some work to make that happen on your end (take the first payment, then calculate and make payouts either weekly as you mentioned or per-incoming-transaction).
A couple other things to think about: if you split some payments into delayed fulfillment but others are chained inside one payments provider you will need to support two very different flows; you may find it easier (for both you and your content providers) to select one model and run everything through that model.
Also, instead of payments going to you & then chained to the content providers you could have payments to go directly to the content providers and then trigger billing (either invoicing or automatically collected via recurring payments) from the content providers to you for your cut.
The best pattern depends largely upon how you want the legal & financial responsibilities to lie: are you providing the good or service and people are paying you for it, making you like a retail store or distributor for producers? Or are content providers providing the good or service being paid for to the students, and you are like a marketplace/facilitator/advertising venue? This question becomes significant as soon as someone is unsatisfied with something they have bought :).
You can use the Adaptive Payments platform with PayPal to split payments just like you're doing with Stripe. Specifically, you'd use the Pay API setup as a chained payment with a secondary receiver.
If you happen to be working with PHP my class library for PayPal will make all of the API calls very simple for you.
I am a bit confused about the REST and Classic API and which one serves my business case best. My requirement is to be able to send money to one or many customers by just using their email addresses. No need to receive Payments, just to send...Additionally i do not want approvals, i just want to send the payment and the payment to be executed, since i am performing a receiver email validation via the getVerifiedStatus call.
I know there is the Mass Payment option and the Adaptive Payments option however for consistency i need to use only one API. Which API covers my needs?
This isn't yet covered well by PayPal's new REST APIs. But the MassPay api (with # of payments = a set, or just 1) can definitely do what you want. Check PayPal's handling of exception cases that is built into the MassPay product to ensure it meets your requirements; if it does then this is a great answer. The adaptive payments pay() can also definitely work; to determine which works for you will require evaluating the underlying PayPal products moreso than the APIs. They do NOT work entirely the same way....
I would stick to classic API for now as it's much more mature than the REST API is. For your situation I'd go with Adaptive Payments, specifically the Pay API. Since you are the app owner and the payer, you can simply trigger payments however you want to anybody you need.
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.