Withdrawal Methods

This method retrieves all available payment methods that are available for withdrawals (both used and unused).

Note:

• You can only withdraw money to a used card or bank.
• If the returned value says no_card under cards, then the payment methods doesn’t require a card number.
• The logo URL for each payment method appears under key: logo.
• If no payment methods have been used, the API returns only the default payment methods under used_methods. In most cases, the only default payment method is a bank transfer. For details, see the second example. use gateway.[msdomain]

Request (GET)

/gateway/financials/{version}/methods/{brand_id}

Parameters:

Response

Status 200

Version < 4

{
  "used_methods": [
    {
      "Visa": [
        {
          "cards": [
            "3123",
            "-XXX"
          ]
        },
        {
          "logo": "[PROMO_URL]/payment_methods/my_account/visa.png"
        }
      ]
    }
  ],
  "unused_methods": [
    {
      "Skrill": "[PROMO_URL]/payment_methods/my_account/skrill.png"
    },
    {
      "Maestro": "[PROMO_URL]/payment_methods/my_account/maestro.png"
    },
    {
      "Neteller": "[PROMO_URL]/payment_methods/my_account/neteller.png"
    },
    {
      "EcoPayz": "[PROMO_URL]/payment_methods/my_account/ecopayz.png"
    },
    {
      "clickandbuy": "[PROMO_URL]/payment_methods/my_account/clickandbuy.png"
    }
  ]
}

Version = 4

[
  {
    "name": "Visa",
    "cards": [
      "1234"
    ],
    "logo": "logo.png",
    "min": "23.11",
    "max": "105.55"
  }
]

Status 400

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

401 Response

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

Status 500

{
  "result": "internal server error"
}

Response Parameters:

Version < 4

Version = 4

Withdrawal Requirements

Check Withdrawal Requirements

This method checks the requirements for making a withdrawal. use gateway.[msdomain]

Request (GET)

/gateway/financials/{version}/requirements/{brand_id}

Parameters:

Response

Status 200

{
  "minimum_withdrawal": 5,
  "maximum_withdrawal": "100;"
}

Status 400

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

Status 400

{
  "message_format": "wagering_requirements",
  "wagering": 100
}

401 Response

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

Status 500

{
  "result": "internal server error"
}

Response Parameters:

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:

Withdrawal Cancellation

This method cancels a pending withdrawal request, based on the transaction_id in the response to the Transaction History call. Use gateway.[msdomain]

Request (PUT)

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

Parameters:

{
  "transaction_id": 0
}

Response

Status 200

{
  "message_format": "cancellation_success"
}

Status 400

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

Status 400

{
  "message_format": "cancellation_failed"
}

Status 401

{
  "errMsg": "invalid input - invalid אםלקמ"
}

Status 500

{
  "result": "internal server error"
}

Response Parameters: