Wallet API
Last updated
Was this helpful?
Last updated
Was this helpful?
Wallet API is called by Hub88, and a Supplier needs to give Hub88 information on how their systems accept data and calls from Hub88 for the integration between two platforms.
Wallet API requests have to be idempotent. All requests contain a request_uuid field. Hub88 will ensure that requests with the same request_uuid are not processed twice while the response will be the same for all duplicate requests, excluding the /supplier/generic/v2/user/balance call.
The endpoint should be called when the user places a bet (debit). Hub88 decrease users balance by amount and respond with the updated user balance.
Each bet has a transaction_uuid which is a unique identifier for this transaction. Before altering the user's balance, Hub88 has to check that the transaction with such transaction_uuid hasn't been processed previously.
Retry Policy: In case of a network failure (HTTP 502, timeout, nxdomain, etc.) or unsuccessful status (excluding RS_ERROR_NOT_ENOUGH_MONEY and RS_ERROR_LIMIT_REACHED), the Supplier should roll back the transaction.
/supplier/generic/v2/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 user ID in the Supplier's system. If the Supplier renames Hub88's user IDs in any way(prefixes, etc.), the Supplier should send changed user IDs in this field to inform Hub88 about the renaming.
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). Hub88 has to respond on each transaction_uuid. An action with same transaction_uuid must not be processed more than once.
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 Supplier'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.
A standard 16-byte unique user identifier. The ID can be used as network layer action. An ID of an action that is generated for each game Supplier's call to Hub88. It's Used to sync Hub88 and game Supplier's sides for debugging purposes. Hub88 has to respond with the same request_uuid as the one that was received in request.
The flag which shows that the transaction was generated by a promotional tool (FreeSpins, etc).
The unique game identifier in Provider's system in the form of a string. game_code can be obtained from the /game/list endpoint and is a required parameter.
The ISO 4217 currency code. The following list contains all currencies supported by the Hub88 system. Note that native game play support with these currencies may vary per Provider.
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 is displayed in integers (Int64). To convert real float value to integer Hub88 multiplys it by 100000. Example: $3.56 must be represented as 356000
The transaction metadata, enriches the transaction payload for processing.
The game session token that was passed within /game/url endpoint request.
The endpoint should be called when the Supplier receives any status other than RS_OK,RS_ERROR_LIMIT_REACHED , RS_ERROR_NOT_ENOUGH_MONEY. Hub88 will then find the referenced transaction, roll back its effects and return the users new balance.
Retry Policy: In case of a network failure (HTTP 502, timeout, nxdomain, etc.) or unsuccessful status, the Supplier should retry the transaction.
/supplier/generic/v2/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 user ID in the Supplier's system. If the Supplier renames Hub88's user IDs in any way(prefixes, etc.), the Supplier should send changed user IDs in this field to inform Hub88 about the renaming.
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). Hub88 has to respond on each transaction_uuid. An action with same transaction_uuid must not be processed more than once.
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 Supplier's RGS logic, as it is created from game + user + round combination, resulting in uniqueness.
A standard 16-byte unique user identifier. The ID can be used as network layer action. An ID of an action that is generated for each game Supplier's call to Hub88. It's Used to sync Hub88 and game Supplier's sides for debugging purposes. Hub88 has to respond with the same request_uuid as the one that was received in request.
The unique identifier of the transaction which is referenced. In case of a rollback, this field will contain the transaction_uuid of the transaction which needs to be rolled back. In case of win, there will be transaction_uuid of the bet to which the win is related to.
The unique game identifier in Provider's system in the form of a string. game_code can be obtained from the /game/list endpoint and is a required parameter.
The transaction metadata, enriches the transaction payload for processing.
The game session token that was passed within /game/url endpoint request.
The endpoint should be called when a user's balance is needed by the Supplier. Hub88 will return user's current balance. Game identifier is provided to help Hub88 with user's activity statistics.
/supplier/generic/v2/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 user ID in the Supplier's system. If the Supplier renames Hub88's user IDs in any way(prefixes, etc.), the Supplier should send changed user IDs in this field to inform Hub88 about the renaming.
A standard 16-byte unique user identifier. The ID can be used as network layer action. An ID of an action that is generated for each game Supplier's call to Hub88. It's Used to sync Hub88 and game Supplier's sides for debugging purposes. Hub88 has to respond with the same request_uuid as the one that was received in request.
The unique game identifier in Provider's system in the form of a string. game_code can be obtained from the /game/list endpoint and is a required parameter.
The game session token that was passed within /game/url endpoint request.
The endpoint should be called when the user wins (credit). Hub88 will increase the user's balance by amount and respond with the updated user balance. reference_transaction_uuid shows which bet this win is related to.
Each win has a transaction_uuid which is a unique identifier for this transaction. Before altering user's balance, Hub88 will check that the win hasn't been processed previously.
Retry Policy: In case of a network failure (HTTP 502, timeout, nxdomain, etc.) or unsuccessful status, the Supplier must retry the transaction.
/supplier/generic/v2/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 user ID in the Supplier's system. If the Supplier renames Hub88's user IDs in any way(prefixes, etc.), the Supplier should send changed user IDs in this field to inform Hub88 about the renaming.
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). Hub88 has to respond on each transaction_uuid. An action with same transaction_uuid must not be processed more than once.
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 Supplier'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.
A standard 16-byte unique user identifier. The ID can be used as network layer action. An ID of an action that is generated for each game Supplier's call to Hub88. It's Used to sync Hub88 and game Supplier's sides for debugging purposes. Hub88 has to respond with the same request_uuid as the one that was received in request.
The unique identifier of the transaction which is referenced. In case of a rollback, this field will contain the transaction_uuid of the transaction which needs to be rolled back. In case of win, there will be transaction_uuid of the bet to which the win is related to.
The flag which shows that the transaction was generated by a promotional tool (FreeSpins, etc).
The unique game identifier in Provider's system in the form of a string. game_code can be obtained from the /game/list endpoint and is a required parameter.
The ISO 4217 currency code. The following list contains all currencies supported by the Hub88 system. Note that native game play support with these currencies may vary per Provider.
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 is displayed in integers (Int64). To convert real float value to integer Hub88 multiplys it by 100000. Example: $3.56 must be represented as 356000
The transaction metadata, enriches the transaction payload for processing.
The game session token that was passed within /game/url endpoint request.