The Unifiedpost Payments sandbox is based on the Berlin Group API with some small modifications that are detailed in this document. It is generated from the Open-API YAML file provided by the Berlin Group using the OPEN-API generator. Swagger-UI is used to provide a convenient GUI to the sandbox environment.
Registration is the process of submitting the QWAC and QSealC public Certificates to Unifiedpost. In a production environment the access of the TPP will be validated and once the process is complete (< 7 business days) the TPP can operate the AIS or PIS as authorised by the NCA. In the sandbox registration is also required but it is automatic and there is no waiting period.
The Sandbox uses the generated QWAC and QSealC certificates to authenticate the TPP. There is no additional login step.
The Sandbox contains 2 PSUs: John and Emma. John and Emma have the following IBANS. The data is fixed: it is not changed by making Payments or anything else. There is no password, the approval is done simply by clicking the "fingerprint" icon of the chosen user. If Emma tries to approve payments/consents with John's IBANs or vice versa, the payment or consent is rejected.
PSU John IBANs
BE52504001001109 (ACSC)
BE52504001001339 (ACSP)
BE26504001003129 (CANC)
PSU Emma IBAN
BE52504001001556 (ACSC)
When a payment is first created it is in the RCVD state.
To help with testing different statuses are set when the PSU approves the payment. These statuses are determined based on he IBAN (see above). If the PSU cancels the request then the status will be CANC.
Consents are saved and can be used to retrieve Account Information. They can also be revoked. To update a consent it is sufficient for the PSU to grant a new consent. The existing consent is automatically revoked. Consents are based on the Consent-Id and should be provided when accessing Account Information.
Note: Consent data may or may not be stored long term. This data is currently stored in memory and will be lost when the sandbox is restarted.
Payment Initiation Requests are saved and the status is available for a Payment Initiation Status request using the URI provided in the original Payment Initiation request.
Note: Payment Initiation data may or may not be stored long term. This data is currently stored in memory and will be lost when the sandbox is restarted.
The following statuses from the Berlin Group API spec are supported:
RCVD: 'Received'
Payment initiation has been received.
ACTC: 'AcceptedTechnicalValidation'
Authentication and syntactical and semantical validation are successful. The PSU has approved the payment.
ACSP: 'AcceptedSettlementInProcess'
All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution.
CANC: 'Cancelled'
Payment initiation has been cancelled before execution.
ACSC: 'AcceptedSettlementCompleted'
Settlement on the debtor's account has been completed.
RJCT: 'Rejected'
Payment has been rejected due to lack of funds, AML check or other reason.
PART: 'PartiallyAccepted'
Only used for Bulk Payments where individual payments do not all have the same status. If more detail is needed it is suggested to use AIS to query the account to view the individual transactions.
The following balance types from the Berlin Group API spec are supported:
interimBooked
Balance calculated in the course of the account service's business day, at the time specified, and subject to further changes during the business day. The interim balance is calculated on the basis of booked credit and debit items during the calculation time/period specified.
interimAvailable
Available balance calculated in the course of the account service's business day, at the time specified, and subject to further changes during the business day. The interim balance is calculated on the basis of booked credit and debit items during the calculation time/period specified.
IBAN required
Consent creation and Payment Initiation Requests require the IBAN to be provided when making the initial request.We do not yet support issuing consents without specifying the IBAN. This may change in future.
Payment Services Supported
For Payment Initiation: we support two payment services from the Berlin Group: payments and bulk-payments. (periodic-payments are not supported).
Payment Products Supported
For Payment Initiation: we support only the sepa-credit-transfers payment product.
Address
We have adopted a simplified Address Strucutre that aligns well with SEPA file exchange. For example "creditorAddress": { "addressLine1": "Rue de Bruxelles, 60", "addressLine2": "1040 Etterbeek", "country": "BE" }
API Integration
Although we use the Berlin Group API we have removed some (not all) of the optional features that we don't support to simplify the API for integration purposes.
The modified (Swagger 2) API definition in JSON format can be found here: https://aspsp.sandbox.pay-nxt.com:9443/v2/api-docs
It is possible to generate a client API using this definition.
Relaxed API binding
When validating requests we ignore any fields that we don't recognise so be careful with the request element names which are case sensitive.
We will add more functionality over time so you should also ignore fields in the response that you do not recognise.