Integration with slot providers, live casinos, betting
Introduction
The integration of third-party providers is the basis of the extensibility of online casinos. Slots, live casinos and sports betting are handled by different APIs and architectural patterns, but on the platform they must all obey the same logic of sessions, transactions and accounting.
1. Common integration architecture
1. Integration Layer
Responsible for all calls to providers and normalization of responses to a single format.
Exposes unified endpoints '/api/games/spin ', '/api/live/join', '/api/sports/place-bet '.
2. Metadata normalization
Bringing provider's' gameId ',' eventId ',' odds', 'winAmount' to a common JSON template.
Categorization by type: 'slot', 'live', 'sport'; The provider label for the audit.
3. Event Bus
Kafka/RabbitMQ for asynchronous event delivery: 'SpinRequested', 'SpinResult', 'LiveRoundStart', 'BetPlaced', 'BetSettled'.
2. Slot integration
1. REST/JSON-API or SDK
Endpoints:
The platform creates a 'sessionId' and passes it to the provider to link the request and response.
Storage of session and results in Redis with TTL = 5 min.
3. Safety
HMAC signature of requests, nonce and timestamp.
TLS-pinning for REST messages.
3. Live casino integration
1. WebSocket and video streaming
Two parallel links:
JSON messages:
A timecode is inserted into each video frame; WebSocket messages are bound to the timecode to avoid out of sync.
4. Failover и Recover
Automatic failover, re-authorization via 'sessionId'.
4. Integration of sports betting
1. Odds API и Event Feed
Subscription to real-time event feed: 'eventCreated', 'oddsChanged', 'eventSuspended', 'eventFinished'.
Formats: JSON-feeds by WebSocket or SSE.
2. Betting
`POST /sports/bet` → `{ eventId, marketId, selectionId, stake }`
Provider returns' betId ',' acceptedOdds', 'potentialPayout'.
3. Calculation of winnings
After closing the event: 'eventResult' → '{betId, outcome, payout}'.
The platform tests accepted odds against actual ones to avoid arbitration.
4. Risk management
Limits on maximum rates and exposure per market/event.
Real-time monitoring of aggregate liabilities and the possibility of autocashing/suspension.
5. Accounting and calculations
1. Transactional microservice
ACID transactions for rate reservation, debiting and crediting.
CQRS model: commands to change the balance, projections for reading.
2. Audit Trail
Logs of all provider calls, bets and results with the fields' tenantId ',' providerId ',' sessionId '.
6. Monitoring and alerting
1. Metrics
Latency: `spin_request_latency`, `bet_request_latency`, `live_round_latency`.
Error rate: `spin_error_total`, `bet_declined_total`.
2. Dashboard
Grafana by provider and game type.
Alert if p95-latency> 300 ms or errorRate> 1%.
7. Fault tolerance and scaling
1. Chorizontal scaling
Stateless HTTP and WebSocket services in Kubernetes with HPA over QPS and WebSocket connections.
2. Caching
Redis for game metadata and current coefficients.
3. Circuit Breaker и Retry
Resilience4j/Hystrix for provider calls with exponential backoff.
Conclusion
A single platform for slots, live casinos and sports betting is built around an integration layer that normalizes various API providers into a single flow of sessions, transactions and settlements. The WebSocket architecture for live games, REST/SDK for slots and real-time feed for bets are complemented by microservices for accounting, monitoring and fault tolerance, which ensures reliability and scalability.
The integration of third-party providers is the basis of the extensibility of online casinos. Slots, live casinos and sports betting are handled by different APIs and architectural patterns, but on the platform they must all obey the same logic of sessions, transactions and accounting.
1. Common integration architecture
1. Integration Layer
Responsible for all calls to providers and normalization of responses to a single format.
Exposes unified endpoints '/api/games/spin ', '/api/live/join', '/api/sports/place-bet '.
2. Metadata normalization
Bringing provider's' gameId ',' eventId ',' odds', 'winAmount' to a common JSON template.
Categorization by type: 'slot', 'live', 'sport'; The provider label for the audit.
3. Event Bus
Kafka/RabbitMQ for asynchronous event delivery: 'SpinRequested', 'SpinResult', 'LiveRoundStart', 'BetPlaced', 'BetSettled'.
2. Slot integration
1. REST/JSON-API or SDK
Endpoints:
- 'GET/slots/list '→ metadata (RTP, volatility, limits).
- `POST /slots/{id}/spin` → `{ sessionId, betAmount }`
- `GET /slots/{sessionId}/result` → `{ symbols, payout, balance }`
- 2. Sessions and stateful model
The platform creates a 'sessionId' and passes it to the provider to link the request and response.
Storage of session and results in Redis with TTL = 5 min.
3. Safety
HMAC signature of requests, nonce and timestamp.
TLS-pinning for REST messages.
3. Live casino integration
1. WebSocket and video streaming
Two parallel links:
- Video stream (RTMP/WebRTC via CDN-edge)
- Control channel by WebSocket for betting and round status.
- 2. Message protocol
JSON messages:
- `joinTable`: `{ tableId, playerId, token }`
- `placeBet`: `{ roundId, betType, amount }`
- `roundResult`: `{ roundId, outcome, payouts[] }`
- 3. Synchronize videos and bets
A timecode is inserted into each video frame; WebSocket messages are bound to the timecode to avoid out of sync.
4. Failover и Recover
Automatic failover, re-authorization via 'sessionId'.
4. Integration of sports betting
1. Odds API и Event Feed
Subscription to real-time event feed: 'eventCreated', 'oddsChanged', 'eventSuspended', 'eventFinished'.
Formats: JSON-feeds by WebSocket or SSE.
2. Betting
`POST /sports/bet` → `{ eventId, marketId, selectionId, stake }`
Provider returns' betId ',' acceptedOdds', 'potentialPayout'.
3. Calculation of winnings
After closing the event: 'eventResult' → '{betId, outcome, payout}'.
The platform tests accepted odds against actual ones to avoid arbitration.
4. Risk management
Limits on maximum rates and exposure per market/event.
Real-time monitoring of aggregate liabilities and the possibility of autocashing/suspension.
5. Accounting and calculations
1. Transactional microservice
ACID transactions for rate reservation, debiting and crediting.
CQRS model: commands to change the balance, projections for reading.
2. Audit Trail
Logs of all provider calls, bets and results with the fields' tenantId ',' providerId ',' sessionId '.
6. Monitoring and alerting
1. Metrics
Latency: `spin_request_latency`, `bet_request_latency`, `live_round_latency`.
Error rate: `spin_error_total`, `bet_declined_total`.
2. Dashboard
Grafana by provider and game type.
Alert if p95-latency> 300 ms or errorRate> 1%.
7. Fault tolerance and scaling
1. Chorizontal scaling
Stateless HTTP and WebSocket services in Kubernetes with HPA over QPS and WebSocket connections.
2. Caching
Redis for game metadata and current coefficients.
3. Circuit Breaker и Retry
Resilience4j/Hystrix for provider calls with exponential backoff.
Conclusion
A single platform for slots, live casinos and sports betting is built around an integration layer that normalizes various API providers into a single flow of sessions, transactions and settlements. The WebSocket architecture for live games, REST/SDK for slots and real-time feed for bets are complemented by microservices for accounting, monitoring and fault tolerance, which ensures reliability and scalability.
