The Dutch payment landscape, and where the cross-border edges bite
The Netherlands punches above its size in commerce because so much of its economy is outward-facing. It is an EU trade and logistics hub, with marketplaces, distribution, and digital businesses whose customers and counterparties sit all over the map. Domestically, euro payments are well served and a Dutch finance team rarely thinks twice about a local transfer. The friction lives at the edges of that domestic comfort — and for a business built on cross-border flow, the edges are most of the volume.
Card acceptance is the first pinch. A Dutch store selling beyond its home market sees foreign-issued cards decline more often than domestic ones, carries currency conversion the customer notices, and stays exposed to chargebacks that can land weeks after the goods have shipped or the download has been delivered. Those declined customers are not fraud; they simply could not complete a card payment, and the merchant loses the sale for reasons that have nothing to do with the order.
Cross-border settlement is the second. A marketplace or distributor that collects from buyers in one set of countries and pays sellers or suppliers in another watches money crawl through correspondent banking, with a cut taken at each hop and an FX spread layered on. For a business whose entire model is moving goods and money across borders, that drag is structural, not occasional. That is the gap a crypto rail fills, and it is why Dutch merchants commonly price in EUR but want to settle in stablecoins on both sides of the flow.
Which assets fit a euro-priced, cross-border business
For a business that prices in euros but trades across borders, 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, the merchant receives a stable amount, and neither is exposed 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 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. A Dutch merchant does not have to choose one — you enable the networks your customers and sellers actually use and let each party pay or be paid on the rail they already hold funds on. A buyer abroad paying TRC-20 USDT and a seller settled in USDC on Base can both run through the same account. 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, a cross-border operation collects a mix of assets and networks, and that mix does not have to stay scattered. Balance conversion consolidates what arrives — BTC, SOL, a spread 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 euro-priced business that wants to sit mostly in a dollar stablecoin so it can pay international sellers in the same unit can do that without managing each balance by hand.
- Price in EUR; the invoice locks a fixed crypto amount at activation, so neither side is exposed to price movement mid-payment.
- USDT on Tron, Ethereum, or Solana; USDC on Ethereum, Base, or Solana — enable what your customers and sellers hold.
- Bitcoin for customers who pay in BTC, same fiat-anchored invoice and confirmation rules.
- Balance conversion consolidates a mixed cross-border inflow into the reserve asset you choose to settle from.
Verticals that reach for this in the Netherlands
The patterns that pull Dutch businesses toward a crypto rail follow the country's outward-facing economy: marketplaces, logistics and trade, digital goods, and anything that depends on collecting from or paying out to people in other countries. None of these are exotic — they are ordinary businesses hitting the cross-border, chargeback, or acquirer-risk edges described above, just at higher volume because so much of the work crosses a border.
Marketplaces are the broadest case. A Dutch platform collects from buyers across many countries, holds balances, and has to settle a long list of sellers on a schedule — often in different countries than the buyers. That two-sided, many-destination flow is exactly where slow and expensive traditional settlement hurts most, and where idempotent mass payouts and stablecoin settlement change the economics. Trade, distribution, and B2B businesses face the same problem on the supplier side: paying or collecting from a counterparty abroad over correspondent banking is slow and costly, while a stablecoin transfer settles directly between wallets.
- Marketplaces and platforms collecting from buyers in many countries and settling sellers across borders in one run.
- Logistics, trade, and distribution businesses paying or collecting from international suppliers, where wires are slow and expensive.
- Online stores selling beyond the home market, where foreign-card decline rates and cross-border fees cost real conversions.
- SaaS and digital-goods sellers billing customers in and outside the EU — instant, final settlement for things with nothing to ship back if a card later reverses.
- High-risk and underserved verticals that card acquirers treat cautiously but that still need a reliable way to be paid.
How halfin fits the existing setup
halfin sits alongside what a Dutch 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.
Because so much of a Dutch operation is outbound, the payout side matters as much as acceptance. Single payouts cover a one-off send with operator review. Mass payouts fan out over the payouts API with a per-line idempotency key, so a batch submitted twice does not pay twice — which is exactly what a marketplace settling many sellers across borders on a schedule needs. Balance conversion consolidates a mixed inflow into the asset you pay out from. Static deposit addresses give you a persistent receive address when you would rather hand out one address than mint an invoice each time, and machine-to-machine settlement moves value programmatically when there is no human-facing checkout in the loop — a subscription platform, a billing service, a system that pays another system.
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 sellers 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.50",
"fiat_currency": "EUR",
"idempotency_key": "order-NL-71840"
}'
# 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
A Dutch 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 the Netherlands 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 a Dutch merchant — especially a marketplace or distributor paying many counterparties abroad — is to keep your own customer and counterparty checks, your own 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; 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 the Netherlands and trades across the EU and beyond, the relevant questions are which networks and assets your customers and sellers actually use, and how you want incoming balances to settle before you pay out.
- 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 and counterparty checks, screening, and per-order records as the source of truth.
- Availability is subject to jurisdiction and sanctions screening; see the restricted-countries note.