This page is for banks that will start the collaboration with the broker by requesting the purchase contract data.

...

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 .

See a PDF of the purchase contract data

As an alternative for the bank to fetch and present JSon in the bank system, we offer a PDF rendering of the data as PDF. The PDF is generated using the official XSLT as defined by the DSVE project. For a given settlement/contract related to a purchase contract request, you can get the PDF by using the endpoint https://beta-api.ambita.com/eps/#tag/Purchase-Contract/operation/getPurchaseContractPdf. This is a PDF rendering of the contract data, this is not a copy of the signed purchase contract.

Getting the signed purchase contract

If the signed purchase contract is available (as a PDF) you will find the link to it in the array of contracts as a property named signedPurchaseContractLink. If a signed purchase contract is added (for the first time) or updated (new version), the event PURCHASE_CONTRACT_CHANGED. will be generated and the property settlementChanges will contain the category SIGNED_PURCHASE_CONTRACT.

Generating pantedokument (digital registration process)

...