What are some options for taking payments on my website?
These options have been recommended already, but here is my reasoning my I recommend each to my customer:
- PayPal (or Google Checkout or similar) is great for small websites. It's easy to setup and often they don't have a monthly charge, only a per transaction charge. But it can be confusing for the user as they'll be sent to a website that doesn't look like yours and people often get confused with PayPal because the link to pay without an account is small and hidden in the bottom left. You can also get the account and start using it all within 1 day.
- Full payment processor (my recommendation is Beanstream). When you want to integrate the payment solution directly into your website and have a full payment solution integrated into your site, this is the way to go. It will allow you a lot more flexibility and won't be as confusing for users. You can also do debit transactions. They usually have a monthly fee and do credit check. Some of them also have contracts. Within this option are 2 options:
- using the payment processors payment page: this removes the requirement to go through additional security checks on the server. Most times you can format this page as you want and use their secure server to store image, CSS and JS.
- take the credit card on your server and pass it to the payment processor, receiving the response back and doing the appropriate processes. This allows even more customization, but requires additional security checks and an SSL certificate.
- A subscription based shopping cart where they have a shopping cart and payment solution that you pay for on a monthly basis. This has the advantage of not having to do the integration yourself. But they are much less flexible than doing it yourself.
These are the 3 options I've worked with. I'm sure there are others.
Although Darryl has answered your question well I would like to go a bit more in depth here.
I've developed a few sites now that use a variety of payment systems. Depending on how many payments you process and how you want to take payments there are a number of options available to you. You may also note that many large sites offer a number of payment solutions (e.g. credit cards, PayPal and Google Checkout) to their customers in order to offer them the greatest number of options to pay.
There are two basic things you require in order to take payments online:
- A merchant account
- A payment provider/gateway
Companies like RBS Worldpay and PayPal offer the two as a package but other companies like Sage Pay offer them separately which can be quite deceiving in figuring out the costs. My advice would be to draw up a spreadsheet between the different companies you finally settle on and work out which will be the most cost effective for you.
Here are a few questions that you may want to ask yourself before deciding on the payment options you wish to provide. I will list them below in bold with further information relating to each below.
How many transactions do I expect to take?
Depending on the number of payments you will take monthly you may prefer to go down different routes. This will mainly be determined by the costs of the payment providers.
If you have a low number of transactions then you may not wish to pay a monthly fee which some payment providers charge. So in this circumstance you would probably go for a PayPal or Google Checkout account. PayPal offer a service they call "Website Payments Standard" where a percentage (1.4-3.4%) of the sale is taken plus 20p and no monthly fee. This would be an attractive solution if, as I said before, you have a low number of transactions. However if you wish to take payments on your site then this will not work for you.
Do you want your customers to remain on your site to make a payment?
There are two options here:
- Have a hosted payments page much like what Google Checkout, PayPal, RBS Worldpay, and others offer where potential customers are redirected to a page hosted by one of the aforementioned companies where the customer will fill out their billing and credit card details to make a payment. Thereafter they are redirected back to your site.
- Your potential customer remains on your site and completes billing and credit card details which are then sent to your payment provider for processing. This method is commonly known as the XML Direct or XML Invisible method and it does as it says. It invisibly sends the payment data to your payment gateway using a series of XML messages to confirm payment. The most commonly used payment providers in the UK are PayPal, Sage Pay and Worldpay but some might disagree with me on that. Nevertheless whichever company you end up with you must ensure that they offer your required payment solution and they don't burn a hole(s) in your pocket(s)!
The complexity of the two are obvious in that option 2 requires a lot more work. Furthermore you will run into the "PCI compliance" area regarding option 2. For example, when using RBS Worldpay, they require your web site to have passed a PCI compliance scan before they enable the XML Direct payment method for your account.
PCI scanning can be a costly process. For example, the cheapest and most user friendly I've come across has been McAfee Secure PCI scanning at $319 pa for on demand scanning. UK companies seem to really overcharge on this so I shy away from them.
Certain shopping carts actually have built in functionality that enable the XML direct payment method for certain payment providers which may make it easy for you to integrate this solution into your site. This will probably influence your choice in deciding which payment provider to go with.
Finally here is a price comparison between RBS Worldpay and PayPal for accounts that offer the XML Direct payment method:
PayPal
- Setup fee None
- Monthly fee £20
- Transaction fee 1.4-3.4% per transaction + 20p
RBS Worldpay
- Setup fee £75
- Monthly fee £15
- Transaction fee 3.35% per transaction + 15p
Check out Braintree Payment Solutions. They allow you to integrate the payment form into your own website but handle all of the sensitive data directly so you don't have to deal with PCI-DSS compliance.