Skip to content

Bet data update

PUT https://{PARTNER_API_URL}/payment/bet with type: 5

This request sends the latest actual state of a bet, and during processing this request, your backend should update the data to the current state.

Possible Changes in Data

  • coefficient
  • boosterCoefficient
  • metadata.*.coefficient

This request will only be executed if the coefficient changes after the partner's system has accepted the bet. That means this request will not be sent for every bet.

Reasons for Coefficient Changes After Bet Acceptance

If a bet is placed in live mode, the system may introduce a delay mechanism, after send Place bet request, that postpones bet acceptance for a few seconds (typically between 1 to 25 seconds) to prevent fraudulent activities. When the system finally processes the bet, the coefficient may have changed. This request is then triggered to provide the updated coefficient.

If the player has the "Accept all odds changes" setting enabled, your system will receive this request with updated odds. However, if the player has disabled the "Accept all odds changes" setting, you will instead receive a Rollback request.

INFO

This request is informational only and does not alter the bet acceptance process in any way.

WARNING

Ensure that your system does not deduct any funds from the player while processing this request!

WARNING

This request may be triggered even after you have already processed a Settle request. In such cases, you must still handle it properly and update the bet details accordingly. This can happen due to asynchronous processes in the system.

Request examples

The request data contains all common parameters for Place bet with following additions:

  • type value is 5.
json
{
  "token": "5caa4cabce523c2f7610c50ce9819bfb",
  "transactionId": "b26153f9-ef3a-4768-b6c8-0861acdecb7a",
  "currency": "USD",
  "amount": 12.12,
  "userId": "1999",
  "info": "bet info",
  "type": 5,
  "coefficient": 1.2,
  "ip": "35.168.110.10",
  "subPartnerId": null,
  "requestId": "d9195aef-9492-43dd-88d0-dc1732a37f4e",
  "bonusId": null,
  "bonusTemplateId": null,
  "bonusAmount": null,
  "gameType": "sportsbook",
  "ticketType": "single",
  "boosterCoefficient": 1,
  "metadata": [
    {
      "disciplineId": "fifa",
      "discipline": "Fifa",
      "tournamentId": "3971",
      "tournament": "Championship of League",
      "tournamentRegionCode": "GB",
      "eventId": "5663102",
      "event": "Club Black and Club White",
      "eventDate": "2021-03-05 11:08:00",
      "marketId": "5fa4e904d043dea8811a5f98",
      "market": "Match Winner",
      "outcomeId": "111",
      "outcome": "Club Black",
      "coefficient": 1.2,
      "stage": 1
    }
  ]
}

As a response we are expecting to get the same format as for Place bet request.

You should respond positively (HTTP status code 200) in the following cases:

  • There is no bet found in your system and there is no need to update data bet.
  • The bet occurred and you have successfully updated data.
  • The bet occurred, and you have successfully updated data in a previous request, and therefore this request can be safely skipped.

Retry Mechanism for this Requests

If this request fails, the system will automatically retry up to 10 times over a 6-minute period, exponentially increasing the time interval between attempts. Here are the main aspects of the retry functionality:

  1. Retry Conditions: A retry is triggered if the initial this request fails due to:
  • No response received within the 5-second timeout.
  • A response with an HTTP status code other than 200 or 400.
  1. Success Criteria:

The system will consider this request successfully processed and stop retries under either of the following conditions:

  • The partner's server returns HTTP status code 200 with a response body in the following format:
json
{
    "transactionId": "225450d5-01bb-455e-b513-7acf4451de",
    "transactionTime": "2024-09-28T17:12:04.231406Z"
}

This retry mechanism enhances the reliability of the request process, giving multiple chances for a successful process even in case of transient errors or temporary unavailability of the partner’s system.