01AssignedThe chain sees an address. You see PLY-1842.
Attach a reusable deposit address to the player reference your platform already uses. The demo keeps that reference attached to every later state.
Payment operations for iGaming01
Every
deposit,
matched to
a player.
Player-linked deposit addresses, branded collection, one operator balance and payout workflows—connected by one traceable event trail.
- Player
- PLY-1842
Payment- PAY-8F31C
Environment- Read-only demo
Live routing surface
Payment options routed at checkout
Checkout shows the options available for that customer, amount and currency. Availability varies by location, provider status and account configuration.
- Stripe
- PayPal
- Robinhood
- Revolut
- Topper
- Transak
- Binance Connect
- Banxa
- Blockchain.com
- Particle
- Cash App
- Sardine
- Simplex
- Klarna
- iDEAL
- UPI / IMPS
Provider routes
01 / The payment thread
One player reference. All the way through.
Payfux connects the address a player pays, the balance your cashier sees, and the event your platform receives. Follow one illustrative deposit from assignment to reporting.
01Assigned
02CollectedThe payment enters one traceable route.
Card and crypto collection can feed the same operating thread. Payment methods, assets and networks remain explicit instead of being hidden behind a generic balance.
03ResolvedMany routes. One cashier view.
Resolve the player, payment and settlement references in one ledger view so operations can follow the movement without piecing together separate tools.
04ReportedThe same reference comes back.
A signed event can return the player and payment context to your platform. Exact event behavior is confirmed against the integration documentation for your setup.
Illustrative Payfux player-address view with demo player PLY-1842 selected. Illustrative card payment routed through Payfux toward a stablecoin destination. Illustrative card and crypto routes converging into one Payfux operator ledger. Illustrative Payfux API, event stream and webhook receipt carrying one demo payment reference.
02 / Branded collection
Your player never sees the machinery.
Present the payment experience in your brand while keeping method selection, payment context and the return flow attached to the same operator thread.
View the demo checkout
03 / Operator proof
No block explorer required.
Search the player reference, open the payment, and inspect amount, state, destination and event history from the same cashier workspace.
Explore the operator demo
PLY-1842PAY-8F31CSTL-18491
04 / Developer handoff
The same reference comes back.
Request an address against the identifier you already use. Then handle the signed deposit event carrying that identifier back to your platform.
Open integration docs
REQUEST
POST /v1/gateway/end-users/PLY-1842/addressEVENT
deposit.confirmed · end_user_ref: PLY-1842Conceptual excerpt. Confirm exact request and event shapes in the current API docs.
05 / Before integration
The practical questions.
Risk-adapted onboarding for complex digital businesses. Requirements vary by product, jurisdiction, transaction profile, and risk.
Onboarding is risk-adapted. Requirements vary by product, jurisdiction, transaction profile, and risk, and are confirmed during integration review.
Settlement moves through visible states — queued, then completed — and the timeline for each payment is shown in the operator view. Timing depends on payment method, network conditions and review status.
Supported assets and networks are confirmed per operator during onboarding. The examples on this page use demo data and do not represent a supported-asset list.
The demo assigns a reusable deposit address to one player and keeps its attribution trail attached to that account. Product terminology and availability are confirmed during onboarding.
The demo checkout on this page collects no card data. The production card-data boundary and integration model for a given setup are confirmed during integration review.
No. Yield is variable and not guaranteed. Product availability, counterparties, liquidity, lock-up and risk vary by jurisdiction and program.
Bankroll capacity is optional and for qualified operators. Terms, eligibility and the risk model vary and are agreed individually.
Refund and chargeback handling depends on the payment method and is confirmed during integration review. This demo does not state that a particular exception flow is supported.
Availability varies by jurisdiction and product. Coverage for your business is confirmed during onboarding.
See the complete thread
Follow one deposit all the way through.
Start with the read-only product, then use the integration docs to inspect the address and event model.
