The Malta payment landscape: an operator that pays the world
Most businesses that run from Malta and reach for a crypto rail are not local shops serving local customers. They are online casinos, sportsbooks, and the affiliate and marketing networks that feed them — companies headquartered in Malta but with players and partners spread across many countries. The everyday money problem is not domestic; it is the cross-border edge, and that edge is where card and bank rails are slowest and most expensive.
On the inbound side, a player wants to deposit and be in the game now. Card deposits decline often for cross-border traffic and for gaming merchant categories that acquirers treat as high-risk, and an international bank transfer takes days a player does not want to wait. On the outbound side, a player expects a withdrawal to land fast, and an affiliate in another country expects their revenue share — and paying a long list of players and partners over bank rails means a different set of details, fees, and delays for each destination.
That two-sided, many-country flow is what pushes Malta operators toward stablecoins: a player deposits in USDT from a wallet in minutes, and the operator pays a withdrawal or an affiliate in USDC to a wallet on the other side of the world without a correspondent-bank chain in between. Operators commonly book the figure in EUR and settle the actual movement in dollar-pegged stablecoins, keeping the amount stable while the money crosses borders that card and bank rails handle badly.
Which assets fit an operator that books in EUR
For an operator that credits a player balance in a fiat figure, the asset that fits best is the one whose value does not move between the deposit being sent and the deposit clearing. Dollar-pegged stablecoins — USDT and USDC — are the common case on both sides of the flow: the player sends a stable amount, the operator credits a stable amount, and an affiliate revenue share paid in a stablecoin is worth the same when it lands as when it was calculated. halfin anchors each invoice to your fiat figure and locks the quote when the invoice activates, so a deposit booked at a EUR amount owes a fixed crypto amount even if the asset's price drifts while the player is paying.
Where the player or the affiliate holds those stablecoins decides the network. USDT settles on Tron, Ethereum, or Solana; USDC on Ethereum, Base, or Solana. Tron USDT in particular is a familiar deposit rail for retail players, and you do not have to pick one network for everyone — you enable the networks your players and partners actually use, and each one deposits or gets paid on the rail they already hold. Bitcoin remains the option for a player who prefers to fund in BTC, with the same fiat-anchored invoice and the same reorg-aware crediting before a deposit counts as cleared.
On your side, the inflow does not have to stay scattered across assets. Balance conversion consolidates what arrives — a mix of USDT, USDC, SOL, BTC — into the asset you want to hold as your float and pay withdrawals and affiliate revenue from, automatically on a policy you set or manually when you decide to rebalance. An operator that wants to sit mostly in a dollar stablecoin and pay players and partners from that single balance can do that without managing each asset by hand.
- Book deposits in EUR; the invoice locks a fixed crypto amount at activation, so the credited figure does not drift mid-deposit.
- USDT on Tron, Ethereum, or Solana; USDC on Ethereum, Base, or Solana — enable what your players and affiliates hold.
- Bitcoin for players who prefer to deposit in BTC, same fiat-anchored invoice and reorg-aware confirmation rules.
- Balance conversion consolidates a mixed inflow into one float asset you pay withdrawals and affiliate revenue from.
The flows Malta operators and affiliates reach for
The patterns that pull a Malta-based gaming business toward a crypto rail are the two halves of an operator's money flow — funding player balances and paying out — plus the affiliate economy that sits around it. None of these are exotic; they are the ordinary casino, sportsbook, and affiliate flows hitting the cross-border, decline-rate, and many-destinations edges described above.
Player deposits are the broadest inbound case: a player funds a balance by paying a fiat-anchored invoice and settling in the stablecoin they hold, so the operator credits a stable figure as soon as the deposit clears on-chain. On the outbound side, player withdrawals and affiliate revenue shares are payouts to wallets scattered across jurisdictions — the case where one batched, idempotent run beats wiring each destination by hand.
- Player deposits — a player funds a balance against a fiat-anchored invoice and settles in USDT, USDC, or Bitcoin on a network they hold.
- Player withdrawals — a cash-out is an approved payout your platform authorises against the player's balance, executed and recorded by halfin.
- Affiliate revenue shares — settle a long list of affiliates and marketing partners across many countries in one idempotent run instead of one bank transfer per recipient.
- Networks and white-label partners around the operator — programmatic settlement between systems where there is no human-facing checkout in the loop.
How halfin fits the operator's platform
halfin sits alongside the gaming platform and back office a Malta operator already runs; it does not decide who may play, who may withdraw, or which affiliate earns what. On the inbound side you create an invoice anchored to the fiat amount you book the deposit in, redirect the player 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 credit the player balance. The deposit you mark as cleared is reorg-aware and waits for the per-chain confirmation threshold, so it is one that actually held; underpaid and overpaid deposits are recorded against the invoice rather than stranded.
On the outbound side, a withdrawal or an affiliate payment is a payout your platform approves, not one halfin authorises. A single payout is one approved transfer to one destination, carrying an asset, an amount, a destination wallet, and an idempotency key that makes a retried request safe — resubmitting the same payout after a timeout pays the recipient once, not twice. Paying a whole list of players or affiliates is the same single-payout call fanned out over POST /api/v1/payouts, one approved line at a time, each with its own idempotency_key; there is no separate batch endpoint to learn, and a partial failure stays recoverable line by line instead of as one opaque blob. When a transfer settles, halfin emits a signed payout.completed event so your ledger can move the withdrawal or revenue share from pending to done against a record you can trust.
Treat the player's redirect back to your success page as cosmetic and the signed webhook as authoritative: a player can pay and close the tab before the redirect fires, but the webhook still arrives. Always verify the HMAC signature before crediting a balance or releasing a payout state. If you ever need to return a deposit, refunds run as a first-class flow against the original invoice rather than an ad-hoc manual send.
- Create an invoice anchored to the EUR figure you book the deposit in; the rate locks at activation and expiry is enforced.
- Hosted checkout handles wallet, network, QR, and live status — no on-chain code in your platform.
- A signed webhook is the source of truth for crediting a player balance; verify the HMAC first.
- Withdrawals and affiliate revenue are approved payouts; the same single-payout call fans out over the list, each line idempotent.
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": "100.00",
"fiat_currency": "EUR",
"idempotency_key": "deposit-MT-44820"
}'
# The EUR amount anchors the player's deposit; the player settles
# in the crypto asset they pick on the hosted checkout page returned
# in the response. Redirect the player there, then verify the signed
# invoice webhook before crediting the player balance. Withdrawals and
# affiliate revenue go out as approved payouts. See the full request
# and response schema at docs.thehalfin.com.Compliance and availability — a rail, not a licence
A Malta operator taking crypto still owns its own obligations. halfin is payment infrastructure: it collects deposits, executes approved payouts, keeps payment records, and exposes status through dashboard data and signed webhooks. It does not take over the operator's player onboarding, its identity and age checks, its responsible-gaming controls, its bookkeeping, or any approval the gaming business itself needs in the markets it operates in. halfin is not a gaming licence and does not grant one. Nothing on this page is legal, tax, or financial advice, and halfin makes no claim to be registered or licensed in Malta 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 deposit and withdrawal flows, not a certificate halfin issues. The practical division for an operator is clean: keep every player-eligibility, identity, and withdrawal-approval decision inside your platform, and let halfin own only the money movement and its audit trail. You decide whether a player may deposit and withdraw and whether an affiliate has earned a share; halfin executes the instruction and records it.
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 Malta and serves players and affiliates across many countries, the relevant question is which networks and assets your players and partners actually use, and how you want incoming balances to settle before you pay withdrawals and revenue shares from them.
- 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 and is not a gaming licence.
- Player-eligibility, age, responsible-gaming, and withdrawal decisions stay in your platform; halfin executes and records the approved payout.
- Availability is subject to jurisdiction and sanctions screening; see the restricted-countries note.