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:
| Description |
| The deposit request was successfully completed in One Shot and the user will be directly presented with the information to complete the payment. |
| 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.
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 |
| object | Object containing the metadata of the payment |
| string | Name of the account beneficiary |
| string | Agency of the beneficiary |
| string | CNPJ of the beneficiary |
| string | Account of the beneficiary |
| string | Voucher bar code token |
| string | Voucher identifier line |
| string | Document number of the payer |
| string | Type of the payer's document sent |
| string | Reference your customer needs to pay |
| object | Object containing the secondary metadata of the payment |
| string | Reference of the deposit |
| string | PNG image encoded in base64 of the QR code used to display the Pix QR natively on your site |
| string | Plain text string line the user can use to manually pay for the PIX instead of scanning the QR |
| string | Token needed to display the Cards SDK component. |
Please note that the metadata
and the secondary_metadata
objects 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
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 |
| String | Field containing the type of the request. |
| URL | URL used to redirect the customer where they can see the details to pay |
| Integer | ID of the deposit generated. Store this ID for future reference |
| String | ID of the user. If you didn't send it, it is generated by us |
| String | ID of the deposit. If you didn't send it, it is generated by us |
| Object | Object containing the information about the payment |
| String | Type of the payment method. See the list here. |
| String | Payment method code. See the list here. |
| String | Payment method name. See the list here. |
| number | Exact amount the customer has to pay |
| string | Currency of the amount to pay |
| string | Date in which the deposit will be marked as expired |
| string | Deposit creation date |
Success Response example
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
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 |
| String | Field containing the type of the request. |
| URL | URL used to redirect the customer to our Hosted Checkout |
| Number | ID of the deposit on Directa24 end |
| String | ID of the user on your end. If you didn't send it, it is generated by us |
| 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
Click here for the error response format.
Error Response
Error Response fields
Field name | Format | Description |
| Number | Error code. See the list of error codes |
| String | Description of the error |
| String | Details about the errors. It is not always shown |
| String | Error code name. It is not always shown. See the list of error codes |
| Number | Reason code for KYC check failure. See the list of reason codes |
| 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
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 |
| string (length: 2) | Country code of the deposit in ISO 3166-1 alpha-2 code format | ||
| decimal (max decimals: 2) | Deposit amount in the currency specified | Number of up to 18 integers and 2 decimals places | |
| string (length: 3) | Currency code of the amount in ISO 4217 format |
| |
| string (max length: 128) | Unique deposit ID on the merchant end | random |
|
| string | Optional parameter to include additional internal information on the merchant end. | ||
| 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 |
|
| object[] | Object containing details about the customer | ||
| string (max length: 3) | Payment method code | ||
| string | Type of payment methods to show the customer. If | All | |
| array | Same as | All | |
| integer | Used to specify for which SubMerchant ID the deposit will be created. | ||
| boolean | Used to specify if the credit card deposit can be created with installments. For more info visit this link. |
| |
| 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 | ||
| object[] | Object containing details about the bank account from which the deposit will be made | ||
| 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 | |
| boolean | Choose if the deposit's fee will be paid by the customer or debited from your balance |
|
|
| boolean | Choose if the surcharge will be paid by the customer or debited from your balance |
|
|
| decimal (max decimals: 2) | Used to show the customer a bonus amount. I.e.: User will see: Pay 100, receive 150 | Number of up to 18 integers and 2 decimals | |
| boolean | Used to define if the |
|
|
| decimal (max decimals: 2) | Used to show the customer a strikethrough amount. I.e.:
Before: | Number of up to 18 integers and 2 decimals | |
| 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 | |
| string | Valid IPv4 or IPv6 Address |
| |
| string (max length: 100) | Unique customer's device ID. Used to identify and prevent fraud. | String of up to 100 characters | |
| 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 | |
| string (max length: 2048) | Valid URL over HTTPS used to redirect the customer in case of a pending (in process) deposit. |
| |
| string (max length: 2048) | Valid URL over HTTPS used to redirect the customer in case the deposit flow was completed. |
| |
| string (max length: 2048) | Valid URL over HTTPS used to redirect the customer in case of error while generating the deposit |
| |
| 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 |
| |
| 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 |
| |
| boolean | Used to flag a deposit as test. If true, the deposit will not affect the merchant's balance |
|
|
| boolean | Used to specify if the redirection will be made on a mobile device |
|
|
| 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 |
|
|
| boolean | Used to indicate if the |
|
|
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:
Request Objects
Payer Object
Field name | Format | Description | Default | Validations | Required |
---|---|---|---|---|---|
| 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 |
| Recommended |
| 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 | ||
| string (max length: 10) | Customer's document type. Optional, if sent must be a valid document type | Yes | ||
| string (max length: 255) | Valid customer's email address | Valid email address | Yes | |
| string (max length: 128) | Customer's first name | String of up to 128 characters | Yes | |
| string (max length: 128) | Customer's last_name | String of up to 128 characters | Yes | |
| object | Object containing customer's address details | No | ||
| string (max length: 32) | Valid customer's phone number | No | ||
| string (max length: 8) | Customer's birthdate in format yyyyMMdd. E.g.: 19801027 | Numeric format expected: | No | |
| string (max length: 8) | Customer's registration date in your website in UTC with format yyyyMMdd. E.g.: 20211123 |
| Numeric format expected: | No |
Payer.address Object
Field name | Format | Description | Validations |
| string (max length: 255) | Customer's street | String of up to 255 characters |
| string (max length: 128) | Customer's city | String of up to 128 characters |
| 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 |
| 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 |
| string (max length: 45) | Bank account number of the customer | String of up to 45 characters |
| string (max length: 45) | Bank branch of the customer's bank account | String of up to 45 characters |
| string (max length: 255) | Bank account owner name | String of up to 255 characters |
| 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 |
| ||
BR | SJ | Sicredi | ^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$ |
| |
BR | B | Bradesco | ^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$ |
| |
BR | SF | Banco Safra | ^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$ |
| |
BR | BB | Banco Brasil | 00000000000-A | ^\d{1,11}-[\da-zA-Z]$ |
|
BR | BB | Banco Brasil | 0000-A | ^\d{1,4}(-[\da-zA-Z])?$ |
|
BR | BZ | Banco Original | 0000 | ^\d{1,4}?$ |
|
BR | CA | Caixa | 0000 | ^\d{1,4}?$ |
|
BR | BZ | Banco Original | 000000000-0 | ^\d{1,9}-\d$ |
|
BR | CA | Caixa | 000000000-0 | ^\d{1,14}-\d$ |
|
CL | IA | Itau | ^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$ |
| |
CL | SC | Santander | ^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$ |
| |
CL | TY | Security | ^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$ |
| |
PA | DI | Credicorp | ^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$ |
| |
PE | BC | BCP | ^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$ |
| |
PE | IB | InterBank | ^[^\d\s]{2,30}(\s[^\d\s]{2,30})+$ |
|
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 |
| string (max length: 10) | Symbol of the Cryptocurrency | |
| string (max length: 128) | Address of the payer's crypto e-wallet | String of up to 128 characters |
| string (max length: 12) | Network of the wallet | Valid network symbol |
Cryptocurrency symbols
Name | Symbol |
---|---|
Binance USD | BUSD |
DAI | DAI |
RIF Dollar | RDOC |
Tether | USDT |
USD Coin | USDC |
Networks
Network | Symbol |
---|---|
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 MethodsLast updated