There is exactly one thing KYB blocks, and it is not your build. It blocks the live key — the credential that lets a deposit settle into real value and a payout release real funds. Everything else you can do while verification is still open. Teams that understand this ship on schedule. Teams that don't discover, the week they meant to launch, that "we still have to onboard" is a sentence with a timeline attached.
This is the operational view of KYB: not what it is for — that's a separate conversation — but how it sits against the calendar, what the process actually involves, and how to sequence your work so the gate opens the moment you're ready to walk through it.
The two keys, and the line between them
A halfin account gives you two kinds of API key, and the difference between them is the whole story.
A sandbox key talks to the same REST API as production. The request shapes are real, the responses are real, the webhook events are real. You can create invoices, render hosted checkout, fan out single and mass payouts, and verify webhook signatures against genuine event envelopes. What you cannot do is move money: every invoice you create with a sandbox key is test data, and no funds settle on-chain. It is a faithful rehearsal of production with the stakes removed.
A live key is the same surface pointed at real value. The same POST /api/v1/invoices call you tested now produces an invoice a customer can actually pay; the same payout body now debits a real balance. Nothing about your integration changes. The endpoints, the request bodies, the idempotency_key you send, the invoice.paid and payout.completed events you handle — all identical. Only the credential changes, and what it's allowed to touch.
KYB is the gate on that second key. Until verification completes, a live key cannot be issued to settle a deposit or release a payout. That gate is the entire point of verifying a business up front: it is the boundary between test data and real money, drawn before any real money is in play.
What the process actually involves
KYB is a process, not a form, so I won't hand you a document checklist — the specifics depend on your entity, your jurisdictions, and your risk profile, and they get settled in the onboarding conversation where someone can look at your particular case. Any post promising you the exact set of documents is either guessing or describing one provider's snapshot that won't survive contact with your situation. The honest answer to "what do I need" lives where it can be tailored: what you need for KYB onboarding.
What I can describe is the shape. At a high level the process establishes three things:
- That the business is real — registered, identifiable, and what it claims to be.
- Who controls it — tracing ownership through any holding structure down to the natural persons who ultimately own or direct it, and verifying those individuals.
- That the activity is in scope — that what you do, and where you do it, is something the rail can support.
The depth scales with risk. A single-jurisdiction online store and a multi-region, higher-risk operation are not assessed the same way, and a provider that ran them through an identical checklist would be doing the check badly. The deeper guide on how this fits the build is crypto payment KYB, which walks the process end to end without pretending it's a fixed form.
The sequence that works
Here is the assumption that costs teams a launch week: that KYB and engineering run in series, with the build idling behind the paperwork.
They don't run in series, and designing as if they do is the mistake.
Because the sandbox key talks to the same API as production, you can build the entire integration while verification is in progress. Concretely, in parallel with KYB you can and should:
- Wire up invoice creation and confirm the fiat-anchored and fixed-asset shapes both behave the way your pricing expects.
- Render hosted checkout, or your own surface against the API, and walk an invoice from creation through
invoice.confirmingtoinvoice.paid. - Handle the events you'll actually see in production — including
invoice.overpaid,invoice.underpaid, andinvoice.expired— instead of only the happy path. - Get webhook signature verification right: verify the HMAC over the raw bytes before you act on any event. This is the single most common thing teams leave for "later" and then rush under a live key.
- Exercise the payout path, including the pending-approval gate, so the first time someone clicks "release" it isn't also the first time you've seen the flow.
None of that needs a verified business behind it, because none of it moves real money. So the order is boring and fast: build against the sandbox now, run KYB in parallel, swap the key when both are done. Going live becomes a credential swap — the same endpoints and the same request bodies start carrying real balances the moment the live key is in play. The full ordered version of this is the sandbox-to-production checklist; the short version is: don't let KYB sit on your critical path when it doesn't belong there.
Keep the language honest
One precision point, because compliance copy rots when the words get loose.
Completing KYB does not make your business "licensed" or "regulated," and it does not make the provider those things either. Those are regulatory statuses with specific legal meaning. KYB is a verification step — something a provider does, not a status anyone holds. A provider that has run KYB on you has checked who you are; it has not handed you, or itself, a regulatory standing. If a payment provider's marketing blurs that line, treat it as a warning rather than a feature.
The same goes for responsibility. KYB doesn't absorb your obligations. Whether your activity is permitted where you operate, what you must report, and whether you need a licence of your own — those stay with you. The provider verifies the business and keeps an accurate, attributable record of money movement; it doesn't substitute for advice from someone qualified to give it.
What "going live" looks like on the day
When verification completes and the live key is issued, the change on your side is small by design. You rotate the credential, point your integration at it, and create one real invoice for a small amount to confirm the round trip: deposit, confirmation, invoice.paid, settled balance. Then one real payout through the pending-approval gate, so you've seen an operator release real funds before anyone is depending on it. If the sandbox work was done honestly, both pass on the first try, because they're the same calls you already ran a hundred times.
That is the whole promise of doing it in this order. KYB ran in the background while you built. The gate it guarded opened the moment both were ready. And going live turned out to be a key rotation and two confirming transactions — not a rebuild, and not the surprise that eats your launch week.
None of this is legal advice. Where a question turns on what is lawful for your specific business, the answers come from the onboarding conversation, where the details can actually be assessed, and from your own counsel.