Return clear errors and handle repeated deliveries

The institution never calls a Blinc operation endpoint. Blinc calls the institution's endpoint, and the institution returns one protected response to that call.

The institution does not schedule retries or decide whether Blinc should try again. It only needs to:

1. return an accurate result for the request it received;
2. avoid applying the same business action twice; and
3. keep enough records to recognise an earlier request if Blinc delivers it again.

Return an HTTP result and a business result

These two results answer different questions:

• The HTTP status says whether the institution's endpoint could receive and understand the protected request.
• The encrypted business status says whether the requested account or payment action was accepted.

For example, return HTTP 200 with business status RJCT when the protected request was valid but the account link did not exist. Do not use HTTP 500 for a normal business rejection.

Even an error response must not reveal private keys, decrypted payloads, institutional or customer signatures, or unnecessary customer data.

Return a business rejection

When a valid protected request fails a business rule, return RJCT and explain the decision:

{
  "TxSts": "RJCT",
  "StsRsnInf": {
    "Orgtr": { "Nm": "Example Issuer" },
    "Rsn": { "Cd": "MD01" },
    "AddtlInf": "The account-linking ID was not found."
  }
}

Reason codes the institution can return

Know which requests Blinc may deliver again

This table explains what may arrive at the institution endpoint. The institution does not initiate any of these retries.

For Credit Notification, Credit Transfer, and Reverse, Blinc creates a fresh HTTP delivery timestamp, signature, and encryption. The readable business message and business identifiers stay the same.

The institution must store enough information to tell these cases apart:

• same permitted delivery again: same identifiers and same plaintext; return the stored result without another business action;
• conflicting duplicate: same identifier but different plaintext; reject it without processing;
• new customer action or instruction: new identifiers; validate and process it normally.

Handle a Reverse after a Debit Authorization timeout

Blinc does not resend a timed-out Debit Authorization. It sends Reverse with the original debit references:

Blinc sends Debit Authorization
        |
        v
No dependable response reaches Blinc
        |
        v
Blinc sends Reverse with the original debit references
        |
        +-- accepted debit exists --> return the full amount once
        |
        +-- no accepted debit exists --> return `RJCT` with `NOOR`

Store the original debit references even when the connection closes before the response is delivered. Never create a debit while processing Reverse.

Log safely

Log the operation name, safe correlation and message IDs, outcome code, validation stage, HTTP status, and duration. For the three operations Blinc may retry, also log the delivery attempt or duplicate outcome. Do not log private keys, institutional or customer signatures, decrypted bodies, or full customer and account identifiers.

Next

Prove the institution endpoints work by following Certify the integration.