...
Once the user/customer is authenticated and has 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
...
A PISP must not create a payment-order-consent ConsentId on a newer version and use it to create a payment-order resource in a previous version
E.g., A ConsentId created in v3, must not be used to create a v1 PaymentSubmissionId
A PISP must not create a payment-order-consent ConsentId on a previous version and use it to create a payment-order resource in a newer version
E.g., A PaymentId created in v1, must not be used to create a v3 DomesticPaymentId
...
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 a domestic-payment created in v3, which 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)
...