The Hong Kong payment landscape, and where the cross-border edge bites
Hong Kong is a trade and finance hub before it is a domestic market. Money comes in and goes out across borders by default: import and export companies settling with suppliers and buyers abroad, professional and digital services billing clients overseas, marketplaces and platforms whose users are scattered across many countries. The local card and bank rails handle a Hong Kong customer paying a Hong Kong business well enough. The strain appears the moment a counterparty sits somewhere else.
Cross-border card acceptance carries the usual drag at scale: international cards decline more often than domestic ones, the customer often sees a currency conversion they did not ask for, and a chargeback can land weeks after goods have shipped or a service has been delivered. International wires are reliable but slow and stepwise, with correspondent banks in the middle, cut-off times, and fees that are awkward to pass on for a smaller invoice. For a business whose customers and suppliers are spread across time zones, 'when does the money actually arrive' is a real operational question, not a formality.
That cross-border reality is why stablecoins have found practical traction with internationally-facing Hong Kong businesses: a US-dollar-denominated digital asset that moves the same regardless of which side of a border the counterparty is on. It is also why the common pattern here is to price in HKD or USD but settle in USDT or USDC — keep the familiar accounting currency, take the payment on a rail that does not care about borders.
Which assets fit a Hong Kong, cross-border business
For a business that thinks in HKD or USD, 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 there is 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 an order priced in HKD or USD 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. A Hong Kong merchant serving a global base does not have to pick one rail and force everyone onto it — you enable the networks your customers actually use and let each customer pay from funds they already hold. That matters more here than in a single-country market, because 'your customers' may mean wallets and habits from a dozen different places at once. 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 mixed inflow does not have to stay mixed. Balance conversion consolidates what arrives — BTC, SOL, a spread of stablecoins across networks — into the asset you want to hold as your reserve, automatically on a policy you set or manually when you decide to rebalance. A trading or platform business that wants to sit mostly in a dollar stablecoin can do that without nursing each balance by hand.
- Price in HKD or USD; 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 the rails your global customers actually 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 Hong Kong
The businesses that pull hardest toward a crypto rail in Hong Kong are the ones built around movement across borders — which, in this market, is most of them. None of these are exotic. They are ordinary companies hitting the cross-border, settlement-speed, or chargeback edges described above.
Trading and export businesses want to collect from buyers abroad and pay suppliers abroad without each leg sitting in correspondent banking for days. Online stores and marketplaces want to sell into many countries without losing customers to declined international cards, and to settle sellers spread across jurisdictions in one run rather than dozens of separate wires. Software, SaaS, and digital-goods businesses want final settlement for something delivered instantly that cannot be shipped back when a card later reverses. And platforms that move value between systems want settlement that does not need a person clicking through a checkout at all.
- Trading, import / export, and cross-border B2B, where collecting from buyers and paying suppliers abroad over traditional rails is slow and stepwise.
- Online stores and marketplaces selling into many countries, where international card decline rates and cross-border fees cost real conversions, and sellers need settling across jurisdictions.
- SaaS and subscription businesses billing a global customer base, 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.
- Higher-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 Hong Kong business already runs; it does not replace the HKD or USD accounting or the bank flows that work. You create an invoice anchored to your fiat 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.
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 or trading business settling counterparties 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 HKD or USD 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": "1200.00",
"fiat_currency": "HKD",
"idempotency_key": "order-HK-50281"
}'
# The fiat 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 Hong Kong 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 Hong Kong 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 Hong Kong 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 Hong Kong and sells or settles across borders, the relevant question is which networks and assets your customers and counterparties 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.