Online Payments — the basics
Working with software development is very challenging. You can frequently change the target business you’re developing on. If you’re starting on a project in which doing a payment is a must-have, then consider this article as your starting point.
Basically, the shopper adds its payment details at the merchant’s checkout page which requests a payment authorisation to the acquiring bank that bypasses it to the issuer. This information will be validated and an authorisation or a decline is returned. There’s a second part in which the merchant reconciles all the payments ensuring the transactions were made successfully.
It seems a lot of new information and specific terms right?
Who is who?
There are multiple entities when a payment is being processed.
The shopper
The customer. The shopper is the person browsing your website. Selects the products that wants to buy and supplies to the platform all the required details to process the payment.
The merchant
The company selling the products. The website should provide product detailed pages in which the shopper selects the product quantity and adds it to the cart. The merchant must store all the purchases related information so it can handle post-payment processes.
The acquirer bank
An entity contracted by the merchant. If the merchant processes payments with credit/debit cards, one approach is to do it directly with an acquiring bank. This entity will receive the merchant authorisation requests and deal with the issuing bank for approval. Processing credit/debit cards directly with an acquiring bank takes the merchant into multiple risks and legal compliance such as Payment Card Industry Data Security Standard (PCI DSS).
Another approach is to integrate one or multiple Payment Service Provider solutions like Adyen, Braintree, Stripe (… or others). This way, the merchant reduces the risks and effort to do online payments as the majority of the work is taken by these 3rd party entities.
The Issuer
The Issuer, or the issuing bank, is the entity authorising a payment request to be done on the shopper’s card. It will authorise or deny the transaction to proceed, based on previously collected data from the merchant’s page, the shopper’s card, and the transaction itself.
The shopper’s journey
As a shopper, I’ll browse the merchant’s website or mobile app selecting the items I want to buy then, I want to review the my list of items and how much I’ll pay, so finally introduce my payment details. It’s a simple flow, but there are some extra points to consider in the background.
Unless the merchant is using a 3rd party application or website to handle the checkout flow (such as Shopify, Stripe Checkout or other), it is necessary to build it, reading and storing all the required information. A shopping cart flow style should be implemented and will need to store each item the shopper is adding or removing.
Payment methods
There is a wide selection list of payment methods in which the merchant can provide. From credit/debit cards to country-specific methods or most recent ones such as Apple Pay and Google Pay, each one can work in a very specific way, and do not forget they can increase your conversion rate if you provide the better ones for your audience.
Just in case you’re wondering what’s the easiest way to provide any payment methods, simply rely on top of the payment service providers (example: Stripe Elements). Implementing each payment method as a stand-alone development can end up being a very repetitive task as well as expensive from a development point of view.
Storing information
Implementing the flow of a shopping cart can turn into a complex task. Not only the item that the shopper is selecting should be stored but also order related information should be considered. Attributes as the product Id, the quantity, the unit price, the currency the shopper is browsing and the settlement currency should be stored so the application can, before processing the payment, to validate everything is correct and avoid the shopper to hack the pricing (just one example of course).
Currency information
If your business’s audience is the whole world then you’ll find out that currencies are part of your daily data.
If the merchant’s website is in France probably the acquiring bank will be French too. This means that the starting point is to accept payments in euros (EUR), but what if an American shopper is trying to buy something? The shopper will, in this case, to pay the exchange costs. Of course, this doesn’t seems to impact the merchant, but in fact it is, given the shoppers can fetch another merchant with the same or identical product in which the final amount charged on their bank account will be smaller. What is then the alternative? The merchant can put in place all the required steps to accept multiple currencies by having acquiring accounts on those different currencies.
In case of accepting multiple currencies, make sure you record the exchange rates between them as you may need that information in the future for reconciliation processes and also, the checkout flow should present to the shopper the calculation done between the different currencies.
A Payment confirmation page
It is a best practice, and very useful as a shopper, to get a confirmation on the payment. After the application handles a success payment the shopper should see a summary of the selected items, a visual component displaying the success of the checkout flow and finally some contacts in case any support is needed in the future.
Keep a record on the processed payments
The merchant’s responsibility doesn’t ends after the shopper succeeds on getting charged, in fact, it turns itself into the Merchant of record of those transactions. From a financial point of view, the merchant will be responsible for the success of the purchased items delivery / consumption and additionally for two extra operations: Refunds (the return of the transacted amount to the shopper. This operation is triggered by the merchant) and disputes/chargebacks (when the shopper claims with the issuing bank that they didn’t processed that payment or the product / service wasn’t honoured by the merchant and for that there’s a dispute between them and the merchant).
Keeping a record of all the payments data will help the merchant to do the reconciliation processes (like QA processes but for the payments logic).
Processing a payment requires different steps between the actors involved on the process and also depending on the sort of payment methods being used.
Considering credit cards we have three main events happening: authorisation, Capture and settlement. What is the difference between them?
Authorization
After the shopper introduces the credit card data on the website or app (either on the payment service provider or directly in form fields), the merchant will request the acquirer to get that amount from the issuing bank. This is not a simple request, as the credit card data will be validated by the issuer as well as risk percentages, total amount available to perform that operation. At this stage the issuer can authorise that transaction to be performed, decline it with a valid reason or to challenge it using PSD (Payment Service directives) by triggering 3DS1 or 3DS2 challenges (requiring the shopper to add a personal code or an acceptance response on their home banking app).
Capture
If the merchant receives a success response on the authorisation request (either at the first attempt or because the shopper succeed at the 3DSx challenge), it means that the issuer allows the acquirer to ask the amount to be transferred from the shopper’s bank account into the merchant’s bank account. At this stage the merchant has everything in place to trigger the capture request. This means that all the internal information has been stored, all the shopper’s details have been registered and there is only missing the funds to be transferred.
Please note that this operation can be an automatic step, the majority of the payment service providers will allow the merchant’s integration to do the authorisation + capture ate the same time. It will depend on the merchant’s business flow.
Settlement
This operation means the funds transferred from the shopper’s bank account into the merchant’s one.
Given this is the money physically being transferred, it’s understandable that takes some days to be performed (after the capture request succeed). The merchant should then, to check the income balance and the charged fees as well.
If processing payments is an important step so doing the reconciliation processes as well. This will allow the merchant to validate all the information and guarantee the business is working as expected. The financial reconciliation can turn to be very simple or very complex depending on the merchant’s business. From a technical point of view, the merchant should have in place processes to fetch the processed transactions within a time range, fetching the equivalent data from the payment service providers and compare that with the stored payment transactions information, ensuring the correct amounts were charged and transferred from the shoppers bank accounts. Also depending on the size of the merchant’s business a lot of information will be used to build finance reports supporting the decision making process.
Processing payments isn’t only about showing a total amount and charging it. There are a few topics that need to be under the merchant’s radar.
Chargebacks
Either because someone says they didn’t processed processed a specific purchase or because a credit card was stolen, these are some of the reasons shoppers can contest certain payments. If this happens, the issuing bank will notify the merchant that a dispute was created and with lack of evidences from the merchant, that specific amount will be transferred back to the shopper’s bank account. That’s why the merchant should store as much information as possible during the checkout process, so the fraudulent shoppers trying to get their money back after they consumed the items don’t harm the business.
Refunds
A refund happens when the merchant willingly returns the paid amount to the shopper. This can happen because a certain product was damaged and the shopper doesn’t want a replacement or because the merchant business policy allows such scenarios.
Fraud Rates
It is one of the most volatile variables for any merchant processing payments but one of the most important topics dealing with online payments. The merchant’s reputation counts and it is impacted by every transaction. Parameters like the merchant’s country, the shopper’s country, the currency, the browser version, the transaction amount…, everything counts to the payment service providers and issuing entities to proceed with the transaction.
The merchant can have a direct impact on those fraud rates. Using internal tools to analyse and find fraudulent shoppers and/or making usage of the payment service provider tools, the merchant can provide more information processing those transactions (example: shipping addresses when selling goods) or implementing rules/constraints that will deny certain transactions to be processed (such as black lists of emails, etc).
Keep the shoppers happy!
The payment flow requires a full set of tools, processes, security procedures and development, but more than that, requires the merchant to be simple and transparent so the shoppers are happy. This topic is very important. By keeping your customers happy, with good communication and support, most of the issues and improvements will come from honest feedback, not forgetting this will reduce the complaints on social media or even the chargeback requests.
And that’s it! Just a simple and raw view on implementing online payments. Do your experiments, try new approaches and alternative methods, but ensure you keep them within the standards.
I hope it helps!
