Integration Testing

The scenarios in this guide are designed for validation and preparation before your integration connects directly to the CCA QA environment. The Sandbox reproduces the same transfer, response, and reversal patterns you will encounter in certification, so you can verify that your Gateway handles each outcome correctly — without touching production or shared QA infrastructure.

Because the Sandbox runs in a controlled environment, you can exercise every case safely and without limits on retries: repeat transfers, reversals, SAF cycles, or error triggers as many times as you need until your client behaviour is stable.

Prerequisite: Run these tests only after your full Endpoints and Webhooks implementation is complete. The scenarios below assume your Gateway can originate transfers, receive asynchronous responses, and process webhook notifications end-to-end. Testing before that foundation is in place will not give meaningful results.

Field conventions

All triggers below refer to fields inside the Send Transfers request body, under document.transactions[], unless stated otherwise.

Rules are evaluated top-to-bottom within each table; the first match wins.

Warning: creditor.account = "111156789" is reserved for the SAF flow. Do not use it in any other test.

Happy path

Send a transfer via Send Transfers whose fields do not match any error trigger below. The outcome arrives asynchronously on your Receives Responses webhook with status approved (CCA 000).

Example payload

{
  "document": {
    "header": {
      "message_id": "d560eb8a-d644-4f12-8ae2-075ac6ee9320",
      "creation_date": "2026-01-15T10:30:00Z",
      "sender": "FINTECH_CL",
      "receiver": "SHINKANSEN"
    },
    "transactions": [
      {
        "transaction_id": "eae6df11-566c-4ef0-bee6-579c361024ff",
        "currency": "CLP",
        "amount": "70000",
        "reference": "Fintech TEF Test",
        "debtor": {
          "name": "Nombre debtor",
          "identification": {
            "id_schema": "CLID",
            "id": "11111111-1"
          },
          "financial_institution": "FINTECH_CL",
          "account": "12345678",
          "account_type": "current_account",
          "customer_type": "individual"
        },
        "creditor": {
          "name": "Nombre creditor",
          "identification": {
            "id_schema": "CLID",
            "id": "20667105-K"
          },
          "financial_institution": "BANCO_DESARROLLO_CL",
          "account": "8514092885",
          "account_type": "cash_account"
        }
      }
    ]
  }
}

Expected webhook: Receives Responses with status approved.

Same-bank transfers (inter-account)

In practice, this is a single transfer that the Sandbox routes through both sides of your integration: the sender (IFO) and the receiver (IFR), as if they were two distinct participants connected to the same Sandbox.

Trigger: debtor.financial_institution and creditor.financial_institution refer to the same institution.

Step-by-step flow

What you are testing

• Send Transfers and Receives Responses (IFO side) work together.
• Receives Transfers and Send Transfer Responses (IFR side) work together.
• The same client can act as both sender and receiver on an intra-bank transfer.

Inter-account transfers skip the IFR error-simulation table below. Error triggers only apply to standard cross-institution transfers.

Certification scenarios

Evaluated before account-based error rules.

Simulate transaction errors (IFR)

Send a transfer via Send Transfers with the field values below. The outcome arrives on Receives Responses.

Note: Compound rules (two conditions) take priority over simple ones. For example, creditor.account = "987654321" with creditor.identification.id = "35600053-6" triggers 046 (not 041).

Example — error 041

Change only creditor.account; keep the rest of your payload unchanged:

"creditor": {
  "financial_institution": "BANCO_DESARROLLO_CL",
  "account": "987654321",
  "account_type": "cash_account",
  "identification": { "id_schema": "CLID", "id": "20667105-K" }
}

Expected webhook: Receives Responses with status error_creditor_account_invalid (CCA 041).

Simulated errors from Switch (reversals)

After a transfer times out or fails, your IFO initiates a reversal via Send Reversals. The outcome arrives on Receives Reversal Responses (or the reversal section of your responses webhook, depending on your integration).

Conditional reversals must use reversal reason conditional (code 003). Any other reason returns error_invalid_message (CCA 011) immediately.

The 60-second window is measured from the original transfer timestamp to the reversal request. The deadline is inclusive — a reversal sent exactly 60 seconds after the original transfer is still accepted.

Notes

• 014 only applies after a previously approved reversal. A prior error rejection (010, 012, 013, etc.) does not block retries.
• Rows for 010, 012, and 013 are static trigger accounts for deterministic tests — they do not perform real settlement-cycle or IFR-approval lookups.
• Error 009 applies when the reversal is sent more than 60 seconds after the original transfer — not within 60 seconds.

Store and Forward (SAF)

The SAF flow is a deterministic test artifact for exercising your client’s own Store-and-Forward retry cycle on conditional reversals. It is not a literal model of Switch CCA behaviour.

In production, if the destination IFR does not respond within 11 seconds, the Switch returns reversal error 037 (Time-out). Your IFO client is then expected to retry via its own SAF mechanism (typically starting ~11 s after the transfer, retrying every ~5 s until a terminal response: approved, 013, 014, or 069). The Sandbox does not model the 037 path.

Trigger

Do not use this account in any other test.

What the Sandbox simulates

Terminal responses for your IFO SAF loop: in production you stop on approved, 013, 014, or 069. This Sandbox flow terminates on 013. Error 069 is not simulated.

Exception: if the original transfer used creditor.financial_institution = "SCOTIABANK_CL", the delayed-approved certification rule applies instead — you receive Receives Responses with ~5 s delay rather than a timeout.

Step-by-step

sequenceDiagram
    participant Client as You_Like_IFO
    participant Sandbox as Sandbox

    Client->>Sandbox: Send Transfers creditor.account=111156789
    Note over Sandbox: No Receives Responses
    Note over Client: Timeout waiting for response
    Client->>Sandbox: Send Reversals reason=conditional
    Note over Sandbox: 30s timer started
    opt Reversal retry while pending
        Client->>Sandbox: Send Reversals duplicate
        Note over Sandbox: Silently ignored
    end
    Note over Sandbox: After 30s
    Sandbox->>Client: Receives Reversal Responses error 013
    Client->>Sandbox: Send Reversals same transaction
    Sandbox->>Client: Receives Reversal Responses error 013 immediate

References

• Shinkansen Sandbox — Simulated errors from IFR
• Shinkansen Sandbox — Simulated errors from Switch