Environments

Two environments with the same contract. An integration that passes the sandbox end to end uses the same API in production; production is enabled per client.

Production and sandbox

A key from one environment used in the other returns 403 environment_mismatch.

Servers declared in the contract

• https://api.fcmpayments.com — Production. Real money; transfers through COELSA are irreversible.
• https://empresas-sandbox.fcmpayments.com — Sandbox. Simulated ledger and rail; it never moves real money.

Sandbox

• Outgoing transfers complete on their own after ~2 s, unless the cents of the amount say otherwise: …13 ends failed with destination_closed (COELSA 7502), …70 ends failed with rail_expired (COELSA 7570) and …99 stays submitted until you resolve it with POST /v1/simulations/outgoing_transfers/{id}/rail_result.
• Test aliases (the human-readable names of Argentine accounts) for validating counterparties: sbx.valida (valid), sbx.inactiva, sbx.inexistente, sbx.bloqueada (compliance control) and sbx.otro.titular (a CUIT, the Argentine tax ID, other than the expected one, if you send expected_cuit). Any CBU (bank account number) or CVU (virtual account number) with correct check digits validates with a synthetic holder.
• POST /v1/simulations/incoming_transfers simulates an incoming credit: it goes through the same path as a real COELSA notice (ledger entry, fee, event and webhook).
• Per-entity test clock: GET /v1/simulations/clock and POST /v1/simulations/clock/advance move the entity's time forward (daily and monthly limits, webhook retries, expirations).
• Late settlement, in two steps: on a failed transfer that went out through COELSA (for example, a …13), POST /v1/simulations/outgoing_transfers/{id}/rail_result with {"outcome":"completed"} simulates that COELSA credited it later, through the same path as in production (compensating debit of the amount, outgoing transfers disabled, submitted with late_settlement_review and the event transfer.outgoing.reopened). Then, POST /v1/simulations/outgoing_transfers/{id}/late_settlement_review with {"outcome":"completed"} simulates that two people at Grip Rails confirm the settlement: a few seconds later Grip Rails closes it as completed, free of charge, with the event transfer.outgoing.completed. As in production, from the first step on your outgoing transfers are disabled (403 entity_suspended). In the sandbox only, a few seconds after that transfer.outgoing.completed Grip Rails enables them again on its own (GET /v1/entity is back to active; not if Grip Rails blocked your entity in the meantime) and you can keep testing; in production they stay disabled until Grip Rails re-enables them.