Skip to content

Player API Betting Flow

When an operator decides to integrate with the Gamnify's Player API, either directly or through the Gamnify's Full integration solution, a very similar workflow is used. Additionally, the workflow for all the product suites (scheduled sports, instant sports, games, etc), follow a similar structure.

In this page we don't go into the product specifics, but rather the main workflow and integration points between the operator and Gamnify.

Typical flow


sequenceDiagram
    actor Player
    participant Operator Website
    participant PAM
    participant Gamnify API
    participant Settlement

    Player->>+Operator Website: login(u, p)
    Operator Website->>+PAM: getToken(u, p)

    PAM->>-Operator Website: token


    Operator Website->>-Player: storeCookie(token)


    Player->>+Gamnify API: placeBet(bet, token)
    activate Player
    activate Gamnify API
    Gamnify API->>PAM: getUserDetails(token)
    note over Gamnify API: Done first time token is seen. 
    PAM->>Gamnify API: return(userData)
    Gamnify API->>Gamnify API: store(userData)

    Gamnify API->>+PAM: createTransaction (txDebitRequest, token)
    PAM->>PAM: verifyToken(token)
    note over PAM: The token is verified by the operator
    PAM->>Gamnify API: return (txResponse)

    Gamnify API->>+Gamnify API: recordBet(bet)
    Gamnify API->>+Activity Search: storeActivity(bet, txResponse)

    deactivate Gamnify API
    Gamnify API->>-Operator Website: return(betResponse)

    Operator Website->>Player: showBetConfirmed
    deactivate Player


    note over Settlement: Settlement will pay once results are in 
    activate Settlement
    Settlement->>+PAM: createTransactions(txCreditRequest)
    note over PAM: Note that no token is sent in this case
    PAM->>-Settlement: txResponse
    Settlement->>Activity Search: updateActivity(bet, txResponse)

    deactivate Settlement



Wallet Logic

The following diagram shows the logic that we expect from the Operator's PAM


flowchart TD
    CTX[CreateTx] --> TXE{Tx Exists?}
    TXE --> |Yes| TXEY(Return Existing Transaction)
    TXE --> |No| RR{Is Reversal?} 
    RR --> |Yes| RRE{Original Tx Valid?}
    RRE --> |Yes| TXEN
    RRE --> |No| RREERR[Return Invalid Original Tx]
    RR --> |No| TXEN{TxType?}

    TXEN -->|Debit| DTX{Has Balance?}
    TXEN -->|CreditReversal| RB
    TXEN -->|Credit| IB[Increase Balance]
    TXEN -->|DebitReversal| IB


    DTX --> |No| NOF[Return Insufficient Funds]
    DTX --> |Yes| RB[Reduce Balance]

    RB --> CCTX[Create Transaction]
    IB --> CCTX
    CCTX --> R{Is Reversal?}
    R --> |Yes| CncTx[Flag Old Tx]
    R --> |No| RTTX[Return Tx]
    CncTx --> RTTX

Key points:

  • CreditReversal and DebitReversal types are assumed to be the reversals. The ReservedId should always be filled for these transaction types.
  • We expect that in the majority of cases we will have Credit and Debit calls only. The reversals are used only during reconciliation.
  • The system is idempotent on the Gamnify's Transaction Id (PlatformTxId). In the unlikely event that Gamnify calls the operator's PAM to create the same transaction multiple times, the operator is expected to merely return the original transaction.
  • When reversals are involved, we need to validate that the original transaction: 1. Exists 2. Is a valid transaction (i.e. if a CreditReversal is issued, then original transaction needs to be of Credit type) 3. Pertains to the same user as the original transaction.
  • The step "Flag Old Tx" is optional, as we understand that wallet systems might be immutable.
  • There exists an edge case with CreditReversal whereby Gamnify will ask from money to be debitted but the player has already spent the funds. It is up to the operator to decide whether to put the balance in negative (not recommanded due to potential regulatory problems) or just take the available funds. It is expected that whatever amount has been taken is reflected in the BalanceAfterTx field.