The Ultimate Guide to Payment Authorisation

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.

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.

There are several parties that work together to complete the authorisation process.

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.

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.

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.

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).

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.

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.

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.

Molly needs to move her money from her merchant account to her business bank account — a process called funding.

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.

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.

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.