Overview

The casino deposit API lets a player fund a casino account with cryptocurrency. ByteFederal quotes the deposit, gives the player an address, watches the blockchain, screens the funds and settles the casino in US dollars. Your platform decides whether to accept each deposit or send the crypto back.

Who does what

Party	Role
ByteFederal	Verifies the player's identity (KYC) by SMS link. Quotes the deposit and assigns a deposit address. Holds the crypto that arrives. Watches the blockchain and reports each confirmation. Runs KYT (blockchain risk) screening and OFAC screening of the addresses that funded the deposit. Sends the crypto back when a deposit is returned. Settles accepted deposits to the casino in US dollars by ACH.
BurraPay's platform	The API client. Holds the API key, creates deposits, reads them, and accepts, returns or freezes them. Receives webhooks unless a casino has its own webhook URL.
The casino	An entity under BurraPay's account, identified by entity_id. Credits the player's balance once a deposit is accepted. May receive webhooks directly at its own webhook URL.

A few terms used throughout these pages:

• entity_id identifies one casino.
• gambler_ref is the casino's own identifier for the player. ByteFederal ties KYC to it, per casino.
• deposit_id identifies a deposit in every casino endpoint. transaction_id identifies the underlying payment and appears alongside it.

One deposit, end to end

1. Your platform creates a deposit for a player. The first deposit for a new gambler_ref returns kyc_required instead of an address, and ByteFederal texts the player a verification link. See Player KYC.
2. The player sends the quoted amount to the address. Show the player a 15-minute window; ByteFederal honors a payment until expires_at, 30 minutes after creation. See Expiry and late payments.
3. ByteFederal sends webhooks as the deposit moves: deposit.received when the payment is seen on-chain and deposit.confirmed at the first confirmation.
4. ByteFederal screens the deposit. ofac_complete reports the OFAC result. kyt_complete reports the KYT result.
5. Every deposit webhook and every deposit read carries an acceptable flag. When it is true, your platform may call accept.
6. Your platform accepts or returns the deposit. deposit.accepted or deposit.returned follows.

The screening events do not arrive in a fixed order. They come from separate processes, and some deposit types are screened before confirmation. Handle each event on its own and do not wait for a particular sequence. Deposit lifecycle covers every status and event in detail.

A deposit can also be frozen, either by your platform or by ByteFederal when screening fails. See Accept, return and freeze.

Base URL

All requests go to:

https://quinix.byteconnect.us

Requests and responses are JSON over HTTPS. Every casino endpoint authenticates with an API key in the X-API-Key header. See Authentication.

Environments

There is one environment: production, on mainnet. There is no sandbox and no testnet.

To test, use a test-mode API key and small amounts of real crypto. Test mode only keeps deposits out of US dollar settlement. Addresses, payments, confirmations, screening and returns are all real. See Live and test mode and Testing.

Where to go next

• Quickstart: check your key, send a test webhook, run one small deposit.
• Authentication: API keys, entity-scoped keys, live and test mode.
• Deposit lifecycle: statuses, events and when a deposit is acceptable.
• Player KYC: what happens the first time a player deposits.
• Create a deposit and Read deposits.
• Accept, return and freeze.
• Webhooks and Webhook events.
• Errors.
• Testing and Going live.