The problem we set out to solve
Online businesses that sell across borders run into the same wall. A customer in one country wants to pay, the business is in another, and the money has to cross a banking system that was not built for either of them. Cards get declined for being foreign. A bank transfer that should take an afternoon takes three days and arrives in a currency you have to convert back. Each link in that chain adds a fee you can't see in advance, a delay you can't plan around, and a failure mode you find out about only when a paying customer gives up.
Crypto removes the correspondent banks from the middle of that path. A stablecoin payment settles on its network in minutes, not days, and it doesn't care which country the payer is in. But raw blockchains are not a payment system on their own — they hand you addresses, raw transactions, and per-chain quirks, and leave the hard parts to you: pricing in your own currency, knowing when a payment is actually final, matching deposits to orders, and paying people back out. halfin is the layer that turns those primitives into something a business can run on.
We are deliberately narrow about who this is for. halfin serves online businesses with a cross-border payment problem — companies whose customers, suppliers, or partners sit on the other side of a slow or unreliable banking corridor. It is infrastructure for moving money, not a wallet for individuals and not an on-ramp that sells crypto to end users.
What halfin does
halfin is the money-movement layer between your application and the chains your customers pay on. You price and reconcile in your home currency; the platform handles the conversion to and from crypto, the on-chain mechanics, and the per-chain rules that decide when a payment is real. The pieces below are the surface of the product — each is a primitive you can compose into your own flow rather than a fixed checkout you have to adopt wholesale.
The point of grouping them this way is that money moves in two directions and you usually need both. Inbound: invoicing and checkout turn an amount you're owed into a payment a customer can make. Outbound: payouts turn a balance into money that reaches a destination. In between sits the settlement layer — balances, conversion, and refunds — plus the integration surface that lets your own systems drive all of it.
| Capability | What it gives you |
|---|---|
| Invoicing | Bill an amount in your own currency; the rate locks when the invoice goes live and the customer settles in any supported asset. |
| Hosted & self-hosted checkout | A halfin-hosted payment page, or the same invoice object rendered inside your own UI against the same API. |
| Static deposit addresses | Persistent receive addresses for flows that aren't tied to a single invoice. |
| Single & mass payouts | Send one approved payout, or fan out many over the same payout API with a per-line idempotency key. |
| Balance conversion & M2M settlement | Rebalance treasury automatically or by hand, and settle programmatically between systems. |
| Dashboard, API, webhooks & refunds | Run it from an operator UI or drive it spec-first; react to signed events; return funds when you need to. |
Who it is for
The common thread across halfin's users isn't an industry — it's a shape of problem. These are businesses where a meaningful share of the people paying them, or being paid by them, are far enough away that the traditional rails are slow, expensive, or simply don't connect. When that's true, the ability to take a stablecoin or a native coin and settle it against a clean fiat figure is the difference between a global customer base and one bounded by which cards happen to clear.
In practice that lands in a few recurring places. An e-commerce store selling internationally wants checkout to work for a buyer whose card issuer blocks cross-border charges. A platform paying contributors, affiliates, or creators in dozens of countries wants one payout flow instead of a patchwork of local bank integrations. A subscription or services business wants to bill in dollars or euros and not eat the FX swing between invoice and payment. The vertical differs; the underlying need — predictable money across borders — does not.
- Online businesses selling to customers in countries where local card and bank rails are unreliable or slow.
- Platforms that pay out to many recipients across borders and want one idempotent payout flow, not many.
- Businesses that price in a stable home currency but want to accept the assets their customers actually hold.
- Teams that would rather integrate one spec-first API than maintain a separate connector per country.
How we think about building it
Crypto payments are irreversible, so the product is opinionated about correctness over convenience. An invoice is marked paid only after on-chain confirmations reach a threshold chosen for that specific chain, and crediting is reorg-aware — if a chain reorganizes and unwinds a transaction we were tracking, that's reflected rather than ignored. The amount you see as settled is an amount that actually held. Outbound, a payout moves only behind an approval that lands in an audit trail, and every payout request carries an idempotency key so a retry can't quietly send the same money twice.
We also keep a clear seam around what we control. halfin signs the events it sends so you can authenticate them, enforces the scoped permissions on your API keys so a leaked key has a bounded blast radius, and records who created and approved each payout. Those are mechanisms you can verify. What we don't do is make sweeping custody promises beyond signing, permissions, and audit — being precise about that is part of the product, not a caveat to it.
Compliance sits alongside the technology as process, not as a badge. Know-your-business onboarding, anti-money-laundering awareness, and travel-rule handling are procedures halfin runs; none of them is a certification or a license, and nothing here is legal advice. If you need the specifics of how those processes work, the documentation and compliance material are the place to look rather than this page.
Where halfin fits — and where it doesn't
It helps to be explicit about the boundary, because the surrounding ecosystem is full of products that look adjacent. halfin is the infrastructure a business integrates: a merchant dashboard at dashboard.thehalfin.com, a hosted checkout at checkout.thehalfin.com, public documentation at docs.thehalfin.com, a REST API at api.thehalfin.com/api/v1, and the @halfin/sdk-merchant TypeScript SDK. Those are the surfaces you build against.
What halfin is not: it is not a consumer wallet, and it does not sell crypto to end users — there's no fiat on-ramp here. It does not provide official storefront plugins; guides that mention a platform like Shopify or WooCommerce describe the general API and checkout approach, not a packaged plugin. And it makes no claim to be regulated or licensed — the compliance language on this site is always about process. The scope of this page itself is narrow too: it's about the product and who it serves, not investor relations, hiring, or press.
If the shape of your problem matches the one at the top of this page, the most useful next step is concrete rather than abstract. Invoicing is where most integrations start, because it's the primitive that turns a fiat amount into a crypto payment without handing you the FX risk. The e-commerce use case shows that primitive in a familiar setting, and the dashboard is where you'd watch it all happen once it's live.