PayPal, 2Checkout, Authorize.net, Alert Pay, and a host of other payment gateways…have you ever thought of how they actually work? And by actually work, I do not mean the simple redirecting to the payment gateways site, paying for an item, and being redirected back to the merchant site in a with a success or failure message.
Truthfully, for the most part, what I have just described above is to a great extent, how payment gateways work but there is more. A lot more. After developing quite a few PesaPal modules now for various systems, namely GeoDesic, Flynax, WordPress, Joomla, eDirectory, Jamroom and SkaDate to mention but a few, I believe I have a deeper understanding of how payment gateways actually work. And below is a general description of this, from a developer’s perspective.
There are four parties whenever you are dealing with a payment gateway on a site, namely;
- The customer, who is buying a product(s) or service(s),
- The merchant, who is selling the product(s) or service(s), that the customer is buying,
- The payment gateway, the company that links the merchant to the payment provider
- The payment provider, the company or system that actually has the money that is to be used to pay for the product(s) or service(s),
Just to clarify, suppose I was buying a shoe from Vafara and I wish to pay using my VISA credit card but with PayPal as the payment gateway. In that transaction, I am the customer, Vafara is the merchant, PayPal is the payment gateway, and VISA is the payment provider.
So, to connect the money on the credit card to the merchant, this is actually what goes down.
The merchant will have to already be registered with the payment gateway, and by so doing, will have been provided with a unique identifier (in the case of PayPal, this identifier is the email address the merchant registered with). This unique identifier is normally safely recorded in the site and is parsed to the payment gateway. Other useful information is also parsed, with the fundamental parameters being amount to be paid, and a unique order identifier for the order or transaction provided by the merchant site and the callback URL the payment gateway should call upon successful completion of payment. Other details like the name of the product, or list of services being bought, e.t.c, may also be parsed to the payment gateway but this is subject to the features offered by the payment gateway. It should be noted that this data is normally sent to the payment gateway via POST in a bid to increase security. Use of GET method would allow easy manipulation of parameters by simply changing the URL being called and is therefore highly insecure.
The payment gateway will then provide a page, with options on how the customer can use to pay for what he/she is buying. Whether it be VISA, direct bank transfer, or by credit that the user has stored or saved with the payment gateway. The user then choses the payment method, providing whatever details are needed to complete the payment, and confirms the payment. Other details needed to complete payments include things like card number and CVN when paying with a credit card, or login credentials when paying with credit saved with the payment gateway.
Upon confirming the payment from the payment provider, the payment gateway will then call back the website using the callback URL provided by the merchant. Now this is here where things get interesting. When the payment gateway calls back the merchant site, it returns normally returns everything that was parsed to it in the first place, and adds one more parameter – a transaction id, one generated by the payment gateway. Please note that this data normally does not include information as to whether the transaction was successful or not (transaction status). This data, by the way, it still parsed via POST.
Once the merchant site receives the gateways’ transaction code, the merchant site is normally charged with returning the received data back to the payment gateway. Once this is done, the gateway then calls the merchant site back, this time, adding a transaction status, whether failed, success, or pending. Only then can the merchant site then mark the order with the transaction status and then notify the customer if all is well, or if things are thick. The POST method of parsing data is still in use during this process.
It might also be important to note that with some payment gateways, the URL called to parse transaction data may not be the same as the URL called once the payment is done. An example is PayPal, which, if the merchant is signed up for what they call ’Instant Payment Notification’ or ‘IPN’, the merchant site will parse a notify URL, in addition to the callback URL normally parsed. The data being sent back and forth via POST will happen on the notify URL, with the callback URL simply being where the user is redirected upon completion of payment.
Lastly, it might also be important to note that while the gateway is using a different URL to notify the merchant of the status of a transaction, there are also a few things that they do that help the merchant.
Most payment gateways will simply not allow you to return to the merchant site until the payment is successful. If you do not have enough credit, or your card is unverified et cetera. Whatever the reason, payment gateways normally keep the customer on their site until they can get a successful payment for the amount(s) stated. In case a successful payment cannot be reached, then a cancel URL is normally provided for by the merchant, where the user can return to to try again, or pick another payment gateway or payment method. This is normally placed somewhere on the payment gateway site and labeled ‘cancel and return to checkout’.
And there you have it. The inner workings of a payment gateway. Just in case you may be wondering why I am doing this, well, lets just say that I have a few bones to pick with some payment gateways. And I will be picking them soon, on ways they can improve their services, to make them more seamless and easier to implement.Share