Wallet API
The endpoints need to be implemented by the Operator and made available for Hub88 to call.
Last updated
Was this helpful?
The endpoints need to be implemented by the Operator and made available for Hub88 to call.
Last updated
Was this helpful?
Wallet API is an API to integrate Seamless wallet logic to Hub88. The API works in a manner where Hub88 is the consumer and the Operator needs to provide corresponding endpoints based on the following API structures. Wallet API also has its own response status codes available here.
Provides a player's data. The Operator is expected to return all available details.
/user/info
RSA-SHA256 is used to sign the request body using the private key. The signature is validated using the public key associated with the provided operator_id.
An ID of an action that is generated for each of our calls to the Operator, used to sync Hub88 and Operator sides for debugging purposes, displayed in standard 16-byte UUID format. The Operator has to respond with the same request_uuid as the one received in request.
The unique User ID in the Operator’s system. When generating the value, avoid using any real user data, that could be used to identify the person (e.g. full name, phone, email). Minimum value 4 characters.
Called when the player's balance is needed. The Operator is expected to return player's current balance. The Game code is provided to help the Operator with player's activity statistics.
/user/balance
RSA-SHA256 is used to sign the request body using the private key. The signature is validated using the public key associated with the provided operator_id.
The unique user ID in the Operator’s system. In case of DEMO gameplay, this parameter may be omitted.
An ID of an action that is generated for each of our calls to the Operator, used to sync Hub88 and Operator sides for debugging purposes, displayed in standard 16-byte UUID format. The Operator has to respond with the same request_uuid as the one received in request.
The unique game identifier in Hub88 system in the form of a string. game_code can be obtained from the /game/list endpoint.
The game session token that was passed within /game/url endpoint response.
Called when the User wins (credit). The Operator is expected to increase player's balance by amount and return a new balance. The reference_transaction_uuid is used to show to which bet the win is related to.
Each win has transaction_uuid which is unique identifier of this transaction. Before any altering of User's balance, Operator has to check that win wasn't processed before.
Retry Policy: In case of network fail (HTTP 502, timeout, nxdomain, etc.) we will retry 3 times with 1 sec of timeout. The rest of retry logic is left to provider’s RGS: the retries may continue indefinitely or the bet may be rolled back, and the money returned back to user.
/transaction/win
RSA-SHA256 is used to sign the request body using the private key. The signature is validated using the public key associated with the provided operator_id.
The unique user ID in the Operator’s system. In case of DEMO gameplay, this parameter may be omitted.
The unique transaction identifier. An ID of business logic action (transaction) that <b>needs to be stored</b> on both sides for <b>at least 4 months</b> (for reconciliation purposes). Operator has to respond on each transaction_uuid. An action with same transaction_uuid shouldn't be processed more than once.
The transaction identifier received from the game Supplier. This identifier will be used to investigate any issues via customer support tickets.
The name of the user in the Provider’s system. In case Operator needs to find a user in Provder’s back office or report a problem with the user. If the value is NULL, the Operator can search for their own user_id.
Denotes when the round is closed.
The game round ID used to relate all bets and wins made in one round. All transactions related to the same round have the same value in this field. The ID is not unique through whole system. The value depends on provider’s RGS logic, as it is created from game + user + round combination, resulting in uniqueness.
The unique identifier for an reward on Hub88 side in standard 16-byte UUID format.
An ID of an action that is generated for each of our calls to the Operator, used to sync Hub88 and Operator sides for debugging purposes, displayed in standard 16-byte UUID format. The Operator has to respond with the same request_uuid as the one received in request.
Unique identifier of the transaction that this transaction is referencing. In case of a rollback, this field will contain transaction_uuid of the transaction which needs to be rolled back. In case of a win, there will be transaction_uuid of the bet to which this win is related to.
Flag which shows that transaction was generated by a promotional tool (FreeSpins, etc). Usually, these transactions are credited to bonus wallets (if available).
The flag which shows that related freebet transactions identified in the field reward_uuid have been aggregated into one single transaction. For example, a player was rewarded ten (10) freespins, but Hub88 sends one single transaction request with field is_aggregated set to true.
The unique game identifier in Hub88 system in the form of a string. game_code can be obtained from the /game/list endpoint.
The ISO 4217 currency code. The following list contains all currencies supported by our system. Note that native gameplay support for these currencies may vary per Provider. Please contact us to know which Provider supports which currencies.
BSD, TTD, ZMW, BMD, USD, BYR, UGX, HKD, MGA, GIP, UZS, MKD, PTS, mLTC, EGP, AWG, CZK, ILS, MZN, TND, XPF, SOS, DOP, RUB, KRW, BTN, KGS, BAM, AOA, SOC, AMS, BND, RSD, FKP, PEN, EOS, GHS, JPY, TRY, SBD, UAH, LTL, FJD, GNF, MDL, AFN, ZAR, MOP, TJS, BOB, JMD, QAR, IRR, SYP, XXX, NAD, MYR, CUP, NOK, BGN, KPW, MNT, NZD, uETH, SGD, PYG, OMR, DZD, EUR, TMT, MMK, PTQ, ANG, TZS, CRC, VES, ETB, THB, ZWD, LYD, CHF, MVR, KES, CVE, LSL, KMF, SZL, KYD, BRL, AED, WST, YER, ALL, TRX, HUF, GTQ, uBTC, IDR, MWK, CUC, DKK, TWD, XCD, BBD, LRD, KZT, JOD, BYN, BIF, PLN, SDG, VUV, SEK, BDT, HNL, BWP, VND, ISK, SLL, BHD, HTG, USDT, ADA, MUR, ERN, uLTC, LKR, COP, GEL, AUD, GBP, CAD, PHP, PAB, DJF, GMD, PKR, NIO, AMD, RWF, RON, NGN, TOP, UYU, AZN, SRD, KWD, PGK, CDF, SAR, IQD, XRP, SCR, mETH, MAD, GYD, INR, LBP, ARS, MXN, CLP, BNB, CNY, KHR, LAK, HRK, BZD, SSP, XOF, X5T, MRO, NPR, mBTCThe field for metadata related to transaction, such as type of bet, value, time, etc. Differs from game to game. Not relevant for transaction processing procedure but could be useful for statistics or activity backtracking.
The amount of money displayed in integer**(Int64)** format. To convert real float value to integer, it is multiplied by 100000. Example: $3.56 is represented as 356000
The transaction metadata. Differs from game to game and used for enriching the transaction payload for processing.
The game session token that was passed within /game/url endpoint response.
The endpoint called when a User places a bet (debit). The Operator is expected to decrease the player's balance by the amount value and return a new balance.
Each bet has a unique identifier ( transaction_uuid) for this transaction. Before altering the user's balance, the Operator has to check that the bet wasn't processed before. There might be
Retry Policy: In case of network fail (HTTP 502, timeout, nxdomain, etc.), we will retry 3 times with 1 sec of timeout. If we do not receive 200 HTTP status, this transaction will be counted as failed and rollback will be generated (to ensure that failed bet hadn’t affected User’s balance). This rollback will be retried 500 times (or less if we get logical response) with exponential back off.
/transaction/bet
RSA-SHA256 is used to sign the request body using the private key. The signature is validated using the public key associated with the provided operator_id.
The unique user ID in the Operator’s system. In case of DEMO gameplay, this parameter may be omitted.
The unique transaction identifier. An ID of business logic action (transaction) that <b>needs to be stored</b> on both sides for <b>at least 4 months</b> (for reconciliation purposes). Operator has to respond on each transaction_uuid. An action with same transaction_uuid shouldn't be processed more than once.
The transaction identifier received from the game Supplier. This identifier will be used to investigate any issues via customer support tickets.
The name of the user in the Provider’s system. In case Operator needs to find a user in Provder’s back office or report a problem with the user. If the value is NULL, the Operator can search for their own user_id.
Denotes when the round is closed.
The game round ID used to relate all bets and wins made in one round. All transactions related to the same round have the same value in this field. The ID is not unique through whole system. The value depends on provider’s RGS logic, as it is created from game + user + round combination, resulting in uniqueness.
The unique identifier for an reward on Hub88 side in standard 16-byte UUID format.
An ID of an action that is generated for each of our calls to the Operator, used to sync Hub88 and Operator sides for debugging purposes, displayed in standard 16-byte UUID format. The Operator has to respond with the same request_uuid as the one received in request.
Flag which shows that transaction was generated by a promotional tool (FreeSpins, etc). Usually, these transactions are credited to bonus wallets (if available).
The flag which shows that related freebet transactions identified in the field reward_uuid have been aggregated into one single transaction. For example, a player was rewarded ten (10) freespins, but Hub88 sends one single transaction request with field is_aggregated set to true.
The unique game identifier in Hub88 system in the form of a string. game_code can be obtained from the /game/list endpoint.
The ISO 4217 currency code. The following list contains all currencies supported by our system. Note that native gameplay support for these currencies may vary per Provider. Please contact us to know which Provider supports which currencies.
BSD, TTD, ZMW, BMD, USD, BYR, UGX, HKD, MGA, GIP, UZS, MKD, PTS, mLTC, EGP, AWG, CZK, ILS, MZN, TND, XPF, SOS, DOP, RUB, KRW, BTN, KGS, BAM, AOA, SOC, AMS, BND, RSD, FKP, PEN, EOS, GHS, JPY, TRY, SBD, UAH, LTL, FJD, GNF, MDL, AFN, ZAR, MOP, TJS, BOB, JMD, QAR, IRR, SYP, XXX, NAD, MYR, CUP, NOK, BGN, KPW, MNT, NZD, uETH, SGD, PYG, OMR, DZD, EUR, TMT, MMK, PTQ, ANG, TZS, CRC, VES, ETB, THB, ZWD, LYD, CHF, MVR, KES, CVE, LSL, KMF, SZL, KYD, BRL, AED, WST, YER, ALL, TRX, HUF, GTQ, uBTC, IDR, MWK, CUC, DKK, TWD, XCD, BBD, LRD, KZT, JOD, BYN, BIF, PLN, SDG, VUV, SEK, BDT, HNL, BWP, VND, ISK, SLL, BHD, HTG, USDT, ADA, MUR, ERN, uLTC, LKR, COP, GEL, AUD, GBP, CAD, PHP, PAB, DJF, GMD, PKR, NIO, AMD, RWF, RON, NGN, TOP, UYU, AZN, SRD, KWD, PGK, CDF, SAR, IQD, XRP, SCR, mETH, MAD, GYD, INR, LBP, ARS, MXN, CLP, BNB, CNY, KHR, LAK, HRK, BZD, SSP, XOF, X5T, MRO, NPR, mBTCThe field for metadata related to transaction, such as type of bet, value, time, etc. Differs from game to game. Not relevant for transaction processing procedure but could be useful for statistics or activity backtracking.
The amount of money displayed in integer**(Int64)** format. To convert real float value to integer, it is multiplied by 100000. Example: $3.56 is represented as 356000
The transaction metadata. Differs from game to game and used for enriching the transaction payload for processing.
The game session token that was passed within /game/url endpoint response.
Called when there is need to roll back the effect of the referenced transaction. The Operator is expected to find the referenced transaction, roll back its effects and return the player's new balance.
/transaction/rollback
RSA-SHA256 is used to sign the request body using the private key. The signature is validated using the public key associated with the provided operator_id.
The unique user ID in the Operator’s system. In case of DEMO gameplay, this parameter may be omitted.
The unique transaction identifier. An ID of business logic action (transaction) that <b>needs to be stored</b> on both sides for <b>at least 4 months</b> (for reconciliation purposes). Operator has to respond on each transaction_uuid. An action with same transaction_uuid shouldn't be processed more than once.
The transaction identifier received from the game Supplier. This identifier will be used to investigate any issues via customer support tickets.
Denotes when the round is closed.
The game round ID used to relate all bets and wins made in one round. All transactions related to the same round have the same value in this field. The ID is not unique through whole system. The value depends on provider’s RGS logic, as it is created from game + user + round combination, resulting in uniqueness.
An ID of an action that is generated for each of our calls to the Operator, used to sync Hub88 and Operator sides for debugging purposes, displayed in standard 16-byte UUID format. The Operator has to respond with the same request_uuid as the one received in request.
Unique identifier of the transaction that this transaction is referencing. In case of a rollback, this field will contain transaction_uuid of the transaction which needs to be rolled back. In case of a win, there will be transaction_uuid of the bet to which this win is related to.
The unique game identifier in Hub88 system in the form of a string. game_code can be obtained from the /game/list endpoint.
The transaction metadata, enriches the transaction payload for processing.
The game session token that was passed within /game/url endpoint response.