Skip to content
Integration Package/
RubyPlay Seamless Wallet...
/
/
Credit
Last updated

Credit

The Credit request is used for providing information about the win result of the game for the player. Even if the player doesn't win anything, the Credit request is sent with zero amount.

If the Credit request fails due to a non-business problem, such as a connection timeout, unavailable resource, network problems, etc., RubyPlay will retry this Credit request until the success to make sure that possible winning was credited.

The initial retry will be done a maximum 10 times with pauses for a fixed period of time equal to 1 second between the attempts. If the last 10th attempt fails, the error dialog will be displayed. Then the request will be retried with pauses for a fixed period of time equal to 60 seconds until successful processing without retry number limitation.

The Credit request on the Operator side must be idempotent (see the note in the Overview section of this document). It means if several same Credit requests come, the response must be with the same result and should not contain the error of duplicated transaction ID.

In case of non-determined (unpredicted) HTTP server errors with HTTP Status Code 5xx (500, 501, 502, 503, 504, 505, 506, 507, 508, 509, 510, 511) from the wallet's side, RubyPlay will also retry this Credit request until the success.

It is also possible to explicitly trigger the Credit request retry apart from responding with HTTP Status Code 5xx. For this purpose, the response to the Credit request must contain HTTP Status Code 200 "OK" and the HTTP body must contain a "code" property equal to "501" (Retry / cancel triggered).

If the Credit request receives the response with the HTTP Status Code 200 "OK" and the response's "code" (described in the Response Codes) is considered failed (100, 101, 102, 103, 104, 105, 106, 107), RubyPlay will not retry the Credit request (because the Operator has already responded with the description of the problem). The player session will be blocked, so the player won't be able to play that particular game until manual cleanup by the Support team, results will be sent for manual correction.

API Call Sample:

curl -i -X POST \
  http://integrator-gaming-platform.io/rest/v1/api/credit \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionToken": "0Ja8M7KvY",
    "playerId": "24681",
    "promotionId": "123456",
    "externalCampaignId": "123456",
    "currencyCode": "EUR",
    "gameId": "rp_12",
    "country": "US",
    "amount": 2,
    "roundId": "444277",
    "transactionId": "1000",
    "deviceType": "desktop",
    "gameRoundEnd": false,
    "freeRound": true,
    "purchasedFeature": "freespins",
    "reelsPosition": [
      {
        "property1": {},
        "property2": {}
      }
    ],
    "autoPlayNotification": true
  }'
Response
application/json
{
  "code": "0",
  "description": "Success",
  "balance": 500.45
}

Request Schema:

sessionTokenstringrequired

Login session token, provided by the Operator side. Used in all requests initiated by RubyPlay (the RGS) when invoking the Operator GP service.

Example: "0Ja8M7KvY"
playerIdstringrequired

Unique player ID on the Operator side.

Example: "24681"
promotionIdstring

The ID of the campaign if a free round is reported. The wallet is expected to return the promotion balance for the specified promotionId along with its status, even if the campaign is no longer available (completed or expired).

Example: "123456"
externalCampaignIdstring

External ID of the campaign if a free round is reported and the external ID was set during the campaign creation.

Example: "123456"
currencyCodestringrequired

Currency used by the current player.

Example: "EUR"
gameIdstringrequired

Unique game ID on the Operator side.

Example: "rp_12"
countrystring

ISO 3166-1 alpha 2 country code. It corresponds to a country the played launched the game from, defined by client IP of the game init request.

Example: "US"
amountnumberrequired

The amount used in the transaction.

Example: 2
roundIdstringrequired

Game round ID. One game round can contain several transactions. When the last transaction is sent, the game round is being closed and no transactions can be processed within the same game round anymore.

Example: "444277"
transactionIdstringrequired

Unique transaction ID. Can be used in the retries to send a transaction (for example, in case of failure). Transaction ID has to be idempotent during handling. It means if transaction is retried with the same transaction ID, the status of the original transaction is returned instead of creating a new one.

Example: "1000"
deviceTypestringrequired

Device type. Possible game modes: desktop for playing game using PC, mobile for playing game using mobile phone.

Example: "desktop"
gameRoundEndbooleanrequired

Flag of the end of the game round (true if the game round is over, and false otherwise). When the last transaction is sent, the game round is being closed and no transactions can be processed within the same game round anymore.

Example: false
freeRoundboolean

Indicates whether the round is free or paid.

Example: true
purchasedFeaturestring

Type of in-game feature purchased in the round.

Example: "freespins"
reelsPositionArray of objects

Reels position report used for regulatory purposes. Can be configured separately.

autoPlayNotificationboolean

Indicates whether autoplay mode is enabled.

Example: true

Response Schema:

codestring

Response code.

Example: "0"
descriptionstring

Short description of the response code.

Example: "Success"
balancenumberrequired

The player's balance in the currency which was sent in the currencyCode field of the Balance request.

Example: 500.45
Previous page
Next page