...

• Register an intent to stage a payment-order consent.
• Optionally confirm available funds for a payment-order
  • Domestic immediate, international immediate and international scheduled (immediate debit) payments only.
• Subsequently submit the payment-order for processing.
• Optionally retrieve the status of a payment-order consent or payment-order resource.

...

The payment-order consent and payment-order resource in the following flow generalises for the different payment-order types. e.g. for a domestic payment, the payment-order consent resource is domestic-payment-consents; and the payment-order resource is domestic-payments. 

Steps

Step 1: Agree Payment-Order Initiation

• This flow begins with a PSU consenting to a payment being made. The consent is between the PSU and the PISP.
• The debtor account details can optionally be specified at this stage.

Step 2: Setup Payment-Order Consent

• The PISP connects to the ASPSP that services the PSU's payment account and creates a new payment-order consent resource. This informs the ASPSP that one of its PSUs intends to make a payment-order. The ASPSP responds with an identifier for the payment-order consent resource (the ConsentId, which is the intent identifier).
• This step is carried out by making a POST request to the payment-order consent resource.

Step 3: Authorise Consent

• The PISP requests the PSU to authorise the consent. The ASPSP may carry this out by using a redirection flow or a decoupled flow.
  • In a redirection flow, the PISP redirects the PSU to the ASPSP.
    • The redirect includes the ConsentId generated in the previous step.
    • This allows the ASPSP to correlate the payment order consent that was setup.
    • The ASPSP authenticates the PSU.
    • The PSU selects the debtor account at this stage (if it has not been previously specified in Step 1).
    • The ASPSP updates the state of the payment order consent resource internally to indicate that the consent has been authorised.
    • Once the consent has been authorised, the PSU is redirected back to the PISP.
  • In a decoupled flow, the ASPSP requests the PSU to authorise consent on an authentication device that is separate from the consumption device on which the PSU is interacting with the PISP.
    • The decoupled flow is initiated by the PISP calling a back-channel authorisation request.
    • The request contains a 'hint' that identifies the PSU paired with the consent to be authorised.
    • The ASPSP authenticates the PSU
    • The PSU selects the debtor account at this stage (if it has not been previously specified in Step 1)
    • The ASPSP updates the state of the payment order consent resource internally to indicate that the consent has been authorised.
    • Once the consent has been authorised, the ASPSP can make a callback to the PISP to provide an access token.

Step 4: Confirm Funds (Domestic and International Single Immediate Payments Only)

• Once the PSU is authenticated and authorised the payment-order-consent, the PISP can check whether funds are available to make the payment.
• This is carried out by making a GET request, calling the funds-confirmation operator on the payment-order-consent resource.

Step 5: Create Payment-Order

• The PISP creates a payment-order resource to indicate that the payment created in the steps above should be submitted for processing.
• This is carried out by making a POST request to the appropriate payment-order resource.
• The ASPSP returns the identifier for the payment-order resource to the PISP.

Step 6: Get Payment-Order/Consent Status

• The PISP can check the status of the payment-order consent (with the ConsentId) or payment-order resource (with the payment-order resource identifier).
• This is carried out by making a GET request to the payment-order consent or payment-order resource.

Sequence Diagram

participant PSU
participant PISP
participant ASPSP Authorisation Server
participant ASPSP Resource Server
     
note over PSU, ASPSP Resource Server
Step 1: Agree Payment-Order Initiation
end note
PSU -> PISP: Agree payment-order initiation request
   
note over PSU, ASPSP Resource Server
 Setup Payment-Order Consent
end note
PISP <-> ASPSP Authorisation Server: Establish TLS 1.2 MA
PISP -> ASPSP Authorisation Server: Initiate Client Credentials Grant
ASPSP Authorisation Server -> PISP: access-token
PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA
PISP -> ASPSP Resource Server: POST /payment-order-consents
state over ASPSP Resource Server: Consent Status: AwaitingAuthorisation
ASPSP Resource Server -> PISP: HTTP 201 (Created),  ConsentId
   
note over PSU, ASPSP Resource Server
 Step 3: Authorize Consent
end note
alt Redirection (Using authorization code grant)
        PISP -> PSU: HTTP 302 (Found), Redirect (ConsentId)
        PSU -> ASPSP Authorisation Server: Follow redirect (ConsentId)
        PSU <-> ASPSP Authorisation Server: authenticate
        PSU <-> ASPSP Authorisation Server: SCA if required
        PSU <-> ASPSP Authorisation Server: Select debtor account if required
        state over ASPSP Resource Server: Consent Status: Authorised
        ASPSP Authorisation Server -> PSU: HTTP 302 (Found), Redirect (authorization-code)
        PSU -> PISP: Follow redirect (authorization-code)
        PISP <-> ASPSP Authorisation Server: Establish TLS 1.2 MA
        PISP -> ASPSP Authorisation Server: Exchange authorization-code for access token
        ASPSP Authorisation Server -> PISP: access-token
else Decoupled (Using CIBA)
        PISP -> ASPSP Authorisation Server: POST /bc-authorize (login_hint_token)
        ASPSP Authorisation Server -> PISP: OK
         
        PSU -> ASPSP Authorisation Server: Authorise (Consent Id)
        PSU <-> ASPSP Authorisation Server: authenticate
        PSU <-> ASPSP Authorisation Server: SCA if required
        PSU <-> ASPSP Authorisation Server: select accounts
        state over ASPSP Resource Server: Consent Status: Authorised
 
        alt Using callback
                ASPSP Authorisation Server -> PISP: Callback (authorization-code)
                PISP <-> ASPSP Authorisation Server: Establish TLS 1.2 MA
                PISP -> ASPSP Authorisation Server: Exchange authorization-code for access token
                ASPSP Authorisation Server -> PISP: access-token
        else Using polling
                PISP <-> ASPSP Authorisation Server: Establish TLS 1.2 MA
                PISP -> ASPSP Authorisation Server: Poll at /token using auth-req-id
                ASPSP Authorisation Server -> PISP: access-token
        end alt
end alt


note over PSU, ASPSP Resource Server
Step 4: Confirm Funds (Domestic and International Single Immediate Payments Only)
end note

opt 
PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA
PISP -> ASPSP Resource Server: GET /payment-order-consents/{ConsentId}/funds-confirmation
ASPSP Resource Server -> PISP: HTTP 200 (OK) funds-confirmation resource

end opt
 
note over PSU, ASPSP Resource Server
Step 5: Create Payment-Order
end note
PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA
PISP -> ASPSP Resource Server: POST /payment-orders
state over ASPSP Resource Server: Consent Status: Consumed
alt Immediate Payment
state over ASPSP Resource Server: Payment Status: Pending
state over ASPSP Resource Server: Payment Status: AcceptedSettlementInProcess
state over ASPSP Resource Server: Payment Status: AcceptedSettlementComplete
else Standing Order or Future Dated Payment
state over ASPSP Resource Server: Payment Status: InitiationPending
state over ASPSP Resource Server: Payment Status: InitiationCompleted
end alt
ASPSP Resource Server -> PISP: HTTP 201 (Created), Payment-Order Id
   
note over PSU, ASPSP Resource Server
Step 6: Get Payment-Order/Consent Status
end note
   
opt payment-order-consent
PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA
PISP -> ASPSP Resource Server: GET /payment-order-consents/{ConsentId}
ASPSP Resource Server -> PISP: HTTP 200 (OK) payment-order-consent resource
end opt
   
opt payment-order
PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA
PISP -> ASPSP Resource Server: GET /payment-orders/{Payment-Order Id}
ASPSP Resource Server -> PISP: HTTP 200 (OK) payment-order resource
end opt
   
   
option footer=bar

...

• A PISP must use a payment-order consent ConsentId within the same version to create the payment-order resource (in that version)
  • E.g., A v3 payment-order consent can only be used to create a payment-order resource in v3.
• An ASPSP must not allow a PISP to use a ConsentId from a previous version to create a Payment Order in a newer version, and vice versa

...

• A PISP must refer to the ASPSP's online Developer Portal for guidelines on accessibility of a payment-order resource in a newer version
• A PISP must not access the payment-order resource types introduced in a newer version, on an older version endpoint:
  • E.g., an international-payment created in v3, that is accessed via the v1 payment-submissions endpoint.
• A PISP must not access the payment-order resource created in a newer version on an older version endpoint:
  • E.g., for a domestic-payment resource created in v3, access via the v1 payment-submissions endpoint is not permitted.
• An ASPSP must document the behaviour on the accessibility of a payment-order resource in a newer version on the ASPSP's online Developer Portal.
• An ASPSP must allow access to the payment-order resource created in a previous version on a newer version endpoint (depending on an ASPSP's legal requirement for data retention):
  • E.g., a payment-submission created in v1, must be accessible as a v3 domestic-payment, with sensible defaults for additional fields introduced in v3 (e.g., if an ASPSP must make payment resources available for 7 years).
  • In the case where a payment-order type is the same, but the structure has changed in a newer version, sensible defaults may be used, with the ASPSP's Developer Portal clearly specifying the behaviour.
    • E.g., a new field StatusUpdateDateTime was introduced in v3, an ASPSPs must populate this with the last status update time (as the StatusUpdateDateTime is a mandatory field).

...

PISPs must use a client credentials grant to obtain a token to make POST requests to the payment-order consent endpoints. In the specification, this grant type is referred to as "Client Credentials".

PISPs must use an authorization code grant using a redirect or decoupled flow to obtain a token to make POST requests to the payment-order resource endpoints. This token may also be used to confirm funds on a payment-order consent resource. In the specification, this grant type is referred to as "Authorization Code".

...

The ASPSP responds with a ConsentId. This is the intent-id that is used when initiating the authorization code grant (as described in the Trust Framework).

...

The Swagger Specification for Payment Initiation APIs can be downloaded from the following links:

• JSON
• YAML

Data Model

Reused Classes

OBRisk1

...

...

...