RGS Wallet Integration

Introduction

The document describes the integration process of the latest version of Sportradar’s Remote Game Server (RGS) version, which delivers all Sportradar’s Virtual Sports over a single integration.

The integration involves a back-end (wallet) integration, which is described in this document, and a front-end (user interface) integration described in a separate document (RGS Frontend Integration Guide).

General

RGS is designed in a way that the platform sends requests to various endpoints on your wallet system and processes responses received from your wallet system:

There are seven API endpoints that need to be implemented by your wallet system, which can be broken down into three categories:

• User related API endpoints: /userInfo, /queryBalance

• Betting related API endpoints: /reserveFunds, /payment and /approve

• Back office related API endpoints: /cancel, /manualPayment

Your wallet system is expected to implement all API endpoints which we will describe in more detail in this documentation.

Interface Definition

In addition to this document, you will receive an OpenAPI document that conforms to the OpenAPI Specification.

Please study the OpenAPI document as well as it contains all technical details with regards to the wallet interface.

Security

Wallet communication uses SSL (Secure Socket Layer). All messages are exchanged over non-persistent connection and contain HTTP Basic authentication for additional security.

Both our staging and production environments will reject unsecured (http) connections.

The following IP range needs to be whitelisted on your end to be able to get connection to our system:

87.238.140.0/24

Batching Support

In general, requests from the RGS platform contain one element of a specific type. In the unlikely event we need to improve performance, we reserve the right to batch requests.

Batching means that each request can contain multiple elements allowing RGS to send multiple instructions per request. Nonetheless, each batch will contain only items of the same type.

Note that a batch does not represent a set of instructions, which must be executed in a single transaction; it is simply a “container” for sending multiple unrelated items between remote systems.

You need to ensure that your wallet system can accept and process batches as described above. Responses from your wallet system must contain an array with the same number of response instances of the same type (unless stated otherwise) and use the correlationNumber to match responses with their corresponding requests.

Idempotence

Wallet endpoints must act idempotent, meaning that multiple calls of the same endpoints with same arguments have no side effects. This behavior prevents duplication in the case of failures or multiple retries.

Response Parameters

Most of the requests received by your wallet system produce a response which contains an array of GenericResponse instances. This section describes the GenericResponse element.

When a request produces a specific response, the response is specified in the sections below describing that request.

GenericResponse

Parameter	Type	Required	Description
balance	number	Required	Funds available in the user’s account.
correlationNumber	integer	Required	A number used to match associated request and response elements.
currencyCode	string	Optional	A three-character ISO 4217 code specifying the currency used by the user.
status	Status	Required	An enumeration member describing potential errors encountered while processing associated request element. See section Status Codes for further details.

Status Codes

The table below lists all status codes that can be returned by your wallet system. As mentioned above, even though all response elements use the parameter status to indicate whether the associated request element was processed successfully, individual responses use only a subset of status codes defined in the enumeration:

Status Code	Description
OK	The associated request element was processed successfully.
REQUEST_FORMAT	The format of the associated request element was not correct (missing required field…).
INVALID_TOKEN	The specified user token is not valid or was revoked.
INSUFFICIENT_FUNDS	The player does not have enough funds to complete the requested action.
USER_NOT_FOUND	The player specified by the userId does not exist in your wallet system.
INVALID_CREDENTIALS	The provided credentials are not valid.
USER_FROZEN	The player specified with the userId is frozen.
DUPLICATE_PAYMENT_ID	The specified paymentId is already in use.
PAYMENT_ID_NOT_FOUND	The transaction with the specified paymentId was not found.
RISK_VALIDATION	The payment request was denied due to failed risk validation.
CANCEL_NOT_POSSIBLE	The transaction cannot be canceled because it has already been approved.
USER_EXISTS	The player with the specified identifier already exists.
ERROR	An unknown error occurred while processing the request element.

User Messages

Messages in this section are the first that should be undertaken when implementing the RGS API. These messages are used to retrieve information about the logged in user.

All methods described in this section are mandatory and must be provided by your wallet system.

Retrieving User Information – /userInfo

The /userInfo endpoint is called the moment the game launch URL containing a player’s token within the id parameter is accessed.

/userInfo is used primarily to authenticate the player in your wallet system.

If the /userInfo call is successful, your wallet system should respond with a UserInfoResponse of status OK along with the required fields containing the player information to the RGS server.

Otherwise, your wallet system should send a UserInfoResponse with the most appropriate error enumeration in the status field.

It is also important to note that the parameter currencyCode is used by the frontend to determine which currency should be displayed in the player’s bet slip.

UserInfoRequest

Parameter	Type	Required	Description
correlationNumber	integer	Required	A number used to match request and response elements.
token	string	Optional	A token passed to the platform when authenticating the user.

UserInfoResponse

Parameter	Type	Required	Description
balance	number	Required	Player’s funds available on their account.
correlationNumber	integer	Required	A number used to match associated request and response elements.
currencyCode	string	Optional	A three-character ISO 4217 code specifying the currency used by the user. Currency codes must be provided in lower case. If no currency is added, it will fall back to default eur.
languageCode	string	Optional	An ISO 639-1 code specifying the language of the user. Language codes must be provided in lower case. If no language will be added it will fall back to default en.
status	Status	Required	An enumeration member describing potential errors encountered while processing an associated request element. See section Status Codes for further details.
timeToLive	integer	Optional (deprecated)	A value specifying the time interval after which the token will expire.
userId	string	Required	A pseudo anonymous string uniquely identifying the user in your wallet system. Values for userId are restricted to the following: · Allowed characters are [0-9A-Za-z_-] · Max. length is 36
username	string	Optional	A username of the user in your wallet system.
vipLevel	string	Optional	A VIP level of the user in your wallet system.

UserInfo Status Codes

Status Code
OK
REQUEST_FORMAT
INVALID_TOKEN
USER_NOT_FOUND
USER_FROZEN
ERROR

Retrieving Player’s Balance – /queryBalance

RGS retrieves a player’s current balance by calling the /queryBalance endpoint.

/queryBalance endpoint parameters contain an array with one or more QueryBalanceRequest instances. Your wallet system’s response must contain an array with the same number of GenericResponse instances.

QueryBalanceRequest

Parameter	Type	Required	Description
correlationNumber	integer	Required	A number used to match request and response elements.
token	string	Optional	A token passed to the platform when authenticating the user.
userId	string	Required	A pseudo anonymous string uniquely identifying the user in your wallet system. Values for userId are restricted to the following: · Allowed characters are [0-9A-Za-z_-] · Max. length is 36

Status Codes

Status Code
OK
REQUEST_FORMAT
INVALID_TOKEN
USER_NOT_FOUND
ERROR

Betting Messages

There are three core API endpoints that must be implemented in your wallet system to handle betting related requests:

• /reserveFunds

• /payment

• /approve

Details about each endpoint will be provided in the following sub-sections.

Prior to entering this phase of the integration, Sportradar will have provided you with access to the RGS Backoffice system in Betradar’s staging environment. The RGS Backoffice will give visibility to audit logs, helping with any troubleshooting of error messages.

Placing a Bet – /reserveFunds

The /reserveFunds endpoint is called by RGS during bet placement to take money from a player’s account.

/reserveFunds endpoint parameters contain an array with one or more ReserveFundsRequest instances. Your wallet system’s response must contain an array with the same number of GenericResponse instances.

Your wallet system should verify that the token present in each request is still valid and return an error response if the token has expired.

Also note, that whilst RGS will reject bets that were placed in a currency other than the one specified in the UserInfoResponse it is good practice to either reject the transaction or perform a currency conversion if the currencyCode sent with this request does not match the currency in the player’s wallet.

If the ReserveFundsRequest is successful, your wallet system should deduct the stake amount from the player’s account.

Timeouts during Bet Placement

Should a response on a ReserveFundsRequest take longer than 8 seconds, the player will be presented with a message informing them that the bet was not placed.

If the response arrives after this message was delivered to the player, RGS will try to roll-back the transaction on your wallet system by calling the /cancel endpoint sending a CancelRequest (see section 2.10.1 for further details).

RGS will wait up to 1 minute for the response from the wallet (The player will be notified in 8 seconds). If there is no response or if the response is not parsable, RGS will try to cancel (rollback) the transaction. We will attempt the cancellation up to 10 times, using an exponential delay up to a maximum delay of 32 minutes between retries.

After the retry limit is exceeded, the ticket will be put into the BACKOFFICE_SETTLEMENT state and will require manual intervention via the backoffice.

ReserveFundsRequest

Parameter	Type	Required	Description
correlationNumber	integer	Required	A number used to match request and response elements.
currencyCode	string	Optional	A three-character ISO 4217 code specifying the currency used by the user. Currency codes must be provided in lower case.
gameCategoryCode	string	Optional	A value specifying the category of the game associated with the request.
gameCode	string	Optional	A value specifying the game associated with the request. See section Product Game Codes for further details.
gameFormatCode	string	Optional	A value specifying the channel (web, mobile…) used by the user when placing the bet.
maxPayout	number	Required	A value specifying the maximum payout for the ticket associated with the request. Risk control is handled on during bet acceptance, before any wallet requests are made. Min and max bet amounts and max payouts can be set in back office. This is only some additional info to inform you about the maximum possible winnings for this reservation, should you wish to implement additional risk control.
paymentId	string	Required	A value used to uniquely identify the transaction. The value must be unique through the application’s lifetime.
stake	PaymentElement	Required	A value specifying the amount to be reserved (withdrawn) from the user’s account.
ticketInfo	string	Optional	A JSON representation of the ticket associated with the current element.
token	string	Optional	A token that was passed to the RGS when the user was registered
userId	string	Required	A pseudo anonymous string uniquely identifying the user within the wallet system. Values for userId are restricted to the following: · Allowed characters are [0-9A-Za-z_-] · Max. length is 36

Product Game Codes

Product Game Code	Description
VFB	Virtual Football Bundesliga
VFEL	Virtual Football English League
VFSL	Virtual Football Spanish League
VFIL	Virtual Football Italian League
VFFL	Virtual Football French League
VFGL	Virtual Football German League
VWMF1	Virtual World Match Football 1
VWMF2	Virtual World Match Football 2
VWMF3	Virtual World Match Football 3
VFF1	Virtual Fast Football 1
VFF2	Virtual Fast Football 2
VFF3	Virtual Fast Football 3
VFLM	Virtual Football League Mode
VFWC	Virtual Football World Cup
VFEC	Virtual Football Euro Cup
VFAS	Virtual Football Asian Cup
VFNC	Virtual Football Nations Cup
VFCC	Virtual Football Champions Cup
VCI	Virtual Cricket In-Play
VBI	Virtual Baseball In-Play
VTI	Virtual Tennis In-Play
VTIATP1	Virtual Tennis In-Play ATP 1 (1990s)
VTIATP2	Virtual Tennis In-Play ATP 2 (2000s)
VTIATP3	Virtual Tennis In-Play ATP 3 (2010s)
VTIATP4	Virtual Tennis In-Play ATP 4 (2020s)
VBL	Virtual Basketball League
VDR	Virtual Dogs Kiron
VHC	Virtual Horses Kiron

PaymentElement

Parameter	Type	Required	Description
amount	number	Required	Specifies the value to be withdrawn or deposited to the user’s account.
timestamp	integer (int64)	Required	Specifies the time of the event in UTC time.

Status Codes

Status Code
OK
REQUEST_FORMAT
INVALID_TOKEN
INSUFFICIENT_FUNDS
USER_NOT_FOUND
USER_FROZEN
DUPLICATE_PAYMENT_ID
RISK_VALIDATION
ERROR

Crediting an Account – /payment

The /payment endpoint is used by RGS to credit money to a player’s account.

/payment endpoint parameters contain an array with one or more PaymentRequest instances. Your wallet system’s response must contain an array with the same number of GenericResponse instances.

The approvePayment property is almost always set to false, as such the payment will be approved later by calling the /approve endpoint.

If the PaymentRequest is successful, the wallet should credit the payment amount to the player’s account.

Also note, that whilst RGS will reject bets that were placed in a currency other than the one specified in the UserInfoResponse it is good practice to either reject the transaction or perform a currency conversion if the currencyCode sent with this request does not match the currency in the player’s wallet.

Should the payment fail due to an error or a timeout, RGS will automatically retry the payment, up to 30 times (10 on staging), using an exponential delay between the retries, up to a maximum delay of 32 minutes between retries. After the retry limit has been exceeded, RGS will no longer try to automatically pay out the ticket and the ticket will be set into the BACKOFFICE_SETTLEMENT state, and require manual action via back office to resolve.

Bet Cancellation

If market information received by RGS indicates that one of the markets associated with the bet was cancelled, RGS will call the /payment endpoint to refund the affected bet(s).

In case a ticket contains several bets on different markets and some bets are unaffected by the market cancellation, potential winnings from the unaffected bets will also be credited in the same PaymentRequest.

Information on whether a bet has been refunded due to market cancellation can be obtained by inspecting the JSON representation of the ticket associated with the request, which is passed in the ticketInfo string parameter to the PaymentRequest. Such refunded lines will have the result attribute set to #.

PaymentRequest

Parameter	Type	Required	Description
approvePayment	boolean	Required	A value specifying whether the transaction should be approved. If value is false, the transaction will be approved by a separate message
correlationNumber	integer	Required	A number used to match request and response elements.
currencyCode	string	Optional	A three-character ISO 4217 code specifying the currency used by the user. Value should be provided in lower case.
payment	PaymentElement	Required	A value specifying the amount won by the user (see section PaymentElement for further details).
paymentId	string	Required	A value used to uniquely identify the transaction. Value must be unique through the application’s lifetime.
ticketInfo	string	Optional	A JSON representation of the ticket associated with current element.
userId	string	Required	A pseudo anonymous string uniquely identifying the user within the wallet system. Values for userId are restricted to the following: · Allowed characters are [0-9A-Za-z_-] · Max. length is 36

Status Codes

Status Code
OK
REQUEST_FORMAT
USER_NOT_FOUND
DUPLICATE_PAYMENT_ID
PAYMENT_ID_NOT_FOUND
ERROR

Ending the Round – /approve

Each transaction initiated by RGS must be either approved or cancelled. When a transaction is approved all withdrawals and deposits associated with its paymentId are approved.

The /approved endpoint is used by RGS to initiate the approval of a transaction.

/approve endpoint parameters contain an array with one or more ApproveRequest instances. Your wallet system’s response must contain an array with the same number of GenericResponse instances.

Should the approval fail due to an error or a timeout, RGS will automatically retry the approval, up to 30 times (10 on staging), using an exponential delay between the retries, up to a maximum delay of 32 minutes between retries. After the retry limit has been exceeded, RGS will no longer try to automatically approve the ticket and the ticket will be set into the BACKOFFICE_SETTLEMENT state, and require manual action via back office to resolve.

ApproveRequest

Parameter	Type	Required	Description
correlationNumber	integer	Required	A number used to match request and response elements.
paymentId	string	Required	A value used to uniquely identify the transaction. Value must be unique through the application’s lifetime.
ticketInfo	string	Optional	A JSON representation of the ticket associated with current element.

Status Codes

Status Code
OK
REQUEST_FORMAT
USER_FROZEN
PAYMENT_ID_NOT_FOUND
ERROR

Betting Flow Examples

Player places a Bet and loses

The sequence diagram below describes the interaction steps when the player places the bet, and the bet is lost.

RGS calls the /reserveFunds endpoint in order to debit the funds required for the bet.

When the markets associated with the bet are settled, RGS determines that the bet was lost. Since there are no winnings (the user lost the bet) the /payment endpoint will not be called.

However, RGS will call the /approve endpoint in order to specify the bet is settled and the transaction is completed.

Player places a Bet and wins

When a player places a bet and wins, the flow of messages is like the example above. However, this time when the markets associated with the bet are settled, RGS determines that the bet is won and will call the /payment endpoint.

Once RGS receives the confirmation that the request was successfully processed, it will call the /approve endpoint to notify your wallet system that the bet is settled, and the transaction is completed.

Backoffice Messages

Endpoints described in this section support the RGS Backoffice functionality.

A user guide for the Backoffice is available as a standalone document, and should be made available to your operation staff, so they can support management of bets in RGS.

There are two API calls that need to be implemented in your wallet system to handle Backoffice requests:

• /cancel

• /manualPayment

Ticket Cancellation – /cancel

The /cancel endpoint is called by RGS when a bookmaker’s support staff want to cancel a ticket through the Backoffice, if the market has been voided, or if an error occurred during ticket placement.

When the transaction is cancelled, all withdrawals and deposits associated with its paymentId are cancelled.

/cancel endpoint parameters contain an array with one or more CancelRequest instances. Your wallet system’s response must contain an array with the same number of GenericResponse instances.

Should the automated cancellation fail due to an error or a timeout, RGS will automatically retry the cancellation, up to 10 times, using an exponential delay between the retries, up to a maximum delay of 32 minutes between retries.

If the transaction has already been approved, then the force parameter will be set to true.

CancelRequest

Parameter	Type	Required	Description
correlationNumber	integer	Required	A number used to match request and response elements.
force	boolean	Optional	A value specified whether to attempt to cancel an approved transaction. force will be set to true when /cancel is called by triggering the action through the back office.
paymentId	string	Required	A value used to uniquely identify the transaction. The value must be unique through the application’s lifetime.
ticketInfo	string	Optional	A JSON representation of the ticket associated with current element.

Status Codes

Status Code
OK
REQUEST_FORMAT
USER_FROZEN
PAYMENT_ID_NOT_FOUND
CANCEL_NOT_POSSIBLE
ERROR

Cancellation of a winning Bet

In case that a winning bet needs to be cancelled, the winnings and the stake should be rolled back, and the stake reapplied.

The flow below describes the scenario of cancelling a winning bet:

• Starting balance: 100.00

• Place 1.00 bet @ 1.50 odds

• Balance: 99.00

• Bet wins, returning 1.50 (1.00 for stake, and 0.50 winnings)

• Balance: 100.50

• /cancel called

• Winnings and stake are rolled back

• Balance: 99.00

• Original stake is applied

• Final Balance 100.00

Manual Ticket Re-settlement – /manualPayment

The /manualPayment endpoint is called by RGS when a bookmaker’s support staff want to manually re-settle a ticket through the Backoffice.

Situations where this may be needed include but are not limited to:

• Timeout during /payment

  • RGS called /payment, but your response takes longer than 8 seconds.

  • RGS then will retry to send the request.

  • While retrying, RGS receives the initial response, but an error is returned for the consecutive requests.

  • Now we have a situation where RGS does not know which state the ticket is in as it has conflicting statuses.

  • To reconcile the status, a manual payment needs to be initiated from the Backoffice.

• Missing Settlement Information

  • When results fail to come through, the bet needs to be manually settled via the Backoffice.

/manualPayment endpoint parameters contain an array with one or more ManualPaymentRequest instances. Your wallet system’s response must contain an array with the same number of GenericResponse instances.

Also note, that whilst RGS will reject bets that were placed in another currency other than the one specified in the UserInfoResponse, it is good practice to either reject the transaction, or perform a currency conversion if the currencyCode sent with this request does not match the currency in the user’s wallet.

ManualPaymentRequest

Parameter	Type	Required	Description
comment	string	Optional	An optional comment entered by the operator when re-settling a bet.
correlationNumber	integer	Required	A number used to match request and response elements.
currencyCode	string	Optional	A three-character ISO 4217 code specifying the currency used by the user. Currency codes must be provided in lower case.
payment	PaymentElement	Required	A value specifying the amount won by the user (see PaymentElement for further details).
paymentId	string	Required	A value used to uniquely identify the transaction. Value must be unique through the application’s lifetime.
userId	string	Required	A pseudo anonymous string uniquely identifying the user within the wallet system. Values for userId are restricted to the following: · Allowed characters are [0-9A-Za-z_-] · Max. length is 36

Status Codes

Status Codes
OK
REQUEST_FORMAT
USER_FROZEN
ERROR

Re-settlement of a winning Bet

In case that a winning bet needs to be manually re-settled, the winnings and the stake should be rolled back, and the new win amount value applied.

The flow below describes the scenario of re-settling a winning bet:

• Starting balance: 100.00

• Place 1.00 bet @ 1.50 odds

• Balance: 99.00

• Bet wins, returning 1.50 (1.00 for stake, and 0.50 winnings)

• Balance: 100.50

• /manualPayment with PaymentElement.amount of 1.00 called

• Winnings and stake are rolled back

• Balance: 99.00

• PaymentElement.amount is applied

• Final Balance 100.00

TicketInfo Object

This section contains a sample JSON ticket object, which can be optionally passed in certain API calls.

The TicketInfo Object contains a snapshot of a ticket’s state.

In general, you should not need to process the TicketInfo Object as a ticket’s life cycle is managed on our end and details of a ticket can be looked up in the RGS Back Office.

In addition, the frontend of RGS provides a betting history of a player’s bets, so players can check their bets on Sportradar’s Virtual Sports at any time.

The TicketInfo object is intended to be used for debugging purposes only and we recommend to process the TicketInfo object only in case you have strong reasons. This will keep the integration as simple as possible.

Please also note, that the TicketInfo Object may be subject to changes which may impact your integration even though we aim to implement any changes in a backwards-compatible manner.

Lastly, be aware that data may be missing in the TicketInfo Object depending on the ticket’s state which can make processing the TicketInfo Object more complicated than anticipated.

Example

Below you will find an example of a TicketInfo Object that will be sent during the approve operation:

{
    "ticketId": "618cdf5ffe69e601d116b723",
    "status": "PLACED",
    "bkId": 12345,
    "transactionId": "74226243394769538",
    "product": "VFB",
    "placedTs": "1636622164932",
    "receivedTs": "1636622164046",
    "updatedTs": "1636622401792",
    "ticketExpiryTs": "1636632964054",
    "estimatedSettlementTs": "",
    "settledTs": "",
    "stake": "50000",
    "possibleWinnings": "135000",
    "totalReturn": "0.00",
    "productType": "VFB",
    "selections": [
        {
            "eventId": "vf:match:177637419",
            "id": "uof:6/sr:sport:1/1/1",
            "result": "*",
            "odds": 13500,
            "metaData": {
                "lang": "EN-EN",
                "marketName": "Fulltime",
                "outcomeName": "Borussia M'gladbach",
                "productType": "VFB",
                "tournament": {
                    "name": "Season 1422",
                    "sequence": "",
                    "event": {
                        "competitors": [
                            {
                                "id": "sr:competitor:798914",
                                "name": "Borussia M'gladbach",
                                "abbr": "BMG"
                            },
                            {
                                "id": "sr:competitor:798930",
                                "name": "VfB Stuttgart",
                                "abbr": "VFB"
                            }
                        ],
                        "eventStart": "1636622251000",
                        "name": "Matchday 20",
                        "sequence": ""
                    }
                }
            }
        },
        {
            "eventId": "vf:match:177637421",
            "id": "uof:6/sr:sport:1/1/1",
            "result": "-",
            "odds": 20000,
            "metaData": {
                "lang": "EN-EN",
                "marketName": "Fulltime",
                "outcomeName": "Bayer 04 Leverkusen",
                "productType": "VFB",
                "tournament": {
                    "name": "Season 1422",
                    "sequence": "",
                    "event": {
                        "competitors": [
                            {
                                "id": "sr:competitor:798912",
                                "name": "Bayer 04 Leverkusen",
                                "abbr": "B04"
                            },
                            {
                                "id": "sr:competitor:798916",
                                "name": "Eintracht Frankfurt",
                                "abbr": "SGE"
                            }
                        ],
                        "eventStart": "1636622251000",
                        "name": "Matchday 20",
                        "sequence": ""
                    }
                }
            }
        }
    ],
    "bets": [
        {
            "selectionRefs": [],
            "selectedSystems": [
                2
            ],
            "sumOfWins": "135000"
        }
    ],
    "exchangeRate": "1.0"
}

Data Structure

Below you will find a list of all possible data that can be sent inside the TicketInfo Object. All fields are optional and only if the information is available, the field will be sent as part of the object.

Parameter	Type	Description
ticketId	string	The ticket’s unique id.
status	string	The ticket’s status. See section 3.2.1 for further details.
bkId	integer	Identifies you as a bookmaker in our system. The bkId will be provided to you by your technical account manager.
transactionId	string	A value used to uniquely identify the transaction. Value must be unique through the application’s lifetime.
product	string	A value specifying the game associated with the ticket.
placedTs	string	13-digit epoch timestamp representing the time of ticket placement.
receivedTs	string	13-digit epoch timestamp specifying the time when the ticket was received by RGS.
updatedTs	string	13-digit epoch timestamp specifying the time when the ticket was last updated.
ticketExpiryTs	string	13-digit epoch timestamp specifying the time when the ticket is going to expire.
estimatedSettlementTs	string	13-digit epoch timestamp specifying the estimated time when the ticket will be settled.
settledTs	string	13-digit epoch timestamp representing the time of ticket settlement.
stake	string	The stake multiplied by 10000.
possibleWinnings	string	The maximum possible winnings multiplied by 10000.
totalReturn	string	The actual won amount.
productType	string	Abbreviation of the product which the ticket was placed under. See section 2.9.1.3 for further details.
selections	Selection[]	An array containing the selections of a ticket. See section 3.2.2 for further details.
bets	Bet[]	An array containing all bet combinations of a ticket. See section 3.2.3 for further details.
exchangeRate	string	Exchange rate between the ticket’s currency and Euro.

TicketInfo Status Codes

Status	Description
UNDEFINED	The ticket has not yet been processed by RGS.
PLACING	The ticket is currently being processed.
REJECTED_INTERNAL_ERROR	The ticket was rejected because of an internal RGS error (terminal state).
REJECTED_EXTERNAL_ERROR	The ticket was rejected because of an external error, e.g., unexpected wallet issues (terminal state).
REJECTED_BASIC_VALIDATION	The ticket was rejected because basic validation failed, e.g., invalid ticket structure (terminal state).
REJECTED_SESSION_VALIDATION	The ticket was rejected because it was placed with an invalid authentication token (terminal state).
REJECTED_RISK_VALIDATION	The ticket was rejected because risk validation failed, e.g., stake too high or too low, possible winnings are too high or too low (terminal state).
REJECTED_BOOKMAKER_SETTINGS_VALIDATION	The ticket was rejected because bookmaker settings were not respected, e.g., betting restrictions.
REJECTED_BY_BROKER	The ticket was rejected by the RGS broker. This state is not likely to happen as a more specific rejection status will be associated with the ticket (terminal state).
REJECTED_WG_INTERNAL_ERROR	The ticket was rejected because of internal RGS wallet adapter error (terminal state).
REJECTED_WG_EXTERNAL_ERROR	The ticket was rejected because of an external RGS wallet adapter error, e.g., a bookmaker wallet integration issue (terminal state).
REJECTED_WG_INSUFFICIENT_FUNDS	The ticket was rejected because a punter does not have enough funds available (terminal state).
REJECTED_WG_SESSION_EXPIRED	The ticket was rejected because the authentication token used with the session expired on bookmaker side (terminal state).
REJECTED_ADAPTER_INTERNAL_ERROR	The ticket was rejected because of an internal RGS settlement / ticket engine error. The ticket will eventually be cancelled.
REJECTED_ADAPTER_EXTERNAL_ERROR	The ticket was rejected because of an external RGS settlement / ticket engine error. The ticket will be eventually be cancelled.
REJECTED_ADAPTER_MARKET_DOES_NOT_EXIST	The ticket was rejected because RGS settlement / ticket engine did not recognize one or more markets. The ticket will eventually be cancelled.
REJECTED_ADAPTER_NOT_ACKED	The ticket was rejected because RGS settlement / ticket engine did not acknowledge the ticket. This status is not likely to happen as more a specific status will be associated with the ticket. The ticket will eventually be cancelled.
REJECTED_ADAPTER_MARKET_EXPIRED	Ticket was rejected because the market had expired on RGS settlement / ticket engine. Ticket will eventually be cancelled.
REJECTED_ADAPTER_TICKET_NOT_VALID	Ticket was rejected because RGS settlement / ticket engine rejected the ticket. Ticket will eventually be cancelled.
REJECTED_ADAPTER_MARKET_NOT_ACTIVE	Ticket was rejected because market is not active on RGS settlement / ticket engine. Ticket will eventually be cancelled.
CANCELLATION_PENDING	The ticket is waiting to be cancelled.
TIMEOUTED	Ticket placement exceeded the timeout threshold. A cancellation attempt will be made.
PLACED	The ticket was successfully placed.
CLEARED	The ticket result is known.
CANCELED_WG	The payment associated with the ticket was cancelled on bookmaker’s wallet. The ticket will be eventually cancelled.
BACK_OFFICE_SETTLEMENT	The ticket requires manual intervention.
CANCELED	The ticket was cancelled.
SETTLED	The ticket was settled and monetized (final state; can be refunded and manually settled afterwards).
MANUALLY_SETTLED	The ticket was manually settled by a back-office user (final state; can be refunded and manually settled afterwards).
REFUNDED	The ticket was refunded by a back-office user (final state; can be refunded and manually settled afterwards).
REFUNDED_WG	The payment associated with the ticket was refunded on bookmaker wallet, but the ticket has not been refunded on RGS settlement / ticket engine yet.
EXPIRED	The ticket’s result was not recorded and requires manual intervention.

Selections

Parameter	Type	Description
eventId	string	Betradar’s internal match identifier.
id	string	Betradar’s internal market type identifier.
result	string	Represents the result of a selection. Possible values are “+” (won), “-“ (lost), “#” (void) and “*” (open)
odds	integer	Odds of the selection multiplied by 10000.
metaData	MetaData	Additional information for the selection. MetaData is not unified and my vary from product to product. See section 3.2.2.1 for further details.

MetaData

Parameter	Type	Description
lang	string	The language code.
marketName	string	The human-readable market name.
outcomeName	string	The human-readable name of the selected outcome.
productType	string	A value specifying the game associated with the ticket. See section 2.9.1.3 for further details.
tournament	Tournament	Provides details about the tournament. See section 3.2.2.2 for further details.

Tournament

Parameter	Type	Description
name	string	The tournament’s name.
sequence	string	Additional information about the tournament. Varies from product to product.
event	Event	Provides details about the event. See section 3.2.2.3 for further details.

Event

Parameter	Type	Description
competitors	Competitors[]	Provides information about the competitors of a fixture. See section 3.2.2.4 for further details.
eventStart	string	13-digit epoch timestamp representing the time a match started.
name	string	A name specifying the round within a season.
sequence	string	Additional information about the event. Varies from product to product.

Competitor

Parameter	Type	Description
id	string	Betradar’s internal competitor identifier.
name	string	The competitor’s name.
abbr	string	The abbreviation of the competitor’s name.

Bets

Parameter	Type	Description
selectionRefs	integer[]	References the selections a bet is built of.
selectedSystems	integer[]	We identify systems using an array of the length of combinations to include in each bet: · Singles: [1] - All combinations with length = 1. · Multi: [n] - The only combination where length = n. · System x/n: [x] - All combinations with length 2..n-1, i.e., for a ticket with 4 lines we have 2/4 and 3/4. Each refers to all combinations of x length, respectively [2] and [3]. · Full Cover: [2..n] - All the above excluding singles, i.e., a full cover of 4 lines is identified by [2, 3, 4]. · Full Cover with Singles: [1..n] - All possible combinations including singles: [1, 2, 3, 4].
sumOfWins	string	The sum of winnings from won combinations.