How to Improve Payment Authorization Rates
Discover more from Batch Processing
How to Improve Payment Authorization Rates
What is an authorization rate? How payment infrastructure providers can increase payment acceptance rates. The promise of good payments infrastructure.
About a decade ago, I found myself on a call with representatives of Wells Fargo and Vantiv, attempting to increase the authorization rate for one of my clients. Vantiv, which would later go on to acquire and take the name of Worldpay, a British payment processor, was sponsoring payments for my startup, Balanced. Wells Fargo is a top-3 American consumer bank, responsible for putting debit and credit cards into the hands of tens of millions of people. Many of these cards were being used to make purchases via Balanced but we were seeing a disproportionate number of them declined and we couldn’t figure out why.
In the view of my client, any transaction attempted by their customers yet declined (for real or spurious reasons) was money stolen from them. I don’t subscribe to that view. Honestly, each transaction successfully processed—in near real-time—is a small miracle. Our current digital payments infrastructure is an incredibly complex (and aging) system, with dozens of interlocking pieces that must fit together perfectly for everything to work. Sometimes things go wrong and no one can figure out why. As Patio11 recently described in his wonderful piece about improving how credit cards work: “a disconcerting number of spurious declines are caused by… gremlins, man.”
But I think it is both important and possible to improve things within the payments ecosystem, so I took it upon myself to get each company’s risk department on a call to see how we could increase Balanced’s baseline authorization rate and the authorization rate for this specific client. I, perhaps naively, assumed that we could solve this problem with a simple phone call. After all, it was in the best interest of each party to have more transactions processed (i.e., more revenue, happier customers, higher lifetime value from each customer), yet I ran into one of the most challenging characteristics of payments, a massive coordination problem.
What is an authorization rate?
Each time a customer attempts to make a purchase online or in-person with a payment card running on one of the major four payment networks, an authorization (aka an “auth”) is attempted. This auth message is sent from an acquiring bank (the merchant’s bank) through a payment network like Visa, to an issuing bank (the cardholder’s bank) to determine if a) the cardholder’s account is in good standing, b) if the cardholder’s account has enough balance (real dollars or credit) available to complete that specific transaction, and c) if there are any other fraud signals that should be considered for this specific transaction. The response from the issuing bank to the acquiring bank, and ultimately the merchant, takes just a few seconds and will come back with a success or failure message, and (sometimes) a more verbose description of why the transaction failed if that was the case.
If a transaction is successfully authorized, it can then be captured, meaning the funds will be reserved to be moved from a cardholder’s account to the merchant’s account. Often, especially with in-person payments, the capture occurs immediately after the auth—effectively at the same time. But there are many contexts where the auth and capture do not occur at the same time (e.g. placing a hold on a card at a hotel) and there are some cases where an auth occurs but the capture never happens (e.g. pledging funds to a Kickstarter campaign that doesn’t meet its goal).
Finally, in a growing number of regions, there is an additional “authentication” step being added before the auth. Requirements like Strong Customer Authentication (SCA) are part of the Payment Services Directive 2 (PSD2) standard, which has been rolled out across Europe over the last several years in an attempt to reduce fraud.
An authorization rate is simply the percentage of attempted transactions that are accepted by an issuing bank.
How payment infrastructure providers can increase payment acceptance rates
There are a few ways payment infrastructure providers (e.g., gateways, facilitators, and processors) can meaningfully boost payment authorization rates.
Maintain low fraud rates
One of the reasons we had lower authorization rates at that particular time at Balanced was that we had a spike in fraud and subsequent chargebacks several months earlier, which skewed the baseline risk perception issuing banks had regarding Balanced’s various merchant identification numbers (MIDs). Today, where many individual merchants are relying on the MIDs or integrations of their underlying payment provider, the risk of aggregate risk flowing down to an individual merchant is real. There are tactics for payment providers to mitigate this scenario but the most straightforward is to simply do the work to maintain a low historic fraud rate (as measured by the percentage of transactions and percentage of total payments volume).
There’s a famous line within fintech: “fraud isn’t a problem until it’s your only problem,” or something like that. This wasn’t exactly the case at Balanced. We knew we needed to build and optimize fraud systems but we consciously decided to spend most of our engineering efforts in the early days building functionality and deepening financial service integrations. Then, when fraud became a problem, we solved it.
But I learned a few lessons from this experience, mainly that a period of relatively high chargeback rates, even when resolved, can have lingering consequences. I discovered that Balanced was put on a “grey list” by several issuing banks, which was causing the lower baseline authorization rate. The issuing banks wouldn’t tell me exactly why nor how we could be removed from the lists. Even with Vantiv vouching for our much-improved fraud management practices, we could not resolve the issue directly with the issuing banks. That is why it’s imperative for payment infrastructure providers to maintain a history of low fraud leads in order to provide their customers with higher baseline authorization rates.
Luckily, several technologies have matured in the past decade, which has led to lower overall lower fraud rates. Indeed, the global fraud rate went down by 25% during Q1 of 2022, mainly due to security upgrades performed by financial institutions, and consistent implementation of fraud prevention tools and practices.
One of those tools is biometric-enabled payments, such as Apple Pay, which requires a face or fingerprint scan to authenticate a transaction. Consistent with the three security factors, it is much harder to spoof a characteristic someone has (e.g., their face) than it is something someone knows (i.e., a 4-digit PIN code).
Another tool is machine learning (ML) as applied to fraud detection. At Balanced, we started with a simple rules-based, which we used as the basis for a simple machine learning model to detect fraud. We also built a clever mesh network, which would associate various aspects like IP address, card fingerprint, email address, etc. If one of those aspects were found to be fraudulent, the other aspects would either be banned as well or considered at higher risk of fraud. Today, we are in the heyday of machine learning and artificial intelligence. Standalone companies like Unit21 and Sift provide risk scoring to payment facilitators and gateways. Large payment processors like Adyen, Stripe, and Checkout all provided built-in risk management solutions.
Offer local payment processing
Above, I mentioned that regulators in Europe have mandated SCA, a type of multi-factor authentication standard used to lower fraud for online transactions in the region. A payment processor that’s unable to handle SCA isn’t viable in Europe. Hell, Stripe introduced an entirely new API schema to handle complex payment flows, including user authentication standards like SCA. This is just one of the many differences in processing payments in different regions.
Similarly, payment providers that don’t offer payment methods used and preferred in the regions they operate in will naturally decrease acceptance rates for their customers. A simple thought experiment shows this to be true. If a website only offers, say, Alipay as a payment method, most consumers outside of China are unlikely to complete a transaction. Sometimes a merchant will get a local payment method “for free” by accepting cards from major payment networks like Mastercard. Maestro, for example, is a popular debit card network that operates almost entirely in Europe but is compatible with the Mastercard network. So if a merchant can accept Mastercard cards, they can accept Maestro cards as well. But increasingly, each region has its own collection of popular and convenient payment methods that are not coordinated by the large payment networks. In this case, it’s the job of payment infrastructure providers to make them available to merchants so more transactions will be completed. This is why payment providers like Adyen, Stripe, and Checkout each offer 40+ different payment methods. There are also specialized payment providers like dLocal, Rapyd, Nium, and Airwallex that specialize in local payment methods and cross-border transactions.
Speaking of cross-border transactions. Did you know that payments processed by a “non-local” entity on the major payment networks (i.e., a cross-border transaction) are less likely to be authorized due to perceived higher risk? So to optimize payment authorization rates, most of the large payment processors have set up the necessary legal and technical infrastructure in each region to be considered a “local acquirer” by the payment networks. Again, large payment providers like Adyen, Stripe, and Checkout tout their "smart” routing of payments through the best entities and networks possible to optimize a transaction’s likelihood of success. A simple example in the U.S. could be taking a debit card and routing it, natively, through direct integration into that debit network, rather than running it through a partner network like VisaNet. This would lead to lower costs and potentially higher acceptance rates.
Dynamically modify authorization messages
If you’re wondering what the f**k Patrick is talking about, allow me to provide a slightly more straightforward explanation. Stripe, like all entities that process card-based electronic payments, uses the International Organization for Standardization (ISO) 8583 messaging standard to communicate with payment networks like Visa and Mastercard, as well as issuing banks like Capital One and Bank of America. The bitmap is an “indexing technique used in an ISO 8583 message to indicate which Data Elements are present”. The data elements are arranged in series (a requirement of the low-bandwidth information technology at the time), like so:
Although ISO 8583 is a “standard”, each issuing bank/processor combo has enough subtle differences in their implementation to yield meaningfully different authorization rates for what would look like identical transactions to a human. From Stripe CEO, Patrick Collison, on a 2020 Hacker News thread:
We now have enough data across Stripe to implement an ML engine to optimize these requests on a per-issuing bank basis. As mentioned in original comment, this helps collect a lot more "free" revenue for our users.
Today, Stripe, Adyen, and a few other processors have done enough micro-optimizations of the messages (the “bitfield” or “bitmap”) that they have been able to train machine learning models to dynamically modify how they arrange the bytes in an ISO 8583 submission—per issuing bank—to increase their merchant’s baseline authorization rates.
Adyen has offered primitive versions of this issuer-specific formatting since 2016 as part of their RevenueAccelerate suite of products. First was a Smart Logic Issuer, where Adyen would “automatically re-format the payment request, according to the issuing banks' specific preferences.” Next, they also offered Dynamic Card Validation, which would “automatically format authorization request to $0 or $1, depending on the issuer preference.” Finally, they attempted to use ML to predict whether they should present an SCA multi-factor authentication prompt to a cardholder or not. Since 2020, Stripe has been pushing Adyen to develop more sophisticated ML models to optimize authorization rates and prevent fraud.
This is an area of R&D where I would have assumed Stripe would be first to market. If not, then (again) what is all of its extra headcount for? But on second thought, it does make sense Adyen was driven to this optimization first. First, they manage their finances much better than Stripe so would have looked for ways to drive up revenue and reduce network expenses (via retries) earlier. Second, Adyen works with larger customers, where a 1-2% improvement in authorization rates can lead to tens of millions of dollars in additional revenue each year. Regardless, we’re beginning to see an emerging ML/AI arms race between Stripe and Adyen, which will produce enormous positive externalities for merchants and consumers.
Use Account Updater and Network Tokens
Adyen’s internal data suggests that “10% of cards are refused because of card expiry, or by being lost or stolen.” Changes to card details can lead to scenarios where a card that was successfully charged recently is declined today. And in an economy that is increasingly made up of subscription-based services (i.e. Netflix, Instacart+, Peloton) declines of this nature can be disruptive for consumers and costly for merchants, leading to unnecessary churn, customer support burden, and network fees for reties. As Patio11 put it in his recent piece “credit card numbers change more often than many commercial relationships” (e.g. subscriptions, utility bills).
In an attempt to provide merchants with continuity while maintaining security for cardholders and issuing banks, payment networks like Visa and Mastercard began to offer account updater services, which will automatically inform processors of changes to a cardholder’s details, such as expiration date. This helps reduce churn so everyone can continue to order ice cream from Instacart while binge-watching Wednesday on Netflix and burn off those calories on Peloton the next morning.
Network tokens are another service offered by large payment networks in an effort to provide security and reduce fraud. A network token can stay the same while the associated card details can change. So network tokens, in effect, inherit account updater properties, which leads to higher authorization rates. A knock-on effect of network tokens is that they are considered lower risk and are given favorable interchange rates. And as I mentioned above, transactions that are perceived to be lower risk have higher baseline authorization rates.
Use modern dunning practices to retry failed transactions
When a transaction that is part of a recurring billing relationship fails due to insufficient funds, for example, there are more and less sophisticated ways to retry that same transaction. In modern recurring billing contexts like SaaS, the process of retrying a previously failed transaction is called dunning. The naive approach is to just retry a failed transaction every [1, 3, 7] days in perpetuity. That approach can lead to unnecessary fees for each attempt and abuse fees for attempting to charge an invalid payment credential. A slightly more sophisticated approach would be to exponentially increase the intervals between retries. An even more sophisticated approach is to consider the time of day and day of the month in your retry logic to maximize the likelihood a transaction is successful. For example, a debit card may have a higher account balance after payday vs. another day of the month.
The most sophisticated approach to dunning is to take all of the factors considered in the examples above, get real-world metrics from processing billions of transactions, and train a machine learning model to dynamically update retry logic on what it predicts will lead to the optimal outcome. That is what companies like Stripe and Adyen are now doing.
Use network effect to create novel de facto standards that lead to higher authorization rates
One of the main values large open-loop payment networks like Visa and Mastercard provide is coordinating behavior and incentives among an unfathomably large number of actors in the payments ecosystem. Yet, there are still gaps in the communications between various entities that have similar goals. Recall the story I shared at the beginning of this batch. I wanted Wells Fargo and Vantiv to exchange recently updated risk data to help both parties generate more revenue and satisfy their users. But there was simply no way to do that so Wells Fargo relied on a relatively static list of chargeback rates per MID from several months ago.
Stripe recently announced an Enhanced Issuer Network (EIN) starting with Discover and Capital One. The basic idea is that Stripe is now sharing (in real-time?) risk signals with issuing banks via its Radar tool. It’s essentially a “sidechain” to Visa and Mastercard to communicate risk information in an effort to “reduce fraud and boost authorization rates.” Stripe advertises an 8% reduction in fraud and a 1–2% authorization rate uplift for issuers. The news didn’t seem to make many waves in my opinion, partially because Stripe didn’t do a very good job explaining what they actually built. I think this is an important and novel approach to an ecosystem problem (fraud/auth rates) and represents the best of what good infrastructure development can do.
The promise of good payments infrastructure
Patio11 offers the best explanation of what Stripe’s EIN is and why it’s important in Improving how credit cards work under the covers. If you haven’t figured it out by now, I really enjoyed this piece and HIGHLY suggest you read it. A few quotes that have stayed with me:
The burden for fraudulent credit card transactions, can be reduced by billions of dollars, without [merchants] having to take any action themselves.
New capabilities are hard to build right but easy to adopt. Then the adopters build things on top of them with speed and diversity the company could never have produced itself.
Almost all of the innovations mentioned in this batch offer similar value: One entity can make an improvement that the entire ecosystem benefits from with little or no additional effort. This is the promise of good infrastructure.
Payment networks like Visa and Mastercard are creating and launching solutions like network tokens, user authentication, and account updater. Payment processors like Adyen and Stripe are building cutting-edge machine learning tools to dynamically modify transaction messages, retry logic, and produce fraud signals. Once built and deployed, these tools help increase authorization rates and reduce fraud at scale—billions of dollars of value are created by these improvements each year—and we’re all better off for it.
Cutoff Time
Cutoff Time is a section of Batch Processing that includes links to interesting news or ideas that caught my eye this week:
Apparently, Roku Pay exists, per Jerry
Micropayments will never work, per DK (i.e. zaps on nostr)
What Stripe did in the early days to build a strong brand, from my frenemy Cristina Cordova, an early Stripe.
Revisiting Not Boring’s Stripe bear case, per Brendan Keeler
Very few BaaS providers offer payout via physical check, per Jareau
This batch was powered by:
How to Improve Payment Authorization Rates
Hey Jareau - Curious to hear any thoughts you have on the 'MID warming' process (aka getting over the initial hurdle of lower authorization rates when you open a new merchant account).
I've always found it difficult to explain the phenomenon to merchants who are switching PSPs, as there is rarely much a PSP can do to get through the first few weeks with a new MID (to your point about your call with Wells and Vantiv).
Great article - thank you for sharing.
Are most of these auth rate improvements from the acquirer/merchant perspective? I've worked a lot with issuer and processor side and know that responsibility with auth rates can totally differ based on an issuing or acquiring perspective. Thanks!