Skip to content

Industries · iGaming & betting

Crypto payments for iGaming and betting platforms

Player deposits credited after enough confirmations to act on safely — not on a single block — screened before they touch a balance, and swept to your treasury automatically. Suward is built for platforms where a deposit isn’t a checkout — it’s the start of a session. At the same flat 0.4% as every other merchant.

Building a video game or selling in-game items? Video games & virtual economies

Pains, closed by mechanisms

The four problems every operator knows

01

“We credited a deposit that vanished in a reorg.”

A player deposits, gets credited on one block confirmation, bets instantly — and the chain reorganizes. With Suward, no deposit is credited on a single block: balances are credited at Accepted, when enough confirmations have accumulated to act safely, and withdrawals unlock at Success, when the deposit is irreversible. If the chain rewrites, affected deposits are re-verified automatically while they are still confirming — the checks finish before the player is credited, not after.

How settlement works

02

“Card acquirers treat us as radioactive.”

High-risk MCC codes mean high fees, rolling reserves, and sudden offboarding. Crypto deposits don’t route through an acquirer that can drop you — and Suward’s rate is 0.4%, not a high-risk premium.

Pricing

03

“Crypto deposits create AML exposure.”

Every incoming deposit is screened before it is credited — sanctioned jurisdictions are blocked automatically, and deposit patterns are monitored continuously. Basic screening is included in the rate; platforms with regulator-grade requirements can pin Extended screening — independent blockchain-analytics verification, $0.45 minimum per payment — across the whole organization.

Compliance

04

“Thousands of deposits mean an ops team just for sweeping.”

Each player gets a permanent deposit address; funds move to your treasury by auto-withdrawal rules; manual payouts run under 2FA and role-based access. Volume grows, headcount doesn’t.

Deposit → play → payout

01

A player opens the cashier and gets their personal deposit address — the same one every time, saved in their wallet.

02

They send any amount in the stablecoins or major cryptocurrencies you allow for the wallet.

03

Screening runs while the deposit is pending; at Accepted, a signed webhook tells your backend to credit the balance — and the player is playing.

04

Meanwhile your treasury rule sweeps cleared funds to your own wallet.

05

Payout requests go through your normal flow, with on-chain withdrawals executed under two-factor auth and role separation.

Typical scenario

How it runs on a live platform

The mode built for this isStatic Wallets

For the rest of the committee

Pages to forward to your team

If you’re introducing Suward internally: a flat 0.4% with compliance included, every deposit screened before it is credited, two-stage finality — act on Accepted, withdraw at Success — and withdrawals under 2FA and role-based access. Every claim is verifiable on the pages below.

For your CTO

The settlement model, reorg handling, and signed webhooks — /settlement, /developers, and the full docs.

For your CFO

The complete price math — a flat 0.4%, no monthly fee, quoted network and withdrawal fees — /pricing.

For compliance

The screening pipeline and levels, jurisdiction blocking, and program details — /compliance.

Walk us through your cashier flow

Deposit limits, bonus rules, payout policies — every operator’s flow is different. Talk to us and we’ll map Suward onto yours.