Why Card on File Is One of the Easiest Wins in Embedded Payments

by Todd Ablowitz

Cards on file are exploding right now. So why are we keeping merchants stuck in 2008?

A couple of months ago, I was checking out at the dentist’s office and found out that I still owed them for a previous visit.

I’d submitted payment for that bill using my HSA card weeks before. Little did I know, there wasn’t enough left on the card to cover the entire bill, so it was declined altogether. However, the portal I used didn’t even notify me it had been declined.
As a dental patient, I was so frustrated. I had no idea the HSA card had been declined, and I ended up having to manually pay a bill again — one that I thought I had already paid.

As a payments guy, I was frustrated with our industry. I know we can do better than this.

I should have been able to leave a card on file with that office so they could cover the balance once the HSA card was depleted. The bill would have been paid quicker, speeding funds to the dentist. And it could have been taken care of automatically, making the experience much smoother and less manual for both me and my dentist’s office.

All of this is technically possible. Over the past decade-plus, we’ve gotten a lot better at embedding payments into software, and the technology has really advanced.

But smooth customer experiences that take advantage of the available technology are still the tiny minority, especially in healthcare. And an explosion of potential card-on-file use cases in recent years presents an enormous opportunity to make things better.

Card on file use cases

The term “card on file” refers to cases when a merchant securely stores consumers’ card information on their system (or through a provider) for later use. This is common in recurring billing situations, and it keeps the consumer from having to re-enter card information every time their monthly bill is due. The merchant can easily initiate the payment each cycle, using the stored information.

Recurring billing has skyrocketed in recent years as subscription services have taken off. This trend has declined somewhat over the last year or so as services like streaming platforms have pushed the limit on what consumers are willing to pay, but U.S. households still have an average of 2.8 paid subscriptions, according to one survey.

Cards on file are also increasingly used in ecommerce. The number of merchants who report storing cards on file as a way to reduce failed transactions has increased every one of the last three years. Baynard Institute research lists long, complicated checkout processes as a top reason consumers abandon their carts, and storing cards on file streamlines that process.

But cards on file also shown up in some more unexpected places — even in cases that were traditionally card-present, one-time purchases.
Take restaurants, for example. Most of them used to be an environment without any significant card-not-present volume. People came to the restaurant and had their dinner, then they paid the bill they were presented.
But with the advent of COVID, restaurants evolved into much more of a card-not-present environment. Customers started to order their food and pay ahead. They opted to use DoorDash or another delivery service to summon food from their favorite places.
If the customer already has a card on file with that restaurant or delivery service, the experience of quickly getting something to eat is that much easier. More and more of these use cases are popping up as businesses discover how much more convenient it really is for the consumer to keep their card on file.

We’ve come a long way already — sort of

Implementing cards on file hasn’t been without its challenges. The average card lasts three years. If a merchant keeps cards on file, a third of them are going to either expire or get lost or stolen every year.

This leads to a huge amount of churn. Merchants often find out the card was lost/stolen/expired by just getting a decline. In these card-on-file environments, that means someone has to call or email their customer and convince them to update their card. And the merchant doesn’t get paid until the customer updates their card.

To combat this, the card networks have offered an account updater service for at least 25 years. If the biller checks with them periodically, they can find out new card numbers for any that have been updated.
And that’s helpful. If the merchant can avoid having to call the cardholder and just take care of updating the card on their system, then they’re going to keep a better relationship. But, with these services, they don’t find out right away that the card was lost or stolen or expired. The burden is on the merchant to update their files periodically.

The tokenization solution

Another related challenge for merchants keeping cards on file has been the question of how best to secure them and protect them from hacking.

Tokenization was invented to solve this problem of data security. With tokens, merchants don’t need to store the personal account number (PAN) — the actual card number. Instead, they get a token that represents the card number and cannot be reverse engineered to reveal the PAN.

Obtaining a token involves making an API call to one of the token services. Tokens get stored with the merchant or their provider.

Tokens led to a dramatic improvement in data security. But they also led to an environment where every one of the payment gateways and processors has their own token vault. And they don’t interoperate.

That means that, when merchants change gateways or processors, they may or may not find it easy to take their tokens with them. They have to convert all their tokens to their new provider, which is a technical process. But they also have to have some sort of business arrangement that allows them to move the tokens to a new provider in the first place.

This is where there’s been some gamesmanship. Some providers have taken advantage of unsuspecting merchants, charging enormous fees or even refusing to provide the data altogether.

From tokens to network tokens

So, while tokens have been around for many years, this lack of interoperability means they didn’t fully solve the business case they were intended for.

To remedy this, Visa and MasterCard put tokens on their own platforms. These tokens, commonly known as network tokens, are interoperable across merchant acquirers and processors and within digital wallets, creating a much better experience for the business. They are also typically accompanied by cryptograms, which are one-time use authentication values that tie them to specific transactions, enhancing security.

Network tokenization also helped to solve the lost, stolen or expired card problem. Instead of an occasional update that the merchant has to seek out manually and might typically get weeks after it actually happened, the update is happening automatically, right away.

Authorization rates are also substantially higher when the merchant gets a token, because the issuers trust it more. American Express data says that merchants implementing tokenization experience a 2.75% boost in authorization rates. They get more sales with less work. In many industries, that means more revenue. In some industries, it just means a better customer experience.

Network tokenization is now widely adopted by issuers. Last year, Visa reported that 8,000 issuers were using their tokens and 29% of the transactions they processed used tokens.

The bottom line is that the card-on-file experience is improving from a security and back-office perspective. This all has been decades in the works.

But the customer experience? It still has a long way to go.

Healthcare and cards on file

To show why, let’s go back to the healthcare experience first.

Everyone’s experienced going into a healthcare provider, having to pay a copay, then proceeding to the visit. Sometime later, you get a communication about how much of the visit, if any, was covered by insurance. Then you pay the rest of it.

That is rarely an electronic experience yet. Nearly three-fourths of providers are still mostly using manual processes and paper bills to collect payment from patients. On that paper bill, you’re lucky if there’s a URL or a web address to pay. It’s virtually unheard of for the bill to have a QR code on it.

Here’s where the cards on file come in. Even if there is a printed website or QR code, you’re lucky if provider has your card already.

Rarely does anyone get a communication electronically from the provider or from the practice saying, “Your bill has been finalized, and you owe this amount. Do you want to use the card on file?” In the rare examples where you get a text or email linking you to a patient portal, they still almost always make you enter your card number each time.

You also might use your HSA or FSA card to pay for your healthcare, which depends on prepaid balances. Many of us, when we pay the copay, are going to tap or dip the card in a face-to-face payment terminal. But rarely if ever does a system check to see whether you’re using an HSA card, ask for the balance information, and only charge the available balance.

I’ve also never experienced the device asking if you want to keep the card you use on file for any future balances. And I’ve never seen a case where a backup card is taken for any remaining balance.

All of this is technically possible with existing APIs. Checking whether the card is an HSA card and finding out how much balance is on it is a readily available API call. But nobody has that experience en masse.

The resulting experience is manual and clunky. You submit payment either online or in person with your HSA card, then find out sometime later — in my case, it was weeks later — that it has been declined. And then you have to do it all over again.

The situation is similar for other professional services. I see my tax preparer maybe twice a year. If they do take a card, they don’t keep it on file. You can apply this to other industries, such as auto repair or donations.

All of these have a very similar recurring aspect to the relationship between the buyer and the seller. You’re seeing the same service provider repeatedly, but you have to present a way to pay anew every time.

Putting the functionality together

We have all of this functionality. The business trick is to do all those things in the simplest possible combination of embeddable elements and APIs. That’s where we haven’t simplified the entire process yet.

To make this work in a seamless way, it requires orchestrating as many as 60 to 80 APIs to make it work.

Yes, I’m serious. 60 to 80 APIs.

The software companies that serve the businesses still have to do all those integrations. Fat chance. Most of them are still learning how to spell “payments.”
We’ve gotten a lot better at embedding payments into the software many businesses use to manage their business, but a great customer experience is still the minority. Many businesses are still getting to step one. They’re still solving the most basic problems of embedding payments into the software experience.

And in many, many cases, payments are dis-integrated, when these things are not all embedded in the product.

As an industry, we need to adapt better and more quickly to develop solutions that take advantage of the ways keeping cards on file can improve the user experience and get funds to merchants faster. The future of embedding more and more payment and finance functions into software is sexy and cool, but let’s not neglect getting the payments we already have right.