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.
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.
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
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
payment_info.payment_method
String
payment_info.payment_method_name
String
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
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.
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
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
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
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"}
// With the flag request_payer_data_on_validation_failure = true// The payment method requires any of the fields so a Hosted Checkout link // is returned to collect those// Typical HOSTED response{"checkout_type":"HOSTED", "redirect_url": "https://payin.astro2pay.com/validate/eyJhbGciOiJIUzM4NCJ9.eyJqdGkiOiIzMzg4Mjc3OTIiLCJpYXQiOjE2MTY2MDcyMDIsImV4cCI6MTYxOTE5OTIwMn0.0-_gFW0F0Yk73J8SoAddPUaOrgsKILMVbYa1cZehrF_PEk6cj17dIXDDs6FRjkkd",
"deposit_id":338827792,"user_id":"4-1874596909371448397","merchant_invoice_id":"postmanTest640841435"}
// With the flag request_payer_data_on_validation_failure = true// The fields payer.phone, payer.address.state and payer.address.zip_code are not// required for the payment method// Typical ONE_SHOT response{"checkout_type":"ONE_SHOT", "redirect_url": "https://payment.directa24.com/v1/checkout/eyJhbGciOiJIUzM4NCJ9.eyJqdGkiOiIyMDQxNzcxMjMiLCJpYXQiOjE2MTY2MDY5NzcsImV4cCI6MTYxNzkwMjk3NywibGFuZ3VhZ2UiOiJwdCJ9.sVh4-WAW2Q5lehuDMWXhUuOVQUzqmN_XRrNBDhyOZUb36dWd9a6QX9i-JB_ocjWJ",
"iframe":true,"deposit_id":338827003,"user_id":"4-1874596909371448397","merchant_invoice_id":"postmanTest806586134","payment_info": {"type":"BANK_DEPOSIT","payment_method":"B","payment_method_name":"Bradesco","amount":571.03,"currency":"BRL","expiration_date":"2021-03-24 22:29:37","created_at":"2021-03-24 17:29:37","metadata": {"reference":204177123,"beneficiary_name":"Directa24 LLP","account_type":"Conta corrente","beneficiary_document_type":"CNPJ","agency":"6444","bank_url":"http://www.bradesco.com.br/html/classic/index.shtm","beneficiary_document":"37.123.123/0001-53","account":"49110-3" } }}
Request Objects
Payer Object
Field name
Format
Description
Default
Validations
Required
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)
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:
