Entornos

Dos entornos con el mismo contrato. Una integración que pasa el sandbox de punta a punta usa la misma API en producción; producción se habilita por cliente.

Producción y sandbox

Una clave de un entorno usada en el otro responde 403 environment_mismatch.

Servidores declarados en el contrato

• https://api.fcmpayments.com — Producción. Dinero real; las transferencias por COELSA son irreversibles.
• https://empresas-sandbox.fcmpayments.com — Sandbox. Libro y riel simulados; nunca mueve dinero real.

Sandbox

• Las transferencias salientes se completan solas a los ~2 s, salvo por los centavos del importe: …13 termina failed con destination_closed (COELSA 7502), …70 termina failed con rail_expired (COELSA 7570) y …99 queda submitted hasta que lo resuelvas con POST /v1/simulations/outgoing_transfers/{id}/rail_result.
• Alias de prueba para validar contrapartes: sbx.valida (válida), sbx.inactiva, sbx.inexistente, sbx.bloqueada (control de cumplimiento) y sbx.otro.titular (un CUIT distinto del esperado si mandás expected_cuit). Cualquier CBU o CVU con dígitos verificadores correctos valida con un titular sintético.
• POST /v1/simulations/incoming_transfers simula un crédito entrante: recorre el mismo camino que un aviso real de COELSA (asiento, comisión, evento y webhook).
• Reloj de prueba por entidad: GET /v1/simulations/clock y POST /v1/simulations/clock/advance mueven la hora de la entidad hacia adelante (topes diarios y mensuales, reintentos de webhooks, vencimientos).
• Acreditación tardía, en dos pasos: sobre una transferencia failed que salió por COELSA (por ejemplo, una …13), POST /v1/simulations/outgoing_transfers/{id}/rail_result con {"outcome":"completed"} simula que COELSA la acreditó después, por el mismo camino que en producción (débito compensatorio del importe, salidas deshabilitadas, submitted con late_settlement_review y el evento transfer.outgoing.reopened). Después, POST /v1/simulations/outgoing_transfers/{id}/late_settlement_review con {"outcome":"completed"} simula que dos personas de Grip Rails confirman la acreditación: unos segundos después Grip Rails la cierra en completed, sin cargo, con el evento transfer.outgoing.completed. Como en producción, desde el primer paso tus transferencias salientes quedan deshabilitadas (403 entity_suspended). Sólo en el sandbox, unos segundos después de ese transfer.outgoing.completed Grip Rails las vuelve a habilitar sola (GET /v1/entity vuelve a active; no si Grip Rails bloqueó tu entidad en el medio) y podés seguir probando; en producción siguen deshabilitadas hasta que Grip Rails las rehabilite.