Going live

Each casino is set up by ByteFederal before it can take deposits. This page lists what BurraPay sends ByteFederal for a new casino, what ByteFederal sends back, and what to check before real players use it.

What BurraPay sends ByteFederal

Send these for each new casino.

Item	Required	What ByteFederal does with it
Legal name	Yes	Becomes the casino's name. It appears as name in the key check.
External code	Recommended	The code the casino wants in payloads. It appears as entity_external_code in every webhook and as external_code in the key check. Without it, entity_external_code is null.
Webhook URL and secret	Only if the casino receives webhooks directly	Set on the casino. Its events then go to this URL, signed with this secret, instead of to BurraPay's webhook URL. Send both together: a URL without a secret means the casino's events are sent unsigned. The URL must answer directly; redirects are not followed.
Timezone	Recommended	An IANA name such as America/New_York. Dates in the casino's fee schedule are read as wall-clock times in this zone, so a fee change takes effect at the local time agreed in the contract. Without it, ByteFederal's default zone is used.
No-conf deposits	Only if needed	Lets the casino create deposits with "no_conf": true, acceptable before the first on-chain confirmation once KYT passes. Off by default.
Instant deposits	Only if needed	Lets the casino create deposits with "instant": true, acceptable before KYT completes, up to a cap. Needs no-conf enabled too. Off by default. Say what caps the casino needs. The defaults are $500 for a player's first instant deposit and $1,500 once the player has an accepted, confirmed deposit.
Test casino	Only if needed	Marks the casino as test mode, so none of its deposits are settled to the casino. See Test mode.

ByteFederal also sets the casino's fee schedule from the commercial agreement. Until it is set, every create request for the casino fails with 500 Entity fee schedule is not configured for this entity; contact ByteFederal.

What ByteFederal confirms back

Item	Notes
Entity id	The entity_id to send in every request for this casino.
Which API key to use	Either an existing affiliate-wide key, which can act on all of BurraPay's casinos, or a new key locked to this casino. A locked key cannot touch any other casino. See Authentication.
Key mode	live for real players. A test key marks every deposit it creates as test data, even on a live casino.
Casino status	The casino must be enabled to take deposits.

Pre-launch checklist

Configuration

• GET /casino/integration/key, called with the production key, lists the casino.
• The casino's status is enabled.
• Its external_code is the code the casino expects.
• Its webhook.url is the endpoint that should receive its events, and webhook.source matches: entity_override if the casino receives directly, api_key if BurraPay does.
• webhook.signed is true.
• key.mode is live and key.scope is admin.
• key.expires_at is null or far enough away, with a plan to rotate before it.

Webhooks

• POST /casino/integration/test-webhook returns delivered: true for the casino. See Send a test webhook.
• The receiving endpoint verified the signature of that test event, computed over the raw request body.
• The receiving endpoint rejects a request whose signature does not match.
• The receiving endpoint ignores events with "test": true: no credit, no balance change. It still answers 2xx.
• The endpoint answers 2xx within 30 seconds. Slower answers are treated as failures and retried.

Real money

• One real deposit created, funded, and accepted, with deposit.accepted received. See the mainnet walkthrough.
• One real deposit returned to a wallet you control, with deposit.returned received and the funds arrived.

Handler behavior

• Webhook handling is idempotent. The same event can arrive more than once. Processing it twice must not credit the player twice.
• kyt_complete and ofac_complete can arrive again for the same deposit with a new result, for example when a KYT review ends in passed. The handler acts on the latest result.
• Accept is keyed on acceptable: true, not on the order webhooks arrive in.
• A 409 from accept or return is handled by waiting for the next webhook, not by retrying in a loop.
• A retried accept that gets 400 Decision is already 'accepted', cannot accept is treated as success.
• Every API error is logged with its X-Request-ID header. See Errors.

KYC

• status: "kyc_required" and status: "kyc_pending" on create are handled as normal outcomes, not errors. Both are HTTP 200 and create no deposit.
• The player is told to complete the link sent to their phone, using the message from the response.
• The create request is sent again after the player completes verification. It is not retried in a tight loop: the verification SMS is re-sent at most once every 10 minutes.

See Player KYC.