Variable Recurring Payments - UK OB

IMPORTANT! All the documentation related with this API authorization can now be found in a separate documentation page.

API Overview

The basic usage scenario for Variable Recurring Payments (VRP) Initiation is shown on this diagram:

When a TPP wants to initiate VRP payments (sweeping, between accounts owned by PSU) it acquires a temporary access token and creates a VRP consent. The consent contains basic details about the payment and control parameters under which VRP must operate (amounts and periods). VRP supports:

• domestic payments that meet sweeping conditions,

VRP consent needs to be confirmed by the PSU (OpenID Connect Hybrid Flow). If PSU approves it, then TPP will receive an access token that will allow him to create a payment request and thus submit the payment for processing. Each payment request has a unique resource id that can be used for checking the payment processing status. (Where specifications allow a maximum text number greater than we provide, where possible we will truncate the field instead of rejecting the payment request.) The access tokens for VRP APIs can be refreshed multiple times and PSU authorization is not needed for each VRP payment under a specific consent, as long as consent is valid and payments are within consent control parameters. The Open Banking UK reference documentation can be found here: link.

Making API calls

Technical description of VRP API endpoints can be found in the reference section: link. In each call to the VRP API these are obligatory:

• MTLS connection (with the Network certificate used during TPP onboarding: link).

• Valid access token (acquired as described in the Authorization section: link).

Additionally the following headers may apply for API calls involving a payload (please check reference section to see if they’re required):

• Valid x-fapi-financial-id value in header (for Danske Bank it’s 0015800000jf7AeAAI),

• An x-idempotency-key header with a random value that will prevent multiple processing of the same request,

• An x-jws-signature header with detached JWS signature of the payload.

A sample request might look like this:

GET /domestic-vrps/123 HTTP/1.1
Authorization: Bearer <access token>
x-fapi-financial-id: 0015800000jf7AeAAI

Sandbox test data

The following test customers can be used for authenticating in Sandbox authorization flows:

Login / Password

8195475386 / xUKSWPgHy2H2XBt8cv

If you find the test data not matching your needs please contact us.