Cashout Creation Endpoint

Learn how to generate cashouts request by using our Cashout API v3 directly from your website

Cashout Request

POST https://api-stg.directa24.com/v3/cashout

This endpoint allows you to generate cashout requests

Headers

Name

Type

Description

Content-Type*

string

application/json

Payload-Signature*

string

Control signature

Request Body

Name

Type

Description

string

Your D24 CASHOUTS API login key

pass*

string

Your D24 CASHOUTS API pass key

external_id*

string

Unique cashout ID on the merchant end

country*

string

Country of the cashout

amount*

number

Amount of the cashout

currency

string

Currency in which the amount was specified

document_id*

string

Document ID of the beneficiary

document_type

string

Document type of the ID specified

beneficiary_id

string

beneficiary id (for anonymous)

beneficiary_name*

string

Beneficiary's name

beneficiary_lastname

string

Beneficiary's last name

string

Beneficiary's email address

phone

string

Beneficiary's phone number

bank_code

number

Beneficiary's bank code

bank_account

string

Beneficiary's bank account

bank_branch

string

Beneficiary's branch of their bank account

account_type

string

Beneficiary's account type

address

string

Beneficiary's address

city

string

Beneficiary's city

postal_code

string

Beneficiary's postal code

beneficiary_birthdate

string

Beneficiary's birthdate

notification_url*

string

URL where the notifications will be sent

comments

string

Commentaries about the cashout

on_hold

boolean

Used to mark a cashout as on hold and not process it until manually changed to pending by you

{
    "cashout_id": "8405147"
}

{
    "code": 401,
    "message": "Invalid credentials."
}

{
    "code": 303,
    "message": "Invalid bank code"
}

{
    "code": 300,
    "message": "bank_account: must not be null; Invalid Bank account"
}

{
    
    "code": 504,
    "message": "User unauthorized due to cadastral situation",
    "reason": "Underage user detected",
    "reason_code": 105
}

Request Fields Description

Field

Format

Description

Validations

string (max length: 32)

Your D24 CASHOUTS API Key, found on the Merchant Panel by going to: Settings -> API Access. Notice there are specific Cashout credentials

pass

string (max length: 32)

Your D24 CASHOUTS API Passphrase, found on the Merchant Panel by going to: Settings -> API Access. Notice there are specific Cashout credentials

external_id

string (max length: 100)

Unique cashout ID on the merchant end

country

string (length: 2)

Country code for the cashout in ISO 3166-1 alpha-2 code format

amount

Big Decimal (up to 2 decimals)

Cashout amount on the currency specified

Valid number

currency

string (length: 3)

Currency code of the amount in ISO 4217 format

document_id

string (max length: 40)

Beneficiary’s personal identification number

document_type

string (maxLength: 15)

Beneficiary’s personal identification number type

beneficiary_name

string (max length: 100)

Beneficiary's name

String of up to 100 characters

beneficiary_lastname

string (max length: 100)

Beneficiary's last name

String of up to 100 characters

string (maxLength: 100)

Beneficiary's valid email address

phone

string (maxLength: 20)

Beneficiary's phone number

bank_code

Integer (max length: 6)

Beneficiary's bank code

bank_account

string (max length: 30)

Beneficiary's bank account number

bank_branch

string (max length: 15)

Beneficiary's bank branch number

account_type

string (max length: 1)

Type of account

address

string (max length: 255)

Beneficiary's address

String of up to 200 characters

city

string (max length: 100)

Beneficiary's city

String of up to 100 characters

postal_code

string (max length: 20)

Beneficiary's postal code

beneficiary_birthdate

string (pattern: 'YYYYMMDD')

Beneficiary's birthdate

notification_url

string (max length: 300)

To be provided if the notification URL is different from the notification URL defined on the Merchant Panel

Valid URL over HTTPS

comments

string (max length: 200)

A commentary for this cashout

String of up to 200 characters

on_hold

boolean

If the merchant wants to hold the cashout and set it to process later through the merchants panel. Default: false

[true, false]

Error response

Error response fields

Field Name

Format

Description

code

Number

Error code. See the

message

String

Description of the error

reason

String

Reason description for KYC check failure. See the . *Only shown in case of code 504

reason_code

Number

Reason code for KYC check failure. See the . *Only shown in case of code 504

Error response examples

{
  "code": 300,
  "message": "bankAccount: Invalid or missing Bank account"
}

{
  "code": 303,
  "message": "Invalid bank code"
}

{
  "code": 504,
  "message": "User unauthorized due to cadastral situation."
  "reason": "Underage user detected",
  "reason_code": 105
}

Fields required

Each country has different requirements and therefore we ask for different fields you need to send on the requests.

Go to the Countries Validations page to check each country requirements and validations.

Cashouts to debit cards

In Mexico, we accept cashouts sent directly to debit cards.

When that happens, you need to send the request through a different endpoint, otherwise your request will be declined with Invalid bank account, it shouldn't be a credit card.

PROD endpoint for Debit Cards: Email integration@d24.com with your cashout API Key

STG endpoint for Debit Cards: https://cc-api-stg.directa24.com/v3/cashout

The bank accounts in Mexico are in CLABE format (numeric) and have 18 digits (without dashes). Therefore one way to detect that a bank account specified by the customer is a debit card is by checking with the luhn algorithm if it is a valid card number and/or with a regex for each brand, like the example below.

public static final String SENSIBLE_DATA_PATTERN = new StringBuilder("(?:(?<visa>4[0-9]{12}(?:[0-9]{3})?)")
      .append("|(?<mastercard>5[1-5][0-9]{14})")
      .append("|(?<discover>6(?:011|5[0-9]{2})[0-9]{12})")
      .append("|(?<amex>3[47][0-9]{13})")
      .append("|(?<diners>3(?:0[0-5]|[68][0-9])?[0-9]{11})")
      .append("|(?<jcb>(?:2131|1800|35[0-9]{3})[0-9]{11}))")
      .toString();

private boolean validateCreditCard(CashoutRequestDto request) {
   final String bankAccount = request.getBank_account();
   if (StringUtils.isEmpty(bankAccount) || !LuhnCheckDigit.LUHN_CHECK_DIGIT.isValid(bankAccount) || 
      bankAccount.matches(Constants.SENSIBLE_DATA_PATTERN)) {
      return false;
   }
   return true;
}

If true, send the request through the cc-api endpoint, if false send it through the normal endpoint. The integration and requirements remains exactly the same, only changing the error message returned in case of invalid bank account and that we validate the bank_account sent to be a valid credit card number using the Luhn Algorithm.

Sending a debit card number through the non-cc endpoint will make the request to fail with the following error:

{
    "code": 300,
    "message": "bank_account: Invalid bank account, it shouldn't be a credit card"
}

Invalid bank_account error on the cc-api endpoint:

{
    "code": 300,
    "message": "bankAccount: invalid credit card number"
}

PreviousEndpoints NextNotifications

Last updated 7 months ago