Testing your integration
The credit card numbers to be used in the test can be generated from any card generator site, and the behavior must follow the following rule:
| Credit card | Authorized? | Status |
|---|---|---|
| Final 0, 1 ou 4 | YES | Authorized |
| Final 2 | NO | Not Authorized |
| Final 3 | NO | Card expired |
| Final 5 | NO | Card bloqued |
| Final 6 | NO | Timeout |
| Final 7 | NO | Card canceled |
| Final 8 | RANDOM YES/NO | Authorized / Timeout |
info
Transactions in the sandbox environment involving tokenization normally work on test cards. Each card saved during the tokenization process is treated as a normal card and can be used in the simulation process.
The Security Code (CVV) information respects the following sandbox validation rule, for a CVV ending in zero "0" the card is validated, for any other value the status returns as not validated.
If you have managed to insert the credit card data into your client application, create a token, send the data to your server, and create a charge, then your integration is finished.
Anti-fraud
If you want to test anti-fraud scenarios, the value analyzed in the sandbox will be the end of the document sent in the anti-fraud node (fraudAnalysis) when creating the transaction. The status returned for anti-fraud will follow the rules set out in the table below:
| Document | Status | Declined Code |
|---|---|---|
| Final 0 | Pending | Null |
| Final 1 | Approved | Null |
| Final 2 | Fail | Random timeout ou processing_error |
| Any other value | Repproved | Null |