Build the Blinc integration

Blinc sends requests to HTTPS endpoints provided by a participating financial institution. This guide shows you how to build those endpoints, confirm that each request is genuine, perform the requested action, and return a secure response.

An endpoint is a web address in your system that receives one type of request. JSON is the text format used for request and response data. You do not need to know the shortened financial field names before you start. Each page explains them where they appear.

Read these pages in order

If this is your first time here, follow this path:

1. Follow the integration journey to see one payment from start to finish.
2. Set up security and keys.
3. Decrypt a request from Blinc, then encrypt the response for Blinc.
4. Format identifiers and date-times so messages can be traced and processed once.
5. Understand common payment fields to learn the small JSON shapes reused by the operations.
6. Understand code values so values such as CLRG, P2P, and ACSC are never guessed.
7. Build only the operations required for the institution's payment role.
8. Return clear errors and handle repeated deliveries, then run certification tests.

Choose what you want to do

The request in plain English

Every call follows the same pattern:

1. Blinc creates a readable JSON message describing one banking action.
2. Blinc signs that exact message. The signature proves Blinc sent it and the message was not changed.
3. Blinc encrypts the message with the institution public key. Only the matching institution private key can open it.
4. Blinc sends the encrypted body to the endpoint URL supplied during onboarding.
5. Decrypt the body before verifying the signature in the HTTP headers.
6. Validate the fields and perform the action once.
7. Sign the response, encrypt it for Blinc, and return the response signature in HTTP headers.
8. Blinc decrypts and verifies the response before trusting the business result.

Blinc                                      Institution endpoint
  |                                            |
  |  POST your configured endpoint            |
  |  Headers: timestamp + signature            |
  |  Body: encrypted data                      |
  | -----------------------------------------> |
  |                                            | decrypt
  |                                            | verify signature
  |                                            | validate fields
  |                                            | process once
  |                                            | sign + encrypt result
  | <----------------------------------------- |
  |  Headers: response signature               |
  |  Body: encrypted data                      |

What you supply

Before testing, send Blinc these values through the agreed secure onboarding channel:

Blinc supplies its public key and issues the institution's six-digit member code during onboarding. The member code identifies the institution in message IDs and routing fields. Do not create or obtain this code from another source. Neither side ever shares a private key.

Rules that apply to every operation

• Accept POST requests with Content-Type: application/json.
• Require x-timestamp and x-signature.
• Decrypt the body before verifying the signature because the signature covers the readable plaintext.
• Reject an expired timestamp or a replayed message.
• Treat message and transaction identifiers as idempotency keys.
• Return a signed and encrypted response, including business rejections.
• Do not treat HTTP 200 as proof that the banking action succeeded. The decrypted business status is the final result.
• Never log private keys, complete tokens, plaintext customer/payment messages, or raw customer signatures.

The example used in every guide

These are fictional values. Use approved non-production data during certification.

Next

Start with Follow the integration journey.