Withdrawal Request

This method creates a new, pending withdrawal request. It first verifies that all of the following requirements are met:

• The payment_method matches one of the payment methods in the response to the Get Payment Methods call
• The amount is for at least the minimum amount required
• The card_number parameter includes either the player’s card number if withdrawing to a payment card, or the value no_card if the withdraw is via wire transfer

Note: If withdrawing to a payment card, it must be a card that the player has already used to make a payment or deposit. use gateway.[msdomain]

Version Compatibility Note If you use version 4 in the Get Payment Methods API, you must also use version 4 here in the Withdrawal Request API. Mixing versions will result in incompatible formats and may cause request failures.

Request (POST)

/gateway/financials/{version}/withdrawal/{brand_id}

Parameters:

{
  "amount": 0,
  "bonus_removal": true,
  "payment_method": "stringst",
  "card_number": "string",
  "accountname": "string",
  "accountnumber": "string",
  "swift": "string",
  "bankname": "string"
}

Response

Note on redirect_url: Some payment providers may require additional player actions after a withdrawal request (e.g., card tokenization). When the response includes a redirect_url field with a non-empty value:

• The client should open this URL to allow the player to complete the required action
• The URL can be opened in an iframe or a new browser tab/window
• This is currently used for payment providers like Rapyd when handling Visa and Mastercard withdrawals for players who don’t have a saved card token
• Future payment providers or additional use cases may utilize this field

Return URL Flow: After the player completes the action on the redirect URL (which may be on a different site), they will be redirected back to the site they came from. The return URL includes a status indicator that must be handled by the client. The status can be one of:

• Success - Card token created successfully
• Pending - Card token creation is pending
• Failed - Card token creation failed

Upon return, the player should be prompted with the appropriate status of their withdrawal request.

Return URL Configuration: The return URL pattern is configurable per operator and set once during operator setup. While the domain is preset (the system knows where the player came from), operators can customize the URL pattern according to their site structure. Examples of possible configurations:

• Path-based: https://yoursite.com/card/token/success
• Hash-based: https://yoursite.com#cardTokenSuccess
• Custom path: https://yoursite.com/withdrawal/card-verification/success

This follows the same pattern as deposit redirections, allowing operators to align with their existing URL structure.

Status 201

{
  "amount": 1000,
  "ref_id": 147852369,
  "message_format": "withdraw_success",
  "redirect_url": "https://example.com/card-tokenization"
}

Status 400

{
  "errMsg": "invalid input - invalid brand id"
}

Status 401

{
  "errMsg": "invalid input - invalid token"
}

Status 403

{
  "status": "Failure",
  "data": {
    "request-id": "1234567890"
  },
  "message": "2FA required",
  "userFriendlyMessage": "2FA required"
}

If you receive a 422 error code for an Unprocessable Entity error, the client should not use the Message Format method to send a request to the server, but use its internal logic to present the message for one or more fields that didn’t pass the validation.

When a 422 validation error occurs, the response returns an array of one or more error codes detailing the fields that have validation errors. Multiple error messages are issued in the same validation form. The site should handle these validation errors and present a validation message to the player.

This will not call the message format.

The following table explains validation code behavior:

{
  "message_format": "minimum_withdrawal_requirement",
  "minimum_withdrawal_amount": 5
}

Status 429

{
  "status": "Failure",
  "data": "2fa code rate limit reached",
  "message": "2FA required",
  "userFriendlyMessage": "2FA required"
}

Status 500

{
  "result": "internal server error"
}

Response Parameters: