Skip to content
Ledgerline Help

Going live checklist

Updated 13 September 20263 min read

On this page

Moving from the sandbox to live changes real balances, so do it deliberately. This checklist covers what has to be approved, what to switch and what to verify on the first day.

1. Get your business approved

You cannot create live keys until business verification (KYB) is approved. Reviews take 1 to 2 business days, up to 5 for enhanced due diligence, so submit early. You can finish your integration in the sandbox while the review runs.

2. Accept the agreement and choose a plan

The authorized signer accepts the Ledgerline agreement in the dashboard. Choose a plan that fits your volume and payout limits. Starter is free, so many teams go live on it and upgrade later. See Plans and pricing.

Pick your data region before you create the live organization data, because it cannot be changed afterwards without a migration. See Data residency and retention.

3. Switch the configuration

Setting Sandbox Live
Base URL https://sandbox.api.ledgerline.dev/v1 https://api.ledgerline.dev/v1
API key ll_test_sk_... ll_live_sk_...
Webhook endpoint Sandbox endpoint A separate live endpoint, with its own whsec_ secret
Counterparties Test bank accounts Real accounts, verified by micro-deposit or prenote

Create live keys in the dashboard under Developers > API keys. Store them in your production secrets manager, and prefer restricted keys with an IP allowlist where your plan has one.

Keep the environments from leaking into each other: derive the base URL from the key prefix, or fail at startup if they disagree.

4. Pre-launch checks

  • Every POST sends an idempotency key that is stable across retries.
  • Retries follow the backoff guidance and honor Retry-After.
  • Webhook handlers verify the signature, deduplicate on event.id and tolerate out-of-order delivery.
  • You handle payout.failed and payout.returned, not just payout.paid. See Returns and failed payouts.
  • Your error handling branches on error.code, with a request_id logged for each failure.
  • You stay under 600 requests per minute per key, with headroom. See Rate limits.
  • Amounts are integers in minor units, including the zero-decimal yen.
  • No keys are in source control or client-side code.

5. Verify bank accounts early

Real micro-deposits take 1 to 2 business days to arrive, unlike in the sandbox. Verify your own funding and payout accounts a few days before launch so the first payout is not blocked by counterparty_unverified.

Remember that the first payout above $25,000 to a counterparty younger than 7 days is held for review, usually for up to 4 business hours. Warn the people who will make the first payments.

6. Fund and test with a small amount

  1. Create a virtual account for your funding ledger account and send a small real payment to it.
  2. Wait for the transaction.posted event and confirm the balance.
  3. Make a payout of a small amount to a bank account you control and watch it reach paid.
  4. Check the entry in your next reconciliation run.

7. Monitor from day one

  • Subscribe to the status page so you know about incidents before your customers do.
  • Alert on webhook delivery failures and rising 5xx counts.
  • Track Ledgerline-RateLimit-Remaining to spot a runaway job.

What does not carry over

Nothing in the sandbox is copied to live: not ledgers, accounts, counterparties or webhook endpoints. Create them again, ideally with the same script you used to set up the sandbox. Treat your setup as code so it can run against both environments.

Tip

Put the ledger structure (ledgers and accounts) in a version-controlled script that is safe to run twice, using external_id and idempotency keys. You will be glad of it when you add a second region.