A failed payment isn't necessarily a free payment. Authorization attempts can trigger processor, gateway, fraud-tool, and card-network costs even when the transaction never settles. October 2026 card-network updates make the issue especially visible: Fiserv's merchant update says Mastercard's existing Decline Service Fees increase in October, while PayPal Braintree notes that Mastercard's revised SCA exemption indicator fee in Europe and the UK applies to both approved and declined transactions. The exact fees vary by processor, network, geography, contract, and transaction type, so the point isn't that every decline is expensive in the same way. The point is that merchants should measure the total cost of attempted payments, understand retry behavior, track authorization and reversal fees, and evaluate failed-payment economics separately from settled processing costs.
Your Payment Processor Is Making Money on Transactions That Never Happened
Most companies know roughly what they pay when a card transaction succeeds. They can point to interchange, assessments, processor markup, gateway fees, and maybe a few other line items that show up after money changes hands.
The more interesting question is what you're paying when the money never moves.
A customer attempts a purchase. The authorization is declined. A subscription platform retries the card two days later. The second attempt fails. Another retry goes out. The gateway processes each request, the fraud platform evaluates each attempt, the processor handles the authorization traffic, and the card networks may assess fees tied to that activity. No sale settles, but the payment stack has been busy the entire time.
That's the part of payment economics that gets ignored surprisingly often.
October 2026 is a useful reminder because several card-network updates put authorization behavior and declined transactions directly in the fee conversation. Fiserv's Fall 2026 card-brand update says Mastercard's existing Decline Service Fees increase from 0.03% to 0.06% in October, with the maximum declining from $0.12 to $0.06 and the minimum fee being eliminated. PayPal Braintree also notes that Mastercard's revised SCA exemption indicator fee in Europe and the UK, effective October 12, applies to both approved and declined transactions under the applicable fee structure.
Those examples don't mean every merchant pays the same fee, or that every declined authorization automatically creates the same cost. Network, geography, merchant setup, processor contract, transaction type, routing, and other factors all matter. They do demonstrate something merchants should understand clearly: a payment doesn't need to settle before the ecosystem can start charging for activity around it.
From the customer's perspective, a failed payment is simple. They clicked the button and got a decline message.
From the payment stack's perspective, quite a lot may have happened before that message appeared.
The merchant application created the transaction. The gateway received it. A fraud tool may have evaluated it. The request moved through a processor or acquirer. The network routed it to an issuer. The issuer made a decision and returned a response. Logging, monitoring, token services, credential services, authentication, and other components may also have participated depending on how the transaction was constructed.
If the transaction is retried, some or all of that happens again.
This is why measuring payment cost only against settled transactions can create a distorted picture. The company sees the sales that survived the funnel, while a meaningful portion of the payment expense may have been created by attempts that died somewhere along the way.
A processor or gateway doesn't necessarily wait for a transaction to settle before it has performed billable work. Many commercial agreements include per-authorization, per-attempt, gateway, or other activity-based charges. Card networks also maintain fee structures and integrity programs tied to authorization behavior.
That creates an important distinction between the cost of processing revenue and the cost of attempting to collect revenue.
For a merchant with excellent authorization performance and limited retry activity, the difference may not be dramatic. For a subscription company, marketplace, digital merchant, or business with high transaction velocity, it can become significant.
Imagine a subscription portfolio with one million monthly billing attempts. If 10% fail initially and the billing system makes several recovery attempts, the company can generate hundreds of thousands of additional authorization requests without adding a single new customer. Some of those retries may recover revenue, which is exactly why intelligent retry strategies matter. Others may simply create more cost and more network traffic around a credential that wasn't going to approve anyway.
The question isn't whether you should retry. The question is whether your retry strategy understands economics as well as recovery rates.
Failed-payment recovery is one of those areas where a metric can look great while the underlying economics get worse.
A team might celebrate recovering another percentage point of subscription revenue after adding more retries. That's useful information, but it isn't enough to evaluate whether the strategy improved the business.
How many additional authorization attempts were required to recover that revenue? What did those attempts cost? Did the retries create network integrity issues? Were they timed intelligently based on decline reason, credential status, issuer behavior, or account activity? Did they increase customer complaints or create duplicate-payment confusion? Were hard declines retried when they shouldn't have been?
Mastercard itself now markets payment optimization tools that use authorization behavior, credential trends, and network activity to determine when eligible declined merchant-initiated transactions may be worth retrying. The existence of these tools reinforces a basic point: retry timing and transaction quality matter. Repeatedly sending the same bad request isn't a strategy.
A healthy recovery program should measure incremental recovered revenue against incremental payment cost, customer impact, and network compliance exposure.
Another reason failed-payment economics get messy is that companies often treat every decline as one category.
They're not.
An insufficient-funds response, an expired credential, a suspected-fraud decline, an invalid account number, a technical failure, and a transaction rejected because of incorrect authentication data are very different problems. They may justify different recovery actions, different timing, and different decisions about whether another attempt should happen at all.
If your retry engine treats every failure as "try again later," you're not doing payment optimization. You're generating more payment traffic and hoping probability eventually gets bored.
The decline reason should influence the treatment plan. Some failures are potentially recoverable with updated credentials or better timing. Some need customer action. Some need a corrected authorization request. Some should stop immediately.
Understanding that distinction improves approval performance, but it also reduces unnecessary attempts and the costs attached to them.
Declines aren't the only transactions that can create cost without producing settled revenue.
Authorization reversals, abandoned preauthorizations, and authorizations that aren't cleared correctly can also generate network costs or compliance issues. PayPal Braintree's Fall 2026 network guide, for example, notes that Visa's new Acquirer Network Access and Brand Usage fee in Canada can be billed on authorization and again on an authorization reversal under the applicable structure. The same guide also describes Mastercard pricing in Europe for preauthorizations that aren't reversed or cleared within the required framework.
Again, these are market-specific examples rather than universal merchant fees. The operational lesson is broader: authorization lifecycle management has economics.
If your application creates authorizations but doesn't reverse them correctly when orders are canceled, inventory isn't available, or a transaction is abandoned, that isn't just messy technical behavior. Depending on the payment environment, it can become expensive behavior.
Payments teams should understand what happens from the first authorization request through reversal, clearing, settlement, and reconciliation. The transaction isn't finished just because your checkout page returned a result.
Card-network fees are only one layer.
Merchants may also pay gateway fees per transaction attempt, processor authorization fees, fraud-screening fees, authentication fees, token or credential service charges, or other usage-based costs depending on their agreements and technology stack.
A single failed payment can therefore touch multiple paid services before producing zero revenue.
This is especially easy to miss when each service is reviewed independently. The gateway invoice looks reasonable. The processor statement looks reasonable. The fraud platform bill looks reasonable. The subscription platform's recovery rate looks good. Nobody adds up what all four systems cost on the same population of failed transactions.
Payments Therapist sees this pattern constantly in payments work: the problem often isn't one outrageous fee. It's a collection of individually understandable fees interacting with operational behavior nobody measured end to end.
If you want to understand failed-payment economics, start by separating attempts from completed transactions.
At a minimum, merchants should be able to answer a few basic questions. How many authorization attempts are generated for every successful transaction? What percentage of volume is first-attempt approval versus approval after retries? How many retries occur by decline category? Which retries recover revenue? What processor, gateway, fraud, authentication, and network costs are attached to unsuccessful attempts? How many reversals are created, and are they being handled correctly?
Then look at those numbers by product, payment channel, geography, processor, issuer segment, and recurring versus customer-initiated traffic where relevant.
This is where a blended "effective processing rate" can hide more than it explains. If one business unit produces much higher retry volume or failed-payment traffic, its true payment economics may be materially worse even if the settled transactions appear to carry the same processing rate.
Payment optimization often gets framed as finding a clever way to recover more declines. Sometimes that's appropriate. The better solution may be preventing avoidable declines in the first place.
Tokenization, account updater services, proper credential lifecycle management, correct transaction indicators, better authentication data, intelligent retry timing, stronger authorization messaging, and cleaner processor configuration can all affect payment performance depending on the merchant and use case.
That means the cheapest failed payment may be the authorization request you never had to send because the credential was updated before billing, the transaction was constructed correctly the first time, or the system knew not to retry a hard decline.
More payment traffic isn't the same thing as better payment performance.
The headline says your processor is making money on transactions that never happened, but the more precise diagnosis is that the entire payment stack can generate cost before a transaction becomes revenue.
Some of that cost is completely legitimate. Processors, gateways, networks, fraud providers, and authentication services are doing real work when they handle an authorization attempt, even if the issuer ultimately says no. The problem isn't that fees exist. The problem is when merchants don't know they're paying them, don't understand what behavior triggers them, or can't tell whether the resulting activity is creating enough value to justify the expense.
October's network changes are a timely reason to look at the issue, but the underlying problem isn't seasonal. If you process enough payments, failed transactions deserve their own cost model.
Your settled sales tell you what it costs to process revenue. Your declines, retries, reversals, and abandoned authorizations tell you what it costs to chase revenue that may never arrive.
Payments Therapist helps merchants, fintechs, ISVs, and payment companies understand where those costs come from, how authorization behavior affects economics, and where processor configuration or retry logic is quietly leaking money. If nobody can explain what your failed payments cost each month, it may be time for a proper diagnosis.