Corporate Payments: FAQ

Q:

We wish to implement a PIS flow for Nordea Corporate Denmark. Could you provide the maximum supported character lengths for the following fields:

• creditor.message
• creditor.message_to_bank_statement
• debtor.own_reference
• payment_instruction.information

within these templates:

• DOMESTIC_CREDIT_TRANSFER_DK
• SALARY_PENSION_DK
• DOMESTIC_TRANSFER_FORM_DK
• DOMESTIC_TRANSFER_FORM_WITH_OCR_DK
• INSTANT_CREDIT_TRANSFER_DK

A:

Please see:

* Only transfer form 73 in DOMESTIC_TRANSFER_FORM_DK and 75 in DOMESTIC_TRANSFER_FORM_WITH_OCR_DK have creditor.message field. Other transfer forms do not allow creditor.message.

Q:

With Corporate Payments API v3 now in Sandbox, can a single user sign multiple payments at once (a basket feature)? If yes, how many payments can be included in one signing request? Is this the correct high-level flow?

1. Authorize user with PAYMENTS_PSD2 scope
2. Initiate payment instructions without SCA via POST /corporate/v3/payments
3. Sign all payments in one SCA using POST /corporate/v3/payments/confirm

A:

Yes, it's possible and the flow is correct. We aim for 600 payments. Please see:

Corporate Payments API v3

Corporate Payments - API Reference

Q:

We are integrating with Corporate Payments API v3 for basket payments and observe the following:

• Individual payments are initiated and confirmed via PUT /corporate/v3/payments/confirm (bulk confirm).
• PSU authorizes the basket through an OAuth redirect.
• After basket authorization, trying to cancel individual payments with PUT /corporate/v3/payments/{payment-id}/cancel returns a 400 error: "Payment can't be cancelled at this stage".

After basket authorization, what status do individual payments have? Can individual payments be canceled after basket confirmation, and if so, when?

A:

The status following payment confirmation depends on various factors, primarily the individual user's permissions for the specific action. The status may vary and can be one of the following:

• AUTHORIZATION_FAILED - when an error has occurred
• AUTHORIZATION_PARTIAL - when additional confirmation is required (four-eyes principle)
• PAYMENT_EXECUTED - when the payment requires no further confirmation

For details on the payment flow, see:

Payment Flow - Corporate Payments API

Not all payments can be canceled at every stage. Primarily, cancellations are possible for payments in an AUTHORIZATION_PARTIAL state and, in some cases, for those in PAYMENT_ACCEPTED status, depending on the payment type and the progress of the payment process.

Cancellations cannot be performed when the payment is in AUTHORIZATION_PENDING or any final states such as PAYMENT_EXECUTED or PAYMENT_REJECTED.

Q:

We're setting up Bankgiro/Plusgiro payments via open banking API but encounter errors with references/OCRs. How should references be formatted to avoid bank errors? Example API request:

response body: {"group_header":{"message_identification":"2007731729c16884be","creation_date_time":"2026-07-02T11:37:39.297058571Z","http_code":400},"error":{"request":{"url":"/premium/v2/payments"},"failures":[{"code":"error.validation","description":"Invalid OCR reference format 1234.","path":"creditor.reference","type":"ValidReferenceNumber"}]}}

In this example, we also tried wiring funds with the message 1234, but it didn't work. The recipient confirmed they can receive funds with messages 1234 or DR1234, yet we can't make it work. Recently, using the Corporate File Payments solution, we successfully wired funds to this account with the four-digit message. Several counterparties say they can receive payments without an OCR reference and some pay us without one, but we can't send payments using the references they provide.

A:

Using the Reference (OCR/Creditor Reference) field depends on the beneficiary supporting a structured reference. The reference must follow specific formats (e.g., OCR, RF, or INTL) based on the payment type. If the format is incorrect, the payment cannot be submitted with that creditor reference.

If the beneficiary does not require a structured reference, the reference number should be provided as unstructured remittance information, utilizing the Message to Beneficiary field instead of the structured Reference field. 

This clarifies why certain counterparties may indicate that they are able to receive payments without an OCR reference. In these instances, the information is generally transmitted as an unstructured message rather than as a structured creditor reference.

We recommend the following:

• Use the Reference field exclusively when the beneficiary provides a valid structured reference (OCR, RF, INTL, etc.) that complies with the required validation rules.
• If the beneficiary does not possess a structured reference, please enter the information in the Message to Beneficiary field rather than the Reference field.