The Italian payment landscape, and where it gets thin
Italy has an unusually broad base of small and mid-sized online businesses. A lot of the country's e-commerce is not a handful of large platforms but a long tail of independent stores, regional brands, and single-vertical specialists selling food, fashion, design, craft, and digital goods — many of them aimed as much at customers abroad as at the domestic market. For a sale to an Italian customer, the existing euro rails do their job, and there is often no reason to reach for anything new.
The friction shows up the moment the customer is somewhere else. International cards decline more often than domestic ones, carry a currency conversion the customer notices, and expose the merchant to chargebacks that can land weeks after an order has shipped. For a small business with thin margins, every declined foreign card is a lost sale it never sees, and every chargeback on already-delivered goods is a clean loss plus a dispute fee. That is precisely where an export-leaning, EUR-priced merchant starts looking past cards.
There is a second friction on the money-out side. A business sourcing from suppliers abroad, paying contractors and creators in other countries, or running a marketplace that settles sellers across borders watches funds move slowly and expensively through traditional rails, with a cut taken at each hop and an FX spread layered on top. None of this is unique to Italy, but the country's mix of export-minded small merchants and cross-border supply makes it a common shape — which is why Italian merchants commonly price in EUR but want to settle in stablecoins.
Which assets fit a euro-priced business
For a business that thinks in euros, the asset that fits best is the one whose value does not move between checkout and confirmation. Dollar-pegged stablecoins — USDT and USDC — are the common case: the customer pays a stable amount and the merchant receives a stable amount, with no exposure to a swinging market in the minutes a payment takes to confirm. halfin anchors each invoice to your fiat figure and locks the quote when the invoice activates, so a EUR-priced order owes a fixed crypto amount even if the asset's price drifts while the customer is paying.
Where the customer holds those stablecoins decides the network. USDT settles on Tron, Ethereum, or Solana; USDC on Ethereum, Base, or Solana. An Italian merchant does not have to pick one — you enable the networks your customers actually use and let each customer pay on the rail they already hold funds on. For an export business serving a spread of markets that is the point: a customer who lives on TRC-20 USDT and a customer who is EVM-native on Base both check out against the same EUR invoice. Bitcoin remains the option for customers who prefer to pay in BTC, with the same fiat-anchored invoice and the same reorg-aware crediting before a payment counts as settled.
On your side, the spread of incoming assets does not have to stay scattered. Balance conversion consolidates what arrives — BTC, SOL, a mix of stablecoins — into the asset you want to hold as your reserve, automatically on a policy you set or manually when you decide to rebalance. A small euro-priced business that wants to sit mostly in a dollar stablecoin, rather than juggle a dozen balances, can do that without managing each one by hand.
- Price in EUR; the invoice locks a fixed crypto amount at activation, so the customer is not exposed to price movement mid-payment.
- USDT on Tron, Ethereum, or Solana; USDC on Ethereum, Base, or Solana — enable what your customers hold.
- Bitcoin for customers who pay in BTC, same fiat-anchored invoice and confirmation rules.
- Balance conversion consolidates a mixed inflow into the reserve asset you choose to hold.
Verticals that reach for this in Italy
The patterns that pull Italian businesses toward a crypto rail are the ones where the existing system loses sales at the border or skims money on the way out. None of these are exotic — they are ordinary small and mid-sized businesses hitting the cross-border, chargeback, or settlement edges described above.
Online stores and marketplaces are the broadest case: a brand selling Italian food, fashion, or design abroad does not want to lose customers to declined international cards, and a marketplace wants to settle its sellers across many countries in one run. Digital-goods and SaaS sellers want final settlement for something delivered instantly that cannot be shipped back when a card later reverses. And export-heavy small businesses want to collect from foreign customers and pay foreign suppliers without the slow, expensive cross-border tail of traditional rails.
- Export-leaning online stores — food, fashion, design, craft — selling beyond Italy, where international card decline rates and cross-border fees cost real conversions.
- Marketplaces aggregating many independent Italian sellers, settling them across borders in one idempotent payout run.
- SaaS and subscription businesses billing customers in and outside the EU, where machine-to-machine settlement moves value without a human-facing checkout in the loop.
- Digital goods, software, top-ups, and licences — instant, final settlement for things with nothing to ship back if a card payment later reverses.
- Cross-border B2B and supply settlement, where paying or collecting from a counterparty in another country is slow or expensive over traditional rails.
How halfin fits the existing setup
halfin sits alongside what an Italian business already runs; it does not replace the euro accounting or the domestic flows that work. You create an invoice anchored to your EUR price, redirect the customer to the hosted checkout page — which handles the wallet, the network choice, the QR code, and live status — and wait for one HMAC-signed webhook before you treat the order as paid. The on-chain detail stays on halfin's side; your order system keeps its existing shape, which matters for a small team that does not want to learn block confirmations and reorg behaviour for every chain it accepts.
For automated commerce — a subscription platform, a billing service, a system that pays another system — machine-to-machine settlement moves value programmatically without a checkout page in the loop. Static deposit addresses give you a persistent receive address when you would rather hand out one address than mint an invoice each time. On the outbound side, single payouts cover a one-off send with operator review, and mass payouts batch many destinations into one idempotent run — submitting the same batch twice does not pay twice — which is what a marketplace settling sellers across borders needs.
Treat the customer's redirect back to your success page as cosmetic and the signed webhook as authoritative: a customer can pay and close the tab before the redirect fires, but the webhook still arrives. Always verify the signature before acting on it. If you ever need to return funds, refunds run as a first-class flow against the original invoice rather than an ad-hoc manual send.
- Create an invoice anchored to your EUR price; the rate locks at activation and expiry is enforced.
- Hosted checkout handles wallet, network, QR, and live status — no on-chain code on your side.
- A signed webhook is the source of truth for marking an order paid; verify the HMAC first.
- Mass payouts settle many cross-border destinations in one idempotent batch; refunds run against the original invoice.
curl -X POST https://api.thehalfin.com/api/v1/invoices \
-H "X-API-Key: $HALFIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"amount_fiat": "74.00",
"fiat_currency": "EUR",
"idempotency_key": "order-IT-50731"
}'
# The EUR amount anchors the order; the customer settles in the
# crypto asset they pick on the hosted checkout page returned in
# the response. Redirect the customer there, then verify the
# signed invoice webhook before releasing the order. See the full
# request and response schema at docs.thehalfin.com.Compliance and availability — a rail, not a licence
An Italian business taking crypto still owns its own obligations. halfin is payment infrastructure: it collects payments, executes payouts, keeps payment records, and exposes status through dashboard data and signed webhooks. It does not take over the merchant's customer onboarding, its bookkeeping, its tax handling, or any approval the goods or services themselves require under local rules. Nothing on this page is legal, tax, or financial advice, and halfin makes no claim to be registered or licensed in Italy or anywhere else.
Onboarding to halfin involves KYB — verifying the business behind the merchant account — and the platform operates with AML awareness as a process. The travel rule, which concerns information that travels with certain transfers, is a concept to understand as you design flows, not a certificate halfin issues. The practical pattern for an Italian merchant is to keep your own customer checks, your own counterparty and wallet screening, and your own record of which order each invoice and payout belongs to; halfin gives you the payment primitives and the audit trail, and you keep the decisions about who you serve and what you sell.
Availability is subject to jurisdiction and sanctions screening, and some places are out of scope regardless of demand — see the restricted-countries note for where halfin cannot operate. If your business is based in Italy and serves customers across the EU and beyond, the relevant question is which networks and assets your customers actually use, and how you want incoming balances to settle.
- KYB onboarding verifies the business behind the merchant account.
- AML awareness is a process, not a status halfin grants — and halfin is not 'licensed' in any country.
- Keep your own customer checks, screening, and per-order records as the source of truth.
- Availability is subject to jurisdiction and sanctions screening; see the restricted-countries note.