Visa subscription management mandate has been in force since 18 April 2026 across 13 European markets, and the question for product teams has moved from whether to build subscription management to how to build it correctly. The full mandate overview covers all three of Visa's 2026/2027 requirements; this article focuses only on and what it takes at the implementation level.
The rule asks issuers to do three things: identify and label three recurring transaction types, enable merchant-level stop instructions with the correct decline responses, and inform cardholders that cancelling a card charge does not end their contract with the merchant. None of these are unreasonable. Each one, though, depends on the quality of the transaction data sitting underneath the interface.
Starting with transaction types
Visa distinguishes three transaction types, and the logic for stops and decline responses differs across them. Recurring transactions are a fixed amount at a regular interval, like a monthly streaming subscription. Instalments are a fixed amount across a known number of payments, like a device paid off over twelve months. Unscheduled credential-on-file transactions are variable in amount and merchant-initiated, like a cloud storage bill that rises as usage grows. The UI has to tell these apart, because a cardholder placing a stop on one expects different behaviour from a stop on another.
The rule applies in Belgium, Croatia, the Czech Republic, France, Hungary, Italy, Luxembourg, Poland, the Republic of Ireland, Romania, Slovakia, Slovenia, and the UK.
The implementation detail that trips up most teams is that classification has to happen at the transaction level, not the merchant level. Apple is the standard example: it processes one-time App Store purchases and recurring iCloud subscriptions through the same merchant identity. Label at the merchant level and the two collapse into one bucket. Transaction-level classification keeps them separate, which is the only way a stop instruction lands on the right charge. Getting this right depends on a detection engine trained on real behavioural patterns across all three types rather than on merchant names alone. This is where detection signals do the work in practice, and where accurate subscription labelling separates a compliant feature from one that misfires.
Making stop instructions work
Stop instructions are the most operationally specific part of the rule, and the part most exposed to weak data. A stop placed against a merchant has to resolve to a stable merchant identity, not to the raw acquirer descriptor that arrives in the transaction feed. Those descriptors are frequently:
- gateway strings
- internal codes
- acquirer-formatted names
Visa's own Subscription Manager guidance is blunt on the point: a stop is only as effective as the accuracy of the details behind it, and incomplete instructions are simply rejected.
Clean merchant resolution is the layer that makes a stop reliable. The bank has to know that SPOTIFY*P5F2A4 and Spotify AB are the same entity before a stop against "Spotify" can apply consistently across every variant of that descriptor. Without that resolution, a stop catches some charges and misses others, which is worse than no feature at all because the cardholder believes they are protected. The mandate also requires the correct decline response when a stop causes a refusal, so the matching logic has to run accurately on every authorisation, not most of them. This is the same merchant-identity problem that underpins recurring payments in digital banking generally, and it is what Recurring Payments Intelligence is built to resolve.
The cardholder information requirement
Visa requires issuers to tell cardholders, at the point of placing a stop, that blocking the card charge leaves their contract with the merchant in place. A blocked payment is not a cancelled gym membership or insurance policy, and the cardholder who assumes otherwise comes back to a dispute or a support call later. Surfacing this accurately means the bank needs enough merchant context to know when a contractual relationship actually exists, so the message appears where it applies and not as boilerplate on every screen.
That context comes from the same merchant identity data that powers the stop instructions themselves. This requirement is often read as a UI disclaimer, but it is really a data-quality question. Knowing which merchants represent ongoing contracts, and which descriptors map to which merchants, is what lets the disclaimer fire correctly rather than warning cardholders indiscriminately or, worse, staying silent when it matters.
What a complete implementation enables
Banks that build on accurate enrichment meet the mandate and end up holding the data foundation for subscription features that drive retention. Revolut is the clearest example of what that looks like in practice. Its Subscriptions feature already does what asks:
- Detects recurring charges automatically - no manual setup by the cardholder.
- Surfaces every subscription, standing order and transfer in one view, with start date, next billing date and frequency shown upfront.
- Lets users block future card charges per merchant.
- Tells them plainly that blocking does not cancel the subscription with the provider - the cardholder-information requirement, shipped as product.
What makes the feature work is the data beneath it. Revolut treats enrichment as infrastructure: an internal research found that 40% of transaction-related complaints came down to customers not recognising a payment, and that a clean merchant name, correct logo and category was enough to move the number. The same clean merchant identity that resolves those complaints is what lets a stop instruction land on the right charge and a subscription detector group the right transactions.
Traditional banks have the same opportunity once the enrichment layer is in place, and the business case for going further than compliance is set out in full in how subscription management drives customer value. Compliance sets the baseline, but the same infrastructure takes you further: transaction-level classification, clean merchant resolution and sufficient merchant context are what make the three mandate requirements work together, and they are also what powers the kind of subscription experience Revolut has built. Build the data layer once and it serves both. That is the practical scope of Visa and Mastercard mandate compliance, and the foundation that Recurring Payments Intelligence provides for everything built on top of it.
