Somewhere between the moment a customer presses «pay» and the moment you see the money, several models look at the transaction and decide what happens next. None of them is your provider’s account manager, and none of them will explain the decision afterwards.
AI decides your payment now in a very literal sense, and that is not a forecast. Through 2026 the card schemes have moved scoring, monitoring and even merchant onboarding onto automated systems, and the thresholds behind them have tightened. Which risk band a business sits in is described in our piece on what makes a business high-risk; this is about who now makes the call.
Three places where a model looks at you
The issuer scores the individual payment in milliseconds and approves, declines or asks for confirmation. The card scheme watches your fraud and dispute ratios and enrols you in a monitoring programme when a line is crossed. The acquirer scans your site and your behaviour, before the first transaction and continuously afterwards.
Three different owners, three different objectives, and all three now automated to the point where a human usually enters after the decision rather than before it.
The issuer: your payment as a set of signals
What the model sees is not your business. It sees an amount, a merchant category, a country pair, a device, the age of the card relationship, the hour, and how similar transactions from your descriptor behaved over the past months. Your reputation as a merchant is one input among many, and it is built from events you may never have seen.
The consequences are practical rather than philosophical. Incomplete data — missing address, no email, no phone — makes a borderline transaction easier to decline. A descriptor nobody recognises produces disputes, and disputes make future declines more likely. How the acceptance side handles all of this is described under payment processing.
The scheme: monitoring that runs on its own
The programmes are where automation is most visible, because they publish their thresholds. As of September 2026, Visa’s acquirer monitoring counts reported fraud and disputes together, divided by settled card-not-present transactions, and the merchant «excessive» line moved to 1,5% on 1 April 2026 — down from 2,2%. Enrolment carries a fee per event, with a grace period on a first violation.
Mastercard’s scam merchant monitoring took effect on 24 July 2026: a flagged merchant must be investigated by the acquirer within 72 hours, and a confirmed case means processing stops immediately rather than a fine. Triggers include a collapse in approval rate and fraud reports from multiple issuers.
Check the current numbers with your own acquirer before acting on them — scheme rules change, and acquirers apply stricter internal limits. What the Visa programme means in practice is unpacked in our piece on the VAMP guidelines for high-risk merchants.
The acquirer: your website is read by a machine
This is the part most merchants have not noticed. Since January 2026, acquirers are required to scan a new merchant’s website before the first transaction and to monitor content continuously afterwards. The scan looks for prohibited content, mismatched claims and anything that reads as a scam pattern — and the scope now explicitly includes AI-generated imagery.
In other words, the first thing that reviews your application is a crawler. Prices that are visible, terms that exist, a legal name that matches the register and a description a stranger can follow are no longer polish — they are what the machine is looking for.
What the models see, and what you control
- The descriptor — the single largest source of «I do not recognise this».
- Data completeness in the authorisation request.
- The flag on recurring charges, which separates an agreed subscription from a surprise.
- Refund speed, which decides whether an event becomes a dispute.
- Your site, which is read before anyone speaks to you.
- Volume shape: announced growth is planning, unannounced growth is an anomaly.
When the model is wrong about you
Automated scoring produces false positives, and they are invisible in a single number: good customers declined look exactly like fraud prevented. Read declines by reason rather than as one percentage, and watch for concentration — one issuer, one country, one card range. That pattern is a routing problem, not a proof that your traffic went bad.
What to do about repeated declines from good customers is covered in our piece on what to do when a merchant account is declined.
Routing a retry through a second channel rather than repeating it into the same wall is what cascading does, and how far it can move approval rates is described in our piece on payment cascading and orchestration.
The week your numbers move
Get the exact definition from your provider — which month each half of the ratio is counted in. Refund the borderline cases the same day. Fix the descriptor. Pause the traffic source that produced the spike. Then report your own progress weekly, with the number and what changed: a merchant who reports is treated differently from one who goes quiet, and that is still a human decision.
The costs do not pause while you work: MDR of 3%–5% depending on the business plus 0,50 EUR per transaction, settlement in EUR over SEPA at 0,20% and T+7, a rolling reserve of 10% for 180 days, a refund at 50,00 EUR and a chargeback at 100,00 EUR on top of the returned amount. The published lines sit on the pricing page.
Next: the buyer is a model too
Both major schemes are building rails for payments initiated by AI agents rather than people — tokens bound to an agent’s identity and permissions, and scoring that includes whether the agent had a mandate. For a merchant that is still preparation rather than production, and the preparation is unglamorous: machine-readable prices, honest availability, and terms an agent can parse without a human reading the small print.
In short
Three models look at you — the issuer at each payment, the scheme at your ratios, the acquirer at your site. You cannot argue with any of them, but almost everything they read is something you set: the descriptor, the data, the policies, the speed of a refund. Fix those, keep a second channel for the retries, and the merchant account stays a business decision rather than an automated one.