This page is for banks that will start the collaboration with the broker by requesting the purchase contract data.
...
State | Description |
|---|---|
ACCEPTED | Request was successfully matched with a broker settlement. Response may or may not contain any purchase contract data. |
PENDING | Awaiting response from external broker. Result is available when event |
INVALID_BUYER | Used when request didn’t match any settlements. |
OUTDATED | When a bank requests contract data a again (same broker, same reference) the previous requests are marked as OUTDATED and no more events will be generated on these requests. |
A few more status codes will become available as the whole lifecycle of a request is implemented.
Listening for events
It is essential that the bank has a kind of scheduled batch job that fetches the latest list of events, processes them and takes action on relevant events like PURCHASE_CONTRACT_RESPONSE_RECEIVED and PURCHASE_CONTRACT_CHANGED. Unknown or uninteresting events can be ignored.
Note that the event PURCHASE_CONTRACT_RESPONSE_RECEIVED is the first event that does not have a reference to a settlement (settlementuid). Not having a settlement uid would be a braking change for the /events endpoint. In order for the bank to receive this event type, a new request parameter is required (then we know that the bank can handle null in this property). GET /eps/v1/events?contractevents=true.
...
Setting the intention the easy way
When the bank has requested a purchase contract and successfully received a contract in response, the settlement (unique identifier) is a handle to the broker’s data/settlement. Having this handle, setting the bank’s desired registration method i easy using the new endpoint /eps/v1/purchasecontractrequests/{requestuid}/{settlementuid}/intention/ and only add the desired flow (digital or paper). Se OAS documentation for details.
Requesting purchase contract data several times
DSVE has defined a set of properties that are required in order to create a purchase contract. It’s therefore possible to match the request with a settlement, but still not being able to create a purchase contract. The bank can then request the data again at a later point in time by just sending another POST request to the same endpoint. When requesting purchase contract data again, the following rules apply:
All previous requests to the same broker using the same (bank) reference will change status to
OUTDATED, no further events will be generated for that request and related data such as local (bank) settlements will be cleared.All previous requests to the same broker having a different (bank) reference will be kept alive and the bank will now receive events on both requests.
It is important that the bank’s refernce identifies a specific case in the bank’s system and is not a transaction/correlationId that will change for each request.
The broker doesn’t support purchase contract requests
As purchase contract data request is a rather new message type, it will take some time before all collaborating parties support this message. If the broker in question does not support purchase contract requests, the bank should skip this step and start collaboration by sending a bank intention, se Collaboration starting with bank intention .
Generating pantedokument (digital registration process)
...