Q:
What authentication methods are available in the business flow?
A:
There are several. Please refer to:
Business Access Authorization API
API Reference - Business Access Authorization
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 Domestic Transfer API)
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.
Q:
Which endpoint to use when confirming single and multiple cross-border payments?
A:
The endpoint for single and multiple cross-border payments confirmation is the same:
PUT /business/v4/payments/crossborder/confirm
- For single payment confirmation - payment ID needs to be provided in the URL of a request
- For multiple payments confirmation - payments IDs need to be put in the body of a request
Please refer to:
Business Payments Cross-border Transfer API
Business Payments Cross-border Transfer - API Reference
Q:
Regarding cross-border payments in Norway - when is a regulatory reporting code required? Is it if the amount is greater than 100000 NOK or also other conditions apply?
A:
In Norway, regulatory code is expected with a text field when the amount of a payment is greater than 100000 NOK and it's required by the central bank.
Note: if a currency of a payment is EUR, the amount in EUR will be recalculated to NOK and treated the same way.
Please refer to:
Q:
While requesting:
GET /business/v4/payments/domestic/{paymentId}
we received "PendingUserApproval" for the first status request and then "UserApprovalTimeout" for the second. In our logs we can see that the basket signing was initiated but the SCA (Strong Customer Authentication) was not completed. Could this be the reason for receiving UserApprovalTimeOut error?
A:
Yes. The SCA URL is valid for 10 minutes. If the signing is not completed within this time, the user approval will be timed out. If the user attempts to complete the SCA after the validity period has expired, the signing page will not open (there will be a 400 invalid_request response). The final status of the payment after the timeout will be UserApprovalTimeout and the user can initiate the payment confirmation again.
Please also see:
Payment status description (Business Payments Domestic Transfer API)
API Reference (Business Payments API Domestic Transfer)
Q:
What payment_status is associated with PaymentDeclinedPsuShouldContactNordea payment_status_reason?
A:
Please refer to our documentation:
Payment status description (Business Payments Domestic Transfer API)
API Reference (Business Payments API Domestic Transfer)
Q:
Regarding Nordea business DK domestic account transfer - if customers are sending the reference value what will be the reference type? Is "RF" the right reference type?
A:
Please see:
Nordea payment type field combinations (Business Payments Domestic Transfer API)
"RF" is a valid reference type for domestic account transfer in Denmark. We use "RF" for: domestic account transfer DK and FI Sepa payments.
Q:
How does the 'OnHold' status function for business domestic payments?
A:
Please see:
Payments authorization flow (Business Payments Domestic Transfer)
Q:
Is the SEPA endpoint exclusive to Finland? If so, should we use the cross-border endpoint for EUR accounts in Norway, Sweden, or Denmark? Are payments still processed via SEPA with SEPA fees applied in these cases?
A:
The SEPA endpoint is only for Finland. For other countries, use the cross-border endpoint. Payments meeting SEPA criteria will be routed through SEPA with corresponding fees. Refer to:
Business Payments SEPA Credit Transfer API
Business Payments API SEPA Credit Transfer - API Reference