Estonia's payment landscape is digital-first by design
Estonia built its economy around digital administration earlier and more thoroughly than most. Companies are formed online, taxes and filings are handled online, and a large share of the businesses on the register are software, SaaS, and digital-service companies rather than bricks-and-mortar ones. The e-residency programme adds a second layer: a meaningful number of Estonian companies are run by founders who live elsewhere and never set foot in the country, operating an EU company entirely over the internet.
That shape changes where the payment friction lives. Domestic and intra-EU euro transfers run over SEPA, which is cheap and familiar, and for a company billing other EU businesses in euros there is often nothing to fix. The pain shows up at the edges that a digital, borderless company hits constantly — a customer outside the SEPA area whose card declines or carries cross-border fees, a contractor in a country where a bank transfer is slow and expensive, a founder who themselves is in a different jurisdiction from the company.
Because so much of this is online and cross-border by default, Estonian and e-resident companies commonly price in EUR but reach for a rail that does not care where the counterparty's bank is. That is the gap a crypto rail fills: the customer or contractor needs a wallet, not a correspondent-banking relationship, and the company keeps thinking in euros.
Which assets fit a euro-priced, internet-native company
For a company that keeps its books in euros, the asset that fits is the one whose value does not move while a payment confirms. Dollar-pegged stablecoins — USDT and USDC — are the common case: the customer pays a stable amount and the company receives a stable amount, with no exposure to a swinging market in the minutes a payment takes. halfin anchors each invoice to your fiat figure and locks the quote when the invoice activates, so a EUR-priced subscription or invoice owes a fixed crypto amount even if the asset's price drifts mid-payment.
Where the customer holds those stablecoins decides the network. USDT settles on Tron, Ethereum, or Solana; USDC on Ethereum, Base, or Solana. An Estonian company does not have to pick one rail — you enable the networks your customers and contractors actually use and let each person pay or be paid on the chain they already hold funds on. Bitcoin stays available for customers who prefer 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 — a mix of stablecoins, some BTC, some SOL — into the asset you want to hold as your reserve, automatically on a policy you set or manually when you decide to rebalance. A company that collects in several stablecoins but wants to pay its team in one of them can do that without hand-managing each balance.
- 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 contractors hold.
- Bitcoin for customers who pay in BTC, with the same fiat-anchored invoice and confirmation rules.
- Balance conversion consolidates a mixed inflow into the one reserve asset you choose to hold and pay from.
Verticals that reach for this in Estonia
The businesses that pull toward a crypto rail in Estonia are mostly the ones the ecosystem is known for: software companies, SaaS subscriptions, digital services, and any operation that pays a distributed team. None of these are exotic — they are ordinary internet companies hitting the cross-border edges of cards and bank transfers.
SaaS and subscription businesses want to bill customers in and outside the EU without losing the ones whose international cards decline, and they want billing to run programmatically rather than through a human-facing checkout for every renewal. Developer-heavy and agency-style companies want to pay contractors, freelancers, and remote engineers across many countries on a schedule, in an asset those people can actually receive. And digital-goods and download sellers want final settlement for something delivered instantly, with nothing to ship back if a card payment later reverses.
- SaaS and subscription companies billing customers across the EU and beyond, where machine-to-machine settlement renews without a checkout page in the loop.
- Developer and agency businesses paying remote contractors and engineers, where mass payouts settle many countries in one idempotent run.
- Digital goods, software, and licences — instant, final settlement for things with nothing to ship back if a card later reverses.
- E-resident companies run by founders outside Estonia, where every payment is cross-border by default and a wallet beats a correspondent bank.
- Marketplaces and platforms collecting from buyers and settling sellers or creators in stablecoins across borders.
How halfin fits an API-first setup
Estonian software companies tend to want the integration to be code, not a plugin, and that is the shape halfin takes. You create an invoice anchored to your EUR price over the REST API, 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 billing system keeps its existing shape. There is no CMS plugin to install — the integration is the same API and hosted checkout regardless of platform.
For automated billing — a SaaS that renews subscriptions, a service that bills another service — machine-to-machine settlement moves value programmatically without a checkout page in the loop, which suits a company that already does most things through its own backend. API keys carry scoped permissions and requests take idempotency keys, so a retried call does not double-charge or double-pay. Static deposit addresses give you a persistent receive address when you would rather hand out one address than mint an invoice each time.
Paying the team works out of the same account. 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 settling a list of contractors across many countries runs as one idempotent batch — submitting the same run twice does not pay twice. 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, and you should verify its signature before acting. 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 over the REST API; 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.
- Machine-to-machine settlement renews subscriptions programmatically; API keys carry scoped permissions and idempotency keys.
- Mass payouts fan out over the payouts API with per-line idempotency keys to pay contractors across borders in one batch.
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": "29.00",
"fiat_currency": "EUR",
"idempotency_key": "sub-EE-77310"
}'
# The EUR amount anchors the charge; 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 activating the subscription. See
# the full request and response schema at docs.thehalfin.com.Compliance and availability — a rail, not a licence
An Estonian or e-resident company 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 company'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 Estonia 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 Estonian company is to keep your own customer checks, your own counterparty and contractor screening, and your own record of which charge 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 pay.
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. For a company that runs online, often with a founder outside Estonia and customers and contractors spread across countries, the relevant questions are which networks and assets the people you transact with 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 and contractor checks, screening, and per-charge records as the source of truth.
- Availability is subject to jurisdiction and sanctions screening; see the restricted-countries note.