Case study: the payment account closed ten days after launch

Situation. A small online business selling digital goods, delivered automatically the moment a payment cleared. The card payment account was opened, ran in test mode through the autumn, and started taking real orders at the end of the year. Ten days later the provider closed it, about a month after it had been opened at all.

The reason was card testing. Someone was running stolen card numbers through the checkout to find out which ones still worked. A store that delivers instantly, for small amounts, with no human in the loop, is a convenient place to do that: the answer comes back in seconds and nobody is watching.

Nobody at the business knew that keeping that traffic clean was the merchant's responsibility. The assumption, reasonable until somebody tells you otherwise, is that card fraud belongs to the payment provider: they hold the card data, they run the checks, they take a percentage. What actually happens is that the provider measures the merchant, and when the numbers get bad enough, the provider protects itself.

What it looked like from the inside. Read afterwards, in the shop's own database, the shape of it is not subtle.

One device created 57 accounts in a week, 27 of them in a single day, and placed 135 orders. Three more devices had the same profile at a smaller scale. The accounts were registered in bursts, minutes apart, using random six-letter mailboxes on three domains that had never appeared in the shop's own data before.

For comparison: across the whole period before the wave, no device had ever been linked to more than one account in a day. In six months of real traffic afterwards, on different providers, the maximum was two. There is no overlap between ordinary behaviour and this. Telling them apart does not require a model, it requires somebody looking.

Risk. The application handled exactly one kind of event from the provider, the successful payment. Declines, disputes, fraud warnings and refunds were event types it had never subscribed to, so none of them were recorded anywhere. That gap is invisible while everything works, because the successful path is the one that gets tested.

When the account was closed, access to it closed at the same moment. Every attempt, every decline code, every fraud warning existed only on the provider's side, and there was no longer any way to reach it. A block is not the moment you begin investigating. It is the moment you lose the ability to.

The first conclusion of this case has nothing to do with fraud detection. The payment history in your provider's dashboard is not yours. You can read it freely while the relationship is healthy, which is precisely when you do not need it.

The second conclusion is more useful: the shop's own data survived, and it was enough. Orders in every status, users, devices, IP addresses and the links between them were all on the merchant's side. The identifiers that were lost, card fingerprints and the provider's own customer references, are exactly the ones that would not have transferred to a new provider anyway.

Why the provider's risk tools do not cover this. Every payment provider sells or includes a fraud and risk product. They answer a different question, and the three limits below are structural rather than a matter of quality.

It only sees what goes through it. Accounts, devices, sessions, and orders that never turned into a payment attempt are outside its field of view entirely. The clearest signal in this case, one device standing behind 57 accounts, is invisible to a system that sees payments rather than sessions.

It does not see the other provider. A business that survives this usually ends up running more than one provider, often two at once during a migration. The same buyer who gets declined at one and succeeds at the other is the most reliable signature of card testing there is, and neither provider can see it, because each sees only its own half.

It stops at the payment. For a digital product the expensive part happens after the payment: the fraud warning arrives days later, when the product has already been delivered. The provider cannot hold a delivery it knows nothing about.

There is also the question of whose risk is being managed. The provider's radar protects the provider.

Decision. A monitor on the merchant's side. Not a replacement for the provider's checks, and not a fraud model. A separate service, on the business's own server, designed to do four things.

Writing it down first. The attempt is recorded on the merchant's side at the moment the payment starts, before the provider is involved. If the provider never answers, or refuses before there is anything to confirm, the record still exists. In the old setup that case left no trace at all. Every event that does come back is stored too, including the ones nobody enjoys reading, with the provider's original message kept alongside.

Measuring per provider, never averaged. A combined figure hides a problem at one provider behind clean traffic at another, and the dashboard stays green right up until the block. Each provider gets its own baseline, its own thresholds and its own alerts.

Judging entities, not payments. Concentration is the signal: how many accounts appeared behind one device in an hour, how many unfinished orders came from one narrow range of IP addresses, how many registrations landed on one mail domain in a day. The average tells you nothing here. Ordinary customers abandon a checkout once and leave, and their noise is spread across thousands of different entities. An attack is concentrated on a handful.

Saying what to do. The output is not the word "suspicious". The alert I want reads like this: one device, eighteen minutes, eleven cards tried, nine declined, then three identical digital products bought, do not deliver these orders, freeze this account. The person receiving that message is usually not an engineer, and should not have to be.

Two constraints on the monitor itself, both about trust. It has no write access to orders, which is a database permission rather than a promise, so it cannot stop payments or fulfilment even if it fails badly. And it never sits in the payment path, so it cannot become the reason a payment fails.

How sensitive to make it. Every alarm has the same problem. Set it too sensitive and it goes off on ordinary days, and after a few false alarms people stop paying attention to it. Set it too loose and it stays quiet during a real attack.

So every rule that raises an alarm was tested against the shop's real history before it was accepted. A rule was kept only if it would have gone off during the attack and stayed silent everywhere else: in the quiet months before it, and through six months of normal trading afterwards. For example: "three or more new accounts from the same device within a day". During the attack, that rule would have gone off on the first morning. Outside the attack, it would not have gone off once.

Two other rules would have caught the attack too, but they would also have gone off on quiet days, when real customers were simply buying. They were thrown out, not adjusted until they looked good.

That first-morning alarm is the clear one, the one nobody could misread, and it would have given four days of warning before the last payment went through. That is enough time to block the device and stop delivering before the numbers the provider judges the shop by start to go bad. The data showed an earlier and weaker signal almost three weeks before that: one customer placing fifteen orders in a week. Someone would have had to look at it and decide whether it was fraud or just a keen buyer, so it does not count as warning.

These rules come from one attack. They are a starting point, and they will be adjusted as real orders are marked good or bad.

Status. The service, the data model, the provider adapters, the merchant-side telemetry and the behavioural detectors are built and covered by tests. Alerts, the interface and the deployment are not finished. The stage that holds a delivery or reverses one is designed and deliberately left until later: a system allowed to stop fulfilment has to earn that, and this one has not run in production yet.

What this case is about. Two things cost this business its payment account, and a missing fraud product was not one of them. Nobody had told it that the traffic through its own checkout was its own responsibility, and the evidence needed to see the problem was being written into somebody else's system, where it disappeared the moment the account did.