Merchant blocking on a business card means two different things, and companies in Lithuania often mix them up. The first is a control you set: the card declines payments at certain types of merchants, such as gambling sites or fuel stations. The second is a block the bank or payment institution applies to your card when it suspects fraud or needs information from you. This guide covers both: how to configure merchant restrictions on a company card programme, what the issuer is allowed to block, and why “the merchant was in the wrong category” rarely wins a dispute.

Demivoltdemivolt.comManage Business Payments With More ControlDemivolt offers business cards, dedicated IBAN accounts and payment tools for companies managing expenses and cross-border operations.Explore Demivolt

TL;DR

Merchant blocking is usually done by Merchant Category Code (MCC): you block or allow whole categories of merchants rather than single shops.
Category rules are more durable than blocking individual merchant IDs, because a merchant can change its ID but its industry category tends to stay the same.
Separately, a payment service provider must and may block cards on its own: for suspected unauthorized use, and under anti-money laundering rules when a client does not supply requested information.
A card block does not reverse a payment you authorized. Disputes turn on whether the cardholder authorized the transaction, not on how the merchant labeled its business.
Layer your controls: a program-level baseline, then narrow exceptions per team, card or user.

Two kinds of card blocking, and who controls each
How MCC-based merchant blocking works
Designing a layered rule set
What the bank or provider may block on its own
Limited network instruments: when blocking is a legal requirement
Blocking is not a chargeback strategy
Perspective: what we see in practice
Setting up merchant controls: a checklist
Business cards and accounts at Demivolt
FAQ
Sources

Two kinds of card blocking, and who controls each

When a finance lead searches for merchant blocking, the intent is usually one of three situations:

You want to restrict where employees can spend. This is a control you configure on your cards.
Your cards were blocked and you want to know why. This is a decision by the issuer, governed by law and your contract.
A payment went through at a merchant you did not expect and you want it reversed. This is a dispute process with its own rules.

The table below separates them.

Situation	Who acts	Basis	What you can do
Block categories of merchants	You, through the card platform	Your internal policy	Set MCC rules at program, product or user level
Card blocked by the provider	Issuer or payment institution	Payment Services Act, AML law, contract	Respond to information requests, contact the provider
Disputed payment	You and the issuer, through the card scheme	Scheme rules, payment services contract	Show the transaction was not authorized

The rest of this article takes each in turn.

How MCC-based merchant blocking works

Every card acceptor is assigned a four-digit Merchant Category Code that describes its line of business. When an employee taps a card, the authorization request carries that code. Your issuer’s system checks it against the rules attached to the card. If the code is on a block list, or is missing from an allow list, the payment is declined before any money moves.

Card infrastructure providers describe this in similar terms. Worldline’s issuing documentation explains that authorization restrictions are blocking conditions that decline transactions on an account, with defaults defined at the product level when an account is created. Marqeta’s guide for Europe says controls can be configured by card product, user and transaction. Visa’s commercial controls documentation lists rule codes that can be set in its Controls Management Service.

Block lists and allow lists

There are two ways to build a rule:

Block list. Everything works except the categories you name. Suitable for general-purpose employee cards where you want to exclude a few risky categories, such as gambling.
Allow list. Nothing works except the categories you name. Suitable for single-purpose cards: a card that only pays for software subscriptions, or one used only for travel.

An allow list is stricter and safer for narrow use. A block list is easier to maintain for broad use. Most companies end up with both, applied to different cards.

Why categories beat individual merchants

It is tempting to block a specific shop or website. In practice this is fragile. Practitioner guidance on commercial payment controls points out that blocking by category is generally more robust than blocking by individual merchant identifier, since a merchant may change its identifier while its industry category stays consistent. Block individual merchants only when you have a specific, known reason, for example a subscription you cancelled and do not want to see again.

Designing a layered rule set

The strongest card programs do not rely on one rule. Fintech infrastructure guidance favors a baseline at program level, then narrow overrides only where a team has a legitimate operational need. A practical structure looks like this:

Program baseline. Block categories nobody in the company should pay: gambling, adult services, cash-like transactions if you do not need them.
Card product rules. Different card types for different jobs: a travel card, a marketing card, a software card.
User or department exceptions. The marketing team may need advertising platforms and event vendors. The sales team may need airlines and hotels. Grant only those.
Amount and frequency limits. Combine category rules with per-transaction and monthly limits, so a permitted category cannot be abused.
Review cycle. Check declined transactions monthly. A pattern of declines at a legitimate supplier means a rule is too tight. A pattern of declines at suspicious merchants confirms it is working.

A worked example

Take an online retailer with 12 staff. It issues three card types:

Ads card for the marketing manager: allow list covering advertising and marketing services, plus a monthly limit.
Software card held by the finance lead: allow list covering software and cloud services, used only for subscriptions.
Travel cards for two sales staff: allow airlines, hotels, car rental and restaurants, block everything else.

If an employee mistypes a card number into a fake storefront, the transaction fails because that merchant’s category is not on any allow list. The control did its job without anyone reviewing it manually. For travel-specific settings, see our guide to travel card controls finance teams must set, aligned with EU SCA.

What the bank or provider may block on its own

The second kind of blocking is not a setting. It is a decision by the provider. The Bank of Lithuania explains that a payment service provider may restrict a client’s right to use a payment account or payment instruments in the manner and under the conditions set by law, such as the Payment Services Act and the Law on the Prevention of Money Laundering and Terrorist Financing, and by the client’s contract. Its guidance on when a provider may restrict an account or payment instruments is the page to read first if your cards were blocked.

In practice, the common triggers fall into two groups.

Suspected fraud or unauthorized use

The Payment Services Act framework allows, and in cases of reasonable suspicion expects, a provider to block a payment instrument when there are grounds to suspect unauthorized access or fraudulent use. The Bank of Lithuania’s anti-money laundering FAQ includes the question of whether a provider must block an instrument if it suspects fraud. Providers also act on scheme alerts. A well-known Lithuanian example: in October 2009, Visa and MasterCard contacted Lithuanian banks, which then blocked large numbers of cards as a precaution, as reported in the press at the time.

Missing information about your business

Providers must apply a risk-based approach to client due diligence. If a company does not answer reasonable questions about its activity, the legitimacy of transactions or the source of funds, the provider can limit or end the service. The Bank of Lithuania’s guidance above describes this as a right provided by law and contract.

This matters for cross-border businesses. A sudden wave of payments from a new country or a new type of counterparty can raise questions. The fix is simple: keep documents ready (contracts, invoices, ownership information), answer requests quickly, and tell your account manager before unusual activity begins.

What to do if your card is blocked

Read the notification. It usually states what is needed.
Contact your provider through the official channel, not through a link in an unsolicited message.
Prepare documents that explain the transaction or activity in question.
Check whether other users on the account are affected. A block on one card is different from a restriction on the account.
Review your contract’s terms on blocking and notification, and consult a lawyer if you believe the block is unjustified.

Limited network instruments: when blocking is a legal requirement

There is a narrower case where merchant restriction is not a convenience but a condition of regulatory status. PSD2 excludes from its scope services based on instruments usable only in a limited network of acceptors or for a limited range of goods and services. This is Article 3(k) of the directive, available on EUR-Lex. The EBA’s final report on the limited network exclusion guidelines explains how that exclusion should be interpreted.

This applies to issuers of closed-loop gift, fuel or store cards, not to ordinary business cards. But if you are a platform designing a card or voucher product, the lesson is that technical restrictions on where an instrument works can decide whether it is regulated as a general payment instrument. A contract clause alone may not be enough. Take legal advice before launching such a product, and read our note on BIN sponsorship, Mastercard rules and EBA risks for EU founders.

Blocking is not a chargeback strategy

A frequent mistake is to treat merchant category as grounds for reversing a payment. The reasoning goes: this merchant is coded as one thing but sells another, so the payment should be refunded. Disputes do not work that way.

The Bank of Lithuania publishes decisions in consumer disputes with payment providers. In one such case involving a Mastercard payment, the central question was whether the payment had been authorized by the cardholder, not how the merchant described itself. The practical reading for businesses:

If an employee entered the card details or approved the payment, the transaction is treated as authorized.
A category label that you consider misleading is rarely enough on its own to win a reversal.
A merchant block must be in place before the payment. It cannot be applied afterwards to undo one.

That is the strongest argument for setting rules in advance. A decline costs nothing. A dispute costs time and may not succeed. Note that this dispute decision concerns an individual case and is not a rule that applies to every scenario. If you have a specific disputed payment, contact your provider promptly and seek legal advice if the amount is significant.

Perspective: what we see in practice

We see the same pattern with growing companies. They start with one shared card and no rules, then add staff, subscriptions and advertising accounts. Within a year nobody can say who pays for what. Merchant controls are rarely the first thing a company sets up, but they are among the cheapest to put in place and the hardest to retrofit after an incident.

Our view is that merchant blocking works best as part of an account structure, not as a standalone setting. A dedicated IBAN account per entity or project, role-based access for each user, and cards issued for specific purposes make rules easy to define, because each card has a job. When a card has a clear purpose, the category rules follow naturally.

We also encourage clients to treat provider-side blocks as a compliance conversation, not an obstacle. As a regulated platform, we have to apply risk-based checks, and clients who keep their documentation current and communicate about unusual activity have fewer interruptions. Segregated client funds and transparent onboarding are there so that a block, when it occurs, is explainable and resolvable.

— dd

Setting up merchant controls: a checklist

Use this list when you launch or review a card programme.

Map spending. List the categories your business pays every month: software, advertising, logistics, travel, utilities.
Define card purposes. One purpose per card where possible.
Choose block or allow. Allow lists for narrow cards, block lists for general ones.
Set the baseline. Apply program-level blocks first.
Add exceptions deliberately. Document who asked, who approved and why.
Add limits. Per-transaction and monthly amounts alongside category rules.
Set up alerts. Make sure someone sees declines and unusual attempts.
Review monthly. Adjust rules based on real declines.
Keep records ready. Contracts and invoices for your main suppliers speed up any provider inquiry.

If your team integrates cards and payments into its own systems, build your reconciliation on events rather than polling. Our article on payment webhooks for Lithuanian developers covers this. For broader context on how card networks are adding fraud checks, see our news item on Mastercard’s fraud detection layer for Agent Pay and on American Express’s AI-powered spend controls.

Business cards and accounts at Demivolt

Demivolt is a regulated European platform that offers dedicated IBAN accounts, SEPA and SWIFT payments, virtual and physical Visa business cards, multi-account structures and role-based user management. Account opening, account verification, a dedicated client manager and monthly maintenance are all listed at 0 on our site. SEPA Out costs 0.40 €, and SEPA In is 0 €.

If you want to build a controlled card setup for your team, start with business accounts and then look at our card programmes. For the payment side, see payments. To discuss the specific controls you need, contact us through demivolt.com.

FAQ

Can I block a specific merchant on a company card?

Often yes, but it depends on the card platform. Blocking by category is usually more reliable, because a merchant can change its identifier while its category remains the same. Use merchant-level blocks for specific, known cases only.

Why did my provider block my business card?

The usual reasons are suspected fraud or unauthorized use, scheme alerts, or missing information requested under anti-money laundering rules. The Bank of Lithuania says providers may restrict instruments under the law and the client contract. Contact your provider through its official channel and ask what documents are needed.

Can I get a refund if a merchant used the wrong category code?

Not on that ground alone. Disputes focus on whether the cardholder authorized the transaction. If an employee took part in the payment, a questionable category label is rarely sufficient for a reversal, so set controls before spending happens.

Do merchant blocks apply to online and in-store payments alike?

Category rules are checked at authorization, so they generally apply to any card payment that carries a merchant category code. Settings can differ by platform and by card type, so check how your issuer applies them to online, in-store and recurring payments.

Sources

Business accounts

Business accounts, dedicated IBANs, payments, cards and currency for companies working directly with Demivolt.

Learn more

Merchant Blocking on Business Cards: MCC Rules and Bank Blocks