If you’re selling stuff online, you need a “payment gateway”. That’s something that sits between your website and the bank, so that you can accept money over the Internet. PayPal is the biggest and best known of these. As far as I can tell, different payment gateways work in three different ways. (There may be more, but these are the three I’m aware of. I’m also including one other way of taking money, which is a gateway for payments, but isn’t a “payment gateway” according to the standard definition.) I don’t know of any standard terminology to distinguish these methods, so I’ve invented my own.
So, here’s my breakdown of five types of checkout. (Yes, five.)
1. Orders only
There are, I said, four types of payment gateway (or, three plus a bonus fourth), but five types of checkout. That’s because it’s possible to have something like an online shop where no money actually changes hands. I’ve built a site like this. It displays products, and has nice little “add to cart” buttons, so you can build up an order. You can then review your order and submit it. Then you get an order ID. The owner of the site will then contact you separately to arrange payment and delivery. This method works fine for the site in question (which is for a trade-only wholesale merchant in the fashion business).
This sort of checkout process is by far the easiest to build, as there is no need to interact with* any other system. It’s entirely self-contained.
2. Internal checkout
I call this one “internal” because all the work goes on behind the scenes. You have a form on your website into which the user enters their credit card details. (Watch this: you’re receiving credit card information, so now you’re under a legal obligation to deal with it carefully.) But we don’t store this information, instead, our webserver submits that credit card data to the payment gateway. The response from the gateway indicates whether or not the transaction was successful. (Submitting the information and receiving the response can be a single operation. The exact workflow will depend on the payment gateway concerned. The only one I’m familiar with, Realex Payments, receives the credit card information as a POST request in XML format, and returns the response (also in XML format) immediately.)
Remember, talking to the payment gateway is all happening behind the scenes. The customer has no idea how it works, or which payment gateway you’re using. They enter their credit card details into your website, press submit, and get a response of “payment made” or “declined” or whatever from your site. They have no need or reason to know or care which payment gateway you’re using.
An advantage of the internal checkout method is that you are entirely in control of the user experience. The customer never leaves your site; never sees any logos or branding other than yours. And if you think the checkout process is clunky and difficult to use, you can change it.
Realex Payments, based in Dublin, is one of the largest such operators in the European market. PayPal also supplies this type of payment gateway, but only in the UK, the USA, and Canada.
3. External checkout
For the external checkout, the customer is sent away to an external site to complete the payment process (hence, as you may have guessed, the name). So when the customer has added a few items to their cart, they can click on a button labelled “Pay with X”, proceed to that other site, and pay there. There are a few advantages to this. For a start, customers may be more likely to trust a big site like PayPal or Google with their credit card data. Also, they may already have an account there, and so be able to pay without having to type out their credit card information at all. And, from your perspective, you’re free from having to worry about credit card security: you never see any credit card information at all.
Another thing about the external checkout is that you aren’t limited to just the one of them. There’s nothing to stop you giving the customer options: you can put “Pay with PayPal” and a “Check out with Google Checkout” buttons on the same page, and give the customer a choice. (You can also give the customer the choice of using the internal checkout, of course.)
A while later, the customer will probably arrive back on your site with a similar POST request containing information that they’ve paid. This is all well and good, but how do you know it hasn’t been faked? Also, what if they never do come back to your site? What if they go to PayPal, pay, and then continue on their merry way without visiting your site again? Well, we don’t rely on that.
In our initial submission to PayPal, we send full data about all the products being purchased: ID, title, price, tax, shipping costs, and suchlike, but we also send them a URL and a unique tracking code. When the payment is made, PayPal posts all this data back to that URL (we call it the listener URL, because it sits and listens for PayPal to call it). That’s when we know the payment has gone through. Oh, wait, no we don’t. That could have been faked too. Remember, we aren’t contacting PayPal directly. We haven’t posted any information to PayPal’s servers. We’ve given information (including the unique tracking code and our listener URL) to the customer, and asked them to send it to PayPal. They could be tricking us. The “payment made” response to our listener URL could be a fake too.
So this is the point where we do contact PayPal directly. As soon as we receive the “payment made” call to our listener URL, we send all the information back to PayPal, basically asking “Hey, did this actually come from you?”. PayPal responds immediately, either confirming or denying the call. If PayPal confirms it, we mark the payment as made.
Hang on a second. Someone ordered on our site several thousand euros worth of goods. We created an order, gave it a unique tracking code, and sent them off to PayPal. Then we got word from PayPal that a payment had been made for an order with that tracking code. But the payment was only three euro. What now? And that’s why our listener doesn’t actually mark a payment as made as soon as PayPal confirms it. Instead, it reads all the data from the PayPal response, which includes full details of every item bought, its cost, and all related handling and shipping charges. We then verify that this all matches up with the order we have on record for that unique tracking code. And only then do we mark the payment as made. And we store the order with the PayPal transaction ID (this ID is generated by PayPal, and is unrelated to the code we generated and have used to track the order so far).
When the customer returns to our site, they do so with a POST request from PayPal which includes the transaction ID. This request cannot have been faked, because a faker would have no way of knowing that transaction ID, which was generated by PayPal. So we can be happy that the person landing on our site now is the person who just made the purchase, and we can show a receipt. Everything is hunky-dory.
Except … wait for it. Sometimes, PayPal will return a customer to us before sending the order confirmation to our listener URL. So if a customer lands on our site with a transaction ID we don’t recognize, we can’t simply assume it’s an error. It might be an order which hasn’t come through yet. So we show the page and wait on it a while for an order to come through, checking occasionally (using Ajax) whether an order with that transaction ID has been processed. If it has, we redirect the customer to the receipt for that order. Failing that, we eventually give up.
Just to be slightly more awkward, in PayPal’s sandbox (test environment), there’s no way to force delay the call to the listener URL so you can test this workflow. You just have to code and hope it works. Read that sentence again: Sometimes, PayPal will return a customer to us before sending the order confirmation to our listener URL. Sometimes. There’s no way to force that situation so you can test it.
Also, in case you thought that was too easy, PayPal provides a bunch of other services. It can supply shops which are managed entirely by PayPal: you log into PayPal and create your products and set their prices, and PayPal will give you little HTML snippets to put into your site. And so you can have a shop with no server-side coding on your part at all. This is all very well, but PayPal puts all the documentation for these two completely different situations together into one massive, badly written, repetitive PDF document, and expects you to read it. PayPal’s documentation is easily the worst I’ve ever seen anywhere. It is eye-bleedingly awful. (Realex Payments, by contrast, has very well-written documents. They are to the point, self-contained, and clear.)
The only external checkout I’ve built worked with PayPal. Google Checkout is another provider in this area, and Realex Payments also provide an external checkout service. And, so, no doubt, do many others. As I said earlier, there’s nothing stopping you giving your customer the choice of all these and more.
4. Redirect checkout
The “redirect checkout” is basically an external checkout which pretends to be an internal checkout. The customer enters their credit card details into a form on our site, but the form submits to an external site, which then redirects straight back. The customer, unless they are paying close attention to their browser, does not even realize that they’ve left the site they were on. From a coding perspective, this is essentially the same as an external checkout, but from a user’s perspective, it’s the same as an internal one.
I’ve never actually built a site which used a redirect checkout, and couldn’t name a provider. I’m not making it up, though. It’s something I’m sure I’ve read about somewhere.
5. Telephone payments
This is the one which doesn’t actually count as a “payment gateway”. The official definition of “payment gateway” is all about credit cards and suchlike, and this method does not require credit cards.
If every product on your site is the same price, and you’re fairly confident that most people will be buying only one product at a time (we’ve done this, for a site which accepted classified advertising), you can accept payment by premium telephone number. First, get a phone number which charges people a fixed price per call, rather than by the second. Then, set up your checkout to create a unique random four-digit number for each order. Then, set up Asterisk to answer the phone, accept input of the four-digit code, and send a signal to to site that the order has been paid.
I did work on a site like this, but I had nothing to do with the Asterisk end of things. It’s a clever program for answering phones and managing phone menu options and phone trees.
* I did not say interface with. You can comment below to thank me for this, if you like.