Deposit Creation Endpoint

Learn how to generate deposits

Experiences

When generating a deposit request there are 2 possibilities, either the deposit is created in One Shot and you can display the user directly with the payment information, or you redirect the user to our Hosted Checkout to complete the missing details.

In any of those cases, a field called checkout_type will be part of the response, containing which one of the flows it is:

Checkout_type

Description

ONE_SHOT

The deposit request was successfully completed in One Shot and the user will be directly presented with the information to complete the payment.

HOSTED

The information sent is missing details required to complete the request. Redirect the customer to our Hosted Checkout to collect those details.

This flow works as a fallback method, so that in cases which by mistake a piece of information was missing or additional information is required in order to create a Deposit, we can collect it and avoid a failure in the deposit creation.

Test all the API features with our Postman collection here.

OneShot Experience

On this Experience, you will send all the information required to complete the deposit request and we will respond you with the payment metadata for you to build the Checkout or with an external link for the user to see the payment information.

In case you didn't send one field that is required, we won't decline the request and instead we will prompt the customer for it 😉 .

OneShot Request example

Each Country and Payment Method has a minimum set of fields you need to send for the OneShot Experience. In case of looking to develop this Experience on your Cashier visit the Payment Methods page to learn more about those requirements.

{
    "invoice_id" : "1000000001",
    "amount": "1000",
    "country": "BR",
    "currency": "BRL",
    "payer": {
        "id": "11",
        "document": "84932568207",
        "first_name": "Ricardo",
        "last_name": "Carlos",
        "email": "juanCarlos@hotmail.com",
        "phone": "+23385266942",
        "address": {
            "street": "Rua 13",
            "city": "bahia",
            "state": "SP",
            "zip_code": "12345-678"
        }
    },
    "payment_method": "BL",
    "description": "test description",
    "client_ip": "123.123.123.123",
    "device_id": "00000000-00000000-01234567-89ABCDEF",
    "back_url": "https://www.d24.com/deposit_cancelled",
    "success_url": "https://www.d24.com/deposit_completed",
    "error_url": "https://www.d24.com/deposit_error",
    "notification_url": "https://www.d24.com/d24/notify",
    "logo": "https://www.d24.com/d24.png",
    "test": true,
    "mobile": false,
    "language": "pt"
}

OneShot Experience Response: OneShot

In case you sent all the details required for a payment method and the method supports it, we will return you all the metadata required for you to build the checkout on your own website avoiding the redirection.

Success Response fields

The fields returned in this integration are the same than the REDIRECT one. The difference lies in the new metadata and secondary_metadata objects containing the information you need to build your own checkout for each payment method:

Field name

Format

Description

metadata

object

Object containing the metadata of the payment

metadata.beneficiary_name

string

Name of the account beneficiary

metadata.agency

string

Agency of the beneficiary

metadata.CNPJ

string

CNPJ of the beneficiary

metadata.account

string

Account of the beneficiary

metadata.bar_code

string

Voucher bar code token

metadata.digitable_line

string

Voucher identifier line

metadata.payer_document

string

Document number of the payer

metadata.payer_document_type

string

Type of the payer's document sent

metadata.reference

string

Reference your customer needs to pay

secondary_metadata

object

Object containing the secondary metadata of the payment

secondary_metadata.reference

string

Reference of the deposit

secondary_metadata.qr_code

string

PNG image encoded in base64 of the QR code used to display the Pix QR natively on your site

secondary_metadata.digitable_line

string

Plain text string line the user can use to manually pay for the PIX instead of scanning the QR

checkout_token

string

Token needed to display the Cards SDK component.

Please note that the metadata and the secondary_metadataobjects will respond with different values depending upon the payment method and the provider we use, the ones above are only examples. It is for that reason that you should be able to iterate through them to display the values on your cashier to your customers.

Success Response example

{
    "checkout_type": "ONE_SHOT",
    "redirect_url": "https://payment-stg.directa24.com/v1/checkout/eyJhbGciOiJIUzM4NCJ9.eyJqdGkiOiI1NjYwODA5NSIsImlhdCI6MTYyMTUzOTYzNCwiZXhwIjoxNjIyODM1NjM0LCJsYW5ndWFnZSI6InB0In0.dDo0kMPEhZRSSeDPiH8Km0EXD1zEd1kg0gFdyhOvQ5iBfPl9skD2NYuD2_b-spE2",
    "iframe": true,
    "deposit_id": 300642187,
    "user_id": "kj2n3432n4k23",
    "merchant_invoice_id": "postmanTest433710480",
    "payment_info": {
        "type": "VOUCHER",
        "payment_method": "IX",
        "payment_method_name": "Pix",
        "amount": 11.65,
        "currency": "BRL",
        "expiration_date": "2021-05-20 22:47:33",
        "created_at": "2021-05-20 19:40:32",
        "metadata": {
            "reference": 56608095,
            "qr_code": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAH0AAAB9AQAAAACn+1GIAAACMUlEQVR4Xt3UMZKsIBAGYEjkCkOCV1sTuQIkioleQRK4miRyhSahH6Uzr2qRucASflXa0Pw0wd8LyJ8CIEKwUwentKFNSGi3tLlu3haf2rB4mHqjlAw7/wI2Rsc9HvIreKeoefFz/gZozWC9Rev/7+M3AOH2vT5nqQAxMyD9TtF++lEBUMOSIZ0gapRNSOeQGYZohui+AV9fMwjphLq3XgOuetmyXHaJRjcBRtEJac+Rm942IW0Jo5tGnuW77AOMGLJMIVMzXT99AIZDdUInM2fShpQp/NC4uaG0uwlZSfRYKsu4XmWfwFYdfHTzTtT10wckGF9TJ0HJ8122BhjsVgLjSlz80oaXUorazI9J3DdXQzI0hJKEg+7vKjVgSE6R3hpp4Qske+rFrtOPttfxH5BsCuvst/1Hw132ASVTYiQMLdDUBOgz3UI49Bbyffwa0kpI+UT0dqV32RowphDdi3nM9/EfUK4y4WYk8O0O3RPW+RyFtscM7wTVkBXzaZ8YmmG5yj4A95F0E7U263zvowbQPqZVsQhjx5uQ1ZCnjsJwknFuAhpmSxzwLB26y9ZQHnqnSKcYzD62YXr1B3caBLsHyhNYeX8h2kPC9I52BdCbrowtloeD+iaUMcM39Isv2brKPqCMLScm7oHbe/Q9IKEbbPJliCYY2rDYQ0jDYgB6PY8WlAbJoz+0+XzygKU0aSzZxWvrT8BdSY/p4NHd+agByEsMRskYYrqfaQ2/19+GfwmGnDkcom5PAAAAAElFTkSuQmCC",
            "digitable_line": "00020126850014br.gov.bcb.pix2563qrcodepix.bb.com.br/pix/v2/ab4d2855-ee85-401a-a16d-716c743aa3af5204000053039865802BR5909AP Brasil6003Pix62070503***6304428B"
        }
    }
}

// Metadata explanation
//
// reference: ID of the deposit on our end.
//
// qr_code: PNG image encoded in base64. You can use the following HTML tag 
//          to render the QR code on your website: 
// <img src='qr_code'/>
//
// digitable_line: Plain text string line the user can use to manually pay for the PIX 
//                 instead of scanning the QR
//
// Make sure the user can't see the QR code after the expiration_date was reached

        

This integration is an extension of the REDIRECT one. It will always contain a link to redirect the customer in case you don't wan't to develop the checkout with the metadata on your website.

Secondary Metadata

The object secondary_metadata is used to display the customer with a second way to pay for the same deposit allowing them to choose the best option. For example, the user could create a deposit for a bank deposit method in Brasil, and show them our Bank Details (field metadata) as well as a Pix QR code (field secondary_metadata) in case they prefer that option.

OneShot Experience Response: Redirect

This integration generates a link to redirect the customer where they will see the details required to pay.

Success Response fields

Field name

Format

Description

checkout_type

String

Field containing the type of the request. [ONE_SHOT, HOSTED]

redirect_url

URL

URL used to redirect the customer where they can see the details to pay

deposit_id

Integer

ID of the deposit generated. Store this ID for future reference

user_id

String

ID of the user. If you didn't send it, it is generated by us

merchant_invoice_id

String

ID of the deposit. If you didn't send it, it is generated by us

payment_info

Object

Object containing the information about the payment

payment_info.type

String

Type of the payment method. See the list here.

payment_info.payment_method

String

Payment method code. See the list here.

payment_info.payment_method_name

String

Payment method name. See the list here.

payment_info.amount

number

Exact amount the customer has to pay

payment_info.currency

string

Currency of the amount to pay

payment_info.expiration_date

string

Date in which the deposit will be marked as expired

payment_info.created_at

string

Deposit creation date

Success Response example

{
    "checkout_type": "ONE_SHOT",
    "redirect_url": "https://payment-stg.directa24.com/v1/checkout/eyJhbGciOiJIUzM4NCJ9.eyJqdGkiOiI1NjU3ODQ2NCIsImlhdCI6MTU5MTgyOTYzNiwiZXhwIjoxNTkzMTI1NjM2LCJsYW5ndWFnZSI6bnVsbH0.XIlYyskFpE_rh1-8sA0Bs3JzB2iMmqAXdovClPzorrZXmzol69JqkeU7TR5FMBRn",
    "deposit_id": 300000011,
    "user_id": "11",
    "merchant_invoice_id": "test123456789",
    "payment_info": {
        "type": "VOUCHER",
        "payment_method": "BC",
        "payment_method_name": "BCP",
        "amount": 6.9448,
        "currency": "PEN",
        "expiration_date": "2020-06-15 22:53:56",
        "created_at": "2020-06-10 22:53:55"
    }
}

Hosted Checkout Experience

In case that you can't collect any of the details required for the OneShot Experience, you can avoid sending it.

Using OneShot improves the experience because it reduces the amount of interactions required by the end-user.

The more details you send will personalize the Experience on our Hosted Checkout and will help in not having to ask the customer for the information again.

Hosted Checkout Request

Request Example

{
    "invoice_id" : "1000000001",
    "amount": "1000",
    "country": "BR",
    "currency": "BRL",
    "payer": {
        "id": "11",
        "document": "84932568207",
        "email": "juanCarlos@hotmail.com"
    },
    "description": "test description",
    "client_ip": "123.123.123.123",
    "back_url": "https://www.d24.com/deposit_cancelled",
    "success_url": "https://www.d24.com/deposit_completed",
    "error_url": "https://www.d24.com/deposit_error",
    "notification_url": "https://www.d24.com/d24/notify",
    "logo": "https://www.d24.com/d24.png",
    "test": true,
    "request_payer_data_on_validation_failure": true,
    "mobile": false,
    "language": "pt"
}

Notice that this request will return a Hosted Checkout because we didn't include the fields payment_method, first_name and last_name which are required for OneShot.

Hosted Checkout Response: Success

Response Fields

Field name

Format

Description

checkout_type

String

Field containing the type of the request. [ONE_SHOT, HOSTED]

redirect_url

URL

URL used to redirect the customer to our Hosted Checkout

deposit_id

Number

ID of the deposit on Directa24 end

user_id

String

ID of the user on your end. If you didn't send it, it is generated by us

merchant_invoice_id

String

ID of the deposit on your end. If you didn't send it, make sure you save it as it is generated auto-generated and may be needed in the future (See refunds)

Response Example

{
    "checkout_type": "HOSTED",
    "redirect_url": "https://payin-stg.directa24.com/validate/eyJhbGciOiJIUR_JErX-j3S1pVaD",
    "deposit_id": 300000010,
    "user_id": "4-2845801292757825290",
    "merchant_invoice_id": "100000001"
}

Click here for the error response format.

Error Response

Error Response fields

Field name

Format

Description

code

Number

Error code. See the list of error codes

description

String

Description of the error

details[]

String

Details about the errors. It is not always shown

type

String

Error code name. It is not always shown. See the list of error codes

reason_code

Number

Reason code for KYC check failure. See the list of reason codes

reason

String

Reason description for KYC check failure. See the list of all reason descriptions

Error Response examples

In case of error due to KYC check, we display two extra fields reason and reason_code. The list of errors can be found here

{
    "code": 201,
    "description": "Field validation error. Check details",
    "details": [
        "payer.document: Invalid document type and/or document",
        "payer.address.state: Invalid State for Country"
    ]
}

{
    "code": 201,
    "description": "Field validation error. Check details",
    "details": [
        "amount: invalid numeric format",
        "country: Invalid value. Accepted values: AR|BR|CL|CM|CN|CO|EC|GH|IN|ID|KE|MY|MX|NG|PA|PE|PH|PY|TH|TZ|UG|UY|VN|ZA"
    ]
}

{
    "code": 502,
    "description": "Invalid request body",
    "type": "INVALID_REQUEST_BODY"
}

{
    "code": 304,
    "description": "The user limit has been exceeded: TRANSACTION",
    "type": "USER_LIMIT_EXCEEDED"
}

{
    "code": 303,
    "description": "User rejected after KYC check",
    "type": "USER_REJECTED_KYC_CHECK",
    "reason": "Underage user detected",
    "reason_code": 105
}

{
    "code": 201,
    "description": "Field validation error. Check details",
    "details": [
        "invoiceId: must match \"^[A-Za-z0-9-_]*$\""
    ],
    "type": "BEAN_VALIDATION_ERROR"
}

Crypto payments

Please get in touch with your Account Manager in order to start processing payments with Cryptocurrencies.

When processing payments to a Cryptocurrency e-wallet, you must send in the request an object called crypto with the currency the wallet address and the network the wallet belongs to. Please click here for more details about the crypto object.

To retrieve the actual exchange of any currency against a cryptocurrency, please use the Crypto Exchange Endpoint.

When a customer pays a crypto transaction, the money is credited directly into the customer's wallet address and not into your merchant balance. After the transaction was paid by the customer, the status of the transaction will be APPROVED while we are transferring the funds to the user's wallet. As soon as the money gets into the user's wallet, the deposit will change to COMPLETED status. Please click here for more information about deposit statuses.

Request Fields Description

Field name

Format

Description

Default

Validations

country

string (length: 2)

Country code of the deposit in ISO 3166-1 alpha-2 code format

amount

decimal (max decimals: 2)

Deposit amount in the currency specified

Number of up to 18 integers and 2 decimals places

currency

string (length: 3)

Currency code of the amount in ISO 4217 format

USD

invoice_id

string (max length: 128)

Unique deposit ID on the merchant end

random

^[A-Za-z0-9-_]*$

merchant_external_reference

string

Optional parameter to include additional internal information on the merchant end.

request_payer_data_on

_validation_failure

boolean

Boolean used to specify if you want to receive declines by invalid data even if it is not required by the payment method. here for more info

false

[true, false]

payer

object[]

Object containing details about the customer

payment_method

string (max length: 3)

Payment method code

payment_type

string

Type of payment methods to show the customer. If null is sent and payment_method is null, "ALL" will be assumed

All

payment_types

array

Same as payment_type but multiple payment methods' types can be specified with an array. I.e.: payment_types: ["BANK_DEPOSIT", "BANK_TRANSFER"]

All

sub_merchant_id

integer

Used to specify for which SubMerchant ID the deposit will be created.

allow_installments

boolean

Used to specify if the credit card deposit can be created with installments. For more info visit this link.

false

reported_info

object[]

Object containing details about the bank account from which the deposit will be made. Used in ONE_SHOT mode to auto-detect user's payment

bank_account

object[]

Object containing details about the bank account from which the deposit will be made

expiration

numeric

Used to express, in minutes, how long after its creation the deposit should expire. Cannot be more than the default expiration of the payment method.

Number of up to 5 integers

fee_on_payer

boolean

Choose if the deposit's fee will be paid by the customer or debited from your balance

false

[true, false]

surcharge_on_payer

boolean

Choose if the surcharge will be paid by the customer or debited from your balance

true

[true, false]

bonus_amount

decimal (max decimals: 2)

Used to show the customer a bonus amount. I.e.: amount:100, bonus_amount:50

User will see: Pay 100, receive 150

Number of up to 18 integers and 2 decimals

bonus_relative

boolean

Used to define if the bonus_amount was specified as a percentage of the amount or as an absolute value

false

[true, false]

strikethrough_price

decimal (max decimals: 2)

Used to show the customer a strikethrough amount. I.e.: Before: 150 Now: 100

Number of up to 18 integers and 2 decimals

description

string (max length: 100)

Deposit description. It will be shown to the customer on our Hosted Checkout as the description of the product to be acquired

String of up to 100 characters

client_ip

string

Valid IPv4 or IPv6 Address

IPv4/v6 Address

device_id

string (max length: 100)

Unique customer's device ID. Used to identify and prevent fraud.

String of up to 100 characters

language

string (length: 2)

Language to show the customer on the deposit page in ISO 639-1 code format. *Not all the languages are available

String of 2 characters [es, en, pt, ja]

back_url

string (max length: 2048)

Valid URL over HTTPS used to redirect the customer in case of a pending (in process) deposit.

HTTPS URL

success_url

string (max length: 2048)

Valid URL over HTTPS used to redirect the customer in case the deposit flow was completed.

HTTPS URL

error_url

string (max length: 2048)

Valid URL over HTTPS used to redirect the customer in case of error while generating the deposit

HTTPS URL

notification_url

string (max length: 2048)

Valid URL over HTTPS used to receive the notifications about the deposit's changes of status. If none is sent, we will use the one configured on the Merchant Panel

HTTPS URL

logo

string (max length: 2048)

Valid URL over HTTPS used to show your logo on our Hosted Checkout Experience. If none is sent, we will use the one configured on the Merchant Panel

HTTPS URL

test

boolean

Used to flag a deposit as test. If true, the deposit will not affect the merchant's balance

false

[true, false]

mobile

boolean

Used to specify if the redirection will be made on a mobile device

false

[true, false]

early_release

boolean

Used to specify if the deposit should be early released. Useful when you want to release payments to your VIP users before it were completed

false

[true, false]

requested_token

boolean

Used to indicate if the checkout_token is needed in the response.

false

[true, false]

The fields bonus_amount, bonus_relative, strikethrough_price, and description only affect our Hosted Checkout GUI and doesn't affect any balance or calculations.

Using the same back_url, success_url and error_url is ok if you want to show your customers with a generic message when being redirected. Even better is to generate one unique link for each deposit for better user experience when being redirected. I.e.: https://www.example.com/deposit/{deposit_id_hashed}/pending

Required flags

We recommend sending the following flags to prevent declines and improve conversion rates.

mobile

The flag mobile is a boolean and has to be sent equal to true if the customer generating the deposit is using a mobile device/application. If not sent it defaults to false.

There are some payment methods that have a different flow on mobile devices compared to the flow on web devices because the payment method doesn't work the same way in those devices. When a deposit gets created as ONE_SHOT, it means the flow is assigned before the user navigates into our website, and therefore, we can't identify if the customer comes from a mobile device or not.

Considering that, if the flag mobile is not sent we could route a mobile user through the web flow, therefore, affecting the ability of the customer to complete the deposit.

request_payer_data_on_validation_failure

The flag request_payer_data_on_validation_failure can be used to prevent the request to be declined in case you send an invalid payer.phone, payer.address.state and/or payer.address.zip_code.

If it is required by the payment method, we will return you with a HOSTED CHECKOUT link where the customer will fill in the incorrect details on our checkout and if the details is not needed by the payment method, it will be ignored and the link for ONE SHOT will be returned.

Example responses:

// With the flag request_payer_data_on_validation_failure = false
// or not sent (it defaults to false)

{
    "code": 201,
    "description": "Field validation error. Check details",
    "details": [
        "payer.address.zipCode: Invalid zip code format for Country",
        "payer.address.state: Invalid State for Country",
        "payer.phone: Invalid phone for Country"
    ],
    "type": "BEAN_VALIDATION_ERROR"
}

Request Objects

Payer Object

Field nameFormatDescriptionDefaultValidationsRequired

id

string (max length: 128)

Customer's ID generated on your end. Used to locate user's transaction on our Merchant Panel

If none is sent, we will autogenerate it

^[A-Za-z0-9]*$

Recommended

document

string (max length: 30)

Customer's document ID. Ensure it is correct and the user can't change it every time he/she deposits

Yes

document_type

string (max length: 10)

Customer's document type. Optional, if sent must be a valid document type

Yes

email

string (max length: 255)

Valid customer's email address

Valid email address

Yes

first_name

string (max length: 128)

Customer's first name

String of up to 128 characters

Yes

last_name

string (max length: 128)

Customer's last_name

String of up to 128 characters

Yes

address

object

Object containing customer's address details

No

phone

string (max length: 32)

Valid customer's phone number

No

birth_date

string (max length: 8)

Customer's birthdate in format yyyyMMdd. E.g.: 19801027

Numeric format expected: yyyyMMdd

No

registration_date

string (max length: 8)

Customer's registration date in your website in UTC with format yyyyMMdd. E.g.: 20211123

Numeric format expected: yyyyMMdd

No

Payer.address Object

Field name

Format

Description

Validations

street

string (max length: 255)

Customer's street

String of up to 255 characters

city

string (max length: 128)

Customer's city

String of up to 128 characters

state

string (max length: 3)

Customer's state code in ISO 3166-2 code format

Valid state code in ISO 3166-2 format. Check our States endpoint here

zip_code

string (max length: 16)

Customer's zip code

Reported_info Object

This object will be used to auto-detect the user payment in our bank extracts.

This information is mandatory for some payment methods if you would like to use the ONE_SHOT experience by building your own cashiers with the metadata. If not sent, we will ask the customer for it on our hosted payment page.

If used with the redirect flows, we will automatically populate the fields with the information sent.

Field name

Format

Description

Validations

bank_account_number

string (max length: 45)

Bank account number of the customer

String of up to 45 characters

bank_branch

string (max length: 45)

Bank branch of the customer's bank account

String of up to 45 characters

bank_beneficiary

string (max length: 255)

Bank account owner name

String of up to 255 characters

bank_account_type

string (max length: 16)

Bank account type of the customer

Payment Methods requiring the reported_info object

See in the below table the list of fields required for each payment method.

Country

Payment Method Code

Payment Method Name

Field Mask

Field Regex

Field Name

BR

CA

Caixa

bank_account_type

BR

SJ

Sicredi

^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$

bank_beneficiary

BR

B

Bradesco

^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$

bank_beneficiary

BR

SF

Banco Safra

^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$

bank_beneficiary

BR

BB

Banco Brasil

00000000000-A

^\d{1,11}-[\da-zA-Z]$

bank_account_number

BR

BB

Banco Brasil

0000-A

^\d{1,4}(-[\da-zA-Z])?$

bank_branch

BR

BZ

Banco Original

0000

^\d{1,4}?$

bank_branch

BR

CA

Caixa

0000

^\d{1,4}?$

bank_branch

BR

BZ

Banco Original

000000000-0

^\d{1,9}-\d$

bank_account_number

BR

CA

Caixa

000000000-0

^\d{1,14}-\d$

bank_account_number

CL

IA

Itau

^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$

bank_beneficiary

CL

SC

Santander

^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$

bank_beneficiary

CL

TY

Security

^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$

bank_beneficiary

PA

DI

Credicorp

^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$

bank_beneficiary

PE

BC

BCP

^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$

bank_beneficiary

PE

IB

InterBank

^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$

bank_beneficiary

Account types

Caixa requires the field bank_account_type to be sent, here is the possible values to be sent:

Country

Payment Method Code

Payment Method Name

Value

Description

BR

CA

Caixa

001

001 - Conta Corrente - P.Física

BR

CA

Caixa

002

002 - Conta Simples - P.Física

BR

CA

Caixa

003

003 - Conta Corrente - P.Jurídica

BR

CA

Caixa

006

006 - Entidades Públicas

BR

CA

Caixa

013

013 - Poupança de P.Física

BR

CA

Caixa

022

022 - Poupança - P.Jurídica

BR

CA

Caixa

023

023 - Conta CAIXA Fácil

BR

CA

Caixa

028

028 - Poupança de Crédito Imobiliário

Crypto object

This object will be used to specify that the deposit will be credited into a crypto e-wallet.

Field name

Format

Description

Validations

currency

string (max length: 10)

Symbol of the Cryptocurrency

wallet

string (max length: 128)

Address of the payer's crypto e-wallet

String of up to 128 characters

network

string (max length: 12)

Network of the wallet

Valid network symbol

Cryptocurrency symbols

NameSymbol

Binance USD

BUSD

DAI

DAI

RIF Dollar

RDOC

Tether

USDT

USD Coin

USDC

Networks

NetworkSymbol

AVAX C-Chain

AVAXC

BNB Beacon Chain

BEP2

BNB Smart Chain

BEP20

Ethereum

ERC20

Polygon

Polygon

Solana

Solana

Tron

TRC20

Tezos

Tezos

RSK

RSK

For other networks not in that list please reach out to your Account Manager.

Payment Methods fields requirements

Click on the link below to learn about our Payment Methods and the fields required for each of them:

Payment Methods

Last updated

#864: SDK Without User interface explanation

Change request updated