Contexts

Connectors.

A connector is linked to a bank and a country. Connecting to ING in The
Netherlands and with ING in Belgium requires two different connectors.
A context holds all information required by a connector to communicate with the bank. That
information might be different depending of the bank, while we do our best to standardize as much as we can.

Since the docker doesn't store data in any way, you have the responsibility to store the contexts and give them back when required.

The contexts are serialized JSON string that you should consider as blackboxes. You don't have to introspect them and certainly not to modify them!

📘

The base principle is that if the user or flow context is not null in the response we send you, you must store them for the next calls.

You’ll have to deal with 3 different contexts:

User context

Used to store the information of the relationship between a PSU and a bank (tokens for
example). This means the user context is related to one user (PSU) and one and only one bank
(connector).

🚧

This object is long living and should be protected against concurrent modifications

that may occur if you launch parallel connector operation for the same user context (so same bank and
same user).

Flow context

Used to store information about a specific flow. Generally used when an operation
requires more than one call to the bank API. For example, when a redirection to the bank is required
between calls. See request account access and payment initiation service for usage.

Paging context

Used to store the information needed to navigate into the pages of a list of operations. You get the first from the call to get first page of transactions and you supply it to the call to get the next pages .