I'm trying to split the payment into 2 accounts, the main and the secondary. Like any other marketplace or service platform, the secondary account is owned by the platform itself. I've read that it is called parallel payments under adaptive payment in Paypal. But right now, they don't accept new integration.
I've also read about the new mass payment and checkout features, but I'm not sure if they are the same. What I want to have is similar to fiverr where when a customer pays, the payment is automatically split into 2 just like I described above.
Any idea what section in Paypal docs I should read? Thanks.
Mass Payments is old, it's been replaced by Payouts, which you could request access to. It may or may not be approved for your marketplace use case.
Related
I need a solution that allows UserA to make a payment to UserB. UserA is a registered account in a web service that has their information stored in the "vault". UserB has no registered account and would simply pay at checkout by entering a valid card number. The web service would take 2% of the payment that goes to I guess a separate account for the website.
I am trying to wrap my head around which payment service to use as this is the first time I am creating a service with money transactions involved. I like Braintree specifically from what I see:
Free up to first 50k (good for a small cloud based web service)
Drop in UI that handles the encryption side of thigns for me (so it seems)
My question is my solution requirements need me to seemily split up the transaction that UserB pays from a card into two places - a portion to UserA and a portion to the web service. Does Brain tree offer a solution that makes this possible as I see it is with Paypal Adaptive Payments
Just looking for a quick link to the documentation.
I think Braintree supports "Split & pay". Refer : You can designate a service fee with each transaction and Braintree will disburse the appropriate funds to you and your sub-merchant..
And Paypal of course supports Adaptive payments. Refer : Adaptive Payments
I think all you need is in the above links.
I've made already some applications with the requirements of yours, and if I was you, I would consider Paypal Adaptive payments, because through the API, you can select how you want to "split" the payment between the receivers.
check this page for the configurations : page with configs
I am trying to create a subscription feature on my site. The users can subscribe to a number of projects (from 1 to 30). The price of a projet: 10$.
For subscribing I use a the Subscription button. I validate the payment using the IPN from paypal. All ok.
Now I want to give to users the possibility to change the number of projects they are subscribed for. But the paypal doesn't allow an increasing of payment more than 20%.
How can I change the user's subscription ? Should I remove his profile (not sure if I understant what it is) and create a new one ?
As you saw in the documentation, PayPal Subscriptions product doesn't seem like a good match for your requirements. You could have someone re-subscribe with new (higher) premium, but you probably would be better off with a product that allowed you to simply change the recurring amount billed.
PayPal has several other products that allow you to do that; hopefully one will meet your needs. In particular look at Recurring Payments & Reference Transactions (within PayPal's classic product suite) or Future Payments (within PayPal's RESTful API suite).
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'm going to offer my customers a selection of subscriptions to digital content. I want the customer to be able to add or delete subscriptions later, with as little hassle as possible.
It seems that if I use Paypal vault, I can collect the card information on the same subscriptions screen without multiple redirects and later change the monthly total without another checkout process or even customer sending approval to Paypal!
Does Paypal allow this? It seems too easy and also too permissive. Also, do I need to worry about PCI compliance?
Does anyone know a better way to do this (with or without Paypal)? I don't know how to use paypal recurring payments without a lengthy checkout if they ever change their subscriptions. Google wallet does not have subscription cancellation in their API! Several other alternatives only allow preset subscription amounts.
The CSC/CVV is missing from the examples here: https://developer.paypal.com/docs/integration/direct/store-a-credit-card/ which makes me think you cannot use the card at will. The customer is probably going to be asked for authorisation.
Normally your online payment provider needs to support recurring payments (installments, subscriptions). PayPal does, there's a specific API:
https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/installment_buttons/
For the customer it's one-off, then the card is billed, say, monthly.
I developed a Web Application that accepts payments via the ExpressCheckout API, for users to become a members.
Everything works fine.
I now want to extend my Web Application Services and offer my users with the possibility to buy items which are sold by third parties (my members).
The principle I would like to implement is quite simple: for each order, let the user pay for the item they choose and then transfer a part of the amount I received to the item provider, and keep some money for me. I would like to automate this process so that once I received the payment notification, I compute the amount of money to transfer to the item provider who might or not have a Paypal account (in other words, this means that I could maybe need to transfer the money to a bank account, using the IBAN/SWIFT data) and then proceed with the money transfer.
I tried to find a solution reading your documentation and came across the "chained payment" but the latter does not seem to be used within the ExpressCheckout workflow.
Also, since my implementation of the ExpressCheckout flow works, I would not like to have to find a totally different solution but rather extend it... if possible.
Could you please tell me which is the best solution for me?
In advance, many thanks for your help.
You could do 1 of 2 things. You could use Express Checkout with parallel payments. This means you could split the transaction up between different accounts at the time of purchase. The other option would be to just receive all of the funds into your account, and then when you are wanting to send money to the other accounts you could either use the Adaptive Payments (Pay) API or the MassPayments API to send money to the other accounts. Keep in mind you would have to send it to their PayPal accounts, you would not be able to send it directly to a bank account with either one of these API's.
I had the same issue and I got an answer from PayPal that it is not allowed to use Express Checkout to transfer money to your PayPal account and - at a later point in time - transfer the amount minus your service fee (which stays on your PayPal account) via Adapative Payments API to the seller's PayPal account. PayPal suggested to use Chained Payments API instead. All works fine in the sandbox, but once you need a Live APP ID from PayPal they will review your business case and deny it. At least that what happened to me.
I know that is old question, but anyway, I tried to find solution and was enable to perform the simillar thing like described in question. So, then I asked paypal about this, and they gave me advice to use SellerDetailsType Fields that 's called PayPalAccountID, description for this field is Unique identifier for the merchant. For parallel payments, this field is required and must contain the Payer Id or the email address of the merchant. It wasn't clear for me to use this field for solving my problem. Here is link https://developer.paypal.com/webapps/developer/docs/classic/api/merchant/SetExpressCheckout_API_Operation_SOAP/ I described field for soap request, for NVP it's called PAYMENTREQUEST_n_SELLERPAYPALACCOUNTID, but the idea is the same. I hope it will help someone.