The Authorization, Billing, and Dispute Lifecycle

When someone orders a pair of shoes online, a number of unseen steps occur between that customer clicking "Submit Order" and the merchandise arriving on their doorstep.

In addition to the customer and the merchant, there are other essential parties involved in any online transaction:

The Players

First, when the customer clicks "Submit Order," the merchant passes the customer's payment information to the payment gateway. A payment gateway, as its name implies, directs a merchant's financial traffic to several different destinations, beginning the validation process and supplementing that information where appropriate.

A payment processor then receives the information, which relays outbound authorization requests to the card association. The card association communicates with the issuing bank. Some of these players may be one in the same; for instance, it's possible that your arrangement is such that your gateway communicates directly with American Express, acting as its own processor, card association, and issuing bank all at once. However, this consolidation doesn't have an impact on the overall flow of the transaction.

Authorization

As a merchant, the first thing that you do when your site receives a new order is to submit an authorization request. Merchants can complete authorizations in several different ways: the simplest method is to authorize for the full amount of purchase upfront. If a purchase is $50 after taxes and shipping, the merchant would request an authorization for $50. Other merchants perform a partial authorization for some portion of the purchase—frequently just a single dollar or single cent. Still, other merchants perform a zero-dollar authorization, where purchase authorization checks occur, but no money is set aside.

Regardless of the authorization amount, once a payment request arrives at the issuing bank (through the players outlined above), the bank sends back several pieces of information. First, they send a status code indicating approval or rejection of the request, as well as reasoning. These codes can vary by bank, and payment gateways are tasked with correctly interpreting these codes. A request might be declined due to insufficient funds, or because the card submitted doesn't exist in the bank's records, or for several other reasons.

The other information that can come back with the authorization status code is dependent on the merchant's preferences, but generally merchants will request a CVV response. This response indicates whether the customer correctly entered a few digits (3 on the back of the card for Visa and MasterCard, 4 on the front for American Express). This acts as a security measure, because in theory only the cardholder should know those digits. Additionally, the merchant may receive an AVS response if they requested it and the issuing bank supports it. This response contains a few pieces of information, primarily indicating whether the street address and postal code provided by the customer each match the bank's records.

A merchant can process an order even if the AVS and CVV responses are negative. Many won't, but they're allowed to, although they may not have some fraud protections they might otherwise. The authorization itself, though, is mandatory—if that fails, there's no way to try to bill the customer anyway.

The Difference Between the Authorization Hold and Billing

Once the merchant has successfully obtained an authorization for the amount of the order, what should you do? Before turning over the purchase funds to the merchant, the bank sets aside the customer's money (seen online as a pending charge) so those funds are unavailable to the customer.

What if something happens to cancel a customer's order after authorization, but before their card is charged? Authorization holds are generally valid for 5-30 days, depending on the processor and card association. Until the authorization hold falls off, the money remains on hold; merchants must be careful about how they handle authorization in order to keep the customer experience streamlined and positive.

When the merchant is ready to confirm the order and ship the goods, they can use a valid authorization to bill the customer. You send a message out through the gateway requesting that a certain amount be billed against the authorization, whether zero, partial, or the full amount. This step can fail as well; for instance, if the authorization is not valid for the amount the merchant tries to bill against it, billing will not go through. If it succeeds, however, the issuing bank transfers the money to the merchant's acquiring bank, which then transfers the money into the merchant's own bank account.

What if the customer requests their money back?

There are two ways that the money could go back out from the merchant's account to the customer's account at the issuing bank: a refund or a chargeback.

In the case of a refund, the merchant sends out a request that's identical to the billing request, but with a negative amount and no need for the authorization to still be valid. The merchant is able to refund up to the amount originally billed.

Chargebacks are more complicated, but we've done our best to explain them in their own article.

What happens in the event of a dispute?

Disputes don’t exactly follow a linear path. Indeed, there are stages in the dispute life cycle that make it seem it’s a straightforward process. But there is a lot of iteration within those stages, and not every dispute may be processed through every stage.

This section provides a comprehensive overview of the dispute life cycle.

Step 1: The cardholder disputes a charge

While there are reason codes related to processing errors that cause disputes, the majority of reason codes result from a cardholder disputing a charge. The cardholder may be the customer or the someone who lent their card to a friend or relative. And there’s always that possibility the card was used in a fraudulent transaction, which means the cardholder is a victim of true fraud.

No matter who was involved in the transaction, the scenario usually involves the cardholder either seeing an “unrecognizable charge” on their statement or disputing the quality of the goods/services rendered. This is when they submit a claim to their issuing bank and (unfortunately) it is fairly easy for cardholders to submit it.

Stage 1, Phase 1: Issuing bank conducts an inquiry

Depending on the card network’s dispute workflow, the dispute will enter the inquiry stage. This is a pivotal moment in determining whether or not it should proceed to the chargeback stage. If so, it will be filed as an official case and the disputed revenue will be withdrawn from the merchant’s bank account.

Under Visa, disputes that enter the inquiry stage are assigned to the collaboration workflow. This consists of disputes with reason codes in the Process Error or the Consumer Dispute category. Fraud and Authorization disputes (if verified by VROL) are sent to the allocation workflow, and the first stage in that workflow is the chargeback stage.

Mastercard reason codes do not require an inquiry. They are instead assessed on a case-by-case basis by their affiliated banks.

Stage 1, Phase 2: Card network facilitates the inquiry to the merchant

At this phase of the dispute life cycle, the merchant still possesses the disputed revenue. But that won’t last long if they are not able to fulfill the issuer’s inquiry—and quickly. The card networks’ initiatives show they intend to continue streamlining the dispute process. All of their efforts involve using automation in order to prevent invalid disputes in real-time. However, that shrinks the merchant’s response window to only a few seconds. This makes real-time response the only effective, viable solution to fulfill inquiries—and you’ll need intelligent dispute management software to make it possible.

While this facilitation (and response) occurs through APIs, here’s what happens during this phase:

1. The cardholder contacts their card issuer and is connected to a dispute analyst.
2. The dispute analyst conducts an inquiry.
3. The card network’s automated tool (i.e., VROL) recognizes that the merchant’s system is equipped with API-driven software, and the software generates a Real-time Resolution Inquiry.
4. The software renders a response within seconds, containing details about the customer, order, product, and other related information.
5. The dispute analyst provides response details to the cardholder.

The dispute life cycle ends when the inquiry is fulfilled and it is in favor of the merchant. Otherwise, the life cycle proceeds to the chargeback stage.

Stage 2, Phase 1: The dispute enters the chargeback stage

Now that the dispute has been officially filed, it has entered the chargeback stage. This means the disputed revenue will be transferred from the merchant’s bank account to the cardholder’s account. The time limit to respond starts once the merchant has received notice of the dispute. Each card network sets their own time limit, and the issuer, acquirer and merchant act accordingly. Here are the time limits merchants should be aware of:

However, it is worth noting the time limits above apply to acquirers and processors, not merchants and dispute analysts. It is recommended that the response document is sent to them by the midway of the time limit. The recommended time limits below are what we recommend for analysts to send their document. This not only secures their submission being accepted, but it also gives acquirers and processors time to review the document.

Stage 2, Phase 2: The analyst creates a response document

How analysts should create a response document will depend on the reason code tied to the dispute. They can find the exact details of each code in our reason codes encyclopedia.

Additionally, we have free chargeback response templates to help guide them on how to write a rebuttal and what evidence needs to be included.

All response documents need to include evidence from the merchant’s payment processor, authorization gateway, e-commerce platform, and (if applicable) the carrier for disputed shipped goods. Analysts will be able to provide additional evidence such as support tickets, screenshots, and social media posts. But that again will depend on the reason code being addressed.

The dispute will be rejected if the response document achieves two things:

1. The analyst provides the required evidence as stated by the reason code.
2. The response document proves a legitimate transaction occurred.

Please note, depending on the card network, the analyst will not be able to challenge the outcome if the issuing analyst favors the cardholder’s case. Visa’s dispute process does not allow the merchant side to re-open the case if they are at fault.

However, the cardholder (and sometimes the issuing bank) will have a chance to re-open the case. That is, if they are able to meet the conditions set for the next stage in the dispute life cycle: pre-arbitration.

Stage 3: The dispute enters pre-arbitration

Pre-arbitration (i.e., pre-arb) is where the outcome in the chargeback stage is being reviewed on the “merit of reasonableness.” In other words, the cardholder and/or issuing bank believe the dispute being rejected at Stage 2 was not reasonable. Pre-arb gives them another chance to have the outcome reversed in their favor.

The exact conditions (and terminology) for a dispute to enter pre-arb will vary. But it usually shares the following requirements:

Cause 1

The reason code is different now than it was compared to when it was tied to the dispute. The cardholder and/or issuer believe this new change legitimizes their case for a chargeback. The dispute enters pre-arb in order for it to be reviewed again.

Cause 2

The cardholder has new information that was not provided during the chargeback stage. This new information is believed to legitimize their case for a chargeback to be issued.

Cause 3

The issuer believes the analyst’s evidence did not disprove the dispute. This kind of cause is highly technical and will only occur if there is evidence that is considered “too broad” or “insignificant.”

This cause is easily preventable when either:

1. The response document is properly formatted.
2. The document itself was created from a template that describes all of the relevant evidence needed to challenge the dispute (see our templates page for examples).

Cause 4

There are miscellaneous causes that may send a dispute to pre-arb. One example is the merchant’s return policy or Terms and Conditions not being properly disclosed. This can technically be considered new information the cardholder can present (see Cause 2). This documentation should be transparent, clear, and concise. This allows the analyst to provide this information as evidence for the merchant.

Stage 4: The dispute enters arbitration

This dispute life cycle continues if no consensus was reached by the issuing party (i.e., the cardholder and the issuer) and the acquiring party (i.e., the acquirer and merchant). Now the card network gets involved in order to make a final ruling on the dispute. Please note this stage in the dispute life cycle is expensive, and there is rarely an opportunity to challenge the decision.

The response method in this stage is relatively the same when compared to the others above. However, under Visa, merchants and analysts have fewer than 10 days to submit a response to their acquirer. Mastercard allows the acquiring party to submit their response within 45 days. However, keep in mind the acquirer will need time to thoroughly review the response document—so, we recommend analysts submit their cases within 22 days.

The Dispute Life Cycle: Bottom line

There are several scenarios where the dispute can be rejected before entering another stage of its life cycle. The first scenario is the inquiry stage, as this is where an analyst can stop a dispute from being filed at all. Avoiding dispute filings lowers your dispute rate and prevents revenue loss.

Analysts can successfully recoup revenue in the chargeback and pre-arb stages, but the time and resources used to respond can be costly. This usually happens when analysts are using an ad hoc approach to manage disputes. Whenever a dispute passes the retrieval request stage, the goal is to have a well-documented workflow to keep the response documentation well-formatted and clear. But the most effective workflows are automated, ingesting information from comprehensive sources and drastically reducing time spent on manual data entry and review.

Automation empowers analysts within the retrieval request stage, programmatically presenting the transaction, order, and customer details, and allowing Real-time Resolution to have the biggest impact on dispute management. Finally, it’s important to remember that while the particulars can change, merchants have the power to enhance (or disrupt) the customer experience depending on how they arrange these steps and communicate them to their users.