This guide provides a general testing approach for Cobre integrations, with recommended test cases split by Payin and Payout. It is designed to help you validate both happy paths and common failure scenarios, and to ensure your integration behaves correctly across environments.QA / Sandbox environment#
Cobre’s test environment is currently based on a QA environment. To use the APIs in QA, request QA credentials (client_id and client_secret) from your Account Manager.Base domain (QA): https://api.qa.cobre.coAvailability#
Below is a table with the products/solutions that have a QA environment, along with some additional endpoints:| Country / Solution | Available in QA |
|---|
| Colombia | true |
| Mexico | false |
| Connect Account | false |
| Account Verification | false |
| Cobre Keys | false |
| Checkout (CO) | true |
| Cross Border | false |
| Notifications | true |
| Evidence | false |
When a product isn't available in QA — pre-go-live testing instance#
For products marked false above, Cobre deploys a dedicated pre-go-live testing instance instead of QA, to support development, testing, and User Acceptance (UA) for that product.The pre-go-live testing instance is fully isolated from your eventual live environment: separate credentials (client_id/client_secret), separate Portal users, and separate data. It is not QA, and it is not your live production instance.
Credentials & data isolation — its own credentials, Portal users, and data, isolated from both QA and the eventual live instance.
Confidentiality & SLAs — data in the pre-go-live testing instance is handled under the same confidentiality and data-masking standards, and the same support SLAs, as agreed for your production environment.
Go-live transition — once you're ready for live operation, Cobre deploys an additional, separate live instance with its own isolated credentials, Portal users, and data. The pre-go-live testing instance is not promoted or merged into it.
Decommissioning — the pre-go-live testing instance can be decommissioned at your request.
The pre-go-live testing instance runs on production-grade infrastructure, but it is a separate account from your live production instance — separate credentials, separate data. Don't treat activity in one as reflecting the other.
Availability matrix (high level)#
| Description | Endpoint | QA | Comments |
|---|
| Authentication | /v1/auth | true | It is possible to generate a token for QA |
| Accounts | /v1/accounts | true | It is possible to create a Cobre Balance |
| Counterparties | /v1/counterparties | true | It is possible to create a Counterparty |
| Add/Remove funds | /v1/account_test_transactions | true | It is possible to add or remove funds from a Cobre Balance. |
| Description | Endpoint | QA | Comments |
|---|
| Direct Link Money Movement | /v1/money_movements | true | Full testing solution with PSE and Bancolombia rails |
| Checkout | /v1/checkout | true | It's possible to create the Checkout. Full testing solution only with rail Bancolombia |
Nequi and BreB are not available.
| Description | Endpoint | Available in QA | Comments |
|---|
| Money Movement | /v1/money_movements | true | Full testing solution |
| Change PayOut State | /v1/change_mm_state | true | Simulate status transitions to completed or rejected |
As the financial institution for the counterparty, you must use 1007, as this is the only available option.
General testing principles#
What you should validate in every integration#
| Solution | Validations |
|---|
| Authentication | Token generation, Expiry handling, Refresh strategy |
| Resource creation | Creating Accounts and Counterparties required by your flows |
| Money Movement correctness | Allowed source_id / destination_id combinations, Amount in smallest currency unit, Idempotency behavior, Error handling and retries |
| Observability | Webhooks consumption and reconciliation via Money Movement retrieval and reports (if used) |
Tip: Always test both Happy and Unhappy paths, using the error dictionary to interpret failures.
