Certify the integration

Certification proves that Blinc can call the institution's non-production endpoints securely and that every operation behaves correctly under success, rejection, repeated delivery, timeout, and tampering conditions. The institution never calls a Blinc operation endpoint during these tests.

What you provide

Send these values through the agreed secure onboarding channel:

Item	What to provide	Why it is needed
Operation URLs	Complete HTTPS URL for every supported operation	The simulator calls the same routes the integration will use.
Institution public key	P-256 public key in the agreed SubjectPublicKeyInfo format	Blinc encrypts requests and verifies institution response signatures.
Institution member code	Six-digit routing code issued by Blinc	Message IDs and routing fields must use the exact code supplied during onboarding.
Network rules	IP allow-list, mutual TLS, DNS, firewall, and certificate requirements	The simulator must be able to establish HTTPS connections.
Test customer	Approved non-production identity and account	Linking and debit tests require a predictable customer record.
Test beneficiary	Approved non-production credit account	Credit Transfer and Credit Notification require a predictable beneficiary.
Support contact	Name/team and reachable channel	Both teams use correlation IDs to investigate failed cases.

Never send an institution private key. It stays in the institution's controlled key store.

Prepare the environment

Create separate non-production P-256 signing/decryption keys.
Import the Blinc non-production public key.
Configure the six-digit institution member code issued by Blinc.
Deploy HTTPS endpoints with trusted certificates.
Synchronise system clocks to a reliable UTC source.
Create replay and idempotency storage that survives application restarts.
Load the approved test customer, account, beneficiary, account link prerequisites, and balances.
Enable correlation-safe logs without plaintext, tokens, keys, or raw signatures.
Confirm the environment cannot route requests to production accounts or hosts.

Run the connection check

The first check contains no financial action. It proves that:

DNS and TLS work;
network allow-lists permit the call;
the configured URL is correct;
the receiver reads all required headers;
the institution can decrypt a Blinc request and verify its signature;
Blinc can decrypt the response and verify the institution signature.

Do not continue to business scenarios until this check passes.

Run one complete customer journey

Use the same fictional identity and references throughout:

Account Linking: connect the test customer account and store the returned account-linking ID.
Debit Authorization: debit the linked account using the account link and positive numeric authenticator ID.
Reverse: return the complete debit amount once.
Repeated Reverse delivery: Blinc delivers the same Reverse again; confirm no second credit is created.
Account Unlinking: cancel the account link.
Post-unlink debit: confirm a new debit using the cancelled account link returns RJCT.
Credit Transfer: credit the test beneficiary and confirm the balance or ledger changes once.
Repeated Credit Transfer delivery: Blinc delivers the same transfer again; confirm there is no second credit.
Credit Notification: record both a PDNG and BOOK notification.
Repeated Credit Notification delivery: Blinc delivers the same notification again; confirm no duplicate record or ledger action is created.

For each step, save the safe correlation IDs, decrypted business status in the controlled test report, account/ledger result, and whether response signature verification passed.

Run security rejection scenarios

Each case must fail before a financial or account link state change:

Scenario	How the simulator changes the request	Expected result
Missing signature	Omits `x-signature`	Reject authentication; no processing.
Invalid signature	Signs with an untrusted key	Reject before parsing business data.
Changed plaintext	Alters the encrypted plaintext after signing	Signature or AES-GCM authentication fails.
Changed ciphertext/tag	Flips a ciphertext or tag byte	Decryption authentication fails.
Wrong recipient key	Encrypts for another institution	Decryption fails safely.
Expired timestamp	Sends an old `x-timestamp`	Reject as stale.
Future timestamp	Sends a value beyond allowed clock skew	Reject as invalid.
Replay	Resends a previously consumed protected delivery	Return stored idempotent result or reject according to the documented duplicate rule; never process twice.
Invalid customer signature	Changes signed customer-visible payment data	Debit Authorization returns `RJCT`; no debit.
Wrong authenticator ID	Sends an unknown, zero, inactive, revoked, quoted, or mismatched `key_id`	Debit Authorization returns `RJCT`; no debit.

Run field and business rejection scenarios

Test at least these cases:

missing required parent object;
missing, null, empty, or wrong-type required leaf field;
malformed 35-digit message ID;
invalid or non-UTC date-time;
message time inconsistent with the ID timestamp;
zero or negative amount;
unsupported or mismatched currency;
incorrect institution member code;
unknown, expired, cancelled, or mismatched account link;
creditor ID mismatch;
beneficiary account closed, blocked, unknown, or unable to receive the currency;
Reversal original transaction not found;
Reversal amount or currency differs from the original debit;
unsupported payment method or inconsistent terminal fields;
HTTP 200 carrying RJCT is treated as a rejection, not success.

Every rejection must include a stable code and a simple correction sentence without leaking protected data.

Run failure and recovery scenarios

Scenario	Expected behaviour
Debit Authorization completes, but its response is lost	Blinc does not send Debit Authorization again. Blinc sends Reverse with the original debit references, and the institution returns the funds once.
Debit Authorization never completes and its response is lost	Blinc sends Reverse with the original debit references, and the institution returns `RJCT` with `NOOR`. No debit is created.
Account Linking response is lost	Blinc does not retry the old request. The customer starts again, and the new request has new identifiers. No duplicate account link is created.
Account Unlinking response is lost	Blinc does not retry the old request. The customer starts again, and the new request has new identifiers. The account link is not changed twice.
Credit Notification, Credit Transfer, or Reverse response is lost	Blinc may deliver the same plaintext and business identifiers again. The institution returns the stored result and applies no second business action.
Institution application restarts before a permitted repeated delivery	Stored duplicate-protection state survives the restart and still prevents a second business action.
An unexpected duplicate Account Linking, Account Unlinking, or Debit Authorization arrives	The institution does not apply the account or financial action twice, even though Blinc does not normally retry that operation.
Response signature is invalid	Blinc does not trust or report the business result.
Blinc cannot open the encrypted response	Blinc does not treat the operation as a confirmed success and follows the operation-specific behavior above.

Evidence required for approval

Provide a report containing:

institution name, member code, environment, and test date;
endpoint names and hostnames, with secrets and sensitive query data removed;
test-case ID, request message ID, business identifiers, and result;
HTTP outcome and decrypted business status;
proof that request and response signature checks passed or correctly failed;
proof that permitted repeated Credit Notification, Credit Transfer, and Reverse deliveries did not create duplicate business actions;
proof that unexpected duplicate link, unlink, or debit deliveries did not create duplicate state;
proof that a Debit Authorization timeout was followed by Reverse rather than another debit request;
safe ledger/balance evidence for accepted financial operations;
every unresolved failure, owner, and remediation date.

Do not attach private keys, complete tokens, plaintext customer payloads, or raw signatures.

Approval criteria

Certification passes only when:

all required operation journeys pass;
all protected responses can be decrypted and verified;
every security-negative scenario fails before mutation;
repeated-delivery, timeout, and restart scenarios produce no duplicates;
business rejections are distinguished from HTTP delivery success;
examples, field formats, error codes, and implemented schemas agree;
no production data or production endpoint was used;
no blocking security or reconciliation issue remains.

Use the Glossary whenever a field or protocol term is unfamiliar.