One operator surface over the whole payment stack
When a payment platform only has an API, every routine action becomes an engineering ticket. Finance wants to see what cleared today, support needs to check why an invoice expired, an operator has to release three withdrawals before end of day — and all of it routes through whoever can run a curl command. That backlog is the problem the dashboard removes.
The dashboard is a read-and-write console over the exact same primitives the REST API exposes: invoicing, hosted and self-hosted checkout, static deposit addresses, single and mass payouts, balance conversion, refunds, webhooks, and key management. Nothing in the dashboard is a parallel system. An invoice you create from the UI is the same object your integration reads back over the API; a payout an operator approves on screen settles through the same execution path your code would have triggered.
That parity matters for how teams actually split the work. Engineering wires the integration once — invoices created on contract events, webhooks consumed, settlement state reconciled — and then finance and operations run the day-to-day from the dashboard without touching the codebase. Both sides are looking at one source of truth, so a number on the dashboard and a field in a webhook never disagree.
Create and track invoices without an integration
The first thing most teams do in the dashboard is issue an invoice by hand. You set a fiat-anchored amount in USD or EUR, pick the assets and networks the customer may pay with, and the rate is locked at activation so a swing between issue and payment does not change what the customer owes. The invoice carries an expiry, and you watch it move through its lifecycle in real time as the deposit is detected, confirmed, and credited.
Manual issuance covers the cases an integration is awkward for: a one-off B2B contract pre-pay, a sales-assisted deal where the rep sends a payment link in an email, a quick test against staging before you wire anything up. It is also where support lives — when a customer says they paid and the order never updated, an operator opens the invoice and sees exactly which state it reached and why.
Underpaid and overpaid payments are surfaced as first-class states rather than buried as failures. If a customer sends slightly less than the locked amount, the invoice shows the shortfall instead of silently rejecting; an overpayment is recorded so it can be refunded or credited. The deeper mechanics of fiat anchoring and partial payments live on the invoicing page — the dashboard is where you act on them one record at a time.
Approve payouts with a human in the loop
Sending crypto out is the action that warrants the most care, because on-chain settlement is final — there is no chargeback to undo a mistake. The dashboard treats a payout as something an operator reviews and approves, not something that fires the instant it is requested. You see the destination, the asset and network, and the amount before you release it, and the approval itself is recorded against the operator who made it.
A single payout is one approved transfer to one destination — a supplier invoice, a partner settlement, a contractor payment. Mass payouts run the same review over a batch: you load the recipient list, check the totals, and approve the run as a unit. Because batches are idempotent, re-submitting the same batch after a network hiccup never double-pays the recipients, which is the failure mode operators worry about most when a screen times out mid-action.
Every payout keeps its full status visible — queued, sent, confirming, completed — so an operator answering "did the vendor get paid?" has a definitive answer instead of a guess. Tying approvals to named operators and an audit trail is the practical substitute for the four-eyes controls a bank would impose, kept inside the same surface where the work happens.
Balances, transactions, and treasury at a glance
The balances view is where finance lives. It shows what you hold per asset and network, the transactions that moved those balances, and the settlement state behind each one. Because crediting is reorg-aware and respects per-chain confirmation thresholds, a balance the dashboard shows as settled is a balance you can act on — it is not counting a deposit that a chain reorganization might still reverse.
From the same place you can run balance conversion to rebalance treasury: convert one asset to another, automatically on a rule or manually when you decide. A team that quotes invoices in USD but accepts several tokens uses this to consolidate incoming payments into the settlement asset they actually want to hold, without exporting data into a spreadsheet and reconciling by hand.
The transaction history is the reconciliation backbone. Every deposit ties back to the invoice it paid; every payout ties back to the operator who approved it and the destination it went to. When the books close, the dashboard is the record finance reads against — and the same data is available over the API for teams that pull it into their own ledger.
Manage API keys and scoped permissions
An integration is only as safe as the credentials behind it, and the dashboard is where those credentials are governed. You create API keys, assign each one a narrow set of scoped permissions, and revoke a key the moment it should no longer work. The principle is least privilege made operational: a key only carries the permissions its job needs.
That separation is what lets you hand out access without handing out the whole account. A read-only key for the accounting export cannot move money. A separate key scoped to payouts can execute withdrawals but nothing else. A checkout integration gets exactly the surface it needs and no more. If a key leaks or a developer leaves, you rotate that one credential from the dashboard without disturbing every other integration.
Scopes are the same mechanism the API enforces server-side — the dashboard is the front door for managing them, not a softer version of the rule. Combined with operator-level audit on the actions people take in the UI, you get a coherent answer to "who can do what, and who did it" across both the human and the programmatic side of the account.
| Operator task | What the dashboard gives you | Same primitive over the API |
|---|---|---|
| Issue a one-off invoice | Fiat-anchored amount, asset/network choice, rate locked at activation, live lifecycle | Invoicing |
| Release a withdrawal | Destination + amount review, named-operator approval, final status | Single payouts |
| Pay a batch of recipients | Load list, verify totals, approve as a unit, idempotent re-runs | Mass payouts |
| Reconcile what cleared | Per-asset balances, transaction history, reorg-aware settled state | Balances + webhooks |
| Rebalance treasury | Convert assets automatically or manually | Balance conversion |
| Govern integration access | Create, scope, and revoke API keys; least-privilege permissions | API keys with scoped permissions |
Where the dashboard ends and the API begins
The dashboard and the API are two doors into one account, and most teams use both. High-volume, event-driven work belongs to the integration: an invoice per checkout, a payout per approved withdrawal in your own back office, webhooks consumed to keep your systems in sync. Verify each webhook's HMAC signature before you act on it — the event tells you something changed, and the signature is what proves it came from halfin.
Everything that needs human judgment or sits outside a coded flow belongs to the dashboard: approving the payout your back office queued, investigating an invoice a customer disputes, rotating a key, checking the day's settled balance, running a one-off conversion. The two never drift apart because they read and write the same records.
A typical setup wires the integration once and runs operations from the dashboard from then on. The code snippet below mints an API key's first invoice; from that point an operator can find, refund, or follow that same invoice on screen — no extra plumbing required.
# Create an invoice via the API — then manage it in the dashboard
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": "49.00",
"fiat_currency": "USD",
"deferred": true,
"description": "Pro plan — March",
"idempotency_key": "7f3c2a10-0000-4a1b-9c2d-000000000001"
}'
# The returned invoice is the same object an operator
# opens, refunds, or tracks at dashboard.thehalfin.comOnboarding, roles, and the audit trail
Access to the dashboard starts with KYB onboarding — establishing who the business is before it can collect or send funds. This is a process, not a certification halfin holds on your behalf, and it is the foundation the rest of the controls build on. AML awareness and travel-rule concepts inform how a merchant should think about counterparties; the dashboard is where the resulting decisions get made and recorded.
Operator actions are logged. When an operator approves a payout, creates a key, or runs a conversion, that action is attributable — which turns the dashboard from a convenience into a control surface. For a finance or compliance reviewer, the audit trail answers the questions that matter after the fact: who released this withdrawal, who issued this key, what changed and when.
None of this asks your team to trust the platform blindly. Signing, scoped permissions, and the audit log are the concrete mechanisms — not custody promises — that let a business run real money through the dashboard while keeping authority where it belongs.