Integration test
Before going live, we recommend testing the proper functioning of your integration and transaction processing. This will allow you to verify if the integration was done correctly and if payments are being processed without errors. See below how to test your integration.
The Payouts integration test consists of creating transactions with predefined status. These status will be defined based on the value you send for the external_reference field. In other words, you will send data to create a transaction based on the status you want to obtain as a response and, in this way, you can verify if the processing is happening correctly. For example, if the field external_reference=new, a status=new should be returned.
To test your integration with Payouts, create transactions by sending a POST, with your test Access TokenPrivate key of the application created in Mercado Pago and used in the backend. You can access it through Your integrations > Integration data > Tests > Test credentials. and the X-Test-Token:true header to the endpoint /v1/transaction-intents/processAPI so the request is made in a test environment. Modify the external_reference field according to the status you want to obtain. Below, you will find an example curl and a table with details about the different states.
curl
curl --request POST \ --url https://api.mercadopago.com/v1/transaction-intents/process \ --header 'Authorization: Bearer {{YOUR_ACCESS_TOKEN}}' \ --header 'Content-Type: application/json' \ --header 'X-Enforce-Signature: false' \ --data '{ "external_reference": "12345", "point_of_interaction": { "type": "PSP_TRANSFER" }, "seller_configuration": { "notification_info": { "notification_url": "http://example.mx/notification" } }, "transaction": { "from": { "accounts": [ { "amount": 25 } ] }, "to": { "total_amount": 25, "accounts": [ { "amount": 25, "bank_id": "646", "number": "646180110400000007", "holder": "JUAN JOSE MARIA", "type": "savings_account", "description": "envio de 25" } ] }, "total_amount": 25 } }'
Value of the external_reference field | Response |
new | A new transaction will be created and the response will return the value new for the status field. |
failed_by_bank | A new transaction will be created, this time rejected by the bank. The response will return the value failed for the status field. The status_detail within the from.accounts object will be by_bank. |
failed_by_provider | A new transaction will be created, this time rejected by the provider. The response will return the value failed for the status field. The status_detail within the from.accounts object will be by_provider. |
failed_by_caps | A new transaction will be created, this time rejected for non-compliance with Central Bank regulations. The response will return the value failed for the status field. The status_detail within the from.accounts object will be by_caps. |
failed_other_reason | A new transaction will be created, this time rejected for other reasons. The response will return the value failed for the status field. The status_detail within the from.accounts object will be other_reason. |
failed_by_high_risk | A new transaction will be created, this time rejected due to fraud risk. The response will return the value failed for the status field. The status_detail within the from.accounts object will be by_high_risk. |
failed_invalid_destination_account | A new transaction will be created, this time rejected for entering incorrect destination account data. The response will return the value failed for the status field. The status_detail within the from.accounts object will be invalid_destination_account. |
failed_by_compliance | A new transaction will be created, this time rejected due to non-compliance with regulations. The response will return the value failed for the status field. The status_detail within the from.accounts object will be by_compliance. |
failed_insufficient_funds | A new transaction will be created, this time rejected due to insufficient funds in the source account. The response will return the value failed for the status field. The status_detail within the from.accounts object will be insufficient_funds. |
partially_processed | A new transaction will be created whose processing has not yet been completed. The response will return the value partially_processed for the status field. |
partially_processed_pending_bank | A new transaction will be created whose processing has not yet been completed due to issues related to the destination account. The response will return the value partially_processed for the status field. The status_detail within the from.accounts object will be pending_bank. |
reverted | A new transaction will be created, this time refunded. The response will return the value reverted for the status field. The status_detail within the from.accounts object will be refunded. |
partially_reverted_partially_refunded | A new transaction will be created, this time partially refunded. The response will return the value partially_reverted for the status field. The status_detail within the from.accounts object will be partially_refunded. |
timeout | A new transaction will be created that will exceed the time limit. The response will return the value processed for the status field, but it will arrive after 2 minutes. |
internal_server_error | A new transaction will be created that will fail due to system errors. It will return an Error 500. |
| Any other value | New resources will be generated with status processed. |
Ready! Once these steps are completed, the integration is complete and you can go to production.