What MiCA Means for a Business Accepting Stablecoin Payments

For a business that accepts stablecoin payments, MiCA mostly changes three practical things: which stablecoins are comfortable to take from EU customers, which providers handle the funds, and what paperwork those providers carry. A merchant receiving payments in its own wallet is in a different position from one whose provider holds the balance. This post covers those branch points. The legal detail sits with the regulator and with xregos.com.

What is MiCA, in terms of a payments business?

MiCA is the European Union's Markets in Crypto-Assets Regulation. It sets rules for issuers of certain crypto-assets and for firms that provide services around them, such as custody, exchange and transfer. Stablecoins are one of its main targets.

For a merchant, the regulation does not read like a checkout manual. Most of its obligations fall on two groups: the entities that issue stablecoins, and the firms that provide crypto-asset services. A merchant that sells software, courses, design work or subscriptions and gets paid in a stablecoin is neither of those by default. That does not make MiCA irrelevant. It shapes the supply side the merchant buys from: the token, the venue where it is traded, and the payment provider in between.

This post stays at that practical level. It does not walk through classifications or article-by-article obligations. For that depth, xregos.com covers the regulation itself, and the primary text is linked at the end of this post.

Which stablecoin you accept is now a business decision

Before MiCA, "which stablecoin" was mostly a question of what customers already held and which chain they preferred. Now there is a second layer: how the token is treated by EU-regulated venues, banks and service providers. That treatment can affect how easily a customer can buy the token, and how easily a merchant can later convert it.

The practical consequence is that token choice has become a small piece of risk management. A merchant with mostly EU customers may care about euro-denominated options. A merchant with a global customer base may care more about which token customers can acquire cheaply on their chain of choice.

Here is what inzi supports, per chain. These pairings are the product's actual coverage, so a token is only listed where it runs.

Two details matter for anyone thinking about MiCA exposure:

• EURC is available on Base and Ethereum only. A merchant that wants to price and receive in euro-denominated stablecoins is choosing from those two chains.
• USDT runs on Polygon, Ethereum, Tron and TON. USDC runs on Polygon, Base, Ethereum and Solana. Neither token is available on every chain, so "accept USDT everywhere" or "accept USDC everywhere" is not an option.

Whether a specific token is easy to buy or sell on EU-licensed venues can change as those venues update their listings. Venue announcements are the primary source for that, not a payment provider's blog. A merchant tracking this usually follows the venues its customers use, plus the supervisor pages listed at the end.

Who holds the funds? The custodial and non-custodial split

This is the branch point where MiCA bites hardest for payment infrastructure. Providers fall into two broad models.

This is a description of how the money flows, not a legal opinion on any specific provider. A provider's regulatory status depends on its exact activities and its jurisdiction, and the provider's own documentation is the place to read that.

inzi is non-custodial. The payment goes from the customer to the merchant's wallet, never through an account inzi controls. inzi has no merchant balance to hold. For a deeper explanation of the model, see the non-custodial crypto payment processor guide.

One consequence follows directly from the structure. In a custodial setup, the merchant relies on the provider's authorisations, safeguarding and solvency. In a non-custodial setup, that dependency is smaller, because the funds are not in the provider's hands at any point. The merchant's exposure moves to other places: the token, the chain, and the merchant's own wallet.

What does non-custodial change, and what does it not?

It helps to be exact here, because "non-custodial" is sometimes heard as "outside regulation". It is not a claim of that kind.

What it changes:

• The provider is not holding the merchant's funds between the customer's payment and the merchant's receipt.
• The merchant does not need to ask whether a provider's safeguarding arrangements are adequate, since there is nothing to safeguard on the provider's side.
• Settlement is the on-chain transfer itself. The merchant sees the payment arrive in its own wallet.

What it does not change:

• The merchant is still a business receiving stablecoin revenue, with the usual accounting, tax and reporting questions in its own jurisdiction.
• The token the customer pays with is still subject to whatever rules apply to its issuer and to the venues where it trades.
• The merchant is still responsible for wallet security. Non-custodial means the merchant manages keys, access and recovery. A lost key or a compromised signer is a merchant problem, and no support desk can reverse it. That is a real cost of the model, and one reason some finance teams pick a custodial route despite the other tradeoffs.

A custodial provider can sometimes absorb part of that operational burden. A non-custodial one cannot, by design. Teams comparing the two usually weigh regulatory dependency against operational responsibility, and neither side wins in every case.

What does MiCA change for payouts, payroll and other outgoing flows?

Acceptance is only half of a stablecoin operation. Many digital businesses also pay contractors, affiliates or creators in stablecoins, and the same custody questions apply to that side: who holds the funds while a payout is being prepared, and who moves them.

The practical questions are the same ones as on the receiving side. Where do the funds sit before they are sent? Which token is going to the recipient? Does the recipient have a wallet on the right chain? A recipient who only holds a wallet on Tron can receive USDT, and cannot receive USDC through the same route, so chain and token have to be matched to what the recipient can actually use.

For how outgoing flows are structured, see mass payouts in stablecoins and the crypto payroll guide. Batch payouts at inzi are a guided pilot available on request, not a self-serve feature, so a team planning large recurring payouts would start by talking to inzi about the pilot.

What stays the same for bookkeeping and tax?

MiCA is not a tax regulation. It does not decide how a stablecoin payment is recorded, when it counts as revenue or how VAT applies. Those questions follow national tax law and the rules of each country where a business operates.

What does stay constant is the underlying paper trail. Many accountants log the fiat-equivalent value of each payment, the timestamp of the on-chain transfer, the transaction hash, and the wallet it landed in. In a non-custodial flow, that data sits on a public ledger and in the merchant's own wallet history, which is helpful for audits. The crypto accounting guide for stablecoin payments goes into the bookkeeping mechanics.

Which questions help compare providers under MiCA?

A payments team evaluating gateways in a MiCA environment often comes down to a short list of factual questions. These are things to ask the provider, and the answers are in its documentation or its regulator's register.

1. Does the provider ever hold the merchant's funds? If yes, for how long and under which authorisation?
2. Which stablecoins and which chains are supported? Check the per-chain pairing, not a general "we support USDC".
3. What does the provider say about its own regulatory status, and is it verifiable in a public register?
4. What happens to the merchant's access to funds if the provider has an outage or a problem? In a non-custodial flow the funds are already in the merchant's wallet.
5. What is the cost structure? inzi works on subscription plans, and no percentage is deducted from payments. Gas and provider fees are separate. Current plans and limits are on the pricing page.

The fifth question is the one that tends to be asked last and matters for the spreadsheet. Regulation shapes the cost of custodial providers, but the fee line a merchant sees is a pricing decision, and it is worth reading the plan details directly.

What is the practical summary?

MiCA changes the environment around stablecoin payments more than it changes the act of accepting one. The token, the venue and the provider each carry their own regulatory position, and a merchant's exposure depends on how many of them touch the money.

• Token choice is now partly a regulatory question as well as a customer-convenience one. EURC on Base and Ethereum is the euro-denominated option on inzi.
• A non-custodial flow removes the provider from the custody chain, and moves the security responsibility to the merchant's own wallet.
• Accounting and tax obligations are unchanged by MiCA itself and follow national rules.

For a merchant ready to test a non-custodial flow, creating an inzi account is the starting point. For the regulation itself, the sources below are the place to read it directly. xregos.com covers classification and timelines in the detail this post leaves out.