What are the possible payment statuses?
Initiation Status (PaymentStatus)
status indicates whether the payment has been successfully initiated with the
Institution and should be considered as the 'primary' status.
It may be set to one of the following values:
PENDINGwhen the initiation request is still being processed
COMPLETEDwhen the initiation request has passed validation checks and been accepted by the
Institution. Settlement is expected to happen in due course (or according the the provided schedule for a Periodic or Scheduled payment)
Institutionhas rejected the initiation request and the payment will not be processed further
You may wish to monitor the
status of a payment until it has reached the
FAILED state by polling Get Payment Details
Whilst unlikely, there may be an issue in the
Institution processing of a payment after it has been accepted. In order to provide visibility of when this occurs, a payment initiation request that was
COMPLETED may subsequently become
status reports on payment initiation only and, as such,
COMPLETED does not indicate that settlement has occurred. The
isoStatus should be used (where available) to understand the status of payment processing and execution, including whether settlement has occurred to the payer or payee account.
Processing & Execution Status (PaymentIsoStatus)
isoStatus provides more detailed and extensive reporting on the payment status.
It's primary use is after a payment has been successfully initiated (i.e.
COMPLETED) when the
Institution will proceed with executing the payment. The
isoStatus can be used to track the payment through its execution process through to final settlement to the payee's account.
Yapily cannot guarantee the provision or accuracy of the
isoStatus. The reporting is limited within some Institutions and they may stop reporting at an intermediate state (e.g. ACTC) even though processing has continued.
COMPLETED, but an issue is experienced with the payment, then this indicates that a problem has occurred with the
Institution, who should be contacted for further investigation.
code and associated
name are reported using ISO20022 values, as summarised below.
|Settlement on the debtor’s account has been completed.
|Settlement on the creditor's account has been completed.
|Preceding checks of technical validation was successful. Customer profile check was also successful.
|All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution.
|Authentication and syntactical and semantical validation are successful
|Instruction is accepted but a change will be made, such as date or remittance not sent.
|Payment instruction included in the credit transfer is accepted without being posted to the creditor customer’s account.
|Pre-ceeding check of technical validation and customer profile was successful and an automatic funds check was positive .
|Payment initiation has been received by the Institution.
|A number of transactions have been accepted, whereas another number of transactions have not yet achieved 'accepted' status. This code may be used only in case of bulk payments, where reporting is performed against the entire file. Yapily reports status against each transaction, so this status is not expected.
|The payment initiation needs multiple authentications, where some but not yet all have been performed. Syntactical and semantical validations are successful.
|Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed.
|Payment initiation or individual transaction included in the payment initiation has been rejected.
|Payment initiation has been cancelled before execution
Monitoring the Payment Status
Not all banks report all
isoStatus as shown above, and typically we can see two main distinctions:
- For UK banks : Most of the banks report up to
- For EU banks : Many banks will report up to
ACSC, but many others will stop reporting at
ACCP, specially (but not only) German banks such as DB, Commerzbank; several Italian banks; etc. In this scenario (EU Payments in general) the lowest common denominator is the
Yapily will return the
COMPLETED status when the
Institution returns the final
isoStatus which will be an indication to stop checking for any additional status updates.
Based on this logic, it is not always possible to receive confirmation from the
Institution for the settlement of funds on the creditor account or even the debtor's. If this is important for your use case, Yapily recommends using AIS services to monitor the account balance and transactions as a means of confirming settlement.
When building logic to monitor the payment status, Yapily recommends using Exponential Backoff based on the expected settlement of the payment (considering the timings aforementioned, and the
status limitations described above).
For future dated payments (ie. Scheduled, Periodic, or Bulk Payments) the Open Banking regulatory bodies (ie. OBIE, Berling Group) do not mandate that banks provide the means to check the processing or execution status. It is common for the bank to only provide the initiation status of the payment.
What does this mean for you? You do not have the same visibility of whether a future dated payment settled as you do with single payments through Open Banking APIs.
It is also possible for the user to cancel a future dated payment by going directly to the bank.
The only way to confirm that a future dated payment created through Open Banking had settled would be to verify the payment on the recipient’s account transaction list.