Inside the Innovation: Optimizing Revenue-Boosting Authorization Rates and Reducing Network Declines

Raymond Lee from Stripe explains why online transactions fail at rates 10% higher than expected. About 58% of declines are false positives, rejecting legitimate customers. Stripe's Adaptive Acceptance tool uses machine learning to reverse-engineer why banks decline payments and recapture lost sales in real time.
Chapters
Foreign.
Hello and welcome to Inside the Innovation.
My name is John Feldman.
Right now we're in the midst of a huge shift to online commerce. $1.05 of all retail sales are now online. And E commerce is growing at 30% a year globally. But moving online brings with it some challenges. Online transactions see an average of 10% higher failure rate as compared to in person transactions. These failed payments, known as network declines, happen for a lot of reasons, from a typo on a payment form to a suspicion of fraud. And while declines can help you filter out fraudulent transactions, they can also mean losing legitimate customers and revenue. Customers experience a decline, often abandon their cart, and are unlikely to return. Consider some of these industry wide statistics. 58% of declined E commerce transactions are actually legitimate orders. And that's just pure lost revenue. More than 80% of cardholders who experience a false decline said it wasn't just inconvenient, it was embarrassing and aggravating. And in a recent survey by Javelin, 32% of shoppers who experienced a decline said they would no longer shop with that merchant. So for you, as an online retailer or a business considering a move, online network declines can be a huge challenge and you may be confused about how to manage them. Well, today in Inside the Innovation, I'm talking with an expert in this area. With me is Raymond Lee from our commerce cloud partner, Stripe. Raymond is a payments performance strategist in Stripe and he spends his days helping merchants optimize their entire payment flow to boost revenue and increase customer loyalty.
Welcome, Raymond.
Thanks, John. It's really great to be here and excited to chat today.
Yeah, thanks for coming in.
So let's jump in. You know what's happening behind the curtain.
After the customer hits the buy button? How does it, how does the merchant figure out what's happening next in terms of payment?
Yeah, absolutely. When the customer hits that buy button, they normally expect a super fast result. Hopefully they're getting their product or good. But what's going on in the background is actually pretty complex. First your payments provider needs to take the charge details and then send them as a payment authorization request to the card networks like Visa or MasterCard and then Visa or MasterCard. Then forward that request onto the customer's bank who issued the card, like Chase versus City. So it's, and it's that issuing bank that ultimately decides whether or not that transaction is accepted. So really, at a minimum, you need to think about three separate players that need to handle or interpret your customer's payment. It's like one, the payment processor to the card networks, and then three, the customer's bank that ultimately issued the card.
Totally. And so I'm a merchant. I've got someone's typed in a credit card number. I've got my MasterCard number. What am I sending to Stripe to authorize that payment? What is a payment request message?
Yeah, what the merchant is sending to Stripe, it might look really simple. And this is where Stripe famously became known for their seven lines of code to make a payment. It's things like, who's the customer? What's the card credential? Any statement descriptor you want. But in the background, it actually is really, really complex. What we're sending to the network doesn't look anything like that. It's actually an encoded message called an ISO 8583. And it contains over 100 different fields, rather than just those seven or so fields that you might need to send to your processor. But it's things like the cardholder's address, the business category, transaction amount, type of transaction, and so on and so forth. And then each issuing bank needs to interpret all those fields together to decide whether or not that transaction should be approved or declined.
Interesting.
In the introduction, we talked about how the majority of E Commerce transactions that do decline are legitimate. So why are the banks declining legitimate transactions and what happens when that occurs?
Yeah, so for a bank, a big part is really balancing out the fraud that they're trying to prevent and also the good customer experience and the revenue they're trying to generate by accepting that transaction. And when these cards are declined, there's usually three main reasons this happens. You know, first is your card might have insufficient funds. So this is like, you know, if you have a debit card that you run out of funds or you might have hit your credit limit. Another one might be that you might have just entered in the information incorrectly. Like maybe you fat fingered the CVC on your phone or something. Or maybe it's a safe card that just became outdated over time. And then. And then finally there's sort of a slightly broader area where the transaction maybe wasn't properly authenticated, or, you know, the bank might even suspect fraud. And then, you know, know, less common are things like if the issuer is down or the network's down, you know, it's really important to note that, you know, while we have a good understanding of why issuers decline transactions, it's actually rare that you get really helpful insight from the issuer and they actually don't tell you why a transaction was declined. In fact, like over a third of all the declines that Stripe sees actually come back as a generic decline, like do not honor, which, you know, for those payments nerds out there is a really dreaded decline code.
Well, I mean, wouldn't they be incented.
To take the transaction? Why wouldn't they want to help you get that transaction finished?
Yeah, I mean, it depends on the issuer. Like, you know, we've talked to a lot of issuers about this directly and you know, for some issuers, they just don't have the capabilities to send anything more specific than a do not honor. But for other issuers, they actually intentionally send do not honor because they might suspect that there's fraud from either the merchant or the customer. They don't really want to give you a hint as to why the transaction was declined. You know, if they're telling you, hey, the CVC is wrong, they don't just want you to match, you know, three digit codes or four digit codes to try to get that right.
Well, totally. But like, you know, any good person sort of trying to rub the magnetic strip to get the cargo through the second time, like, why should businesses try in that case, like what, what's in it for a business to try that to care about network declines and try the card again?
Yeah. So I mean, businesses ultimately want to give that customer a good experience. And when, you know, you know, while declines, you know, do serve a purp to prevent fraud, they can really hurt your customer experience. And the statistics that you mentioned are pretty dramatic. And if there's friction, oftentimes they're gone. And we actually have done a lot of research on that here at Stripe, where even your most loyal customers, after they get a decline, they actually end up spending less. Or maybe you're going to a competitor.
Oh, totally. Right. Because when you're in person, there's an opportunity for a human being to be like, I'm going to help make sure that this transaction happens where when it's.
Online.
There isn't that human chance to do it.
So are there other reasons beyond that that make it so hard for businesses.
To manage these declines?
Yeah. So E commerce and in store is vastly different. If you think about your buying experience in a store, between one type of store versus another type of store, it's going to look roughly the same. But as you've seen, E commerce is changing super, super rapidly. And this is especially true in the last year. This includes everything from the way merchants are accepting payments, the types of products they offer, and the customers prefer to pay. And with it fraud patterns are also evolving. And as you might imagine, financial institutions like issuers are definitely not adapting at the same pace. Even though some are more technologically advanced. Things are just evolving differently and everyone has a different perspective on what direction they need to go into. And you layer that on top of the tens of thousands of issuers out there and each one is going to have slightly different criteria or or requirements for what they deem as a safe and legitimate payment.
No, that totally makes sense. So what can you do about a decline transaction?
Is there a silver bullet?
Is there a way to get it back?
Yeah, I really wish there was a silver bullet here, but unfortunately there isn't. Depending on your business type, when that decline happens, you might be able to retry the transaction or attempt it later. And this is pretty common for things like subscriptions. But of course you see varying success rates across issuers or depending on why the transaction was declined in the first place. But when I talk to merchants, the most effective way we talk about in terms of getting a decline recovered is to get the customer to try a new payment method and fix the issue themselves. Again, the important piece here is you need to make sure that you think that customer is legitimate. As long as you think they're legitimate, you should always prompt the customer to try again. We've run some tests here where we turn a generic decline reason like hey, your card has been declined versus something a little bit more specific with a call to action like hey, your card insufficient funds, Please try another payment method and you actually see fairly promising results just with that little call to action there.
It's interesting too, and I'm sure that as a merchant, as someone taking a card, you're incented to try and reduce the number of declines and fraudulent cards just for your own reputation and to keep your bank rate in a good place.
What are the biggest opportunities for most.
Merchants to reduce declines before they happen? Are there things that I can do to try and cut this off the pass?
Yeah, and this is where I actually spend most of my time. Ideally, the customer never knows you have a decline because even if they do recapture it, we do see some negative customer lifecycle impacts there. But the biggest opportunity by far I see with most merchants is to really ensure that you're collecting the right information from the cardholder during that checkout flow. Are you collecting things like the card, CVC or expiration date? Those are both pretty common. But how about things like the billing, zip code? All these things are fields that can help the issuer feel more confident that that transaction and the customer are legitimate. But even better, you want to ensure your checkout flow just supports AutoFill capabilities or one click pay methods like Apple Pay and Google Pay, so they don't even have to worry about a lot of this stuff. It can be really fast and seamless for that customer and can give the issue a lot of confidence in that transaction.
Totally. That makes a lot of sense. Are there services out there that can also help with these problems?
Yeah, yeah, absolutely. Stripe, for example, has their own sort of like hosted checkout there as well. Or we'll use products like Card Account Updater that can help keep some of these cards up to date. But depending on the type of merchant you have, you want to really look at your entire conversion flow and understand which areas there are really impact network acceptance and what you can optimize.
That makes sense. So if I have a decline, is it useful to ever reach out to the issuer directly or is it like, what's a really effective way of resolving a decline?
Yeah, this is a really tricky one and a really, really common question I get. I think, you know, most merchants, they want to have that direct connection to the person who's ultimately making that decision, which is the issuer. But for most issuers, sorry, most merchants, in most cases, actually probably not helpful. Oftentimes issuers actually don't want to share their acceptance logic because this is their secret sauce for managing their own fraud. And even if you do get in touch with an issuer, it's really hard to find the right person who knows exactly how it works. They're doing what they think is best in terms of managing their risk versus accepting transactions. And oftentimes their advice is a little generic to action. It'll be things like, hey, make sure you keep your fraud rate low, or you collect the CDC on the transaction. And most of the times the merchant is already doing that or knows it's a clear opportunity already. And it's actually exceedingly rare for an issuer to actually change some of their rules for a specific merchant. Unless you know, you're one of their top 10 or 25 merchants.
Yeah, I mean, it makes a lot of sense, right, because they spend a lot of money for that AI and if they then have to customize it for everyone who comes, it's no longer a generic system. It's like how everybody games it.
So recently we announced a partnership where.
Stripe is a payment provider powering commerce cloud payments. Can you elaborate on how we're working together to manage network declines for someone who's coming onto Stripe through Commerce Cloud?
Yeah, I mean, Commerce Cloud is leveraging Stripe in part to provide best in class payment processing. And as we've talked about already, a super important part for this is to minimize network declines before they happen or recapture them. What we've learned throughout our time processing payments is that issuers have somewhat weird and inconsistent decision rules. And if you don't know their roles rules, it's impossible to follow them. We found the best way to minimize these declines is actually to understand or even reverse engineer some of these rules. But this is extremely tough. Now, you can imagine that if you wanted to do this yourself, you'd need to have one, an incredibly massive amount of data, and then two, you need a really large team of very experienced machine learning engineers to really crunch the numbers, take all the variables, put them together and really reverse engineer this issuing logic. And these are really two areas that Stripe really excels at. You know, we've got a ton of data, you know, processing hundreds of billions of dollars each year for millions of merchants. And you know, in fact, almost 90% of US adults have made a purchase on Stripe in the last year. So if you're a new merchant coming to Commerce Cloud, you can actually leverage all of that data to help your own processing, even if you've never processed a dollar on Commerce Cloud or at all, which is a huge, huge advantage here. And then on the technology side, you know, we're pretty unique in how incredibly heavily we invest in technology. You know, over 40% of our workforce is dedicated to R and D, which is quite a large ratio for many payments companies out there. And we've got, you know, dozens of machine learning engineers just like, working on this specific problem that's, you know, constantly evolving. So we're constantly working on it.
No, it makes sense. And so if you know, particularly somebody who's moving into payments for the first time rather than going it alone, you get the benefit of not only the experiences of a lot of other companies on the platform, but Stripe's active work on the platform to try and make payments, to minimize declines as much as possible with your own machine learning based on all your merchants.
Yep, that's exactly right.
That's awesome.
So do you have any unique tools.
That Commerce Cloud and Stripe offer to retailers together?
Yeah, absolutely. One of our very unique tools is called adaptive acceptance. And what this does is it recaptures decline transactions in real time before a customer even knows they've been declined. We've talked about when a decline happens, really, the bad piece is not even that you've lost a transaction, but it's a really bad customer experience and they often don't come back. But we've realized that when a decline happens, we can actually take that decline information and add it to all the data. We have to actually reverse engineer what went wrong and what might seem off to an issuer and then actually try to fix it in real time. This is incredibly powerful. You know, our merchants see a lot of declines recaptured this way and many of them see a 1% or more improvement in their offers due to this. But more importantly, it turns a potentially bad customer experience into a good one and it's completely seamless for the customer.
No, that's a good point because it's not just the, you know, the 1% of revenue that you're capturing from the lost transactions, it's also that you're not for the customers who you. For the customers who present that decline, they'll come back.
Right.
So there's a better lifetime value.
That's exactly right.
It sounds really awesome.
How did you develop adaptive acceptance?
Yeah, hopefully I don't get into too much like payments engineering nerdery here, but.
No, let's nerd it out.
Let's hear it.
Yeah, when you dive into that transaction message, the ISO 8583 is super complex and there's so many millions and millions of different combinations of fields that we want to test and there was just too many places to start testing. And so it created this interesting challenge for engineering teams where we wanted both maximize revenue gain for merchants, but also be able to test a ton of things at the same time. In our nerdy data science terms, we're hoping to balance out exploration versus exploitation. To solve this, we began running a series of experiments with a tool called the Multi Arm Bandits. These are a set of algorithms that are especially good at running a ton of experiments at the same time with a bias towards automatically adjusting towards those with the best outcome. We spent a couple of months with this multi armed bandage approach to a gather a lot of data but also understand what worked best. And we got some really strong revenue gains for our merchants and tons of learnings for Stripe. But we're really eager to adapt that into a true machine learning model. So we're able to leverage all those learnings that we got from that multi armed bandit experiment and we shifted it to a orchestration of multiple XGBOOST models. In payment notary speak. And without getting into too many details, XGBOOST is a industry leading machine learning framework. And an ensemble of decision trees. So all in all, what really changed is that this allowed us to much better understand the context of a transaction. When we say context, we mean who the issuer was, what type of merchant is it, what type of transaction are they making. We can basically look at way more variables at the same time to understand what's the best path to resolution here.
No, it's interesting. So the messaging has an ISO standard and then the machine learning framework has a standard that's shared between companies too. It's awesome.
Yeah.
So, you know, we talked about the issuers, like who are they? Who are the key players and how.
Do you approach working with them?
Yeah, I mean, it's. We've always had relationships with issuers and there's so many different ways you can work with them. I think one of the interesting things is that we're actually also an issuer ourselves. So we have a pretty unique insight into how issuers actually think about these things. That challenge of balancing out fraud versus getting transactions accepted is a challenge that we think about every day. And the collaboration between our processing teams and our issuing teams is actually pretty unique in the sense that even before issuing was publicly launched, we were actually using that platform to improve our payments processing capabilities almost from day one, I bet.
And it must be really interesting when you get to see both sides. Did you get any insights that you hadn't expected?
Yeah, I think what many people don't know immediately is that what that payment processor actually sends in that transaction message is not exactly what the issuer sees. All the parties between the processor and the issuer might actually change or add information in particular, like the card networks themselves will even add a risk score to many transactions which will heavily influence the decision of many issuers, as you can imagine. So since we're an issuer ourselves, we can actually see how the networks viewer transactions and iterate basically almost immediately to increase the likelihood that our transactions are accepted. And sort of like as an added bonus, we can also see what other acquirers and processors are doing in the industry and come with new experiments, ideas based on these. So it's really, really helped us speed up our development.
No, it's interesting. Has it changed your relationship with the outside issuers as well?
Yeah, I mean, absolutely. I think one of the things we've really been more keen on is developing these strong collaborative working relationships with major issuers and even the card networks themselves. We know a little bit more about what questions to ask and these relationships have really given us insight into, for example, how an issuer is interpreting new guidelines or e commerce trends they see, but they can also help us do things like benchmark our performance against others. And we can really drill down into what are the differences, what's driving them and what are some areas we should improve. And we use those to find improvements for merchants across stripe, including those running on commerce cloud.
That's awesome. Well, Raymond, I think those are the.
Questions we have for today.
I really want to thank you for your time. I think this is a really exciting partnership and found money is great news for everybody. So thank you.
Yeah, of course. Great chatting with you today, John.
That's it from Inside the Innovation. I hope you enjoyed our conversation today with Raymond. We look forward to seeing you soon. And from all of us here at Inside the Innovation, thank you for your.
Time and I hope you have an outstanding day.










