Backup payment processor: the afternoon a quarter that prevents the bad fortnight

I have been telling people for 2 years that a backup payment processor means having a second one under contract. I had assumed the contract was the hard part, and it is not. The reason is written down in the card networks' own monitoring rules, which I had never read properly until this week, and which describe a machine that punishes exactly the businesses that fail over slowly. Do not sign a second provider before you have read the 3 thresholds below, because the thresholds are what decide whether the second provider helps you or costs you.

This is the corrected version. The advice underneath has not changed much, but the argument for it has, and the argument is now built from published thresholds rather than from my opinion, which is a considerably better place to be arguing from and I should have started there.

The thing I did not know about the ratio

Every merchant sits inside 2 dispute monitoring programmes, 1 at Visa and 1 at Mastercard, and both work on a monthly ratio of disputes to payments. That part I knew and had written about twice. What I did not know is that the 2 networks divide by different months.

Stripe's documentation states it plainly: "Visa calculates the ratio of disputes or fraud to the total number of payments in the same calendar month. Mastercard calculates the ratio of disputes or fraud to the total number of payments in the previous month." And then the sentence that took me a while to absorb: "Both networks assign a dispute or fraud report to the month in which they received it, regardless of when the original payment occurred."

I read that as an engineer for a week before I read it as a merchant, and only the second reading is useful. Your disputes arrive weeks or months after the sale that caused them. Under Mastercard's method they are divided by the sales of the month before the one they arrived in. So the denominator is a number you set in the past and the numerator is a number that lands whenever the cardholder gets round to it.

Now put an outage in the middle of that, which is what I should have done two years ago and did not. A month where you could not take money for 3 hours has a smaller denominator, and the disputes from the good month before it are still on their way. Lose 4 per cent of a month's transactions and every ratio computed against that month rises by about 4 per cent of itself, before a single extra customer complains.

The numbers that decide whether anybody minds

Visa replaced its old dispute and fraud programmes with a single combined one, and I had been quoting the retired numbers until this week. The thresholds are published and they are count-and-ratio, not one or the other.

Non-compliant sits at a ratio of 0.5 per cent with a count of 5. Excessive sits at 1.5 per cent in the United States, Canada, Europe and Asia Pacific, with a count of 1,500 a month, and at 2.2 per cent with a count of 150 in the CEMEA region, which means the same behaviour puts a business into 2 different categories depending on which side of a regional boundary its acquirer sits on, and I do not think most merchants know that boundary exists. Fees are assessed above Excessive and may be assessed above Non-compliant.

The count gate is doing more work than the ratio, and I had not noticed it at all. A shop with 400 transactions a month cannot reach 1,500 disputes, so in practice it lives near the 0.5 per cent line and the count of 5, and 5 is not a large number of unhappy customers. At 400 transactions, 0.5 per cent is 2 disputes. The count gate of 5 is the only thing standing between that shop and a monitoring letter, and it is 3 disputes wide. I keep thinking about that number more than is reasonable, because 3 unhappy customers in a month is a Tuesday for most small shops and here it is the whole margin of safety.

Mastercard runs a separate programme with 2 levels, and it removes you only "when your chargebacks drop below the program threshold for 3 consecutive months". 3 months is a quarter. That is the sentence that made me rewrite this piece, because it means a single bad month is not a bad month. It is a bad quarter with paperwork.

Mastercard also "counts a chargeback regardless of whether it was hidden due to a refund, regardless of liability shift, and regardless of its outcome". Refunding an angry customer does not remove the chargeback from the count if the chargeback already exists, and winning the case does not either, which means every piece of goodwill you spend after the fact buys you a happier customer and exactly 0 improvement in the number that decides whether you get fined. I find that genuinely odd as an incentive to put in front of a merchant.

Monitoring thresholds as published in Stripe's dispute monitoring documentation, checked 3 August 2026. Both a count and a ratio have to be met.

Where I was wrong, specifically

I treated redundancy as a procurement question for 2 years. Sign the second provider, keep the account warm, done.

I now think it is an operations question and that the test is a stopwatch. Can somebody who is not an engineer move live traffic to the second rail, on a Friday afternoon, without deploying anything? Under 10 minutes is a backup. Over 60 is a subscription. If the answer involves a code change, a release, or a person who is at lunch, you have bought the second one and called it the first.

The reason I care about the distinction is the ratio above. Failing over in 10 minutes and failing over in 3 hours produce the same invoice from your backup provider and very different denominators. On a shop doing 1,200 orders a month, a 3 hour outage on a normal Thursday removes roughly 20 of them. That is 1.7 per cent of the month, and it moves a 0.45 per cent ratio to 0.46, which sounds like nothing until you remember the line is at 0.5.

The afternoon, and what to do in it

This is the part I would actually spend the time on, and I mean one afternoon rather than a project.

Route 1 real payment through the backup today. Not a test key, not a sandbox: 1 live order, small, refunded afterwards if you like. A rail that has never carried a real transaction has an unknown approval rate, unknown descriptor text and unknown 3-D Secure behaviour, and you will discover all 3 of those at the worst possible moment otherwise.

Write the switch as a configuration change rather than a deployment. A flag in a settings table, a value in an environment variable that a person can edit, anything at all that does not need a build. Then have somebody who did not write it do the switch once, timed, while you watch and say nothing. The silence matters more than the stopwatch, because the moment you start helping you are measuring your own knowledge rather than theirs, and the person who will be doing this at 4 in the afternoon in October is them.

Check what your monitoring actually monitors. An outage rarely returns an error. It returns a valid page with a failed payment inside it, so uptime checks stay green and conversion falls quietly. The alert you want fires when successful payments in a 5 minute window drop below a floor you set from your own worst hour, not when a server stops responding. A shop taking 1,200 orders a month averages about 1.7 an hour, so a 5 minute window is too short to be a floor and a 60 minute one is 60 minutes of silence. I would set it at 30.

Write down the descriptor on both rails, which took me longer to think of than it should have. If they differ, a customer who recognises one and not the other will dispute a charge that was perfectly correct, and under the rules above that dispute counts against you regardless of outcome.

Finally, and this is the smallest item with the largest reach, know your own ratio. Stripe publishes the manual method for accounts without its monitoring products: count payments for a calendar month, and count disputes "from the 5th of that month to the 5th of the following month", because of the reporting delay. That is 12 numbers a year, and I think most merchants have never computed a single one of them.

What the complaint record adds

The federal complaint file gives a sense of how often the customer end of this goes wrong, and it is the only public number in this article that comes from customers rather than from networks. In the twelve months to July 2026 there were 95,478 credit card complaints, of which 27,503 concerned a purchase shown on a statement. Money transfer and wallet products drew 37,516, with fraud or scam the largest single issue at 10,997 and 3,822 people unable to reach funds in a wallet.

None of those numbers is a dispute ratio and I do not want to imply otherwise. They are the volume of people who reached the point of writing to a regulator, which is several steps past the point of clicking dispute in an app, and the gap between those two populations is unmeasured as far as I can tell.

A short digression about 27,503 complaints, because it changed how I think about descriptors. Of the complaints about a purchase on a statement, some fraction are people who did not recognise a name. Nobody publishes that fraction anywhere I could find. If it were 10 per cent it would be the cheapest fix in this entire article, and if it were 1 per cent it would be a rounding error, and I have no way to tell which.

What I could not establish

I went looking for published data on how long payment outages typically last and there is none. Processors publish status pages rather than durations, the pages are rewritten as incidents close, and across the 6 providers I checked there is no archive keeping the old versions. A median outage length would change the arithmetic in the section above by a lot, and I cannot give you one.

I do not know how many of the merchants with a second contract have a backup rail that has ever carried 1 live transaction. My guess is that it is a small share of those who have a contract, on the grounds that testing it costs an afternoon and produces nothing visible, and that is a guess with nothing behind it except how every optional task competes with a shipping deadline.

Nor could I establish what proportion of chargebacks are descriptor confusion rather than genuine disputes, which is the single number that would tell you whether the twenty minute descriptor fix is the best return in payments or a distraction.

The part I have not settled

Three consecutive months below the threshold to get out. One afternoon to make the switch real. I have had both of those numbers in front of me for a week now.

Those 2 numbers sit oddly next to each other and I keep turning them over, because the second is so much smaller than the first that it should not be a decision anybody agonises over. It still is one, and that is the part I find genuinely annoying. I have watched an afternoon like that get postponed four quarters in a row, and I no longer think the reason is cost, or laziness, or even priorities. I think it is that nothing happens when you do it, and nothing happening is very hard to put on a list next to something that ships.