checkout_type
will be part of the response, containing which one of the flows it is:Checkout_type
ONE_SHOT
HOSTED
metadata
and secondary_metadata
objects containing the information you need to build your own checkout for each payment method:metadata
metadata.beneficiary_name
metadata.agency
metadata.CNPJ
metadata.account
metadata.bar_code
metadata.digitable_line
metadata.payer_document
metadata.payer_document_type
metadata.reference
secondary_metadata
secondary_metadata.reference
secondary_metadata.qr_code
secondary_metadata.digitable_line
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.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.checkout_type
[ONE_SHOT, HOSTED]
redirect_url
deposit_id
user_id
merchant_invoice_id
payment_info
payment_info.amount
payment_info.currency
payment_info.expiration_date
payment_info.created_at
payment_method
, first_name
and last_name
which are required for OneShot.payment_method
.checkout_type
[ONE_SHOT, HOSTED]
redirect_url
deposit_id
user_id
merchant_invoice_id
description
details[]
crypto
with the currency
and the wallet
address. Please click here for more details about the crypto
object.country
amount
invoice_id
^[A-Za-z0-9-_]*$
request_payer_data_on
_validation_failure
[true, false]
payment_type
null
is sent and payment_method
is null
, "ALL"
will be assumedpayment_types
payment_type
but multiple payment methods' types can be specified with an array. I.e.: payment_types: ["BANK_DEPOSIT", "BANK_TRANSFER"]
reported_info
bank_account
fee_on_payer
false
[true, false]
surcharge_on_payer
true
[true, false]
bonus_amount
amount:100, bonus_amount:50
bonus_relative
bonus_amount
was specified as a percentage of the amount
or as an absolute valuefalse
[true, false]
strikethrough_price
description
client_ip
IPv4/v6 Address
device_id
bonus_amount
, bonus_relative
, strikethrough_price
, and description
only affect our Hosted Checkout GUI and doesn't affect any balance or calculations. https://www.example.com/deposit/{deposit_id_hashed}/pending
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
.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. 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
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
.