API Market documentation

PIS API specific documentation Finland

Changes from the previous version

This is the change log of the PIS API (SEPA), allowing PSD2-regulated TPPs to initiate payments on behalf of the PSU, in this case the Nordea Business customer. The top most item is the latest change and the API changes described in it are relative to the version directly below. The current version of the API is 4.15.

Version 4.15

Code calculator as a method of payment signing is being decommissioned. As part of that,
- Authentication method “CCALC” during SEPA payments confirmation has been blocked in sandbox. It will be removed in production API.
- The parameters “challenge”, “signing_order_id” has been deprecated from SEPA payments confirm response in sandbox. It will be removed in production API.
- The end point “PUT /v4/payments/sepa/sign” has been deprecated in sandbox. It will be removed in production API.
- The section “Decoupled signing via Code Calculator device” has been removed from the document.
New ENUM value has been added to the parameter “payment_status_reason” in the payments model. Section Payment status description has been updated.

Version 4.14

SEPA credit transfer has been enhanced with instant payment functionality. As part of it

“urgency = express” is supported at payment initiation
Maximum length for creditor name has been increased to 70 char for express payments

Version 4.13

Support for the Confirmation of availability of funds has been added. Please refer to the Confirmation of availability of funds section.

Version 4.12

PIS API Scenarios section updated.

Version 4.11

Support for the header parameter “X-Response-Scenarios” has been added to Sandbox. Please refer to the Mock signing page (Sandbox only).

Version 4.10

The parameter “auto_start_token” has been removed from the payment details.

Version 4.9

Payment model is enhanced with additional attribute “payment_status_reason”.

Version 4.8

Added support for decoupled payment signing using code calculator.

Version 4.7

Added precise description for MTA authorization method for SEPA payments (decoupled signing flow).

Version 4.6

Added Decouple signing for Finland. Now PSU in Finland can sign the payments using Nordea ID app. In order to enable the decouple signing, the TPP needs to provide the parameter “authentication_method” = “MTA” during the confirmation step. Then Nordea will automatically trigger the decouple signing for the user. The signing url is to be used in case of it is not possible to use the decouple signing flow.

Version 4.5

Support for recurring payments in FI Sandbox has been added. Please refer to Recurring Payments section for more details

Version 4.4

The Nordea Codes App has been re-branded to Nordea ID. This version is intended to reflect the updated name in the API documentation. The re-branding has no impact on the APIs.

Version 4.1

Initiate payment now allows for future dated payments by supplying a date as ‘requested_execution_date’ (optional, default is “today”). See swagger definition for limits. Urgency ‘Express’ should not be used with future dated payments. Confirmed payments in sandbox will remain in status ‘Confirmed’ until the requested execution date, but as sandbox is a session based, in-memory data base, this needs to be tested close to midnight.

New endpoints to support DELETE for removal of payments (designed for removal of recurring payments as well, but this function is still to come). Interfaces also work for future dated payments. The request have been defined to support deletion of a single payment, or a list of payments and the services return a list of paymentIds that where deleted and/or tpp_messages for those that were not.

/v4/payments/sepa/ (DELETE - multiple, details supplied in body request)
/v4/payments/sepa/<paymentId> (DELETE - single, details supplied in url)

Note: You can delete a single payment in both services at your own choice.

Version 4.0

Although this is the first version of Nordea Business specific APIs, we have decided to use ‘v4’ to make it clear that the endpoints align closely to the ‘v4’ endpoints for business customers in terms of interface definition and behaviour.

Overview

Payment Initiation Services (PIS) API consists of four endpoints. The PIS API can be used to initiate payments, query payment details, and status and confirm payments. This API supports GET, POST and PUT HTTP methods. At the moment, PIS API supports only SEPA transfers, and the API endpoint URLs have sepa in them.

API Endpoints

The PIS API contains the following endpoints:

Endpoint	Supported HTTP Methods
`/payments/sepa`	GET, POST, DELETE
`/payments/sepa/{paymentId}`	GET, DELETE
`/payments/sepa/{paymentId}/confirm`	PUT
`/payments/sepa/confirm`	PUT
`/payments/sepa/sign`	PUT

The /payments/sepa endpoint has three uses, it can be used to initiate payment, to get payments and to delete payment. It supports GET, POST and DELETE methods. If POST method is used, new payment will be initialized, and the request body must contain the payment details to be initiated. If get method is used, it will return list of unexecuted payments. This endpoint returns HTTP Code 201 on success, and the response contains the payment details which include, e.g., payment receiver details among other things.

Here is an example of the JSON payload format which can be posted to this endpoint, “_type” is an internal defined representation of the account or reference type.

{
  "amount": "1.11",
  "currency": "EUR",
  "debtor": {
    "account": {
      "_type": "IBAN",
      "currency": "EUR",
      "value": "FI6593857450293470"
    },
    "message": "Own message"
  },
  "creditor": {
    "account": {
      "_type": "IBAN",
      "currency": "EUR",
      "value": "FI4910013500015921"
    },
    "name" : "Creditor name",
    "message" : "Message to creditor",
    "reference" : {
      "value" : "RF11223344",
      "_type" : "RF"
    }
  }
}

After the payment is initiated by POST request to this endpoint, it will be available by doing GET request to this endpoint which returns a list of pending payments. The paymentId(s) can be mentioned in a DELETE request to delete the duplicate or unnecessary payments.

The /payments/sepa/{paymentId} endpoint serves two purposes. It can be used to query payment details by payment id using a GET HTTP method. The payment id is returned when payment is initiated successfully, and it can be found from the response JSON by the name _id. Moreover, the payment status can be seen in the response by the name payment_status. Full response example of this endpoint can be seen in examples section below. The DELETE method can be used to delete a specific payment by mentioning the paymentId

The /payments/sepa/{paymentId}/confirm endpoint can be used to confirm payment after the payment is initiated by issuing successful POST request to the /payments/sepa endpoint. This endpoint returns HTTP Code 200 on success. This endpoint supports only PUT HTTP method. Again, the parameters and responses of this endpoint can be found from the examples section below.

The /payments/sepa/confirm endpoint can be used for bulk confirmation of payments. The service also allows for individual payment confirmations. Please be aware that processing multiple payments could subsequently result in multiple errors. The post-signing redirect and decoupled solutions are the same as for the single confirmation endpoint. Also note that if 4 payment_id’s are sent, and two of them return errors, the subsequent signing process will only include the two payments with no errors.

The /payments/sepa/sign endpoint can be used to send the response_code when a payment was confirmed using code calculator device.

sandbox only

In Sandbox: Note that the `payment_status` of a confirmed payment will be automatically updated after some time from Pending to Confirmed to Paid. To confirm the payment, calling the '/confirm' endpoint is sufficient for the decoupled countries (Sweden and Finland), whereas the additional countries (Denmark and Norway) requires activation of the signing url, but the flow is mocked for sandbox.

Nordea payment type field combinations

Endpoint (/payments/.)	Nordea Type	Comments	debtor.account_type	creditor.account_type	.amount (mandatory, max. value)	.currency	.creditor.message	.name (of beneficiary	.reference.value	.reference_type
/SEPA	SEPA	FI uses SEPA for domestic payments as well	”IBAN"	"IBAN”	999 999 999,99	”EUR”	optional (max. 140)	mandatory	mandatory	”INVOICE” or “RF”

Payment status description

Payment Status	Description	Confirmable	Deletable
PendingConfirmation	A payment was created. Confirmation step has not yet been started.	Yes	Yes
PendingUserApproval	The PSU-signing process has started.	Yes	No, waiting for customer action
OnHold	Payment was put on hold by bank, for example due to fraud suspicion. The PSU needs to contact the bank, or maybe reply a sms.	No	No
UserApprovalFailed	Payment process failed.It’s possible to try again. See tpp_messages in response for further details.	Yes	Yes
UserApprovalTimeout	A specific time frame is set for the signing process, in which the PSU needs to sign the payment. If timeline is exceeded the signing process expires and has to be restarted.	Yes	Yes
UserApprovalCancelled	The PSU rejected signing the payment during the signing flow.	Yes	Yes
Paid	The payment has been properly initiated, confirmed, signed and debited.	No	No
Confirmed	The payment has been properly initiated, confirmed, signed, but is pending final execution. Could be a future dated payment, or due to bulk clearing of payments (i.e. not instant).	No	No, but if the customer contacts the bank it can be stopped
Rejected	As stated the payment has been rejected. See the tpp_messages for further details. This payment cannot be (re-)confirmed. The attribute “payment_status_reason” will indicate “InsufficientFunds”, if the payment was rejected due to insufficient funds. The attribute “payment_status_reason” will indicate “PaymentDeclinedPsuShouldContactNordea ”, if the payment was rejected due to other bank checks, then the user needs to contact the bank to resolve the case.	No	No
LimitExceeded	The PSU, the account, or the channel has a limit that has been exceeded. This is technically (re-)confirmable, but it requires something has been changed, for instance the limit is raised or a new month has begun.	Yes	Yes
Unknown	On rare occasions the core payment engine in Nordea returns a status that has not been mapped to any of the above payment statuses. It could be caused by the fact that some processes run in parallel in the core payment engine. Most of these statuses are likely to be changed in a matter of milliseconds. Please re-query the status again until one of the above statuses is received instead.	N/A	N/A

Decoupled signing via Nordea ID mobile application

Decoupled signing is another possibility for PSU to sign payment using external authentication mobile application Nordea ID. PSU is able to choose signing option. If PSU has active Nordea ID for authorization in Nordea Business (logging, signing payments), he can also sign SEPA Payments initiated via Nordea OpenBanking API. In order to activate decoupled flow, TPP is obligated to send additional information during confirming step.

authentication_method must be sent as an additional parameter with value “MTA” in order to initiate decoupled signing via Nordea ID app. If the value sent is null, empty or omitted, it is defaulting to “redirect”.

When user does confirm the payment using MTA, there is no callback sent to the TPP website, thus TPP has to check the status on their own in case of using this method. After about 10 minutes (subject to change without notice) status should be resolved to one of Confirmed or Paid in case of successful signing, UserApprovalCancelled in case used decided to cancel signing, UserApprovalFailed in case of technical issue with executing the payment and UserApprovalTimeout in case used have not taken any action before signing timeout have taken place.

Note: Please note that when MTA is successfully initiated, both signing link is sent back and user receives notification on their application. This makes it possible to make a decision in both places which may be different (like cancel in redirect URL and confirm in Nordea ID application). In case of different answers, confirming payment always takes precedence over cancelation of confirmation, i.e. if in any of the channels user confirms the payment it will be confirmed and executed.

Possible scenarios for MTA signing method:

First event	Second event	Desired result	Notes
Payment confirmed in Nordea ID app	Redirect confirmation done	Payment is Confirmed (or Paid)	After redirect confirmation is done, error is presented on the callback. Error handling will be adjusted in next version of API
Payment cancelled in Nordea ID app	Redirect confirmation done	Payment is UserApprovalCancelled
Payment confirmed in Nordea ID app	Payment cancelled in redirect flow	Payment is Confirmed (or Paid)	Same situation as in first scenario. More adjustments will be introduced in next version of API
Payment cancelled in Nordea ID app	Payment cancelled in redirect flow	Payment is UserApprovalCancelled	Status changes to UserApprovalCanceled immedietly after cancelling in Nordea ID app
Redirect confirmation done	Payment confirmed in Nordea ID app	Payment is Confirmed (or Paid)	Mobile app presents, that signing went OK, even tho it has been already signed by redirect flow
Redirect confirmation done	Payment cancelled in Nordea ID app	Payment is Confirmed (or Paid)	No error displayed in mobile app
Payment cancelled in redirect flow	Payment confirmed in Nordea ID app	Payment is UserApprovalCancelled
Payment cancelled in redirect flow	Payment cancelled in Nordea ID app	Payment is UserApprovalCancelled

Possible errors due to MTA signing method:

HTTP status	Error	Details
429	TOO_MANY_REQUESTS	This error means that customer has already a pending confirmation on their mobile application and thus until these are answered, no other confirmation can be created. In this case, no signing link is provided and there is possibility to call PUT /confirm again with authentication_method other than MTA to try different way of signing or TPP can notify user to open their application and clear all the signing requests before trying MTA method again.
500	INTERNAL_SERVER_ERROR	This might occur for MTA signing flow in case MTA system is not available due to technical issues. TPP should either wait for a bit and try again, or they can try using other method such as “redirect” to allow signing by the user.

Note: Do not poll for the status more often than once every 5 seconds as this is the timing interval for checking the users authorization.

Example for PUT /confirm call:

$ curl 'https://api.nordeaopenbanking.com/business/v4/payments/sepa/confirm' -i -X PUT \
    -H 'X-Nordea-Originating-Host: <your_host>' \
    -H 'X-Nordea-Originating-Date: <now>' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer <access_token>' \
    -H 'digest: <generated_digest>' \
    -H 'signature: keyId=\"<your_clientapp_keyid>\",algorithm=\"rsa-sha256\",headers=\"(request-target) x-nordea-originating-host x-nordea-originating-date\",signature="<generated_signature>"' \
    -H 'X-IBM-Client-Id: <your_client_id>' \
    -H 'X-IBM-Client-Secret: <your_client_secret>'
    -H 'Content-Type: application/json; charset=UTF-8' \
    -d '{
    "payments_ids": [
        "11d55648-8c1d-45e2-951a-69c5aeaed99y",
        "5e6e2d6f-e2dd-4c71-b232-9dfbb88ba99y"
    ],
    "authentication_method": "MTA"
}

As presented above, it is possible to use decoupled flow for bulk confirmation. Parameter “authentication_method” is non-mandatory. When it is not provided, user is not going to get push notification to Nordea ID application. In case of PSU authorizing payment via Nordea ID app, TPP will not be informed from OpenBanking API by any instant notification. TPP must call GET payment details and verify the current status of the payment. If PSU decides to sign payment via Nordea ID application, TPP must call for payment status by itself.

Mock signing page (Sandbox only)

The Mock signing page offers TPP the possibility to experience the payment signing in Sandbox. When the signing URL is activated, the UI is being displayed - where the user can sign payment(s) by entering the user credentials. Additionally to that, the user is provided with various exceptional scenarios related to the payments confirmation process.

Specifications:

Enabled only for redirect signing (decoupled signing is not in scope)
User credentials are not real, but mocked. The implementation accepts any user ID and password in Sandbox
Payment scenarios are mocked. Based on the scenarios specified, payment details are adjusted and shown in Sandbox:
- SecondChannelConfirmation
- InsufficientFunds
- 4eyesConfirmation
Applicable only for 2-SCA payments flow (single SCA payments are not in scope)
Countries in scope: FI
Impacts the following endpoint (only in Sandbox):
- PUT /v4/payments/sepa/confirm

The new optional header parameter

TPP can use the new optional header parameter “X-Response-Scenarios” to specify the scenarios. Valid values for the scenarios are:

AuthenticationWithUI
AuthenticationSkipUI
SecondChannelConfirmation
InsufficientFunds
4eyesConfirmation

Please find the example below:

curl --location --request PUT '<host>/v4/payments/sepa/confirm' \
--header 'X-IBM-Client-Id: <client_id>' \
--header 'X-IBM-Client-Secret: <client_secret>' \
--header 'Signature: <signature>' \
--header 'X-Nordea-Originating-Host: <nordea_originating_host>' \
--header 'X-Nordea-Originating-Date: <nordea_originating_date>' \
--header 'Content-Type: application/json; charset=UTF' \
--header 'Digest: <digest>' \
--header 'X-Response-Scenarios: AuthenticationWithUI,SecondChannelConfirmation' \
--header 'Authorization: <token>' \
--data-raw '{
    "payments_ids": [
        "<payment_id>"
    ]
}'

Validation of the “X-Response-Scenarios” header parameter

The below describes the validations on the “X-Response-Scenarios” header parameter:

If specified, “X-Response-Scenarios” must contain one of the valid values. If not, the request will be rejected with the following details:

{
    "httpCode": "400",
    "httpMessage": "Bad request",
    "moreInformation": "Invalid response scenarios."
}

If specified, “X-Response-Scenarios” must contain only one of the three values: “SecondChannelConfirmation”, “InsufficientFunds” and “4eyesConfirmation”. All three values cannot be specified together. If specified together, the request will be rejected with the following details:

{
    "httpCode": "400",
    "httpMessage": "Bad request",
    "moreInformation": "Invalid response scenarios."
}

If specified, “X-Response-Scenarios” must contain only one of the two values: “AuthenticationWithUI” and “AuthenticationSkipUI”. Both these values cannot be specified together. If specified together, the request will be rejected with the following details:

{
    "httpCode": "400",
    "httpMessage": "Bad request",
    "moreInformation": "Invalid response scenarios."
}

Visualization of the Mock signing page

Please find the visualization of the Mock signing page below:

SigningPage

The scenarios are shown with check boxes. If any of those scenarios was already mentioned in the header parameter “X-Response-Scenarios”, then the specified scenario is pre-selected on the UI
The user still has the option to select additional scenario or uncheck the previously specified scenario
If one scenario is checked, other scenarios are disabled
The user credentials can be anything, no validations on the userId and password

PIS API Scenarios (Sandbox only)

The following section describes the possible scenarios that can be experienced in Sandbox.

a) No scenario is specified

The given includes:

No header is provided
“AuthenticationSkipUI” is provided as an only value in the header
“AuthenticationWithUI” is provided as an only value in the header but no scenarios selected on the signing page

NoScenario

If the execution date is the current business date, then the payment status will be updated as “Paid”
If the execution date is in the future, then the payment status will be updated as “Confirmed”

b) The “SecondChannelConfirmation” scenario

SecondChannelConfirmation

The payment will be updated as stated below:
- payment_status = “OnHold”
- requires_second_channel_confirmation = “true”
After 30 seconds:
- If the execution date is the current business date, then the payment status will be updated as “Paid”
- If the execution date is in the future, then the payment status will be updated as “Confirmed”

c) The “InsufficientFunds” scenario

InsufficientFunds

The payment will be updated as stated below:
- payment_status = “OnHold”
- payment_status_reason = “InsufficientFunds”
After 30 seconds:
- payment_status = “Rejected”
- payment_status_reason = “InsufficientFunds”

d) The “4eyesConfirmation” scenario

4eyesConfirmation

The payment will be updated as stated below:
- payment_status = “PartiallyConfirmed”
- signed_by_current_user = “true”
After 30 seconds:
- If the execution date is the current business date, then the payment status will be updated as “Paid”
- If the execution date is in the future, then the payment status will be updated as “Confirmed”

Recurring Payments

Note: Recurring Payments for FI SEPA Payment are now available in production.

The recurring payments - sometimes also known as standing order - information consist of two additional values; the count and the recurrence_type.

The count has to be a minimum of 2, as the first payment is executed on the requested execution date as a normal payment, and creates another payment immediately afterwards. The number of payments remaining can be found in the count field if payment list or details are requested. It will decrease by 1 for each version of the payment that has been Paid. The normal maximum value for count is 98, but the number 9999 (four nines) is used to indicate an infinite series of identical payments that will not stop until deleted by the submitter. This special ‘count’ will not decrease with each Paid payment, and will continue to return the number 9999.

Note: A simple way to find the next occurrence of the recurring payment in the payment list would be to add an external_id when initiating the payment. The external_id will be present on all occurrences of this payment.

Note: Use /delete interfaces to remove recurring payment schedule. Please note, that for FI deletion of next occurrence only is not supported. All occurrences are always deleted.

recurrence_type	FI	Description
DAILY	-	Every banking day
WEEKLY	-	Weekly, based on the day of the requested execution date (or the next banking day)
BIWEEKLY	-	Every 2 weeks on the weekday of the request execution date (or the next banking day). For Norway BIWEEKLY is only for own account transfers.
MONTHLY_SAME_DAY	X	Monthly, based on the day of requested execution date (or the next banking day)
MONTHLY_EOM	-	Monthly on the last banking day of the month
QUARTERLY_SAME_DAY	-	Every 3 months on the requested execution date (or the next banking day)
QUARTERLY_EOM	-	Every 3 months on the the last banking day of the month
TRI_ANNUALLY_SAME_DAY	-	Every 4 months on the requested execution date (or the next banking day)
SEMI_ANNUALLY_SAME_DAY	-	Every 6 months on the requested execution date (or the next banking day)
SEMI_ANNUALLY_EOM	-	Every 6 months on the the last banking day of the month
YEARLY_SAME_DAY	-	Once a year on the requested execution date (or the next banking day)
YEARLY_EOM	-	Once a year on the the last banking day of the month
EVERY_MINUTE_SANDBOX_ONLY	X	Testing in Sandbox only! Every minute, a recurrence of the payment will be `Paid` and the next occurrence created until the counter reaches 0.

sandbox only

In Sandbox: We have added EVERY_MINUTE_SANDBOX_ONLY to `recurrence_type` for you to test the `count` and `status` of the payments in the sandbox. As confirmed payments in sandbox automatically get `Paid` after a few seconds, the recurring payments will automatically run until the `count` reaches 0. Try calling 'Get Payments List' endpoint time-by-time to observe new payments being created. Please avoid using 9999 too many times whilst testing, and EVERY_MINUTE_SANDBOX_ONLY is not accepted in production.

Confirmation of availability of funds

The given functionality gives TPP the possibility to confirm the availability of funds - so that TPP can decide to either further process, cancel and/or sign the payment or not.

Two new optional parameters have been added:

“request_availability_of_funds” (request)
“availability_of_funds” (response)

Countries in scope: FI.

Payment initiation

Sandbox:

If 2SCA payment initiation endpoint is available and the request contains the new field: “request_availability_of_funds” set to “true” and Sandbox scenario is not being specified in request header - when the endpoint is invoked, then the payment initiation response will be returned with new field: “availability_of_funds” that is set based on the actual check that verifies the payment amount against the available balance on the account.
If 2SCA payment initiation endpoint is available and the request contains the new field: “request_availability_of_funds” set to “true” and Sandbox scenario is specified as: “FundsAvailable” in request header - when the endpoint is invoked, then the payment initiation response will be returned with new field: “availability_of_funds” that is set to “true”.
If 2SCA payment initiation endpoint is available and the request contains the new field: “request_availability_of_funds” set to “true” and Sandbox scenario is specified as: “FundsNotAvailable” in request header - when the endpoint is invoked, then the payment initiation response will be returned with new field: “availability_of_funds” that is set to “false”.

Production:

If 2SCA payment initiation endpoint is available and the request contains the new field: “request_availability_of_funds” set to “true” - when the endpoint is invoked, then the payment initiation response will be returned with new field: “availability_of_funds” that is set based on the actual check that verifies the payment amount against the available balance on the account.

Get payment details

Sandbox:

If 2SCA get payment details endpoint is available and the request contains the new field: “request_availability_of_funds” set to “true” and Sandbox scenario is not being specified in request header and payment status is not: “InsufficientFunds”, “Rejected”, “Paid” or “Unknown” - when the endpoint is invoked, then the get payment details response will be returned with new field: “availability_of_funds” that is set based on the actual check that verifies the payment amount against the available balance on the account.
If 2SCA get payment details endpoint is available and the request contains the new field: “request_availability_of_funds” set to “true” and Sandbox scenario is specified as: “FundsAvailable” in request header and payment status is not: “InsufficientFunds”, “Rejected”, “Paid” or “Unknown” - when the endpoint is invoked, then the get payment details response will be returned with new field: “availability_of_funds” that is set to “true”.
If 2SCA get payment details endpoint is available and the request contains the new field: “request_availability_of_funds” set to “true” and Sandbox scenario is specified as: “FundsNotAvailable” in request header and payment status is not: “InsufficientFunds”, “Rejected”, “Paid” or “Unknown” - when the endpoint is invoked, then the get payment details response will be returned with new field: “availability_of_funds” that is set to “false”.

Production:

If 2SCA get payment details endpoint is available and the request contains the new field: “request_availability_of_funds” set to “true” and payment status is not: “InsufficientFunds”, “Rejected”, “Paid” or “Unknown” - when the endpoint is invoked, then the get payment details response will be returned with new field: “availability_of_funds” that is set based on the actual check that verifies the payment amount against the available balance on the account.

The examples of Confirmation of availability of funds can be found in this documentation under: PIS API examples section.

PIS API examples

Example: get list of payments

This example shows how to get list of pending payments.

This endpoint URL has the following form:

https://api.nordeaopenbanking.com/business/v4/payments/sepa

This endpoint supports GET, POST and DELETE HTTP Methods. Here we use GET since we want to get list of payments.

Here is an example request.

$ curl 'https://api.nordeaopenbanking.com/business/v4/payments/sepa' -i \
    -H 'X-Nordea-Originating-Host: <your_host>' \
    -H 'X-Nordea-Originating-Date: <now>' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer <access_token>' \
    -H 'signature: keyId=\"<your_clientapp_keyid>\",algorithm=\"rsa-sha256\",headers=\"(request-target) x-nordea-originating-host x-nordea-originating-date\",signature=\"<generated_signature>"' \
    -H 'X-IBM-Client-Id: <your_client_id>' \
    -H 'X-IBM-Client-Secret: <your_client_secret>'

And here is the response:

{
    "group_header": {
        "message_identification": "eLiQQhA4TRU",
        "creation_date_time": "2019-10-14T10:38:58.244Z",
        "http_code": 200
    },
    "response": {
        "payments": [
            {
                "_id": "bfc917ad-3a6f-471f-a7e5-1bde3e133966",
                "external_id": "tpp_supplied_string",
                "entry_date_time": "2019-10-14T12:38:36.089Z",
                "debtor": {
                    "account": {
                        "value": "FI6593857450293470",
                        "_type": "IBAN",
                        "currency": "EUR"
                    }
                },
                "creditor": {
                    "account": {
                        "value": "FI6815963000006520",
                        "_type": "IBAN",
                        "currency": "EUR"
                    },
                    "name": "OPEN BANKING AIS 1"
                },
                "amount": "1.19",
                "currency": "EUR",
                "payment_status": "PendingConfirmation",
                "tpp_messages": [],
                "_links": [
                    {
                        "rel": "self",
                        "href": "/business/v4/payments/sepa/bfc917ad-3a6f-471f-a7e5-1bde3e133966"
                    },
                    {
                        "rel": "confirm",
                        "href": "/business/v4/payments/sepa/bfc917ad-3a6f-471f-a7e5-1bde3e133966/confirm"
                    }
		}
	}
}

Example: initiate a new payment

In this example, we initiate a new payment.

This endpoint URL has the following form:

https://api.nordeaopenbanking.com/business/v4/payments/sepa

This endpoint supports GET, POST and DELETE HTTP Methods. Here we use POST since we create a new payment.

Here is an example request. The example contains Confirmation of availability of funds:

$ curl 'https://api.nordeaopenbanking.com/business/v4/payments/sepa' -i -X POST \
    -H 'X-Nordea-Originating-Host: <your_host>' \
    -H 'X-Nordea-Originating-Date: <now>' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer <access_token>' \
    -H 'digest: <generated_digest>' \
    -H 'signature: keyId=\"<your_clientapp_keyid>\",algorithm=\"rsa-sha256\",headers=\"(request-target) x-nordea-originating-host x-nordea-originating-date\",signature=\"<generated_signature>"' \ 
    -H 'X-IBM-Client-Id: <your_client_id>' \
    -H 'X-IBM-Client-Secret: <your_client_secret>' \
    -H 'Content-Type: application/json; charset=UTF-8' \
    -d '{
  "amount" : "100.12",
  "currency" : "EUR",
  "debtor" : {
    "account": {
      "_type": "IBAN",
      "currency": "EUR",
      "value": "FI6593857450293470"
    }
  },
  "creditor" : {
    "account" : {
      "_type" : "IBAN",
      "value" : "FI6593857450293470",
      "currency": "EUR"
    },
    "name" : "Creditor name",
    "message" : "Message to creditor",
    "reference" : {
      "value" : "RF11223344",
      "_type" : "RF"
    }
  },
  "external_id": "tpp_supplied_string",
  "request_availability_of_funds": true
}'

And the response looks like this:

{
  "groupHeader": {
    "messageIdentification": "NzGI4_dbk2A",
    "creationDateTime": "2019-10-14T10:32:49.179Z",
    "httpCode": 201
  },
  "response": {
    "_id": "dbba4ea0-4585-4a98-b0e3-f991f4c9a337",
    "external_id": "tpp_supplied_string",
    "paymentStatus": "PendingConfirmation",
    "_links": [
      {
        "rel": "confirm",
        "href": "/business/v4/payments/sepa/dbba4ea0-4585-4a98-b0e3-f991f4c9a337/confirm"
      }
    ],
    "amount": "123.45",
    "currency": "EUR",
    "debtor": {
       "account": {
        "_type": "IBAN",
        "currency": "EUR",
        "value": "FI6593857450293470"
      }
    },
    "creditor": {
      "account": {
        "value": "FI1350001520000081",
        "_type": "IBAN"
      },
      "name": "Beneficiary name",
      "message": "Message for the beneficiary",
      "reference": {
        "value": "RF18539007547034",
        "_type": "RF"
      }
    },
    "availability_of_funds": false
  }
}
}

Here is an example request including recurrency:

$ curl 'https: //api.nordeaopenbanking.com/business/v4/payments/sepa' -i -X POST \
    -H 'X-Nordea-Originating-Host: <your_host>' \
    -H 'X-Nordea-Originating-Date: <now>' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer <access_token>' \
    -H 'digest: <generated_digest>' \
    -H 'signature: keyId=\"<your_clientapp_keyid>\",algorithm=\"rsa-sha256\",headers=\"(request-target) x-nordea-originating-host x-nordea-originating-date\",signature=\"<generated_signature>"' \ 
    -H 'X-IBM-Client-Id: <your_client_id>' \
    -H 'X-IBM-Client-Secret: <your_client_secret>' \
    -H 'Content-Type: application/json; charset=UTF-8' \
    -d '{
  "amount": "100.12",
  "currency": "EUR",
  "debtor": {
    "account": {
      "_type": "IBAN",
      "currency": "EUR",
      "value": "FI6593857450293470"
    }
  },
  "creditor": {
    "account": {
      "_type": "IBAN",
      "value": "FI6593857450293470",
      "currency": "EUR"
    },
    "name": "Creditor name",
    "message": "Message to creditor"
  },
  "external_id": "tpp_supplied_string",
  "recurring": {
    "count": 10,
    "recurrence_type": "MONTHLY_SAME_DAY"
  }
}'

And the response looks like this:

{
  "groupHeader": {
    "messageIdentification": "NzGI4_dbk2A",
    "creationDateTime": "2019-10-14T10:32:49.179Z",
    "httpCode": 201
  },
  "response": {
    "_id": "dbba4ea0-4585-4a98-b0e3-f991f4c9a337",
    "external_id": "tpp_supplied_string",
    "paymentStatus": "PendingConfirmation",
    "_links": [
      {
        "rel": "confirm",
        "href": "/business/v4/payments/sepa/dbba4ea0-4585-4a98-b0e3-f991f4c9a337/confirm"
      }
    ],
    "amount": "123.45",
    "currency": "EUR",
    "debtor": {
      "account": {
        "_type": "IBAN",
        "currency": "EUR",
        "value": "FI6593857450293470"
      }
    },
    "creditor": {
      "account": {
        "value": "FI1350001520000081",
        "_type": "IBAN"
      },
      "name": "Beneficiary name",
      "message": "Message for the beneficiary"
    },
    "recurring": {
      "count": 10,
      "recurrence_type": "MONTHLY_SAME_DAY"
    }
  }
}

Note that the ‘payment_status’ is ‘PendingConfirmation’, it means the payment confirming(signing) process has to be started by you the TPP.

SEPA: delete multiple payments

This example shows how to bulk delete payments

Note: Not all payments are deletable (see payment status table for further information).

This endpoint URL has the following form:

https://api.nordeaopenbanking.com/business/v4/payments/sepa

This endpoint supports GET, POST and DELETE HTTP Methods. Here we use DELETE since we want to delete payments.

Here is an example request:

$ curl 'https://api.nordeaopenbanking.com/business/v4/payments/sepa' -i -X DELETE \
    -H 'X-Nordea-Originating-Host: <host>' \
    -H 'X-Nordea-Originating-Date: <now>' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer <access_token>' \
    -H 'digest: <generated_digest>' \
    -H 'signature: keyId=\"<your_clientapp_keyid>\",algorithm=\"rsa-sha256\",headers=\"(request-target) x-nordea-originating-host x-nordea-originating-date\",signature="<generated_signature>"' \
    -H 'X-IBM-Client-Id: <your_client_id>' \
    -H 'X-IBM-Client-Secret: <your_client_secret>'
    -H 'Content-Type: application/json; charset=UTF-8' \
    -d '{
	"payments":[
		 {payment_id":"11d55648-8c1d-45e2-951a-69c5aeaed99y"},
		 {payment_id":"5e6e2d6f-e2dd-4c71-b232-9dfbb88ba99y"}
		]
}'

And this is how the response looks like:


{
    "group_header":
    {
        "message_identification": "a42c1707dd444505",
        "creation_date_time": "2020-07-01T10:11:12.134Z",
        "http_code": 200
    },
    "response": [
		 "11d55648-8c1d-45e2-951a-69c5aeaed99y",
		 "5e6e2d6f-e2dd-4c71-b232-9dfbb88ba99y"
		],
    "errors": []
}

Example: get payment information

This example shows how to query payment information.

This endpoint URL has the following form:

https://api.nordeaopenbanking.com/business/v4/payments/sepa/{paymentId}

This endpoint supports GET and DELETE HTTP Method.

Here is an example request

$ curl 'https://api.nordeaopenbanking.com/business/v4/payments/sepa/{paymentId}' -i \
    -H 'X-Nordea-Originating-Host: <your_host>' \
    -H 'X-Nordea-Originating-Date: <now>' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer <access_token>' \
    -H 'signature: keyId=\"<your_clientapp_keyid>\",algorithm=\"rsa-sha256\",headers=\"(request-target) x-nordea-originating-host x-nordea-originating-date\",signature=\"<generated_signature>"' \
    -H 'X-IBM-Client-Id: <your_client_id>' \
    -H 'X-IBM-Client-Secret: <your_client_secret>'

And here is how the response looks like:

{
  "groupHeader" : {
    "messageIdentification" : "7o1UlETFzU0",
    "creationDateTime" : "2019-10-14T10:32:49.179Z",
    "httpCode" : 200
  },
  "response" : {
    "_id" : "f0f7b2ce-6b33-476f-88f8-898b5386ea48",
    "paymentStatus" : "Paid",
    "_links" : [ ],
    "amount" : "123.42",
    "currency" : "EUR",
    "debtor" : {
      "_accountId" : "FI6593857450293470-EUR"
    },
    "creditor" : {
      "account" : {
        "value" : "FI112233",
        "_type" : "IBAN"
      },
      "message" : ""
    }
  }
}

Here is an example request when Confirmation of availability of funds is used:

$ curl 'https://api.nordeaopenbanking.com/business/v4/payments/sepa/{paymentId}?request_availability_of_funds=true'\
    -H 'X-Nordea-Originating-Host: <your_host>' \
    -H 'X-Nordea-Originating-Date: <now>' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer <access_token>' \
    -H 'signature: keyId=\"<your_clientapp_keyid>\",algorithm=\"rsa-sha256\",headers=\"(request-target) x-nordea-originating-host x-nordea-originating-date\",signature=\"<generated_signature>"' \
    -H 'X-IBM-Client-Id: <your_client_id>' \
    -H 'X-IBM-Client-Secret: <your_client_secret>'

And here is how the response looks like with Confirmation of availability of funds:

{
  "groupHeader" : {
    "messageIdentification" : "7o1UlETFzU0",
    "creationDateTime" : "2019-10-14T10:32:49.179Z",
    "httpCode" : 200
  },
  "response" : {
    "_id" : "f0f7b2ce-6b33-476f-88f8-898b5386ea48",
    "paymentStatus" : "Paid",
    "_links" : [ ],
    "amount" : "123.42",
    "currency" : "EUR",
    "debtor" : {
      "_accountId" : "FI6593857450293470-EUR"
    },
    "creditor" : {
      "account" : {
        "value" : "FI112233",
        "_type" : "IBAN"
      },
      "message" : ""
    },
    "availability_of_funds": true
  }
}

SEPA: delete single payment

This example shows how to delete a payment.

Note: Not all payments are deletable (see payment status table for further information).

This endpoint URL has the following form:

https://api.nordeaopenbanking.com/business/v4/payments/sepa/{paymentId}

This endpoint supports GET and DELETE HTTP Method. Here we use DELETE to delete the payment.

Here is an example request

$ curl 'https://api.nordeaopenbanking.com/business/v4/payments/sepa/{paymentId}' -i -X DELETE \
    -H 'X-Nordea-Originating-Host: <host>' \
    -H 'X-Nordea-Originating-Date: <now>' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer <access_token>' \
    -H 'signature: keyId=\"<your_clientapp_keyid>\",algorithm=\"rsa-sha256\",headers=\"(request-target) x-nordea-originating-host x-nordea-originating-date\",signature=\"<generated_signature>"' \
    -H 'X-IBM-Client-Id: <your_client_id>' \
    -H 'X-IBM-Client-Secret: <your_client_secret>'

And here is how the response looks like:

{
    "group_header":
    {
        "message_identification": "a42c1707dd444505",
        "creation_date_time": "2020-07-01T10:11:12.134Z",
        "http_code": 200
    },
    "response": [
		 "11d55648-8c1d-45e2-951a-69c5aeaed99x"
		],
    "errors": []
}

Example: confirm payment

This example shows how to confirm payment. This endpoint URL has the following form:

https://api.nordeaopenbanking.com/business/v4/payments/sepa/confirm

This endpoint supports only PUT HTTP Method.

Here is an example request

$ curl 'https://api.nordeaopenbanking.com/business/v4/payments/sepa/confirm' -i -X PUT \
    -H 'X-Nordea-Originating-Host: <your_host>' \
    -H 'X-Nordea-Originating-Date: <now>' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer <access_token>' \
    -H 'digest: <generated_digest>' \
    -H 'signature: keyId=\"<your_clientapp_keyid>\",algorithm=\"rsa-sha256\",headers=\"(request-target) x-nordea-originating-host x-nordea-originating-date\",signature=\"<generated_signature>"' \ 
    -H 'X-IBM-Client-Id: <your_client_id>' \
    -H 'X-IBM-Client-Secret: <your_client_secret>' \
   -d '{
	"payments_ids":[
		 "11d55648-8c1d-45e2-951a-69c5aeaed99y"
		]
}

And example for decoupled flow:

$ curl 'https://api.nordeaopenbanking.com/business/v4/payments/sepa/confirm' -i -X PUT \
    -H 'X-Nordea-Originating-Host: <your_host>' \
    -H 'X-Nordea-Originating-Date: <now>' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer <access_token>' \
    -H 'digest: <generated_digest>' \
    -H 'signature: keyId=\"<your_clientapp_keyid>\",algorithm=\"rsa-sha256\",headers=\"(request-target) x-nordea-originating-host x-nordea-originating-date\",signature=\"<generated_signature>"' \ 
    -H 'X-IBM-Client-Id: <your_client_id>' \
    -H 'X-IBM-Client-Secret: <your_client_secret>' \
   -d '{
    "payments_ids": [
        "11d55648-8c1d-45e2-951a-69c5aeaed99y"
    ],
    "authentication_method": "MTA"
}

And this is how the response looks like:

{
    "group_header": {
        "message_identification": "vGm8zaLpQww",
        "creation_date_time": "2020-01-09T13:15:13.388Z",
        "http_code": 200
    },
    "errors": [],
    "_links": [
        {
            "rel": "signing",
            "href": "https://<nordeasigninghost>?client_id=y6mWwv2n5IbAVdZa5105&code_challenge_method=S256&redirect_uri=https://<host>/v3/payments/sepa/sign/callback&response_type=code&code_challenge=6v91dW6H4IIhD5Pw3g_yY3BZhycNsxoXTcQRT7yPgTQ&scope=openid+ndf+agreement&state=c2lnbmluZ19vcmRlcl9pZD00NzlhYTcxYi1lN2I3LTQ0ZDEtOTdhZS04OTgzNzFkNmQ4Mzkmc3RhdGVfaWQ9MzBmYTY4MTQtZTViMy00OWZmLWJkY2MtMWIzZWRlNjkzNDNk&signing_order_id=479aa71b-e7b7-44d1-97ae-898371d6d839"
        }
    ],
    "response": {
        "payments": [
            {
                "_id": "11d55648-8c1d-45e2-951a-69c5aeaed99y",
                "entry_date_time": "2020-01-09T13:14:50Z",
                "debtor": {
                    "account": {
                        "value": "FI9310053500006009",
                        "_type": "IBAN",
                        "currency": "EUR"
                    },
                    "message": "Own message"
                },
                "creditor": {
                    "account": {
                        "value": "FI4910013500015921",
                        "_type": "IBAN",
                        "currency": "EUR"
                    },
                    "message": "Dummy mess"
                },
                "amount": "1.13",
                "currency": "EUR",
                "payment_status": "PendingUserApproval",
                "tpp_messages": [],
                "_links": [
                    {
                        "rel": "self",
                        "href": "/v4/payments/sepa/11d55648-8c1d-45e2-951a-69c5aeaed99y"
                    }
                ],
                "planned_execution_date": "2020-01-09",
                "urgency": "standard"
            }
        ]
    }
}

Example: bulk confirm payments

This endpoint URL has the following form:

https://api.nordeaopenbanking.com/business/v4/payments/sepa/confirm

This endpoint supports only PUT HTTP Method.

Here is an example request for standard redirect flow:

$ curl 'https://api.nordeaopenbanking.com/business/v4/payments/sepa/confirm' -i -X PUT \
    -H 'X-Nordea-Originating-Host: <your_host>' \
    -H 'X-Nordea-Originating-Date: <now>' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer <access_token>' \
    -H 'digest: <generated_digest>' \
    -H 'signature: keyId=\"<your_clientapp_keyid>\",algorithm=\"rsa-sha256\",headers=\"(request-target) x-nordea-originating-host x-nordea-originating-date\",signature="<generated_signature>"' \
    -H 'X-IBM-Client-Id: <your_client_id>' \
    -H 'X-IBM-Client-Secret: <your_client_secret>'
    -H 'Content-Type: application/json; charset=UTF-8' \
    -d '{
	"payments_ids":[
		 "11d55648-8c1d-45e2-951a-69c5aeaed99y",
		 "5e6e2d6f-e2dd-4c71-b232-9dfbb88ba99y"
		]
}

And here for decoupled flow:

$ curl 'https://api.nordeaopenbanking.com/business/v4/payments/sepa/confirm' -i -X PUT \
    -H 'X-Nordea-Originating-Host: <your_host>' \
    -H 'X-Nordea-Originating-Date: <now>' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer <access_token>' \
    -H 'digest: <generated_digest>' \
    -H 'signature: keyId=\"<your_clientapp_keyid>\",algorithm=\"rsa-sha256\",headers=\"(request-target) x-nordea-originating-host x-nordea-originating-date\",signature="<generated_signature>"' \
    -H 'X-IBM-Client-Id: <your_client_id>' \
    -H 'X-IBM-Client-Secret: <your_client_secret>'
    -H 'Content-Type: application/json; charset=UTF-8' \
    -d '{
    "payments_ids": [
        "11d55648-8c1d-45e2-951a-69c5aeaed99y",
        "5e6e2d6f-e2dd-4c71-b232-9dfbb88ba99y"
    ],
    "authentication_method": "MTA"
}

And this is how the response looks like (common for standard and decoupled flow):

{
    "group_header": {
        "message_identification": "vGm8zaLpQww",
        "creation_date_time": "2020-01-09T13:15:13.388Z",
        "http_code": 200
    },
    "errors": [],
    "_links": [
        {
            "rel": "signing",
            "href": "https://<nordeasigninghost>?client_id=y6mWwv2n5IbAVdZa5105&code_challenge_method=S256&redirect_uri=https://<host>/v3/payments/sepa/sign/callback&response_type=code&code_challenge=6v91dW6H4IIhD5Pw3g_yY3BZhycNsxoXTcQRT7yPgTQ&scope=openid+ndf+agreement&state=c2lnbmluZ19vcmRlcl9pZD00NzlhYTcxYi1lN2I3LTQ0ZDEtOTdhZS04OTgzNzFkNmQ4Mzkmc3RhdGVfaWQ9MzBmYTY4MTQtZTViMy00OWZmLWJkY2MtMWIzZWRlNjkzNDNk&signing_order_id=479aa71b-e7b7-44d1-97ae-898371d6d839"
        }
    ],
    "response": {
        "payments": [
            {
                "_id": "11d55648-8c1d-45e2-951a-69c5aeaed99y",
                "entry_date_time": "2020-01-09T13:14:50Z",
                "debtor": {
                    "account": {
                        "value": "FI9310053500006009",
                        "_type": "IBAN",
                        "currency": "EUR"
                    },
                    "message": "Own message"
                },
                "creditor": {
                    "account": {
                        "value": "FI4910013500015921",
                        "_type": "IBAN",
                        "currency": "EUR"
                    },
                    "message": "Dummy mess"
                },
                "amount": "1.13",
                "currency": "EUR",
                "payment_status": "PendingUserApproval",
                "tpp_messages": [],
                "_links": [
                    {
                        "rel": "self",
                        "href": "/v4/payments/sepa/11d55648-8c1d-45e2-951a-69c5aeaed99y"
                    }
                ],
                "planned_execution_date": "2020-01-09",
                "urgency": "standard"
            },
            {
                "_id": "5e6e2d6f-e2dd-4c71-b232-9dfbb88ba99y",
                "entry_date_time": "2020-01-09T13:15:02.525Z",
                "debtor": {
                    "account": {
                        "value": "23001546139529",
                        "_type": "IBAN",
                        "currency": "EUR"
                    },
                    "message": "Own message"
                },
                "creditor": {
                    "account": {
                        "value": "FI1350001520000081",
                        "_type": "IBAN",
                        "currency": "EUR"
                    },
                    "message": "Dummy mess"
                },
                "amount": "1.14",
                "currency": "EUR",
                "payment_status": "PendingUserApproval",
                "tpp_messages": [],
                "_links": [
                    {
                        "rel": "self",
                        "href": "/v4/payments/sepa/5e6e2d6f-e2dd-4c71-b232-9dfbb88ba99y"
                    }
                ],
                "planned_execution_date": "2020-01-09",
                "urgency": "standard"
            }
        ]
    }
}

Example: confirm payment using CCALC method

This example shows how to confirm payment using code calculator to sign the payment. This endpoint URL has the following form:

https://api.nordeaopenbanking.com/business/v4/payments/sepa/confirm

This endpoint supports only PUT HTTP Method.

Here is an example request

$ curl 'https://api.nordeaopenbanking.com/business/v4/payments/sepa/confirm' -i -X PUT \
    -H 'X-Nordea-Originating-Host: <your_host>' \
    -H 'X-Nordea-Originating-Date: <now>' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer <access_token>' \
    -H 'digest: <generated_digest>' \
    -H 'signature: keyId=\"<your_clientapp_keyid>\",algorithm=\"rsa-sha256\",headers=\"(request-target) x-nordea-originating-host x-nordea-originating-date\",signature=\"<generated_signature>"' \ 
    -H 'X-IBM-Client-Id: <your_client_id>' \
    -H 'X-IBM-Client-Secret: <your_client_secret>' \
   -d '{
	"payments_ids":[
		 "d97aed94-142c-4375-8c54-026356c3d37d"
		],
    "authentication_method":"CCALC"
}

The response look like,

{
    "group_header": {
        "message_identification": "be7d4857-af76-4d1c-9a83-9b3638a039d6",
        "creation_date_time": "2023-03-31T11:01:50.189101427Z",
        "http_code": 200
    },
    "errors": [],
    "_links": [
        {
            "rel": "signing",
            "href": "https://nasa.nd.test.nordea.com?client_id=IhGRcnee8OnfM0oUuguK&code_challenge_method=S256&redirect_uri=https://open.dev01.qaoneadr.local/business/v4/payments/sign/callback&response_type=code&code_challenge=6v91dW6H4IIhD5Pw3g_yY3BZhycNsxoXTcQRT7yPgTQ&scope=openid+ndf+agreement&state=c2lnbmluZ19vcmRlcl9pZD1hZmMxMzg5Yy05Nzk4LTQ5ZTMtYjU4Zi04YmFjZDJlYWFjMTkmc3RhdGVfaWQ9MzhiNjg5M2UtYjViNC00MmJiLWFmNGQtNGRjYmI0YmJhNDkz&signing_order_id=afc1389c-9798-49e3-b58f-8bacd2eaac19"
        }
    ],
    "signing_order_id": "afc1389c-9798-49e3-b58f-8bacd2eaac19",
    "challenge": "844316",
    "response": {
        "payments": [
            {
                "_id": "d97aed94-142c-4375-8c54-026356c3d37d",
                "entry_date_time": "2023-03-31T08:30:49Z",
                "debtor": {
                    "account": {
                        "value": "FI4810473000107695",
                        "_type": "IBAN",
                        "currency": "EUR"
                    }
                },
                "creditor": {
                    "account": {
                        "value": "FI4514323000205187",
                        "_type": "IBAN",
                        "currency": "EUR"
                    },
                    "name": "WHALES OB SME OY",
                    "message": "MK Message for the beneficiary"
                },
                "amount": "2.5",
                "currency": "EUR",
                "payment_status": "PendingUserApproval",
                "tpp_messages": [],
                "_links": [
                    {
                        "rel": "self",
                        "href": "/v4/payments/sepa/d97aed94-142c-4375-8c54-026356c3d37d"
                    }
                ],
                "planned_execution_date": "2023-03-31",
                "urgency": "standard",
                "requested_execution_date": "2023-03-31",
                "payment_type": "SEPA"
            }
        ]
    }
}

This example shows how to send the response code to sign payment using code calculator. This endpoint URL has the following form:

https://api.nordeaopenbanking.com/business/v4/payments/sepa/sign

This endpoint supports only PUT HTTP Method.

Here is an example request

$ curl 'https://api.nordeaopenbanking.com/business/v4/payments/sepa/confirm' -i -X PUT \
    -H 'X-Nordea-Originating-Host: <your_host>' \
    -H 'X-Nordea-Originating-Date: <now>' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer <access_token>' \
    -H 'digest: <generated_digest>' \
    -H 'signature: keyId=\"<your_clientapp_keyid>\",algorithm=\"rsa-sha256\",headers=\"(request-target) x-nordea-originating-host x-nordea-originating-date\",signature=\"<generated_signature>"' \ 
    -H 'X-IBM-Client-Id: <your_client_id>' \
    -H 'X-IBM-Client-Secret: <your_client_secret>' \
   -d ' {
	"method":"CCALC",
	"signing_order_id":"afc1389c-9798-49e3-b58f-8bacd2eaac19",
	"response_code":"123456789"
}

The response look like,

{
    "success": true
}

Business Payments Salary and Pension Transfer API v4 Business Single SCA Payments API v4