I am setting up the Paypal integration for a Clients website. He has a page where users can buy stuff that others users sell and he wants the buyers to pay using Paypal, he also wants the payment to be charged a fee, so that a percentage of the payment goes to the website owner and the remainder goes to the seller. For example:
Tom sells shirts at $20 each and i want to buy two, so i would pay $40 plus the 3% of the transaction, that would sum up to $41.2, $40 would go to Tom and $1.2 to the page owner.
How can i do this using Paypal? I have been reading a lot Smart Payments Button describes how to set a payment but the funds go to a single person, i need to set a chained payment, split payment or something alike and their docs seem very fuzzy.
Any help is appreciated.
Thanks!
platform_fees , documented here , is the analogue to chained payments. However, it is only available to PayPal partners -- i.e., probably not your client.
For separate transaction payments to more than one receiver account, there is multi-seller payments.
After completing the Paypal Integration and after tears and pain i can tell that i couldn't use platform_fees.
The implementation is complete and working but i wrote to customer support and to dev support and they just don't want you to use platform_fees so nothing will work along that path.
The solution they provide and the one they want you to use is getting all the money on your account and then splitting it using Payouts to all the clients.
Really bad solution imo but its convenient for them because they charge more transactions instead of allowing you to do everything on a single transaction.
I offer a service 2 times a year. Some of my clients desire to make payments rather than pay in one lump sum. They need to choose the amount they desire to pay and when they (date) they want to pay on. I just need PayPal for the processing and also the tracking for the amount they have paid. It also needs to not accept any more funds once they have reached the set amount.
Has anyone heard of this capability?
You time and consideration.
Have a look at https://developer.paypal.com/docs/classic/products/paypal-payments-pro/
They implement payment by instalments on their end with Paypal Credit. I believe you will still receive the entire payment in one go, but the customer will have to pay it off to Paypal directly. Alternatively, you may be able to hack something with recurring payment, though you would need to cancel it once the total amount has been reached; it's definitely not meant for that.
Regardless, you are probably better off contacting paypal support for this, since this isn't really a programming specific question.
I am working on a startup in which the merchant has to disburse funds to customers periodically, from time to time. Think of this as customer loyalty program, cashback etc.
Does dwolla support the ability to transfer money from merchant to customer?
Technically it seems the same as from one bank account to another but just wanted to confirm if that is the case. (Is there a refund API that can help with this?)
Also, would something like this be against the terms of use ? Is there a possibility of running into compliance bottle necks?
Appreciate your help in this as this would help me choose dwolla as our payment processor.
Thanks and Best Regards,
I'll let Michael chime as well but the generic answer is yes. You can do that. You'd simply make an outgoing payment from a bank (or dwolla balance) to the receivers e-mail or phone #.
Not against the terms at all. Let us know if you need any guidance during the process.
The scenario you're describing sounds completely legitimate to me. The only caveat I can see here, is the fact you'll have to store the merchant's PIN number in order to periodically send money from their account, without their direct involvement (or am I understanding this wrong?) - our ToS requires that you hash/encrypt said PIN in your DB.
Regarding a refund API - we don't have one yet. You'l have to simply use the send() method, and if you're so inclined, feel free to break the amount to $10 chunk to avoid any fees.
Bottom line: you should be good to go.
I want to provide a question and answer service (I know there are thousands of such sites on the internet) to my users where someone can ask a question by specifying how much money they will give the person who provides a good answer.
When a good answer is provided, is it possible to take the money from the questioners paypal account and send it to the answering persons account automatically?
Basically, what I don't want to do is take payments from the questioner and hold it in my paypal account, then pay the answering person when his/her answer is accepted.
I will be using a LAMP configuration to make the service.
Neither the PayPal API nor the PayPal service in general provides for automatic person-to-person payments that are initiated by a third party. In other words, you must either be the payer or the payee in order to participate in a transaction; you cannot do it on behalf of another user.
Have you looked into PayPal Adaptive Payments API? From what I know it supports person-to-person money transfer. For more info visit
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_APIntro
Hope this helps.
You can use the PayPal Adaptive. Using this you can transfer money from one account to another account. Download the sample source code from GutHub https://github.com/paypal/adaptivepayments-sdk-php
I'd like to think wildly here (meaning not thoroughly so forgive me if there are mistakes). I think there are a few PayPal products you can consider. They do not perfectly fit, but here they are for your reference:
Auth / Order, Reference Transaction (aka RT), and Adaptive Payment (aka AP, but it doesn't fit your situation very much).
As I understand, your scenario would be like this:
The questioner posts a question, and agrees to pay a certain amount of money, say $5.
You don't want to hold the money. (hmm this is hard)
When a responder answers the question, and the question is selected as the best, the money is paid automatically from the questioner via PayPal.
With Auth / Order, it works like this:
The questioner "auth" you to take the $5. This money is NOT charged yet, but is still in the questioner's account. The amount can be honored too, just like you book a hotel. (Note you can honor the money for at most 29 days.)
When an answer is selected as the best and the responder is to be paid, you capture the money from the questioner. This way, they money is now in your account. (I know you don't like this...)
Then you pay the responder immediately. You can transfer money, you can use Mass Pay API, you can use PayPal Payouts API.
Well I know the best case would be that the money never appears in your account, not even a millisecond. But this is what I can think of, "immediately" is the closest to "not at all". Another problem with this way is, it's done in two steps, and in each step you or someone has to pay the fee. When you as the platform gets the money, you pay the fee, and then when you send it out, it depends on which product you use. But the good thing is, the money is never charged until it has to be charged. And it doesn't have to be charged if there is not a good answer at all.
With RT, it's similar to Auth / Order, it's an agreement between the questioner and you (the platform). The agreement lasts longer (2 years I think), but you still have to pay the responder, and you can't honor the money, meaning when you capture it, you may fail. Good thing is (or maybe this is the bad thing), you can charge the questioner many times with only one agreement.
With AP, it provides "Parallel" payment, meaning the questioner pays you AND the responder with only one payment, and you can share the payment with the responder, and you can decide who receives how much. You can also decide who pays the fee. But the problem is, the questioner has to be present to make the payment, so it's not done automatically without the questioner. (Express Checkout / EC does parallel payment too with some differences, also on the fee thing. So if you want to go AP way, you may also want to consider EC because it's a lot easier to integrate.)
I would go for Auth / Order. But maybe you can get in contact with PayPal merchant technical services and ask for more details.
https://ppmts.custhelp.com/
Or, here is the website of their documents:
https://developer.paypal.com/
Hope this helps.
Many posters have said that AP is a good choice. This is correct. You will need to request an application which provides an app ID once your app is approved by the vetting team. You apply here:
https://www.paypal-apps.com/
Provide as much detail as you can so that they don't have to come back to you with questions about your business, etc. Once it is approved, you can use the app ID provided and start development in a live environment.
If you want to get the API working while they review your app, you can use sandbox. https://developer.paypal.com/docs/classic/lifecycle/ug_sandbox/ I believe that the vetting team requires that you have a sandbox account / setup so that they can test your implementation once you are done.
Don't be fooled because you have ALL API permissions in sandbox. So if you forget to request a needed method like mass pay, you will not have that feature in live, even though it worked for you in Sandbox. If you need a feature, request it WHEN YOU APPLY. Otherwise, you will need to start a new app request. This isn't a big deal, but if time is of the essence, you will have to wait (usually 24 - 48 hours or so) for the app to be approved, barring any questions / requests that PayPal has for you.
Integration guide for AP:
https://developer.paypal.com/webapps/developer/docs/classic/adaptive-payments/integration-guide/APIntro/
API operations and operations for Adaptive Payments:
https://developer.paypal.com/webapps/developer/docs/classic/api/#ap
I'm trying to integrate a payment mechanism to my site. The scenario that I need is not trivial and can be explained by the following example:
User pays upfront for a subscription program (i.e. receiving Netflix). User is able to make changes to the subscription (i.e. change number of movies checked out each time from 4 to 2)
User is able to buy additional one time purchases via the provider's site (Netflix) supplied by 3rd parties. These items (i.e. popcorn, snacks) get billed to the same credit card as the subscription without having to go through the process of resubmitting the credit card information.
Of course, my site takes also a small fee for the transactions :-)
I was wondering if this is supported by PayPal, Google Checkout or someone else.
Thanks.
The Paypal api can handle all of those processes.
I seem to have dropped the ball on what kind of answer you wanted so I'll leave it at that.
If you have some feedback, more direct questions I will try to answer as much as I can
--
The money would best go through you first, unless somehow you can convince your customers its normal to bill them per item. Also if they pay by credit card you should only bill them once as you would incur fees on every payment. I don't know of anyway to bill once but distribute the payments.
As for the paypal docs..
Very good resource, there is also some sample code for most major web languages
Also this will get you started if you don't have a developer login
Their developer support is also pretty good. One thing a lot of people seem to screw up when starting out with the paypal api is not setting the latest version in the configs so don't forget to update that to the latest release. :)
Disclaimer..
Yea I know there is a lot of bad press about paypal and crazy stuff happening, but they do get the job done most of the time, its not my fault the customers love to use it.