How do big e-commerce businesses do payouts to multiple vendors/merchants when people make purchases of multiple sellers. Most e-commerce giants have multiple onboarding methods. For example Wish allows you to onboard as a seller through PayPal, Payoneer, and like 6 other chinese payment gateways.
On the front-end, they always allow cards and PayPal for transactions. What do you do if you have 5 sellers, and 4 of them are on PayPal, and 1 of them is on Payoneer. How do you split that payment? I ask this question because I'm trying to find out how you do payouts to sellers on marketplaces when people can be onboarded to multiple different gateways on the same transaction.
Payouts is for sending money from your own account(s) to others. Are you actually asking about such payout functionality, or are you asking about how to implement a marketplace that facilitates payments from customers to sellers.
In any case, if you are integrating different services then those are simply separate integrations.
If the use case is to spilt a USD 100 payment into 2 parts and settle it to two different vendors across two platforms.
It will require two things
(i) build a business logic using the settlement APIs over and above the integrations of various Payout solution providers
(ii) accept the total amount (USD 100) paid by customers on a single source account prior to settlement to different vendors
Related
Is there an existing solution that provides the following?
any seller can create a store with virtual products - every product costs a monthly subscription fee (the solution will contain many stores)
any buyer can subscribe to products (set-up recurring payment)
the system should be worldwide/universal for all types of payments - credit cards, paypal, ..., the system should also support mass payouts to the sellers
Is there an existing solution that I can use/buy? (can shopify or other services do this?)
If not - what components should I use while building such system? I was thinking about https://www.paypal.com/pdn-recurring along with paypal Payouts API, but what about the system for building the stores?
It sounds like you're the person creating the product and you want many sellers to sell your product and you want to give them a recurring payout when that happens.
If that's the case, have you looked into Affiliate systems like Clickbank or JvZoo, where you list your product with them and then affiliates will sell the product for you and they handle all the payment processing.
Paypal doesn't handle affiliate payouts, so it's going to a lot of work on your side to track and do payment disbursement and handle refunds and charge backs.
I'm a software developer working on a homeschool registration website. I have a use case I'm not sure PayPal Invoicing can handle.
The scenario: I have Families and Teachers. Families select a number of classes and checkout. At time of checkout, I want to generate (what I think of as) an invoice to the Family. I want the invoice to request the family to pay the teacher(s) for the selected classes. I do not want to collect payments myself and redistribute payment to teachers - this raises too many issues about contractors/employees. Payments need to take place peer to peer, Family to Teacher(s).
When payments have been made, I would like a notification for each item on the invoice (a teacher being paid) at which point, I can lock in the enrollment of that family in the class, as it has been paid.
So, is this something PayPal Invoicing can do? I want to emphasize that I want the family to receive a single request to pay multiple teachers, not multiple requests to pay a single teacher. And, all families and teachers are assumed to have PayPal accounts.
Also, I saw that pricing is 2.9% + $0.30. Does the recipient of the invoice (the family) pay this, or does the organization issuing the invoice (the homeschool) pay this? The homeschool is a non profit. Can this be done without fees?
Thanks!
The transaction mode on your platform is a peer-to-peer / marketplace payment flow, so you may want to implement PayPal Adaptive Payments instead of Invoicing service.
As the platform/APP owner (API caller), you would easily manage the transactions with these implementations:
Adaptive - Parallel payments to fullfill the payment request (one to many) from family to teachers
IPN (Instant Payment Notification) to handle the transaction call-backs, your back-office program will be able to lock in the enrollment of that family in the class, based on the payment call-backs.
Adaptive Payments will support flexible fees payer, so that you would be able to set either the family or the teachers to bear the cost
See the overview & technical instructions at the PayPal Developer Site as an intro, and obtain the SDK per your programming language at HERE
The Invoicing API isn't what you want.
What I would recommend is an Express Checkout integration setup with Parallel Payments. You won't have to mess with Permissions if you do it that way, and the individual amounts can go directly to each teacher (receiver) on the transaction.
If you happen to be working with PHP this PayPal PHP SDK will make the Express Checkout Calls very simple for you.
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 developing a website where the users can sell their products. Users can then also buy products on the site, obviously, lol. However the problem is that I am currently using Paypals Parallel Payments and it limits the number of items a user can buy to 6 different sellers at a time including the sites fee.
So I was thinking about switching to using PayPals Masspay API instead. It would work like this. The user buys as many products as they want up to the limit of 250 different users using eithier the Masspay api if acceptable for 1-to-1 payments or something else. Once the payment is completed to the sites paypal account, It will start a masspay api call to pay all the differn't users upto 250 users using the funds from the payment to the site once those are completed.
Also I am limited to paypal right now so I can't use any other payment services.
So is this ok to do or is this a bad way to do it maybe for some security reason I do not know about?
It seems like the only good option, on the plus side, it benefits from the lower fees that masspay offers vs the %2.9 + 0.30 Cents.
First, you'd have to get it approved by PayPal to enable MassPay for your account.
Then, you'd need to be careful about chargebacks and dealing with refunds. If somebody submits an order for $1k, for example, and you dispersed that money among 25 different people, and then the buyer submits a dispute with their credit card company to get that $1k back, you'd be stuck trying to collect all those pieces from all the people you distributed to.
I wanna build a web store for selling people's second hand products.
A customer adds the products into a shopping cart.
He/she pays (credit card, bank account) for it and I get the money.
The seller sends the bought products to the customer.
I get send the money to the seller (and have taken a fee for it).
People tend to mention Amazon's, Google's and PayPal's payment service but recently I came across services like Chargify and Recurly.
My questions:
How do these two differ from the other three?
Which one would support the above mentioned transaction process?
How should I set up the above transaction process?
The "big 3" require an account. How do I charge with just a credit card or bank account only?
Thanks!
Thanks for thinking of Chargify.
We're not the right thing for your need... we focus on helping a business manage many things involved in recurring billing of customers.
For what you want to do, I think one of the "Big 3" is the way to go. You've got the extra "wrinkle" of this, however: you're essentially collecting money on behalf of each Seller, and each Seller may be selling very different things and will have different levels of honesty, etc.
All of my experience is with merchants that have a traditional merchant account and payment gateway, which together allow them to charge credit cards. But the banks that issue merchant accounts want to know what each merchant (each Seller) is about. I'm 99% sure the banks dislike a single merchant account being used to sell / collect credit card payments for more than one merchant.
Anyway, to the degree that it's useful, I wrote a blog post last year about merchant accounts and payment gateways. It may be helpful to you as you explore options:
https://lancewalley.wordpress.com/2010/06/22/merchant-accounts-payment-gateways/
See my answer in Online payments for a middleman.
PayPal Adaptive Payments allows you to accept guest payments, without requiring buyers to have a PayPal account.
Another thing to think about is regional availability; Amazon / Google may sound interesting, but are not very useful if you don't live in the US or UK. Whereas PayPal Adaptive Payments is available pretty much globally (with the exception of a few countries where PayPal hasn't launched yet).