Q:
What authentication methods are available in the business flow?
A:
There are several. Please refer to:
Redirect Access Authorization (Business Access Authorization API)
Decoupled authentication (Business Access Authorization API)
Q:
What are the payment schemes supported in PSD2 for business and what are the fees for them? Are there transfer limits?
A:
We offer several products like: SEPA credit transfer, account payments, salary, pension, own transfer and cross border. Yes, there are limits - if the payment reaches the limit you will receive an error message indicating this.
Q:
Do you support payment cancellations?
A:
Yes.
Q:
Is the PSU name exposed in the PIS flow?
A:
The PSU name is not present in the PIS response. Creditor name will be reported.
Q:
Do you provide settled payee and settled payer status?
A:
We don't provide such functionality.
Q:
Is it possible to approve domestic and cross border payments with the same approval?
A:
It's not possible to sign domestic and cross border payments together, as there are separate APIs for each.
Q:
Regarding "4 eye restriction" and a field signed_by_current_user, your documentation:
Get a list of payments created for the user (Business Payment API Domestic Transfer)
states:
"If the value is true, it means that the current user is the first signer of the payment, and cannot sign it again. If the value is false, it means another user was the first signer, and the current user is allowed to sign it the second time to confirm the payment (does not apply to SE GET single payment endpoint)."
However, while testing, after user A signed the payment (first sign) you responded with: "signed_by_current_user": false" but user A was the first signer. Please explain how this could be and how the flow should be working?
A:
We provide signed_by_current_user value based on who is logged in into TPP application. However, when signing, any user can be used to sign the payment and as long as he has the power to sign it, he can do so using link/data generated by someone else.
Then, it might be, that there were two user accounts - e.g. A and B. User A signed in via Open Banking API (OB API), created the payment and started signing. Then by mistake user B was used to sign the payment. This can happen and is supported. So now we still have user A signed in to OB API while payment was signed by user B. This means that from a perspective of signed in user he can sign the payment because user A did not do so yet.
Q:
We observe that some payments fail due to two main reasons:
- The amount exceeds the limit for transfers/payments from the user's account
- The payment is blocked in the AML (Anti-Money Laundering) controls and gets suspended
What is the expected state of a payment when it falls into above categories? For example, we receive a 503 error stating that the payment exceeds the security limit. What would be the state of the payment in that case? How do we know when it is released and what are the possible states?
A:
The payment status depends on at what stage the error was thrown. If the error response was received at payment initiation, then the payment is never captured. PSU needs to initiate the payment again after considering the amount limit on the account.
In case of a payment being blocked due to AML controls or any other fraud prevention, the payment may be put on hold. In those scenarios, the PSU needs to contact the bank and resolve the case.
In case of the payment being blocked after confirmation due to payment limits, then the payment will remain in Confirmed status until it is possible to book the payment. There are also cases, when the PSU needs to provide a second confirmation via SMS. Open Banking API is not aware of such occurrences and so can't notify when a payment can be released.
Q:
We encounter payment initiation failures due to invalid characters in the message. What characters are allowed so we can make that validation ourselves?
A:
Please refer to: Special characters in message fields (creditor/debtor/beneficiary name)
Q:
While requesting:
POST /business/v4/payments/domestic
We receive the following error regarding payment reference ("code\":\"error.validation\",\"description\":\"The reference number is not valid\",\"path\":\"creditor.reference.value\",\"type\":\"PaymentValidReference\"):
"response_body":"{\"group_header\":{\"message_identification\":\"220482759007166e\",\"creation_date_time\":\"2025-03-23T22:41:08.772668972Z\",\"http_code\":400},\"error\":{\"request\":{\"url\":\"/v4/payments/domestic\"},\"failures\":[{\"code\":\"error.validation\",\"description\":\"The reference number is not valid\",\"path\":\"creditor.reference.value\",\"type\":\"PaymentValidReference\"}]}}Do you have some character limits for BankGiro payments?
A:
BankGiro payment's reference "_type" needs to be "OCR" and "value" needs to be at least 5 digits long (no more than 25). This combination defines BankGiro type of payment.
Refer also to:
Nordea payment type field combinations (Business Payments API Domestic Transfer)
Q:
Do you support Domestic Salary Pension Payment Initiation in Denmark?
A:
Following PSD2 requirements, we mimic functionality of Nordea Business Web. As we don't support Salary Pension in Denmark and Finland in said channel we cannot provide it via Open Banking API. When this feature becomes available in other channels we will implement it in Open Banking as well.