Sportsbook Data Feed: How Result Settlement Works End to End
Settlement errors directly impact player payouts. WSGaming explains how result settlement data flows from official sources through the sportsbook data feed to your platform — and the five event types every handler must process correctly.
Step 1: Official Result Confirmation
Settlement begins when the official data source confirms a result. For football, this is typically 2–3 minutes after full-time — accounting for injury time confirmation and VAR review resolution. Your sportsbook data feed should receive the official result from a primary data provider with direct league agreements, not from a secondary aggregator who adds another delay step.
WSGaming sources settlement data directly from primary providers for all covered leagues. Result delivery latency from official confirmation to your platform webhook is under 90 seconds for standard match results.
Step 2: Market Resolution Processing
When the result arrives, the settlement engine resolves each open market independently. A single match generates multiple markets — match winner, Asian Handicap, Over/Under, halftime result, first goalscorer — each with different resolution logic. AH resolution in particular requires careful handling of quarter-ball void conditions (0.25 handicap: half the stake wins, half pushes) that many settlement engines handle incorrectly.
WSGaming’s settlement engine processes AH void conditions natively, including split-outcome scenarios that generic settlement systems get wrong. First-delivery settlement accuracy for covered leagues exceeds 99.8%.
The Five Settlement Event Types
- Win — bet won; payout = stake × odds at acceptance time
- Loss — bet lost; stake forfeited
- Void — market voided (abandoned match, data error); stake returned
- Push — AH exact-line result; stake returned (not void — different handling required)
- Amended — initial settlement corrected after delivery (VAR goal disallowed after initial confirmation)
Push and Amended are the settlement types that produce payout errors most often. Push must NOT be handled identically to Void — they have different player-facing implications and different compliance audit requirements. Amended requires reversing the original settlement and applying the new outcome — not processing as a new event.
Accumulator Settlement Logic
Accumulator settlement requires processing each leg sequentially and updating the running return after each leg resolves. A void leg reduces the parlay by one leg (a 5-leg parlay with one void becomes a 4-leg parlay) — not voiding the entire bet. WSGaming’s webhook includes accumulator leg state data in each settlement message, allowing correct partial settlement without reconstructing the full accumulator from your database.
| Settlement Type | Payout Logic | Common Error | WSGaming Handling |
|---|---|---|---|
| Win | Stake × acceptance odds | Over/under-payment on AH odds | AH-native calculation |
| Loss | Zero payout | Double debit from duplicate webhook | Idempotency key |
| Void | Stake returned | Confused with Push | Separate event types |
| Push | Stake returned (half on 0.25 AH) | Full void instead of half-push | AH split-outcome native |
| Amended | Reverse + reapply | Not detected — original stands | Amendment flag in message |
Key Takeaways
- Settlement from primary sources (not aggregators) is the foundation of accurate result processing
- AH quarter-ball push requires native settlement logic — generic engines get this wrong
- Push and Void must be separate event types — same handling causes compliance and payout errors
- Accumulator void-leg must reduce leg count, not void the entire accumulator
- WSGaming’s settlement webhook includes accumulator leg state data for correct multi-leg processing
Review WSGaming’s Settlement Architecture
Our integration team walks you through AH split-outcome handling and amended settlement management before go-live.
Review Settlement DocsView Sportsbook Data Feed