Field notes · Payments optimization
Payment optimization balances approvals, fraud, and cost, all scored in the merchant's P&L. The cleanest number in that math is a real person the system quietly decided to read as a threat.
What I've come to believe
Payment optimization is correctly taught as a balancing act: push approval rates too hard and you invite fraud and fees, clamp fraud too hard and you turn away good customers. All true, and all of it scored in the merchant's profit. What I have come to believe is that the whole framework is measured from one side of the counter, and its tidiest assumption is that a known number of legitimate people can be wrongly turned away as the acceptable cost of doing business.
There is a genuinely smart systems idea at the center of modern payments: approval rate, fraud, and network cost are not three separate dials, they are one interconnected loop, and chasing any of them in isolation backfires. The classic example is the Q4 merchant who relaxes fraud filters and retries every decline to push approvals from 87 to 91 percent, then watches network fees and disputes spike, watches issuers notice the fraud and quietly cut the merchant's trust score, and watches them start declining the merchant's legitimate traffic until the approval rate they were chasing falls below where it started. I have drawn the mechanics of a single swipe elsewhere. This is about what happens when you optimize millions of them, and who pays for it.
Look closely at that feedback loop and notice what every node in it is denominated in: dollars to the merchant. Lost sales, dispute fees, lost cost of goods, the trust score, the routing bill. It is a closed accounting system, and it is a good one. The Wayfair move of treating payments as a revenue P&L rather than a cost center is smarter than chasing a headline approval number, because it forces you to weigh the whole picture instead of one vanity metric.
But there is one cost that never enters the loop, because it lands on someone who is not in the room: the legitimate customer who gets declined. In the merchant's books that is a "false positive," a small, accepted percentage. To the person at the register it is a different event entirely, and it is the one the framework is structurally built not to see.
The decline rate is a merchant metric. Every point of it is a person who tried to pay and was told no, and never told why.
A fraud model sorts every transaction into one of these four. Optimization obsesses over the bottom row. Only the top right cell holds a person the system got wrong, and it is the one cell nobody is measured on.
My take
I work the back end of consumer credit, the side that deals with the person the system has already decided is a problem. So I read a payments-optimization deck the way I read everything: I go looking for the person on the wrong end of the metric. In payments, that person has a name in the model. It is "false positive."
Sit with that phrase for a second. A false positive is a real human being who tried to pay for something they could afford, and a fraud model, optimizing a merchant's margin, decided they looked enough like a criminal to turn away. They get no explanation. "Card declined," in front of a line, or a silent failure on a screen. No appeal, no recourse, usually no idea it even happened or why. And the framework that produced that moment does not register it as a failure. It registers it as the cost side of a correctly tuned trade. An acceptable number. Optimized.
Here is the part that actually gets me. The notes rightly say to reduce friction for known, loyal users: a long-term subscriber should never hit the same wall as an unknown first-time buyer. I agree, and I would push it harder, because the inverse is the quiet cruelty of the whole system. The people most likely to eat a false positive are the ones with the thinnest histories: new cards, new credit, names and addresses and devices the models have not seen enough of. Which is to say the system is most willing to wrongly decline exactly the people who already have the least room for a "no." Optimal fraud tolerance is most comfortable spending the customers who can least afford to be spent.
I am not arguing for zero fraud, and I am not arguing against the math. The math is right. I am arguing that "profitability is the North Star" is a complete sentence only if you are standing behind the counter. Stand in front of it and the same system has a second, unmeasured output: a steady stream of real people, disproportionately the already-marginal, told no by a machine that will never explain itself. A serious payments org would instrument that the way Wayfair instruments BIN-level routing. None of them do, because there is no line for it in the P&L.
The merchant sees a decline rate. I keep looking for the people inside it, the ones who tried to pay and got read as a threat.
The tooling is getting better, and that genuinely helps: AI-driven authorization boosting and adaptive risk models mean fewer dumb declines, fewer good customers turned away for no reason. But better optimization of a one-sided objective just makes the one-sided objective more efficient. And the frontier everyone is pointing at, agentic commerce, sharpens the whole problem to a point. When an agent is paying on your behalf and the issuer cannot tell whether it is you, an agent acting for you, or an agent running while you sleep, the safe institutional reflex is to decline what it cannot authenticate. At agent scale, "decline the ambiguous" stops being a missed sweater and becomes the rent your agent was trusted to pay, the prescription it was sent to refill, the bill it was meant to settle. The payments org that wins the next decade will not be the one with the highest approval rate. It will be the one that finally puts the wrongly declined customer on the scale, gives them a reason and a way back, and treats a false decline as the failure it is for the person on the other side of it. That is a product someone has to choose to build, and right now it is no one's KPI.
Threads worth pulling: notes synthesized from payments-optimization material, including conference discussions with Ana Leite (Microsoft, global payments) and Curtis Crawford (Wayfair, fintech) on total cost of payments and authorization strategy, plus Stripe's Radar and Authorization Boost tooling and the emerging agentic-commerce signal problem. Claims here are paraphrased from my notes and are my own synthesis, read through the consumer-credit back end I work in.