Two kinds of money movement
On-chain sends exist for one reason: crossing a trust boundary. When money leaves your control — to a customer's own wallet, to an exchange, to cold storage — you want a public network to settle it, and the fee buys you that finality. But a huge share of real-world "payouts" never cross a trust boundary at all. A marketplace crediting a seller. An operator settling a commission with an affiliate. A business rebalancing between its own regional entities. Both sides of those movements live inside the same platform; putting them on a chain adds cost and latency and returns nothing.
That's what internal transfers are: a ledger move between two OrbChain accounts, addressed by public account ID (the ORB-… identifier every account gets at signup). No broadcast, no confirmations, no fee — the debit and credit happen in one atomic database transaction, so there is no intermediate state where the sender has paid and the recipient hasn't received.
The call
One request, authenticated with your merchant API key (scoped keys need transfer:create):
curl https://orbchain.io/v1/transfer \ -X POST \ -H "merchant_api_key: YOUR_KEY" \ -H "Content-Type: application/json" \ -d '{ "to_account_id": "ORB-3qvxq5yVwnS6c3c3Eycj", "coin": "USDT_TRC20", "amount": "250.00", "idempotency_key": "commission-2026-08-alice" }'
The response returns before you could refresh a block explorer, and the recipient's balance is already spendable — they can pay it onward, swap it, or withdraw on-chain whenever they choose. If your account has 2FA enabled, every transfer also requires a fresh totp_code, so a leaked API key alone can't move balance.
Idempotency is the whole reliability story
An internal transfer is final the moment it commits — like an on-chain payment, minus the wait. What replaces the "did my broadcast go through?" anxiety is the idempotency_key: put a stable identifier on every transfer (an invoice number, a payroll-run row ID) and retry as aggressively as you like. Repeats return the original transfer instead of sending twice. Timeouts, crashed workers, double-clicked buttons — all safe. This is the property that makes internal transfers scriptable: your settlement job can be dumb and rerunnable, which is exactly what settlement jobs should be.
Patterns we see in production
- The commission ledger. Affiliates and sub-operators each hold an OrbChain account. Commissions settle internally the moment they accrue — daily, hourly, per-sale, it costs the same: nothing. Partners cash out on their own schedule through the standard payout API, paying one network fee for a month of accrued earnings instead of thirty fees for thirty payments.
- Marketplace seller balances. Buyers pay the platform once. Seller shares move as internal transfers, instantly and for free; only actual cash-outs touch a chain. (If you'd rather declare shares up front and have settlement fan out automatically, that's revenue splits — the two compose.)
- Multi-entity treasury. Separate accounts per business line — each with its own keys, webhooks, and statement — rebalanced by transfer in seconds. Clean books without a single on-chain hop between your own pockets.
Both sides get a receipt
Every transfer fires two signed webhooks — transfer.sent to the sender, transfer.received to the recipient — with the same HMAC-SHA512 signing and deterministic event IDs as every other event on the platform. Your partner's system learns about their commission the same second yours records paying it, from a payload each of you can verify independently. No "did you send it yet?" support threads.
When you should NOT use it
The honest boundary: internal transfers only work inside the loop. The recipient must hold an OrbChain account, and the movement is a ledger entry, not a public on-chain record — if the receiving party wants trustless settlement to an address only they control, that's what payouts are for, and the network fee is buying something real. Use transfers where trust already exists (your partners, your entities, your sellers) and payouts where it shouldn't have to.
The pattern that falls out is simple and cheap: settle often internally, withdraw rarely on-chain. Frequency becomes free; finality stays available whenever anyone wants it.