The preauth problem

Here it is, at long last: the customer on the checkout page, putting in their card details. None of your customers goes through the same journey to get here, but it’s always expensive. Years of brand building, millions in customer acquisition, entire teams optimizing every step of the funnel. 

Then the customer clicks ‘Buy,’ you try to charge the card, and the card has insufficient funds. Game over.

It’s bad enough to lose a customer. But now you also have to deal with other problems: there are network fees to pay on the failed authorization, and if your decline rate climbs, your processing costs can climb with it. And it goes without saying that this customer isn’t coming back. To them, your site is broken.

This is the preauth problem: the fact that you can’t tell whether a card will work until you’ve already tried to charge it. It’s one of the biggest unsolved problems in commerce.

We set out to solve this, and we finally did. Our solution is a tremendous help to the merchants who use it as well as the customers who shop at those merchants. We’ll explain this solution in just a moment but, first, we want to cover why this is such a hard-to-fix problem.

Why preauth hasn’t been solved until now

It’s sometimes surprising to hear how rudimentary preauth can be even at the largest merchants in the world. (We know because we work with these kinds of companies.) Obviously, none of these merchants want preauth to be a problem, but the data to build a more effective solution lives in silos, like at networks and issuers. This is hard data to get.

If you wanted to bring all of this data together and make a fundamentally better preauth solution, you would have to build a new layer that sits in front of the merchant’s checkout and can give advice like “charge Card A, not Card B.” 

It is not easy to build this layer. It’s not the sort of thing you can have a couple engineers vibe code over a weekend. It requires deep connectivity to the financial system. The kind that comes from years of building real-time data access infrastructure into card issuers for the largest fintechs and consumer brands in the country. That's what Method does. That’s why we were able to solve this.

How preauth works when you use Method

The preauth solution we built is part of our suite of products for commerce. It works like this: when a customer arrives at checkout, they enter their name and phone number. Behind the scenes, Method authenticates this person and connects to their full wallet (every card they could pay with, ownership-verified, with useful data like how close a card is to its limit).

You can then answer questions like… Does the person really own this card? Do they have enough available credit to make the purchase? Do they have other cards that they could use? Is the account fresh or dormant? Or, simply, what is the likelihood that this charge is going to succeed?

This changes how checkout works. The old question was “approve or decline this charge.” The new question is “what’s actually going on with this card, and what should the merchant do about it.” Every merchant is already making decisions about how to handle transactions; it’s just that today, they are flying blind. With Method, they have all the context.

A few examples of how this works:

• A subscription platform sees that a user clears their balance on the 8th. It charges on the 9th instead of retrying on the 1st and writing the revenue off.

• A ticketing marketplace sees a card is maxed out before charging it. It skips the network penalty, skips the broken-checkout moment, and suggests BNPL instead.

• A streaming service sees a signup came in on a card with zero spend history that isn’t linked to the user’s name. It suggests the customer use a different one of their cards instead. 

• An ad platform sees a small business’s actual purchasing power across their full wallet, not just the one card on file. They can extend more spending flexibility proportional to capacity.

• A marketplace sees a card entered at checkout doesn't match the user's identity. It flags the transaction before charging and prompts verification.

• A merchant sees multiple small charges hit a new card in quick succession. It flags the pattern before a larger fraudulent transaction clears.

This new approach unlocks some pretty serious downstream benefits. Most merchants have been building their checkout around the assumption that they can’t see anything. Friction, defensive rejections, retries, dunning flows; a lot of this exists because the merchant is flying blind and trying to compensate. When you can see, you don’t need workarounds.

It’s strange but understandable that everyone accepted the old reality of preauth as a fact of life. But it doesn’t have to be that way, not anymore. And once you’ve seen preauth done with real data, it’s hard to go back. 

If this kind of thing sounds valuable, learn more here.