## Cancel

The Cancel request is used for rejecting previous Debit request and declining possible funds withdrawn from the player's balance.

If the Cancel request fails due to a non-business problem, such as a connection timeout, unavailable resource, etc., RubyPlay will retry this Cancel request until the success to make sure that possible funds withdrawal was canceled.

The initial retry will be done a maximum 10 times with pauses for a fixed period of time equal to 1 second between attempts. If the last 10th attempt fails, 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 Cancel request on the Operator side must be idempotent (see the note in the Overview section of this document). It means if several of the same Cancel 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 Cancel request until the success.

It is also possible to explicitly trigger the Cancel request retry apart from responding with HTTP Status Code 5xx. For this purpose, the response to the Cancel 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 Cancel request receives the response with the HTTP Status Code 200 "OK" and the response code (described in the [Response Codes](/content/integration/seamless-wallet-api/general/response-codes)) is considered failed (100, 101, 102, 103, 104, 105, 106, 107), RubyPlay will not retry the Cancel request (because the Operator has already responded with the description of the problem).

**API Call Sample:**

**Request Schema:**

**Response Schema:**