You do not need to be a customer to try our API! Just contact our team at contact@br.ebury.com to get a free-of-charge credential and instant access to our sandbox environment.
The access to the Ebury Bank API is available using industry standard OAuth2 authentication methods for transparent and secure access to user data.
Token Generator for oAuth2:
In order to have access to your token, you need to make a request to this endpoint using HTTP Basic Authentication
(HTTP/1.0 - 11.1 Basic Authentication Scheme)
The token will expire in 24 hours after being generated, we strongly suggest replacing it 1 hour before the expiration time. Making another token request.
Due our authentication method, you need to have access to a token, which is reponsible for check your credentials. If you already got a token and the error persists, please note that a token could be expired. Call authentication service again to receive a new one. Check our API page.
If you don’t want to pass fields that are optional, your handler should not pass empty strings
You can read about REST API errors in the REST API reference. This list can help you anticipate and account for most errors. You can also learn how to handle common REST Payment API errors.
You can contact us by e-mail integration@bexs.combr or being part of our Slack channel. Our timezone is BRT
Please , note that this support will be available soon.
Represented as the “confirm” property on a payment request, it indicates that payment will check and block the amount on consumer’s balance but is awaiting the confirmation message. It is a useful function when you have to run business rules before product shipping.
Card Payment Type | Mastercard | Visa | Amex | Elo | Hipercard | Diners |
---|---|---|---|---|---|---|
Credit card | Available | Available | Available | Available | Available | Available |
Credit card with installments | Available | Available | Available | Available | Available | Available |
Credit with authentication | Available | Available | Unavailable | Unavailable | Unavailable | Unavailable |
Debit with authentication | Available | Available | Unavailable | Unavailable | Unavailable | Unavailable |
Soft Descriptor | Available | Available | Available | Available | Available | Unavailable |
We are increasing new card brands and payment types every month.
We have local support to bank slip (Boleto Bancario). Please check our API guide to know more about it.
Soon, we will have support to Online Debit (Bank Transfers) to main issuers in Brazil.
Our platform is ready to process cancellation of payments, including partial amount and with more than one cancellation, limited to total amount from payment. You can decide what rules are better to your business model.
The amount will be available on consumer bank account until 10 business days.
Partial cancellations can only be made from the next day onwards (D+N, where N is greater than 0). The limit for partial cancellations is 1 per day for each transaction (it is an acquirer limitation).
We are able to communicate consumer by e-mail about cancellation rules and events on payments. Please, let us know to activate this feature and communicate with consumer on your behalf.
While testing, use only the test credit card numbers on table bellow. Other numbers produce an error.
The expiration date must be a valid date in the future and the secure code is not validated on test environment.
Observation: To be able to use Debit Card Without Authenticate, it is necessary to have a contract with the card issuer.
Card Number | Payment Type | Installments | Http Code | Result |
---|---|---|---|---|
4556897654968402 | Credit | 3 | 200 OK | Success |
6550393682603873 | Credit | 1 | 200 OK | Success |
6550430681715066 | Credit | 1 | 422 | Denied |
4929785925958759 | Credit | 3 | 200 OK | Success |
4024007129267307 | Credit | 1 | 200 OK | Success |
4024007159375863 | Credit | 3 | 200 OK | Success |
5121116960598636 | Credit | 3 | 200 OK | Success |
342398203700310 | Credit | 3 | 200 OK | Success |
342091561592540 | Credit | 3 | 200 OK | Success |
6011652830881662 | Credit | 1 | 200 OK | Success |
6370950000000006 | Credit | 1 | 200 OK | Success |
6370950000000006 | Credit | 3 | 200 OK | Success |
6370950000000006 | Credit | 6 | 200 OK | Success |
4024007117676337 | Credit | 3 | 422 | Denied |
6370950000000005 | Credit | 2 | 422 | Denied |
4532882971768528 | Debit | 1 | 200 OK | Success |
4716071517283162 | Debit | 1 | 422 | Denied |
5532882971768528 | Debit | 1 | 200 OK | Success |
5716071517283162 | Debit | 1 | 422 | Denied |
5200000000001096 | Debit Without Authenticate | 1 | 200 OK | Success |
4000000000001000 | Debit Without Authenticate | 1 | 200 OK | Success |
2221000601734667 | Debit Without Authenticate | 1 | 422 | Denied |
4000000000001109 | Debit Without Authenticate | 1 | 422 | Denied |
Please, as national id is a mandatory field on API, please use one described on table bellow:
47418692021, 31188623001 or 32027006001
As TSP is a specialization of payments with card numbers and a service not provided by Ebury Bank, in the sandbox environment, it have to use the below pattern to inform the tokenized card number.
token-brand-card_number
Where:
All other rules at FAQ #13 are valid.
Some examples of tokenized card number following above pattern:
Token | Payment Type | Installments | Http Code | Result |
---|---|---|---|---|
token-elo-4556897654968402 | Credit | 3 | 200 OK | Success |
token-elo-4024007129267307 | Credit | 1 | 200 OK | Success |
token-elo-6550430681715066 | Credit | 1 | 422 | Denied |
token-mastercard-6550393682603873 | Credit | 1 | 200 OK | Success |
token-mastercard-6370950000000006 | Credit | 1 | 200 OK | Success |
token-mastercard-4024007117676337 | Credit | 3 | 422 | Denied |
token-visa-4929785925958759 | Credit | 3 | 200 OK | Success |
token-visa-6370950000000006 | Credit | 1 | 200 OK | Success |
token-visa-6370950000000006 | Credit | 3 | 200 OK | Success |
token-visa-6370950000000005 | Credit | 2 | 422 | Denied |
Pix payments are asynchronous and depend on the final user to finalize the payment in his own bank. This scenario cannot be replicated in the sandbox environment.
Therefore to simulate some expected scenarios for Pix payments it is necessary to send the last number of the amount field value following the payload below:
{
"amount": 1.01
}
We will be consider behavior as the table below:
Scenario Description | Decimal Number | Status after creation | Status after 3 seconds |
---|---|---|---|
QR Code generated sucessfully and after the creation approved | *.*1 | WAITING_CONSUMER | CONFIRMED |
Transaction denied on creation | *.*2 | DECLINED_BY_ISSUER | DECLINED_BY_ISSUER |
Transaction denied after the creation | *.*3 | WAITING_CONSUMER | CANCELED |
QR Code generated succesfully and payment does not receive any updates after | *.*4 | WAITING_CONSUMER | WAITING_CONSUMER |
Slip payments are asynchronous and depend on the final user to finalize the payment in his own bank. This scenario cannot be replicated in the sandbox environment.
Therefore to simulate some expected scenarios for Slip payments it is necessary to send the last number of the amount field value following the payload below:
{
"amount": 1.01
}
We will be consider behavior as the table below:
Scenario Description | Decimal Number | Status after creation | Status after 3 seconds |
---|---|---|---|
Bank slip generated sucessfully and after the creation was paid | *.*1 | WAITING_CONSUMER | CONFIRMED |
Bank slip denied on creation | *.*2 | DECLINED_BY_BUSINESS_RULES | DECLINED_BY_BUSINESS_RULES |
Bank slip expired after the creation | *.*3 | WAITING_CONSUMER | CANCELED |
Electronic Bank Transfer payments are asynchronous and depend on the final user to finalize the payment in his own bank. This scenario cannot be replicated in the sandbox environment.
Therefore to simulate some expected scenarios for Electronic Bank Transfer payments it is necessary to send the last number of the amount field value following the payload below:
{
"amount": 1.01
}
We will be consider behavior as the table below:
Scenario Description | Decimal Number | Status after creation | Status after 3 seconds |
---|---|---|---|
TED generated sucessfully and after the creation was paid | *.*1 | WAITING_CONSUMER | CONFIRMED |
TED expired after the creation | *.*3 | WAITING_CONSUMER | CANCELED |
In payments with 3DS authentication, it is necessary to send the ECI field, which indicates the authentication result of the cardholder's card, and according to it, it is decided whether the transaction will be approved or not.
Therefore, to simulate some expected scenarios for payments with 3DS authentication, let's consider the behavior according to the table below:
ECI code | Transaction Meaning | Http Code | Result |
---|---|---|---|
02 or 05 | Success in 3DS authentication by the Issuing Bank | 200 | Success |
01 or 06 | Success in 3DS authentication by Brand | 200 | Success |
00 or 07 | Authentication failed for various card-related reasons | 422 | Denied |
04 | Data Only - No Authentication | 200 | Success |
Nupay payments are asynchronous and depend on the final user to finalize the payment. This scenario cannot be replicated in the sandbox environment.
Therefore to simulate some expected scenarios for Nupay payments it is necessary to send the two last numbers of the amount field value following the payload below
{
"amount": 1.01
}
We will be consider behavior as the table below:
Scenario Description | Decimal Number | Status after creation | Status after 3 seconds |
---|---|---|---|
Payment created successfully in app and approved by client | *.01 | WAITING_CONSUMER | CONFIRMED |
Transaction denied on creation | *.02 | DECLINED_BY_ISSUER | DECLINED_BY_ISSUER |
Transaction denied after the creation | *.03 | WAITING_CONSUMER | CANCELED |
Payment generated successfully in app and payment does not receive any updates after | *.04 | WAITING_CONSUMER | WAITING_CONSUMER |
Transaction denied on creation because is canceled by Nubank (national id is not client) | *.11 | DECLINED_BY_ISSUER | DECLINED_BY_ISSUER |
Payment created successfully in app and canceled by Nubank (national id is not client) | *.12 | WAITING_CONSUMER | CANCELED |
Payment created successfully in app and canceled after client not confirm (timeout) | *.19 | WAITING_CONSUMER | CANCELED |
In card verification, All test cards listed at FAQ #13 are valid. Otherwise, the responses are based on the last number of the card sent in request.
The card brand in response will be always MASTERCARD.
We will be consider behavior as the table below:
Scenario Description | Last card number | Response in status |
---|---|---|
The card present in Card number and scenarios for test table | - | VERIFIED |
The card was checked and denied | 0 | DENIED |
The card was not checked | 1 | NOT_VERIFIED |
The card was checked successfull | 2 | VERIFIED |
The card was checked successfull with tokenize | 2 | VERIFIED + Card Token |
Error on checking card | other value | ERROR |