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:

  1. The Bet event is sent once a bet is placed.
  2. The Win event is sent upon a win occurring.
  3. The Bet and Win events are to be sent as separate events.
  4. 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
game_name *
string
Game Name
game_type *
string
​
Accepted Values:
  1. Live Casino
  2. Table
  3. Slots
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:
  1. Approved
  2. Rollback
Indicates whether the event should be reversed or not.
timestamp *
date Format: RFC3339
Timestamp
type *
string Accepted Values:
  1. Bet
  2. Win
  3. Loss
The type of bet placed
user_id *
string
The user id
vendor_id *
string
Vendor Id
vendor_name *
string
Vendor Name
​
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.
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.