Meal vouchers in Europe Can a meal voucher card be open loop?
Can a meal voucher card be open loop?
In several European markets yes, and new entrants already do it. In others no, because the law ties the benefit to merchants holding a contract with the issuer, and a merchant category code cannot tell a contracted merchant from any other. The deciding question is not technical and not commercial. It is whether the national scheme requires an affiliated merchant network, and it has a different answer in Germany than in Italy.
Why the question exists at all
Meal vouchers are cheaper for merchants to refuse than to accept in some markets, and more expensive to accept than any ordinary card in most. That is not an accident of pricing. It follows from where the instrument sits in European law.
The interchange fee regulation carves out a specific exemption. It covers instruments valid in a single member state, provided at the request of an employer or a public body, regulated by a national or regional authority for a social or tax purpose, and usable to buy specific goods or services from suppliers having a commercial agreement with the issuer.
That final clause is the whole story. The affiliated merchant network is not a legacy of the paper era that nobody got round to removing. It is the condition that keeps the instrument outside interchange caps, and therefore the condition that lets an issuer charge a merchant a percentage rather than earn regulated interchange.
The commercial consequence people miss. Moving a scheme from an affiliated network to pure open loop does not save the issuer money. It removes the issuer's ability to charge merchants at all, replacing a percentage fee with regulated interchange. Anyone proposing open loop as a cost saving for the issuer has the direction of the argument backwards.
The three models
| Model | How acceptance is controlled | Who the merchant pays |
|---|---|---|
| Private network, three party | Direct contract with the issuer, settled outside the card networks | The issuer, as a percentage of voucher value |
| Open network, four party | Issuing ranges restricted to selected merchant categories | Its acquirer, on ordinary card terms |
| Mixed | Runs on a card network, but only at merchants that also hold an agreement with the issuer | Both: ordinary card costs plus a separate issuer fee |
The mixed model is the one most people mean when they say open loop, and it is the one that satisfies the exemption while still using card rails. It is also the model that best fits an operator who already has a merchant network and does not want to give up the revenue attached to it.
Which markets allow which
| Market | Open loop by category alone | Why |
|---|---|---|
| Germany | Yes | No register, no merchant accreditation. Restriction by merchant category is the accepted model |
| Spain | Yes | No register, no merchant accreditation. Constraints are tax conditions |
| Portugal | Yes, and increasingly the norm | Bank issued cards restricted by category already operate, and issuers have been shifting toward this model |
| France | Effectively yes | Merchants are accredited centrally by the CNTR and the network is shared, so new entrants issue on international card networks |
| Belgium | Not straightforwardly | Issuers contract merchants directly, so acceptance is tied to an agreement rather than a category |
| Italy | No | Decree 122/2017 requires a contract between the issuing company and each affiliated merchant |
The split is not north against south, and it is not old against new. It follows whether the country built its scheme around a register and a merchant network, or around a tax condition.
What this means technically
Two fields arrive with every authorisation request, and the answer above decides which one your rules depend on.
If the market allows category based restriction, the rule is a list of merchant category codes, and the issuing platform can enforce it without help. This is simple and it scales.
If the market requires an affiliated network, the rule is a list of specific merchants, checked against the merchant identifier on each request. The complication is not the check itself. It is that the authoritative list lives with the operator who signed those merchants, and copying it into a card platform means keeping two copies in step forever.
The arrangement that resolves it
Shared authorisation. The issuing platform receives the authorisation, passes it to the operator's own system with the merchant category code and the merchant identifier attached, and the operator answers approve or decline against its own list. Funds stay held on the platform side, so the operator gets merchant level control without taking on a ledger.
That is what lets one programme serve both kinds of market. In Germany or Spain the operator can answer on category alone. In Italy the same interface answers against the contracted merchant list. The card, the scheme and the platform do not change.
The interface is documented in the shared authorisation documentation.
What goes wrong when this is decided late
Three failures, in rough order of cost.
Designing acceptance before answering the question. A programme built on merchant categories that later has to satisfy an affiliated network requirement is not adjusted, it is rebuilt, because the authorisation path changes rather than the configuration.
Assuming one market's answer applies to the next. An operator expanding from Germany into Italy meets a different rule with the same product name, and the German design does not carry over.
Treating the merchant list as reference data. If the list is not in the authorisation path, nothing fails visibly. Transactions are approved that should not have been, and it surfaces in an audit rather than in a decline.
Next: how to launch a meal voucher card programme, or the mechanics of a meal voucher card.
Settled on open loop? Configure a programme against your own acceptance rules.
Order Now