Ambientes

Dois ambientes com o mesmo contrato. Uma integração que passa no sandbox de ponta a ponta usa a mesma API em produção; a produção é habilitada por cliente.

Produção e sandbox

Uma chave de um ambiente usada no outro responde 403 environment_mismatch.

Servidores declarados no contrato

• https://api.fcmpayments.com — Produção. Dinheiro real; as transferências pela COELSA são irreversíveis.
• https://empresas-sandbox.fcmpayments.com — Sandbox. Ledger e trilho simulados; nunca movimenta dinheiro real.

Sandbox

• As transferências de saída se completam sozinhas em ~2 s, exceto pelos centavos do valor: …13 termina failed com destination_closed (COELSA 7502), …70 termina failed com rail_expired (COELSA 7570) e …99 fica em submitted até que você o resolva com POST /v1/simulations/outgoing_transfers/{id}/rail_result.
• Alias de teste (os nomes legíveis das contas argentinas) para validar contrapartes: sbx.valida (válida), sbx.inactiva, sbx.inexistente, sbx.bloqueada (controle de compliance) e sbx.otro.titular (um CUIT, a identificação fiscal argentina, diferente do esperado, se você enviar expected_cuit). Qualquer CBU (número de conta bancária) ou CVU (número de conta virtual) com dígitos verificadores corretos é validado com um titular sintético.
• POST /v1/simulations/incoming_transfers simula um crédito recebido: percorre o mesmo caminho que um aviso real da COELSA (lançamento, tarifa, evento e webhook).
• Relógio de teste por entidade: GET /v1/simulations/clock e POST /v1/simulations/clock/advance avançam a hora da entidade (limites diários e mensais, novas tentativas de webhooks, vencimentos).
• Liquidação tardia, em dois passos: sobre uma transferência failed que saiu pela COELSA (por exemplo, uma …13), POST /v1/simulations/outgoing_transfers/{id}/rail_result com {"outcome":"completed"} simula que a COELSA a creditou depois, pelo mesmo caminho que em produção (débito compensatório do valor, transferências de saída desabilitadas, submitted com late_settlement_review e o evento transfer.outgoing.reopened). Depois, POST /v1/simulations/outgoing_transfers/{id}/late_settlement_review com {"outcome":"completed"} simula que duas pessoas do Grip Rails confirmam a liquidação: alguns segundos depois o Grip Rails a fecha como completed, sem custo, com o evento transfer.outgoing.completed. Como em produção, a partir do primeiro passo as suas transferências de saída ficam desabilitadas (403 entity_suspended). Só no sandbox, alguns segundos depois desse transfer.outgoing.completed o Grip Rails volta a habilitá-las sozinho (GET /v1/entity volta a active; não se o Grip Rails tiver bloqueado a sua entidade nesse meio-tempo) e você pode continuar testando; em produção elas continuam desabilitadas até que o Grip Rails as reabilite.