Payment authorisation plays a huge role in the transaction lifecycle — from chargeback management to revenue optimisation. Understanding how the authorisation process works will help you make more informed decisions about the systems you implement and the strategies you use to resolve issues.
What is payment authorisation?
Payment authorisation — sometimes referred to as card authorisation — is essentially a real-time conversation between a merchant and a cardholder’s issuing bank, asking if a payment card transaction can be processed. The “conversation” happens through automated systems and is completed within milliseconds.
An authorisation request asks the cardholder’s bank three things:
If the answer to all questions is yes, the transaction is approved. If the answer to one or more of the questions is no, then the transaction is declined.
Who is involved in the card authorisation process?
There are several parties that work together to complete the authorisation process.
Card Scheme
A card scheme (sometimes called a card network, brand, or association) is an organization that facilitates payment card transactions.
It regulates who, where, and how cards are used. Examples of card brands include Visa®, Mastercard®, American Express®, Discover®, China UnionPay®, and JCB®.
Cardholder
A cardholder is an individual who is authorised to make purchases with a credit or debit card issued by an issuing bank. Cardholders can initiate transactions and dispute charges.
Issuer
An issuer is the cardholder’s bank. These financial institutions issue payment cards and accounts to consumers.
As a member of the card schemes, issuing banks are authorised to issue payment cards on the schemes’ behalf. Issuing banks act as liaisons so cardholders don’t have to deal with card schemes and acquirers directly.
Merchant
A merchant sells goods or services and accepts payments from cardholders. Payments are processed through a merchant account provided by an acquirer.
Acquirer
An acquirer is a financial institution that provides merchant services. It is licensed to provide merchant accounts to qualified businesses, enabling those businesses to accept credit and debit card payments. Acquiring banks also acquire funds from the card issuer once a cardholder’s transaction has been approved.
Payment Processor
A payment processor shares and receives data from the card brands, acquirer, and gateway in order to process a merchant’s transactions. Unlike acquirers and issuers, payment processors aren’t card scheme members.
NOTE: Processors are most commonly involved in U.S. payment processing. In Europe, merchants work with acquirers directly.
Payment Gateway
A payment gateway receives, protects, and safely shares transaction information. It’s essentially a cash register for online sales but with more security features.
CRM or Order Management System
A customer relationship management (CRM) platform is a database that captures and organizes interactions with customers or potential customers. While merchants can still accept and receive payments without a CRM, most merchants use one to keep their customer information organized. Many CRMs also offer integration with payment gateways to help merchants track customer purchases.
How payment authorisation works
Payment authorisation is an important part of the transaction lifecycle. It helps keep fraud and unauthorised transactions out of the payments ecosystem. Here’s a high-level overview of how it works.
The entire authorisation process is completed in a matter of milliseconds and is usually undetectable by the cardholder.
Where authorisation sits in the transaction lifecycle
Authorisation is just one of many stages in the transaction lifecycle. Let’s take a look at the entire workflow and understand how money moves from a cardholder’s personal bank account to your business bank account.
We’ll use an example scenario to illustrate the process.
STEP #1
Transaction Initiation
Carl, a cardholder, is shopping for jewellery online. He comes across Molly’s Fashion Boutique and finds a great deal on a pair of earrings for his wife. He grabs his Visa debit card, enters his payment information on the checkout page, and initiates the transaction process.
Carl’s simple act of initiating the transaction triggers a sequence of rapid, complex processes involving half a dozen different systems.
First up, Molly’s website collects Carl’s information. The order information and Carl’s personal information is sent to Molly’s CRM. Carl’s payment information is sent to Molly’s gateway.
Next, the transaction moves into the authorization phase.
STEP #2
Authorisation request
Molly’s gateway receives the payment information that Carl submitted on the website. The gateway encrypts the information and sends an authorisation request to Molly’s acquirer. The acquirer then forwards the request to Carl’s issuing bank through the card brand (in this case, Visa).
STEP #3
Authorisation response
Once Carl’s bank — the issuer of his Visa credit card — receives the authorisation request, it checks several things:
- Did Molly provide all the relevant information?
- Does Carl have enough money in his account to cover this transaction?
- Should Carl be allowed to do business with Molly or is Molly’s business too high-risk?
Depending on the answers to these questions, the issuing bank will supply an authorisation response with a response code.
There are roughly a dozen authorisation code options, but they usually fall into two buckets: approved or declined.
Declined transactions
A declined response code means the transaction was not accepted.
Here are some of the most common reasons for a declined transaction.
- The account doesn’t have enough funds or available credit to pay for the purchase.
- The cardholder claimed the card was lost or stolen, indicating a fraudulent charge.
- The card had expired.
- The CVV was incorrect.
- If AVS is activated, the address verification did not match the billing details.
- The technology malfunctioned somewhere in the transaction lifecycle, so an accurate decision can’t be made.
- Important information was entered incorrectly, so an accurate decision can’t be made.
- The issuer thinks the merchant is too high-risk and doesn’t want the cardholder to do business with the merchant.
Approved transactions
An approved response code means the transaction can be finalised.
Basically, it means that none of the above-mentioned issues are present.
Let’s continue with our example scenario.
Carl’s bank decides to approve the authorisation request. An authorisation response is sent to Molly’s acquirer via the card brand. The acquirer passes the response to Molly’s gateway, which then flows to Molly’s CRM.
STEP #4
Authorization hold
Once the transaction has been authorised, it’s time to start moving actual money from Carl’s personal bank account to Molly’s business bank account.
Unfortunately, this process doesn’t happen instantaneously. Because Molly needs time to check her inventory and make sure the earrings are in stock, get the items Carl chose packed up, and schedule the carrier for pickup.
So Molly asks Carl’s bank to put an authorisation hold on his account. This freezes a portion of Carl’s funds so he can’t spend them somewhere else before Molly gets paid.
NOTE
Not all merchants need to use an authorisation hold. For example, if you sell digital courses, your merchandise is delivered instantly. There is no waiting period that would require you to freeze funds for a later date, so you can proceed directly to the next step in the transaction process.
Holds are most common in industries where there is a delay in delivering the goods or services or the final transaction amount is unknown — like hotel reservations, restaurant dining, etc.
STEP #5
Settlement
Settlement is the process of Molly’s acquiring bank going out and acquiring the funds from Carl’s issuing bank.
After Molly’s Fashion Boutique requests funds, the issuing bank debits Carl’s bank account. (If Carl had paid with a credit card, the issuer would extend a line of credit to Carl while paying Molly, and then recoup the funds from Carl at the end of the month.)
The issuer submits payment to Visa — minus interchange fees to compensate for the issuer’s responsibilities.
Because Visa provides infrastructure, network, and security, the brand is entitled to compensation. Visa takes its cut — called a scheme fee — and forwards the remainder of the money down the line to the acquiring bank.
The acquirer also has to be reimbursed for processing costs, so an acquirer fee is debited from the remaining transaction amount.
Once everyone is paid, the money that’s left is settled in Molly’s merchant account.
NOTE
Usually transactions are settled in a batch at the end of the day.
STEP #6
Funding
Molly needs to move her money from her merchant account to her business bank account — a process called funding.
NOTE
Funding timelines vary.
Typically, funding for domestic transactions happens the same day as settlement. There are some situations where it might be delayed a few days though.
However, for cross-border transactions, timelines are usually longer. Additional tasks — like currency conversion — can slow things down. Here are some of the most common funding timelines.
- 1 day post transaction (T + 1)
- 3 days post transaction (T + 3)
- 5 days post transaction (T + 5)
- 7 days post transaction (T + 7)
What is a credit card payment authorisation form?
Sometimes, merchants need to get written authorisation from a customer before charging a card. Customers do so by filling out a payment authorisation form — a document that formally grants a merchant permission to charge a payment card.
NOTE
A payment authorisation form is not the same as an authorisation request sent to the issuer. An authorisation form gets cardholder approval, not issuer approval. You might decide to include the use of an authorisation form in your payment strategy, but it would not replace the issuer’s authorisation process.
An authorisation form includes information such as:
- Cardholder’s billing address, name, phone number, and email
- Card type, number, and expiration date
- Agreed-upon transaction amount, reason for the charge, and payment frequency
- Written consent from cardholder granting permission for the business to process a charge
- Information about the cancellation policy, refund policy, and terms and conditions
- Cardholder’s signature
Typically, payment authorisation forms are required when setting up recurring payments — such as streaming services, software access, online courses, etc. They might also be used for deposits, hotel reservations, vacation rentals, professional services, and medical procedures.
Because authorisation forms contain sensitive card data, you should follow PCI-DSS requirements for data safety.
NOTE
An authorisation form implies the cardholder has given you permission to charge their card. However, a signed authorisation form won’t stop a chargeback from happening. Issuers don’t have access to these forms and have no way of knowing that the cardholder did consent to the transaction.
If you receive a chargeback, you can challenge the chargeback and submit the authorisation form as evidence.
Stable payment processing from AltoPay
Now that you understand how important the authorisation process is to your business, you likely realise that it’s just as important to work with a provider who helps — not hinders — authorisation requests. And that starts with smart payment solutions.
AltoPay ensures seamless transaction processing with extensive connectivity to a vast network of acquiring banks around the globe, cutting-edge payment technology, and proven-effective chargeback management solutions.
If you’re looking for a payment partner you can trust, reach out to AltoPay today.
AUTHOR
Jessica Velasco
For more than a decade, Jessica Velasco has been a thought leader in the payments industry. She aims to provide readers with valuable, easy-to-understand resources.
