I am working on a website which involves users paying to each other. The payment gateway is going to be paypal., now does it require every user to have their business account with paypal? (or) is it possible to let them have their business account with any business account provider?.
Would appreciate any pointers. Thanks!
Define what you mean by 'business account'. If you mean a merchant account at an acquiring bank: no, that's not required. If you mean a PayPal Business account; no, that's not require either, recipients can have a Premier account as well.
Technically, you'll want to look into Adaptive Chained Payments -- this allows you to chain the payment along multiple recipients (up to 9, if I recall correctly).
Have a look at Introducing Adaptive Payments
Or dev guides
Related
In my Windows-Desktop App I want allow to transfer money from one Personal-Account to another Personal Account. What is the best way to do that?
Using Payouts seems to requiere a business account for the money sender.
In some countries, PayPal can facilitate fee-less "friends and family" payments from the PayPal balance or funding sources that don't charge significant fees, like bank accounts. If this is what you are looking for, all you can do is have the receiver of the payment create their own https://paypal.me link and direct the sender there, or if not using paypal.me then direct the sender to https://www.paypal.com/sendmoney to set up the transfer themselves.
Otherwise, only payments for "goods and services" are possible. There are many ways to set up a PayPal checkout between two accounts, and the receiver's account type is generally not of much importance although this may vary by country due to local legal regulations. A web page with a standard PayPal Checkout to pay another account can be set up with HTML/JS, so you could have your app show a browser with such a page. Alternatively, the much older (~20 years) integration method that uses a full-page redirect is to create a link with this template:
https://www.paypal.com/webscr?cmd=_xclick&item_name=purpose%20of%20payment%20goes%20here&amount=100¤cy_code=USD&business=emailusername#example.com
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 have a hard time finding clear answers to what's involved in implementing following case of chained payments using PayPal...
We are based in New Zealand, offering following types of accounts:
https://www.paypal.com/nz/webapps/mpp/compare-business-products
Currently, we have a Business Express Checkout account.
Our browser app allows users to set up product configurators. The configurators are then used by other users (consumers), to purchase configured products.
A. Simple payment case:
When consumers pay for the configured product, we are the primary recipient, and pass on the payment to the owner of the configurator, minus our revenue share %.
B. Complex Payment case:
Same as A, but multiple secondary recipients. We can't use parallel payments, because the multiple recipients need to be obfuscated.
For each case:
If not chained payments, what is the best fit PayPal option? Which API, if applicable?
Does the Express Checkout account support the required API? If not, which account type, available in New Zealand, does?
Which of the parties requires approval from PayPal? What type of approval? How long does the approval process take, and what affects its success?
Any other considerations when moving from the sandbox to the live setup?
What's the cost of the solution?
We'd obviously favour solutions that require minimal approval hassle, as we will be dealing with many configurators.
It seems like Adaptive Chained Payment is your best option.
Express Checkout support parallel payment but Express Checkout does not support chained payment.
You need a apply for an APP id if you're using Adaptive Payment. I could not answer how long it will took for them to approve.
Everything is the same when you're moving in Live. Just make sure your App has been approved, and the endpoint is change to Live.
The only cost is the PayPal fee's that PayPal collect for each transaction you made.
I'm investigating option to use chargify.com service for recurring payments. They state that i need both merchant account and payment gateway account. But then some websites says that paypal is both merchant account and payment gateway. Does it mean that to use chargify i can have only paypal busniness account without separate merchant account?
If you're going to take payments of any kind you need some sort of merchant account. Over the years things have gotten a little bit easier to work with.
It used to be that you had to have separate companies/accounts setup: 1 would act as your merchant processor and the other would be your gateway. Both carried their own set of fees.
As these merchant companies were competing with each other they began offering their own gateway services so that their users wouldn't have to get that from a 3rd party. Now they pretty much all do it.
PayPal, PayLeap, Group ISO, Optimal Payments, Stripe, Intuit, etc. are all merchant service providers that offer their own gateway solution.
Having a gateway specific to a merchant provider is great, but there are some disadvantages. For example, if you get one gateway integrated nicely into your website but then you decide you want to change merchant account providers for any reason you'll have to re-integrate everything you've done on your website with that new provider.
This can be avoided by using providers that are still compatible with popular gateway services. PayFlow and Authorize.Net are the most popular ones. PayFlow was actually acquired by PayPal a while back so they can provide their merchant services on the PayFlow gateway...a very popular gateway that works with many other providers...and still offer you the all-in-one solution.
Both PayFlow and Authorize.net are compatible with lots of merchant providers, so if you feel like you might want to switch at some point it may be wise to stick to one of those gateways.
All of that said, I would recommend you go with PayPal. They have all sorts of payment features outside of direct credit cards, and if you want direct credit card processing they can offer that, too, on their PayFlow gateway (or their own API that they call DoDirectPayment).
I hope that helps more than it confuses.
Using PayPal you don't need a merchant account.
Sources:
https://www.paypal.com/cgi-bin/webscr?cmd=_payflow-about-ima-outside
http://www.webtys.com/small_business/article_paypal_vs_merchantaccount.php3
https://www.paypal.com/webapps/mpp/compare-business-products
http://chargify.com/payment-gateways/
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).