In 2025, Glenbrook’s Drew Edmond hosted a series on payments performance optimization – how merchants get more good transactions approved and lose fewer customers to failed payments. Since then, Drew has spent most of his time inside subscription businesses doing exactly that work.

This episode is an accumulation of what he has learned about how optimization actually works today. And here’s the short version – for subscription payments and for subscription businesses, an individual transaction success depends on a lot more than just the payment.

Tune in as Drew outlines a data-forward approach that spans every environment a payment touches, highlighted by clips from previous guests from the payments performance optimization series (full episodes linked below):

Oban MacTavish at Spade
Brant Peterson at Worldpay
Rehman Baig at FlexFactor
Chanan Lavi at Kipp
João Del Valle at EBANX

 

 

 

 

Episode Transcript

Drew Edmond: Why does a card get declined at one payment processor and approved at another? Why does a bank send back a decline that says invalid card number and then approve the same exact transaction a second later? And why does a member who has paid every month for three years suddenly look like fraud in month 36?

It wasn’t fraud the first 35 times, but now it’s fraud. I opened my payments optimization series last year on this show with questions just like this. Rehman Baig from FlexFactor saw a version of it firsthand when he was at Adyen, back when Adyen was connecting to the networks through two different sponsor banks.

Rehman Baig: At the time when we had two processors, two banks rather, that were our sponsor banks for the BIN, you could take the exact same merchant, the exact same transaction, the exact same consumer, all the details are the same, it would fail on one, it would go through on the other.

And, you know, obviously one-off stuff happens. It’s not that big of a deal.

Drew Edmond: Yeah, but I mean, that’s wild, right? That’s up to the acquiring BIN, right? That’s not even, like, literally nothing is different.

Same merchant, same customer, same card, two different answers. Ramon’s right that one-off weirdness happens sometimes, but when you’re a subscription business running millions of renewals or hundreds of thousands or tens of thousands, those one-offs add up, and the explanation for results like that is almost never in one single place.

Welcome to Payments on Fire, a podcast from Glenbrook Partners about the payment industry, how it works, and trends in its evolution.

Drew Edmond: Hey everybody, I’m Drew Edmond, partner at Glenbrook and your host for this episode of Payments on Fire. This one’s a little different. There’s no guest today, it’s just me, plus a few of the smartest people I’ve talked to on this show who you’ll hear from along the way. Last year I hosted a series on payments performance optimization, how merchants get more good transactions approved and lose fewer customers to failed payments.

Since then, I’ve spent most of my time inside subscription businesses doing exactly that work. And this episode is an accumulation of what I’ve learned about how optimization actually works today. And here’s the short version. For subscription payments and for subscription businesses, an individual transaction success depends on a lot more than just the payment.

It depends on the offer, the price, the checkout flow, the emails and the receipts that you send, your customer support agents, the card you have on file, the route that it takes, the retry schedule, the merchant’s fraud history, the bank’s fraud model on that particular day, the card network rules, and of course, if there’s any money in the bank account at all. And that’s just for cards.

And every one of those changes kind of on its own schedule, right? Maybe you’d launched a new annual plan, marketing might have added a new affiliate partner, the billing platform that you’re using just shipped a new update. Maybe the bank is changing how it codes its decline codes. The networks change their own thresholds for how they’re monitoring payments.

And when those environments stop moving in lockstep, you start to see performance drifting. Your overall approval rate can be steady, but a single bank could be performing worse or a particular digital wallet.

One subscription plan might be kind of falling apart right underneath you and you don’t even know it. So if nobody’s watching at that level, nobody notices it, and then months later you see it in your report as churn, involuntary churn, voluntary churn.

Now, most of the subscriptions merchants that I work with today have plenty of payments technology, right? You have probably one or more payment providers. You have a billing platform, some fraud tools. You’re using Account Updater. You’ve probably turned on network tokens. Maybe you even have a recovery vendor in there as well. Almost none of them that I’ve worked with have connected all of those environments together.

The processor sees it at the transaction level, the billing platform sees it at the invoice level, the CRM sees it at the customer level, the contact center sees a phone call. None of it’s connected.

So when performance moves overall, the team or the company can’t say why. You can’t tell whether a particular change worked and you can’t really tell if the vendors you’re using are adding incremental benefit.

So the usual answer is, “Well, let’s just get another product.” You know, maybe we need to add an orchestration layer or a different retry vendor, maybe a new fraud tool, maybe add some new dashboards. Now, a lot of those are very good, and I often recommend many of these as components to an optimized payments ecosystem.

But as you add new vendors, as you add new layers to your ecosystem, sometimes they’re adding and introducing their own data, changing or introducing their own definition of what success looks like, using some other algorithm that the merchant can’t see inside, black box retry logic, whatever it might be.

Now, I believe that vendors do belong inside a merchant’s payment strategy, but it doesn’t replace a merchant’s payment strategy.

When I work with and talk to the most sophisticated subscription businesses, they work a little bit differently. They are watching performance continuously. They figure out what changed. They test a fix. They measure it across the entire customer life cycle. They track what they’ve learned. They staff for it.

I saw a recent job posting for a payments insights role at a large marketplace that was looking for 10 years of analytics experience, knowledge of causal inference, payments expertise across fraud and disputes, a graduate degree. It’s not easy for every merchant to hire this person. But that type of background is very useful because it can be very challenging to connect all of these pieces together.

So here’s how we approach it here at Glenbrook with subscription merchants, and it’s kind of how I’ve organized the episode around how we go about this as we’ve gotten better at it over the years.

First is the foundation. You must have a connected data environment. You’ve got your own warehouse. You need to be able to cut your data by many different cuts, right? In as granular a fashion as you can. By bank, by card type, by wallet, by channel, product plan, tenure of customer. All these different ways that you can cut your data helps you find the needle in the haystack sometimes. And then you need a way to test changes against a control group. So you’ve got the data environment and the test environment.

Then we’ve got kind of assessing that environment or assessing every environment really that touches the payment itself. So product and checkout, pricing and bundles, customer communications and support, your CRM, payments, risk and fraud, marketing, external factors that can affect the business.

And then monitoring that and understanding that when something moves, you understand the root cause under the changes to those numbers. From an organizational perspective, who’s responsible for net retention across growth and payments and fraud and finance and support? And then there’s kind of the maturity curve itself of moving up that path in stages from kind of a scattered environment to really highly optimized payments management.

So if you’ve seen a certain movie from a few years back, you’re gonna understand the title of this episode. Every payment, every environment, all at once. That’s the job. Let’s get into it.

So before we get into the weeds, and you know me, I love to get into the weeds on payments, and this will be no exception. In fact, it’ll probably be the rule. But I wanted to up-level some thoughts for folks that maybe want to hear some themes at a higher level about what I’ve learned and what we’ve learned from working with subscription merchants over the years.

One is that the view is often too shallow. Most subscription merchants are looking at their payments through, at most, their processor’s dashboard, monthly approval rates at a high level, and that view really leaves out most of what moves payment performance, right? Understanding how each individual offer, how your checkout flow, how your card mix, the messaging with your customers, fraud rules, the customer’s bank itself. All of those impact payment performance differently.

And understanding that or trying to get to the bottom of what might be changing performance can take days of manual work in some cases, and working off of spreadsheets or trying to pull in CSVs after the fact to try to hunt down what might be the problem.

The second issue is that teams can be very siloed, right? We’ve got growth and payments and fraud and finance and customer support. Oftentimes these teams are kind of running their own shops and, you know, they have their own metrics that they’re measured against and that they’re measuring themselves against.

Growth could bring in customers whose payments then fail at the renewal stage. The fraud team or whoever’s in charge of fraud might be blocking cards that could have been successful. Finance is likely monitoring the cost of payments and trying to optimize those numbers, which may come at the expense of greater growth. Support could be out there recovering payments that the automated retry system could have gotten for cheaper or faster or differently. And nobody sees the whole picture and nobody owns it. So the organizational perspective, or component is really important.

The third part is testing is often too narrow if it exists at all. I think, when it comes to optimization, testing is a really critical component of how to lead to maximum success ultimately, or at least as close as you can get to it. There’s no silver bullet. We’re gonna say that a lot.

And so testing and finding what works for you with your business and your customers and their card mix and their payment method mix, you have to figure out what works best for your business. So you have to test correctly and build your ecosystem from an operational and data perspective in such a way that testing works and is accurate and leads to the outcomes that you’re looking for.

And fourth is kind of the maturity curve that I talked about earlier. Merchants start with data scattered across all these systems. They generate reports that happen after the damage is already done rather than preventing it. So that next step is really connecting data across all these teams, across all these different data sources, testing against controls, running it continuously with an owner monitoring problems that are flagged early.

So it’s really important to start to figure out where you sit on that maturity curve and how to move up, because that’s the only way you’re really gonna get to actual maximum performance, which is what we want.

So let’s get into why this is so hard to get right. There’s no single fix, right? There’s no single fix that works. Payment performance isn’t usually like everything’s great and then everything breaks one day. It’s usually multiple little pieces happening for various reasons over time in different ways. If you’re only looking at kind of surface numbers of high-level approval rates or high-level churn rates, you’re not gonna understand what’s happening.

So why doesn’t a single fix work? We kind of came at this, in the conversations we had during the optimization series, we kind of came at this from some different angles.

So we had Oban McTavish from Spade on kind of from the bank perspective, what they can and can’t see, which was really illuminating because the limitations in the data itself is a fundamental component to payment failure, right?

What banks can see, and that’s what Spade is focused on in terms of trying to enhance and enrich the data that banks can see so that they can make better decisions with it as a result.

We talked to Brant Peterson at Worldpay, now Global Payments, of course. At the time it was still Worldpay. We were talking to him about kind of what the payment processor can control, and of course there’s a lot of value add that payment service providers focus on offering to their merchant customers in order to improve their performance. And so we learned from him on what they focus on there.

We talked to Rehman at Flexfactor. We heard him at the top of the show here, about how kind of the merchant of record model that Flexfactor uses as kind of a new entrant into payment recovery, not at just the renewal stage, but also those upfront payments that have historically been much harder to optimize because you only have the time at which the customer is there versus N number of days to recover a payment for a renewal failure.

With Chanan Levi at Kipp, we discussed insufficient funds, and those are a critical component, obviously, of the optimization experience because it’s typically a major reason for declines. And they have a unique solution for how merchants and issuing banks can work together to improve those.

So we’re really looking at it from all these different points, and it really kind of supports that notion that there is no single fix. All those different components, whether it’s do I leverage a merchant of record model? Which PSP is going to provide me with the best approval rates and optimization services? And which banks are taking advantage of this enriched data from a company like Spade to make better decisions? Or as we go into the conversation around merchant and issuer data sharing. Again, just that overall notion that the more information we can provide to the banks, the better decisions they can make at the approval stage.

So no single fix. And there’s some additional context here. I wanted to pull in a clip from the conversation with Oban because he talks about why the bank’s incentives look so different from the merchants, and how that can result in some of the optimization or approval failures that we see.

Oban McTavish: I often think about it like there is a fundamental difference between how much risk the bank is taking on as a business for every single payment and how much money they make versus the merchants, and they’re essentially completely inversely correlated.

Merchants, especially many of these subscription businesses. High margin, very sticky. All of your jobs is like, “Hey, I want to give you your subscription to, like, a box of food you get every month,” and their margin at minimum is probably, you know, 30, 40%, maybe higher, maybe lower, whatever.

The bank is potentially making 1 to 2% per payment, and the cost of being wrong there is a lost customer, which includes all of these financial products. It includes a lack of trust. It includes someone calling up their local radio station and saying they got scammed by their bank. And I do think that there’s this massive, almost like completely different perspective that the financial institutions and the merchants have.

Drew Edmond: So the bank is weighing a percent or two of revenue against the cost of being wrong, and it’s reacting to everything else that’s going on in the system, right? Your history as a merchant, the data that you’re sending, the particular balance that’s sitting in that account when that transaction happens. So the bank’s going to make that call with all that in mind.

Now, when we look at a subscription business, there’s multiple examples that we kind of can see right? Maybe the product changed the actual payment mix, because we switched from monthly plans to annual plans, and now we are starting to see more closed account declines a year later because the card on file’s been replaced, and it wasn’t updated with the merchant, and so we’re starting to see that. So that’s a change that can result in drift of performance.

Something else that can happen is you’ve introduced a new way to pay, and that’s changed the mixture of your payment method mix or your card mix. So you introduce Apple Pay. Maybe for whatever reason, Apple Pay for your customer portfolio is highly concentrated in a category of banks like neobank cards that, neobank debit cards that approve far less often than cards than from traditional banks.

Or maybe your vendor changed its logic. Maybe you’re using a billing platform’s retry solution, and recovery is starting to slip because they’re experimenting with new logic on that side, and you don’t have insight into those changes. So it’s really important just to understand the different cuts that you can use to manage and monitor your performance.

That leads us into a discussion about the data environment itself. I think if you ask a lot of subscription businesses why renewal revenue maybe went down or up in the last month, you can get some spreadsheet work and a pretty, kind of a best guess on why that happened. And the reason for that is that the data that explains the real root cause there sits on other team’s systems and none of it’s connected.

Now, merchants often have a lot of data. It’s usually not a lack of data that exists. The problem is often that it’s spread across systems that just don’t talk to each other. So the provider, your payment processor, your billing platform, your CRM, your contact center, your fraud tools, some spreadsheets that were built in Google Sheets, you know, two years ago. These are all independent data silos.

So I like to typically go in and ask a merchant, you know, “Take the customers who came in through one affiliate partner who paid with Apple Pay on a neobank debit card. What share of them set up the payment method successfully on the first try? How many of them completed the first purchase? Of those, which triggered a fraud review? How many were successful on their first renewal? How many were recovered after a particular failure? How many asked for a refund? How many disputed a charge? How many were around a year later?”

It’s actually very hard to get answers in the moment from a lot of merchants when you start to ask that level of detail, and that’s the level of detail that you really have to get to in order to optimize your payments, because you need to be able to tie all of those pieces together to start to understand why certain metrics are acting the way that they are.

And why that matters, you know, with one merchant I worked with, Apple Pay looked strange when we started looking at the data, and so we were, on particular renewals, Apple Pay renewals, they were failing at a higher rate. So, I think the obvious move is, “Oh, there’s something wrong with Apple Pay,” right? The obvious move is to go fix Apple Pay, go talk to the provider, go talk to the billing platform, and try to understand how we configured Apple Pay incorrectly and what’s leading to this.

But once we joined all the data together, we actually were able to learn that the wallet was fine. There was nothing wrong with the configuration, the integration. It just so happened that the people that used Apple Pay were disproportionately neobank debit card users, by a large amount, six, six to seven times the normal amount. Now, you pair that with just a general lower approval rate on those cards, and you’re gonna get a chart that shows that Apple Pay is performing worse, but in reality it’s just the customer mix that’s going on there.

So again, just an example to kind of support the notion that until you combine as many sources as possible, you might try to fix something that’s not broken

So seeing the data is definitely half the effort. The other half is kind of choosing specifically what to focus on. And Chanan described a habit that that we run into regularly.

Chanan Lavi: In essence, you can see it through the way that merchants are analyzing their declines. In many cases, they simply remove the NSF declines because they’re saying, “Okay, there’s nothing much I can do with that. Let’s just analyze the real declines that we can do something with.”

So it’s a big problem that needs a solution.

Drew Edmond: So I get it. Insufficient funds feels like it’s a customer problem. They don’t have enough funds in their account. It’s often the single biggest decline reason in the data. So, you know, maybe you filter it out because you don’t think you have an opportunity to fix it. But in reality, there’s a lot of lost revenue there that’s still achievable.

So let’s talk about what a working data environment looks like. I think we want to make sure that we’re reporting at multiple levels, right? We want to report at the level of the payment, the level of the invoice, the level of the subscription, and in some cases, the level of a customer, if a customer can have multiple subscriptions. So you have multiple layers that you need to touch.

Then you need to have really good granular data. In some cases, your providers may be offering more normalized data, decline reason codes, for example, that are normalized at the network or the PSP level. And where you can, you wanna be able to get decline codes that come directly from the bank so that you can get down to that level of detail.

A working data environment connects the pieces that often can break apart, right? It’s really important that joining together things like a failed card add tied to the same customer who comes back two days later, or a retry tied to the original failure, or the billing platform’s payment method tied to how the payment service provider stores that particular credential. You have to make sure that you’re joining these pieces in the right areas.

And the challenge is keeping that data environment really accurate. So processors change their data formats. A new payment method might show up with values that no one’s mapped yet. A new channel could be created that the model doesn’t know how to classify.

So you’re looking at dashboards, you’re looking at charts, but the underlying numbers actually are not true. So data integrity across all these joins, across all these sources is critical.

All right, so we’ve talked about the data environment, and of course, that’s important. A lot of people are missing it. Once you have that in place, the next question becomes whether anything that you change as a result of something you saw in the data actually works. I think an area that goes unmentioned oftentimes is related to the testing environment itself.

Now, a lot of teams test. A lot of teams test kind of in silos, maybe particularly tied to one of the few metrics that they own on their particular team, right? So a payments team is really testing on approvals. Growth and product might be testing conversion. Fraud team is testing things that affect fraud losses. You can be successful on some of those tests and still make the wrong decision for the business.

You know, when we talked to Brant, he was quoting his Chief Product Officer at Worldpay at the time, who’s now CPO at Global Payments, Cindy Turner, who likes to say that optimization is a game of tweaks. And I completely agree, with one condition. A tweak only counts if you can measure what it did. I think we see merchants trying a lot of different things. Change the retry timing, make adjustments to the checkout flow, change a fraud rule, adjust the copy on a dunning email, and then you watch the number. You watch the number for the metric that, that you care about most.

Using control groups, the use of control groups is varied, I would say. Using control groups correctly, even more varied. Or running a test in a vendor’s tool and kind of just accepting the vendor’s own measurement of how they did rather than really comparing it to prior or current behavior in the system.

You know, moving all of your volume over to a new tool and not understanding if degradation in performance is tied to the tool itself or underlying root causes that, that aren’t being monitored. And to be fair, it’s not easy. The reality is that measurement is hard even for sophisticated payments providers, and it’s something that they continuously work at in terms of improving how they do it, improving how they communicate the results of what they’re doing to their customers.

And I’ll reach out to a, a clip here that Brant spoke on related to this topic

Brant Peterson: How do you prove the lift? How do you prove authorization lift? And it’s something I think we’ve actually started to unlock, and our early pilots have indicated meaningful impact. It’s just, it’s harder than the actual technology itself to prove that, so. But I think what we get excited about-

Drew Edmond: Is that kind of AB testing control groups and just trying to measure the difference between those? Is that like at the merchant level or at the BIN level, like what are the levels that you kind of test that to see what that does?

Brant Peterson: Yeah. Yeah, absolutely. We have AB testing experimentation with defined control groups that can be both configurable, and we can turn up, like you said, these little dials that can turn up the levers and turn, taper them down depending on what that is.

But I think the hard part is reporting it in a way, into a dashboard that merchants understand that matters to them, right? Which is the hard part, right? Yeah, absolutely. It’s the ability of, like, quantifying that in a way that they can easily distill and understand because things like AB testing and control and experimentation are not easy concepts.

Drew Edmond: So if it’s hard for Worldpay, Global Payments, to show a merchant the lift on a particular change that’s being done, I can only imagine, you know, it’s challenging for any merchant to do this correctly, do it accurately, communicate it effectively. And so that’s something that we oftentimes spend time working on to ensure that the testing environment and process is done really well.

And I think the real fundamental recommendation is measuring the entire customer life cycle, right? We oftentimes go straight, as payments folks, we think a lot about approval rates. So it’s obviously a very important metric, whether that’s at the invoice level, at the individual payment level, both are interesting in their own different ways.

But we really need to be holistic and comprehensive about how we approach measuring, monitoring, and testing as it relates to payment success. Because we have approvals, of course, we have recovery, we have people updating their cards or their payment methods. We have the number of times and the success rate related to customer support agents contacting customers or customers contacting support and what that results in. Refunds, disputes, renewals, churn, all these pieces that tie together.

If you just stop at approval rates and you’re not looking at refunds and you’re not looking at disputes, you’re missing the forest for the trees. Maybe that’s the right analogy? Then there’s kind of this notion of incrementality, and I think that is an important question to think about when you are building and evolving your payments environment.

You have to think about, does this change I’m making from a vendor perspective or even from an internal process change, what is the incremental impact of it, right? So if you’re adding a new recovery vendor, for example, is it something that’s adding incremental value for the cost that you’re paying, or would you have recovered those payments either way?

So you need to be able to understand how changes affect your outcomes and what the outcomes would have been had you not made that change. And the reality is this is always a moving target. There’s so much going on, so many different factors that can influence your payments, that you have to really understand kind of the broad environment, right?

Things like do not honor retries, right? I think the usage of that particular decline code has changed over time. Your ability to recover that for some merchants has changed over time. I think you have to have this kind of sequential chronological understanding of changes in the ecosystem that can influence your payments as well.

So keeping a history log, a register of tests that you’ve run, of changes that have happened in the ecosystem. All these things can help future you understand why data looked like it did in the past, why certain tests were successful versus not, how that might influence what you do tomorrow.

All right, so we’ve gone through two environments now. We’ve gone through the data environment, we’ve gone through test environment, the test process. Once you have those in place, especially on the data environment side, you can really get into kind of how you think about assessing your business using the data that you have. And like I said, there’s no silver bullet here. The problem of ongoing optimization is often spread across so many places, you have to work on all of them in concert.

And I have to admit something. When I started doing these kind of payment optimization projects for merchants years ago, I went straight to kind of just the payment setup, network tokens and account updater and routing and all of our favorite payments topics, because that was my comfort zone. It was pure payments.

But the reality is the data started to pull me elsewhere. What’s going on on the screen at checkout? What are the emails saying? What do the transaction receipts say? Because the reality is, as we continue to say here, it’s not just the payment that affects future payments, right?

It’s this comprehensive, ongoing, ever-evolving state of the world from your internal environments to the external environments that can affect payments. And how you interact with your customer today can affect how payments are approved tomorrow, right? If all of a sudden your dispute rates and your fraud rates go off the charts, well, what do you think the banks are going to do when they see transactions coming from your merchant ID come across their threshold, and now they have to make a decision on that payment when you haven’t been able to manage your disputes?

Well, they’re going to decline those payments. And so, that’s just one example of how what your merchant history, your current behavior, how you interact with the banks themselves, especially on card payments in terms of what your approval rates can look like.

So when we go in to a merchant, we spend a lot of time looking across every environment that we’ve been talking about. We talk to folks about product and customer communications and payments and risk and fraud and what’s going on outside the business and the external environment, right? And then once the data’s all joined together, we can kind of try to figure out what might be causing some problems and how big each of those problems are.

And you want to understand it from an operational perspective, from a revenue perspective and try to identify the priorities that are emerging in terms of the short, medium, and long-term changes or tests that can be made, that can be run to influence performance as a result. Once you’ve done that, you’ve got kind of a list. You’ve got a kind of a punch list of things to try out, things to implement, things to talk to your providers about.

Going back to an older episode, Chanan has some advice for operators here.

Chanan Lavi: I would just say again that I think a payment manager at a merchant should try to do as many optimization projects as he could. You cannot, like we said before, there isn’t one silver bullet that solves all your problems. You need to really test the waters with all these different solutions.

Eventually maybe all of them will mature or at least some of them will really, really create big value for you. Definitely if there’s no big effort to implement them, then I would do that.

Drew Edmond: So run the projects, measure them. Some will be worth a lot, some won’t, but you’re only gonna find out if testing is done correctly, if it’s in place, if you have the da- data environment set up correctly to understand the outcomes.

All right, so I just want to run through some of the, some of the environments, at a medium level.

We, we won’t be super high level, but we’ll get into some of the weeds because I can’t help myself. We’ve touched on this a few times, but the product environment is a really, really critical component here. Oftentimes because how a customer interfaces with your, with your service, with your products, et cetera, um, has a major impact on the success of, in some cases, the transaction at the time that it’s happening or the future success of, of potentially a renewal or the, your ability to recover them or their likelihood to refund or dispute a transaction which ultimately also affects your approval rate success.

Again, this is in some, in some cases this can be very kind of abstracted in an organization. You might have growth and product teams that are making decisions that can lead to success or failures down the road. Are we making changes to the plans? Are we introducing trials? Are there different channels now that customers might be coming in through, uh, and that particular cohort performs differently.

They use different cards. They are a different demographic, um, from a financial, financial perspective. Maybe changes to a checkout redesign. You know, if your growth teams are judged, their p- if their performance is judged on new signups and they’re doing everything they can, they’re incentivized to generate new signups at all costs, well, the downstream implications of that can be massive when it comes to payment success, right?

And is it signups and a successful payment that they’re measured on or just signups? Is it signups and successful payment and the first three, first three renewals? Are they incentivized for l- the long-term value of a customer or just that initial signup? So there’s, there’s massive, massive impacts on, on how organizations are structured, incentivized, measured, and whether or not the teams are speaking to one another on, on the end-to-end customer life cycle associated with it, ’cause that ultimately is what we, what we want to measure on is, is that total health rather than individual metrics alone.

There’s kind of different components of this, you know, from a in the weeds perspective, how free trials are run can, can lead to all sorts of different behaviors. You know, how are trial conversions approving versus that first follow-up attempt? Uh, what are the refund and chargeback rates of those, of those trials?

Trials are a major, major issue for a lot of subscription merchants and kind of an ongoing point of contention and, and discussion, um, in the industry and individual merchants to understand how to best leverage that tactic to drive signups and to drive customer growth. When I think about the checkout flow itself, fundamental component, obviously this is the journey that your customer is going on to pay you, and so you want that to be a lovely experience for every customer, as personalized as it can be or should be for different cohorts of your customer base to make sure that they are getting the best experience possible, and it’s leading to the highest likelihood of success without confusion down the road that could lead to a refund or a dispute.

And there’s many components of how to think about that from the payment methods that you’re offering, where you’re offering certain payment methods, the language on the page, how many steps are there? What do the buttons look like? What’s the onboarding experience if you use something like a pay by bank versus, you know, am I manually entering, entering my account number and routing number?

Is this, you know, is it a Plaid-like experience that I’m clicking a button and entering my, my bank login details? How does that integration work between my billing provider and the, and the payment provider that’s actually processing that payment? And is that functioning at a level that’s, that’s actually strong and good and leads to success?

And payment methods themselves are a component that not just subscription merchants, all merchants think about a lot. We had a really great conversation with, uh, with João de Vale at Ebanx, and he was talking specifically about Pix Automático, the recurring capability added to Pix. Of course, the popular, very popular payment method in Brazil.

And he mentioned something that surprised me

João Del Valle: And when we analyze some of the merchants, some, not all of them, but the one important data point, 50% of the users that subscribe through Pix Automático are new users to that merchant. Wow. Wow. That’s really powerful. So if you’re getting like 1,000 people subscribing to Pix Automático, 500 of those are gonna be new users.

And that’s really powerful because that is rich. That is rich. That’s new users.

Drew Edmond: So half, right? I mean, Brazil has about 60 million or so financially active adults who don’t have a credit card, and adding this recurring bank payment made them reachable for subscriptions for the first time. So how you choose to integrate payment methods or new capabilities for particular payment methods can be really important.

How you think about cross-border and local acquiring, and how you implement your global acquiring strategy from a merchant category code perspective is really important. We’ve talked about multiple times on “Payments on Fire” around the fact that there is no regional payment strategy, right?

You don’t go into Europe and say, “Here’s my Europe strategy.” It’s like, no, you have to have a France strategy and a Germany strategy and so on, because local acquiring and local schemes and local payment methods are the levers there that can really impact your success within the grand scheme of things, with all these different environments that we’re talking about.

All right, so we talked about product a lot, a lot that you can do on that front, a lot of impact that the product environment has. Going back to the payments environment, like I said, this is kind of where I started when we started doing these types of projects, ’cause it was a natural fit given what we do at Glenbrook.

Still critical, right? I mean, still really critical component to what we’re trying to accomplish here from a performance success standpoint. Now, certainly payments teams are judged oftentimes on approval rate. Retry logic is a fundamental component of a subscription payments operations team, how they think about retry logic, whether it’s something that they own themselves, whether they use a vendor to either supplement with the failures that they weren’t able to recover or to completely kind of own the strategy on their behalf.

Let’s take a step back, maybe two steps, and start with why payments fail. Brant Peterson laid it out, starting with the two most common reasons.

Brant Peterson: The first one we see, number one, financial declines. Insufficient funds is the number one reason why cards decline. Yet, and honestly, it’s really historically been an untapped area in optimization, right?

There is opportunity, and we can talk a little bit about what those strategies could be we’re starting to see in the market. But historically, those have just been an untapped opportunity within a market, especially as we start to mature the space. The second one that we see, number two, is these are addressable, like payment life cycle declines.

Cards expire, they get lost, they’re constantly being reissued. There are technologies like network payment tokens, card account updater, life cycle capabilities that actually can significantly reduce these declines. They’ve had demonstrated success that they’ve done that. But still, we still see declines on payment life cycle more than you would think. Even in the digital space, even in the recurring space, a number of our subscription customers are not adopting these technologies to reduce that.

Drew Edmond: Now, Brant had two more reasons on his list, customers switching off cards in their banking app and fraud, and we’ll get back to those in a little bit here. But on the second one that he mentioned, the lifecycle tools, network tokens, account updaters. These are the services that refresh expired cards or reissued cards, and they of course help a ton, right?

I think any subscription merchant probably knows or knows of these two issues and hopefully is leveraging both of them in some fashion. They also aren’t perfect, right? They work unevenly by bank, by card range, by region, by country. Falling back to raw PAN if possible. Oftentimes it’s the payment service provider doing this on behalf of a merchant if a token is underperforming or not available.

This isn’t kind of a set it and forget it. We flipped on account updater, we flipped on network tokens and hoping for the best, right? No. It’s kind of this ongoing managed process as these tools change, as usage of the tools vary across financial institutions. It’s something that has to be managed at either the merchant level, billing platform, token vault, PSP, et cetera level to really maximize performance.

Sometimes the biggest problems can hide in plain sight, right? I mean, we were working with a merchant and sometimes you just see some really strange data pop up, right? We saw one of the merchants we worked with, the second-largest decline reason code was key exchange validation failed, right?

This is a failed cryptographic handshake, and 99% of it was on one single card network. Or you might see something like timeout at issuer. What’s going on there, right? So you have to kind of continuously maintain an understanding of what type of issues are popping up because it’s not a static world and these changes happen all the time, so you have to keep an eye on everything.

There are a thousand different things to look at, thinking about insufficient funds and your retry timing. If everyone’s trying to retry at 3:00 A.M. on Friday, are we all trying to get the same amount of money at the same time? Insufficient funds can still be a real challenge even when you optimize to the timing of the bank deposit.

Hard declines. How do we think about hard declines? Do we retry them? My network friends will tell me, “Don’t do it. You’re gonna get fined.” Merchants are gonna say, “What’s the cost of the fine compared to the reality that some of these hard declines actually recover and those end up being long-term good customers?”

What’s going on there? Is that an issue with the banks themselves sending bad data? Maybe. How we think about routing. US debit routing, pinless debit routing, routing to local schemes and local networks, routing to different providers, payment service providers. We talked right at the beginning with the quote from Rehman talking about his experience at Adyen.

We’re routing to two different sponsor banks within a PSP, and we’re getting different results. Well, layer that into, I’ve got three different PSPs that I can choose from, some of which have debit networks that I can route over or local networks that I can route over in other countries.

There’s some different options that can happen here. Are you set up in such a way that, one, you can take advantage of them, or have you integrated in such a way that it’s really hard to actually fail over from one payment provider to another, or from one network to another, or whatever it might be?

And then understanding your card mix and your card portfolio for the folks in the audience that run a subscription business and that look at your bank data and understand the outsize impact that some of the neobank-like cards can have on your approval rate, because those cards are used differently, right?

Maybe from a demographic perspective, maybe from an individual perspective, it may not be their primary card. You’re just gonna run into maybe some approval rate issues there from an insufficient funds perspective and maybe some other reasons as well.

Okay. So risk and fraud, another environment that we want to look at.

The reality is that fraud has a massive impact on approval rates. Your dispute rate has a massive impact on your approval rates. It can be challenging to recover from a period of time where if you’ve had elevated fraud and risk, fraud issues and dispute issues, to get your approval rates back up.

I wanted to bring in a quote from Oban when we talked about how banks think about defending themselves, and it’s something that’s really stuck with me.

Oban McTavish: And if you think about the strategies they employ, I think that is very clearly represented by it, right? They’re blocking MIDs. They’re making adjustments based on MCC codes. They’re maybe tracking the dispute rate on a specific MID, and the unfortunate reality is that many of the behaviors trustworthy merchants do to try to optimize their payments actually look a lot like a scammer.

And it’s this weird sort of double-edged sword where on one hand, we all admit that we want to sort of maximize auth rates because having your transaction declined is unbelievably frustrating, and it damages your trust with your bank. But on the other hand, these fraudsters are very sophisticated.

They’re gonna come in, they have five to 10 different merchant IDs, they’re gonna go to different MCC codes. They’re using the most trustworthy MCC codes, and it makes it really hard for the bank to sort of come up with a strategy of saying, “How do I minimize fraud losses while improving performance?”

Drew Edmond: Okay, so he mentioned rotating merchant IDs and switching category codes and retrying hard declines, and a lot of things that we may ultimately recommend depending on what a merchant is doing today, related to trying new things out to optimize their payments. The problem is, as he points out, that a lot of that is exactly what a fraudster might be doing.

And while I don’t recommend that anyone be a fraudster, I do recommend some other tactics, I guess, because some of them work when it comes to optimization, but you have to always be mindful about how you look to the bank on the other end of a transaction. So in a vacuum, a particular tactic could work and be successful for a particular payment or a particular invoice.

But on the whole, if that same tactic’s applied maybe at too broad a set of your portfolio, that may lead to further degradation down the road. And I think about this as, I call it merchant integrity, right? This is kind of how a bank views you as a merchant. Are you a good merchant or a bad merchant?

Where do you fall along the spectrum? There’s a lot of things that can influence that in terms of the type of behaviors that a merchant can leverage to try to win that next particular transaction. So all that to say that of the testing you do, of the things you try, of the roadmap that you set for yourself, it has to be through the lens of, is this going to help me long-term or hurt me long-term?

And there’s no standard answer for that. Merchants ask a lot, “Well, can I do this? Can I do that?” Sure. I mean, you can try it. You can test it. You can keep an eye on your long-term impact. You can try to reconcile if that was a change that resulted in a long-term benefit or a negative impact. And just quickly, on the fourth reason from Brant on declines around fraud, you can block fraud.

You can use tools to block payments. You can block even particular card types, certain banks. There’s a lot that you can do upfront. But if you don’t do a good job, you’re blocking good customers, that’s also bad. So there’s always going to be this tension of how do I optimize on fraud loss as well as approval and long-term success.

And one thing that you have to be careful about is some of these tools that are out there that, again, are great tools. Chargeback deflection tools, great tools. We love deflecting chargebacks. Nobody wants a chargeback. They’re expensive. They’re operationally heavy sometimes. But if you are not also monitoring disputes in addition to chargebacks, then you might be masking disputes that are causing an impact on your approval rates by blocking these chargebacks and not looking at disputes.

So good to block chargebacks, bad to not monitor disputes in parallel so that you know what’s actually happening behind the scenes, your customers’ interactions with their banks, and then ultimately how those banks are viewing you.

All right. So I’m going to touch on a few other points just to start to bring us to a close here. One is the concept of better data sharing. It’s something that came up in some of the conversations that we had with Oban and Brant and some other folks.

I think probably the most interesting topic maybe on that front these days is related to Visa DCAP, the Digital Commerce Authentication Program, 3DS Data Only, these kind of network pipes for merchants to provide more data to banks for them to make better decisions. There’s some major questions, I think, in terms of issuer participation, efficacy of providing the data, ability for certain merchants to even provide that data in the first place, depending on kind of the terms and conditions they have with their own customers.

Overall, the ability to share more data, at least having that capacity is good to have those pipes. I think there’s probably more to get worked out on improving issuer participation, improving the effect of sharing that data with issuers to make better decisions so that it leads to better decisions.

I think another one that I’m always watching is kind of the growth of the ability for cardholders to manage their subscriptions within their own banking app. And to speak to that, I will call back to Brant again on this trend itself.

Brant Peterson: Probably the most interesting trend that we’re starting to see coming up, card not active. This is one where banks now are offering cardholders more control over the payment credential life cycle.

Not the merchants, but the actual cardholders can go into their bank app. They’re allowed to pause, delete, issue new virtual cards against the banking app. And so while that allows great control and responsibility for the consumers, it really creates these… Or I’ll say cardholders, I should say.

It’s really creating unintended friction for our merchants, right? Especially our subscription merchants because they are the ones that want to control that experience. So my favorite streaming service, I can go directly to their online application and pause and resume and do all of these types of things.

When they are actually implemented at the bank app, then our merchants start to lose that visibility with the life cycle, and it kind of creates some disruption and some friction.

Drew Edmond: So since we had that conversation with Brant, both Visa and Mastercard have subscription management capabilities that are offered to their issuing customers, their bank customers that can offer those then to their cardholders, who can then see their subscriptions and cancel them right there in the banking app.

I think that’s a trend that will continue to grow. I think that something that’s maybe adjacent and similar to that is AI agents that can do that on behalf of consumers, and we are already starting to see that, right? This is late September twenty twenty-six. Muse and Instinct are in the market.

They will not be the only agents in the market capable of doing something like finding all of my recurring payments in my emails, in my banking app, in my whatever data source that shows that I have a subscription that’s live, and has the ability to go off and cancel it for you, whether that’s making a phone call, doing something agentically online on your behalf.

I think we might see a bit of a wave coming if consumers adopt these particular agents and use it for this purpose, to cancel subscriptions. We might see some issues on that from a churn perspective. It’ll likely look, in most cases, like voluntary churn to a lot of merchants, but we’ll see how these things start to emerge.

It’s something I’m definitely keeping an eye on. Again, this is in the realm of external data environment. What are the things that could affect my business that aren’t directly in my control? Other things like cancellation rules, FTC’s click to cancel. A lot of states have passed their own versions of this.

New York City, the city itself has its own version of it in terms of making canceling as easy as signing up. So understanding what your cancel flow looks like, your consent language, all those types of things. We’re certainly keeping an eye on the card networks and their scorecards related to risk and fraud and dispute metrics, VAMP, Mastercard’s new program.

Those signals from the networks can shape how the banks treat you. Again, tying all this back to fraud and disputes and how that can affect future approvals themselves.

All right. So just to close it out, and kind of back to the questions that I started with, the answers to those questions and the answers to the questions that all subscription merchants should be thinking about, the answers aren’t in one place. They are spread across your organization, in teams, in people’s brains, in different data sources, and those environments continue to change and keep moving.

And so the subscription merchants that can get payment performance right, those that are performing really well, can see everything, can test what they change, can keep all these environments together. Every payment, every environment, all at once. Look at that, we tied it all back together.

A big thank you to our guests from previous episodes, Oban McTavish at Spade, Brant Peterson at Worldpay, Rehman Baig at FlexFactor, Chanan Lavi at Kipp, João Del Valle at Ebanx. Their conversations made this episode possible. If you haven’t heard them, you can find the links in the show notes. To all of you listening, thank you for joining.

Until next time, keep up the good work. Goodbye for now.