Casino
Casino events are ideally sent on the FT CRM Integration API when Operator works with a casino product.
♣️ Real-Time Events You Can Send
FT CRM will process the raw data feed of events and construct game rounds, game sessions and relevant segmentation data based on this.
RabbitMQ Connector
Kafka Connector
REST API
RabbitMQ Message Properties
key | value |
type | CASINO |
The type is expected as a property (but not in the payload) of the RabbitMQ Message. Any header will be ignored.
Kafka Message Headers
type | CASINO |
⬆️ POST /v1/integration/casino
Business Rules:
- The Bet event is sent once a bet is placed.
- The Win event is sent upon a win occurring.
- The Bet and Win events are to be sent as separate events.
- If a bet does not result in a win, you can send a loss event or a win with an amount of 0 to close the round.
Example Payload - Bet
Example Payload - Win
Example Payload - Loss (Greco)
Data Type
amount = wager_amount + bonus_wager_amount + locked_wager_amount
Required properties are marked with *
Key | Type | Description |
activity_id * | string | Unique ID for each event |
amount * | float | The total amount (bonus_wager_amount + wager_amount + locked_wager_amount) |
balance_after | float | Player balance after the round is finished |
balance_before | float | Player balance before the round started |
bonus_wager_amount | float | Amount (either bet or win) if the round was played using bonus money |
currency * | string
Format: ISO 4217 | Transactions currency |
exchange_rate * | float | Exchange rate |
game_id * | string | game_id identifies the specific casino game where the bet or round took place. It allows operators to track player activity per game and analyze patterns or behaviors associated with specific games. Fast Track will associate this game_id with player behavior, so it is important that it is sent in a consistent and unique format. |
game_name * | string | game_name represents the name of the casino game where the bet or round occurred.
Fast Track will map all game_name values received in the events, so it is important that they are sent in a consistent and unique format, following the standard industry naming for the game. |
game_type * | string Accepted Values:
| If "Live Casino", "Table" or "Slots" are being used, ensure to send the values as specified. If any other game type is being used, any other string is accepted. |
is_round_end | boolean | Is the round ended? |
locked_wager_amount | float | Amount (either bet or win) if the round was played using money from a "locked" wallet (when bonus and real money is combined) |
origin * | string | The origin of the user |
round_id * | string | Send same for Bet & Win |
status * | string
Accepted Values:
| Indicates whether the event should be reversed or not. |
timestamp * | date
Format: RFC3339 | Timestamp |
type * | string
Accepted Values:
| The type of bet placed |
user_id * | string | The user id |
vendor_id * | string | vendor_id identifies the game provider or studio that supplies the casino game. Please ensure it is sent in a consistent and unique format across all events. |
vendor_name * | string | vendor_name represents the name of the game provider or studio that supplies the casino game. Fast Track will map all vendor_name values received in the events, so it is important that they are sent in a consistent and unique format, following the standard industry naming for the provider. |
wager_amount | float | Amount (either bet or win) if the round was played using real money. |
user_bonus_id * | string | Unique identifier of the bonus credited to a player. If there is no bonus wager in this round, send by 0 by default. |
is_free_money | boolean | Indicates whether or not the transaction is made using a free to play wallet, such as Gold Coins or any other virtual currency.
If the property is not included in the payload it will default to false |
meta | object | Used for misc/aux values that is brand specific. |
Crypto Implementation
When implementing Casino Events for crypto casino transactions, the following fields must be sent within the meta tag:
Sequence of Events
The events are sequence sensitive. Below you will find different scenarios on how the sequence of events should take place.
Scenario A - Casino Events (entire round)
Casino Event - Bet
First we should receive a Casino Event with Type Bet with round_id set as 12345
Casino Event - Win / Loss
We should then receive a Casino Event with Type Win or Loss with round_id set as 12345
Scenario B - Casino Event with Bonus Crediting
Bonus Event - Created
First we should receive a bonus event with Status as Created and user_bonus_id set as ABCD . It is important that Timestamp of this event is the earliest.
Casino Event (entire round)
We should then receive a casino event with user_bonus_id set as ABCD . It is important that Timestamp of this event after the timestamp of the Bonus Event Created. This would reflect Scenario A.
Bonus Event - Closure
We should then receive a bonus event with user_bonus_id set as ABCD , Status set to anything apart from Created, and a timestamp after the timestamp of the last Casino Event.