Which payment gateway should I choose from among Authorize.net, PayPal & Google Checkout?
Is there anything wrong if I provide all ? I'm planning for express checkout methods in all the three services, the direct credit card accepting service.
The more choices you offer, the more choices your customers have, so no, there is nothing wrong with offering all three.
If you potentially have customers from the EU or Asia, you may want to investigate options that are popular in those regions as well.
Keep in mind, PayPal tends to freeze money in account for some reason and have huge problems even answering email with 24 hours.
Paypal is of course the most well known and respected, however the answer actually depends on the amount of revenue your company will make (monthly and yearly averages), the average price per transaction and the number of debit card vs credit card payments you are likly to take. Without these figures it's nigh on impssible to determine which one is cheapest for you.
Authorize.Net is only a payment gateway, not a payment processor. You need to have a US based merchant account to use with Authorize.Net.
Paypal and Google Checkout are third party payment processors. They essentially are the payment gateway and merchant account rolled into one package.
It's worth noting, from the research I've done, using PayPal is cheaper than credit card processing directly. They charge less of a fee (I'm assuming because they process everything themselves, and don't go through some third party to get to the credit card company).
Related
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 need to create a subscriptions system in my app, where users can subscribe to a certain package and they must be billed monthly.
Moreover, I need to charge their credit card automatically, and without requiring them to have a PayPal account.
I read about https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=merchant/erp_overview, but is seems it's not available anymore as I click on sign up and it gives me an error ("Sorry, this feature is not available at this time.").
Then I've read about PayPal Standard Payments, which have a subscription method (https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/subscribe_buttons/)
From what I can read there is that this is what is suitable for my use case, and it says that I need to enable the above mentioned service, which it doesn't work.
Can someone point me in the right direction on what service should I use from PayPal in order to implement recurring payments (basically my users will subscribe themselves to a service on my website, and I need to charge them monthly).
Thank you.
If you're wanting to handle credit cards directly I would highly recommend going with Payments Pro w/ Recurring Payments APIs.
You'll have to pay a monthly fee to get it all activated, and it's a little bit more expensive than what you were looking at, but it will give you much greater flexibility building your application(s) into various experiences for your buyers.
I have a bit of experience setting up online payment systems that accept credit card numbers and then pass them over to a gateway for a one time payment.
However, I now need to setup a system that can handle automatic recurring billing - where a user provides their credit card number and is automatically billed on a monthly basis from that point forward.
I am wondering what the best way to approach something like this is? (I notice that Paypal Payflow Pro does have a recurring billing feature, but I am a bit unclear on how it works.)
Any advice on the best method / service / gateway for implementing recurring billing? If possible, I would greatly prefer to avoid keeping a local record of credit card numbers for repeat processing.
Thanks (in advance) for your help.
There's a midpoint between building your own recurring billing and Auth.net's ARB or PayPal's recurring billing (both of which have their disadvantages). There are a number of providers that handle all the details and complexities of recurring billing, and simply report the charges to your payment gateway for processing at the interval you determine.
The most critical piece to look at is which services to credit card tokenization and support credit card data portability - this will ensure that your customer data isn't locked in with a billing provider and that you can take it with you if you choose another provider in the future. This also means that these providers store the customer credit card data for you, so you can greatly reduce your PCI compliance.
Take a look at Recurly (Disclaimer: I manage their customer and technical support) and Braintree. Both services will handle your recurring billing, credit card tokenization, and support credit card data portability.
Recurring billing is easy to handle and offload to a third party if your recurring amount is constant (e.g. the amount a user pays never changes in amount or frequency). Services like Authorize.Net's Automated Recurring Billing (ARB) and Paypal Payflow Pro recurring billing allow you to have those companies handle the actual recurring payments which means you don't have to store credit card information on your servers or even do anything once the subscription is created through their APIs.
If your subscriptions will vary in terms of cost or frequency, you'll need to use a service like Authorize.Net's Customer Information Manager (CIM) to create payment profiles for your customers. Basically you're storing credit card information on Authorize.Net's servers and whenever you want to make a subscription payment you tell Authorize.Net to charge the amount due to that payment profile. The drawback to this is you essentially have to build your own subscription system.
You usually find the recurring billing features in middleware gateways like Payflow Pro. In that case, it is invoked by a variation of the API you use for card processing. You usually set up the time span between billings and they perform the billing. You usually then reconcile the billing with the report that your processor sends you each month. In some cases, the payment gateway will post a notification to you that the billing was performed. You still have to reconcile the payments with the processor report because sometimes the notifications fail.
Canceling the recurring billing is also another API call.
If your gateway doesn't have the recurring feature, you obviously have to set up the billing yourself. This of course leads to storing card info and so forth. In this case, you usually tell the processor that it is a recurring transaction (which the gateway will do for you) so you get a discount on the transaction fees.
First, let apend the statement above "...tell the processor that it is a recurring transaction ...so you get a discount on the transaction fees". The true cost of credit card processing is a percentage fee and a per item fee based on the type of card presented ( and some other factors I won't delve into here.) The point being, on a wholesale price plan, the price would be the same regardless of whether it was recurring or not because there are no special rates for 'recurring' in interchange. But I digress.
"Any advice on the best method / service / gateway for implementing recurring billing?"
Don't take on storing credit card data no matter what. You can't afford the liability.
The right choice depends on several factors.
As to credit card portability, has anyone gone to Wells Fargo/ First Data and gotten their data out? (Braintree ISO/MSP). I guarantee it won't be pretty no matter what so I would focus on the right long term solution, rather than the exit strategy, though it will certainly weigh in.
Here's questions that need to be answered:
How many transactions per month? For very low volume, maybe a few hundred, pick paypal pro. It's easy to get into/ out of.
Are people more likely to pay with consumer cards or business credit cards? Interchange optimization is important if business cards. (CenPOS automatically optimizes the transaction for lowest interchange qualification, paypal and authorize.net do not)
What methods does my client accept payments? self pay on internet only? Phone orders? Mobile payments (special events or retail)? Choose a gateway that fits all their needs.
Do you need to charge on specific days- ie the 1st and 15th? Or any time? If on specific days, how will you prorate? Check the answer against the gateway flexibility.
What happens when a card expires?
What happens when a transaction is declined?
Who will need to see the payment data for customer service? How will they access it?
Determine your needs, then figure out which ones meet them.
For the record, CenPOS is the most robust solution, but may require more steps to integrate since they are newer to ecommerce.
Disclaimer: I've been a business user of paypal and authorize.net for probably a decade and more recently CenPOS. I'm also an authorize.net reseller, and CenPOS direct agent.
Just a heads-up about Payflow Gateway's Recurring Billing:
Their Instant Payment Notifications (IPN) is a fantastic feature, but only applies to their legacy APIs. For the time being, THE ONLY WAY to be notified by PayPal of a successful (recurring) billing transaction, is by inquiry. You will need to maintain a schedule to inquire, and send an individual inquiry for each, scheduled recurring billing transaction, one at a time. PayPal will not notify you if, for example:
A transaction is approaching
A transaction has occurred
This transaction was successful
This transaction resulted in fault
A credit card is approaching expiration
A dispute occurred
... and so on.
In my opinion, this renders their service useless.
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).
I am trying to use the Recurring payment API offered by PayPal.
I have a scenario which I am not able to address directly. It goes like this.
We have a website where we sell some services. Now the services are charged per user license. A user can buy/cancel user license in between. We want to offer the customer a recurring billing option. We have to notice here that the amount may vary each billing cycle based on the number of user licenses the customer uses during that cycle.
Is there any way I can achieve this using PayPal recurring Payment API's.
I realize this is a very old post, but it still shows up for Google searches, so I thought I'd add:
Paypal does allow you to do this now, using their new adaptive payments api.
Authorize.net also has a service that might work called Customer Information Manager.
The recurring payment option is a fixed amount that the customer pre-agrees to pay each month (or period). To do what you're trying to do, a customer would have to pre-agree to pay whatever amount you decide to charge at a later time. This means pre-authorizing an unknown payment amount, which will not be allowed by any payment service.
Your only options are:
Bill the variable amount each month (i.e. no subscription).
Set up a subscription where the monthly amount is the maximum that could potentially be billed, and then refund the difference each month.
Good luck with #2 - I would never agree to such a thing as a customer, personally.
What you're looking for is covered in the UK by the Direct Debit system, however given the potential for abuse it's very tightly controlled and there are a lot of restrictions and regulations governing it.
I'd strongly suggest you just set up a monthly invoicing system that just bills the client each month.
I don't know its meaning full or not as it is a very old post.
Instead of creating recurring profile on PayPal Server, You can store the customer's credit card on the PayPal using REST API: https://developer.paypal.com/docs/api/#vault then every month you can fetch it and charge it like recurring Payment Or When client is no longer with the services then just remove its card from PayPal.
I suppose Authorize.net SIM method also does the same.
Hope this make sense.