How It Works

End-to-End Flow

Challenge Lifecycle

A challenge can end in three ways:

• Completed: balance reached target, minimum bets placed, minimum active days met
• Failed - expired: duration ran out before reaching target
• Failed - drawdown: total loss exceeded the drawdown limit
• Failed - insufficient days: target reached but not enough active betting days

After failure, the user can immediately purchase a new challenge.

Bet Validation Flow

Reward Account

After passing the challenge the user chooses to continue; on continuation FAST creates the Reward Account:

• Balance starts at the configured funded amount (e.g., 5,000 EUR)
• User bets with this balance, profits accumulate
• Gross profit = virtual balance (ledger less open stake) - funded amount. Everything before an executed payout is virtual
• A payout takes any part of the gross profit: the user is paid the profit split of it and that gross amount leaves the balance. The rest stays on the balance; nothing resets
• No minimum active days or bets in this phase. Optional minimum payout, gap between payouts, per-payout and lifetime caps, and max number of payouts (the last one takes everything and closes the account)
• The first payout must be requested within the tier's deadline (30 days by default on new tiers), or the account ends
• Revoked if the drawdown limit is breached
• The own stake is returned on the first funded withdrawal. The bonus is never withdrawable (only profit above the funded base is).

Two Integration Modes

Sync mode: Your backend calls /bets/validate before accepting each bet. FAST returns accept/reject immediately with reason codes. You block or allow the bet based on the response.

Async mode: Your backend sends all bet events to /bets. FAST accepts with 202 and processes in the background. Rejected bets are silently ignored - no impact on your betting flow.

Most operators start with sync mode for tighter control, then switch to async once confident in the integration.