Introduction
Nordea introduces a new feature called Single strong customer authentication (SCA) payment flow. After a payment is initiated, a signing URL will be generated, the TPPs need to redirect the end user to that signing page. After the payment is signed by the PSU, the user is redirected back to the Third Party Provider (TPP) page (the one provided during the onboarding process for the sake of the OAuth2.0 authorization flow). The redirect url also includes auth_code using to exchange to an access token for get details and cancellation for Single SCA payments. If the page is not available for some reason, the PSU will be redirected to the Nordea home page.
Detailed explanation
| Endpoint | AS-IS | More info of changes |
|
POST: /v*/payments/authorization/domestic-credit-transfer or POST: /v*/payments/authorization/sepa-credit-transfer |
response 201 CREATED { "group_header":{ "creation_date_time":"2021-02-17T12:01:33.630Z", "http_code":201, "message_identification":"string", "message_pagination":{ "continuation_key":"string" } }, "response":{ "_links":[ { "href":"string", "rel":"string" } ] } } |
The link relation "signing" will be the header "location" redirection to be sent to the PSU in some form of browser. The result will in the end be a 200 OK, this should trigger a close of the browser session |
|
GET: "$nasa_url$?order_id=1234567&redirect_uri=$obi_url$ &state=$url_encoded_parameters$" |
HTTP_Status 302 redirect Format of the success response (redirection url to the TPP): $tpp_redirect_url$?success=true&state={TPP provide state}&response_code={encode-string-with-multiple-parameters}&auth_code={encode-string} |
After the payment is signed by the PSU, the user is redirected to the Third Party Provider (TPP) page (the one provided during the onboarding process for the sake of the OAuth2.0 authorization flow). If the page is not available for some reason, the PSU will be redirected to the Nordea home page. The "success" query parameter in the response indicates if the signing was completed. Note: it doesn't have to mean the payment was successfully executed. For example: for domestic DK payments a second channel confirmation (like SMS) is required when the amount is bigger than 100 000 DKK. To make sure the transfer was paid and done - see next step. The encode-string-with-multiple-parameters has 2 parameter external-id and status (the payment status). |
|
In case of error, HTTP_Status 302 redirect Format of the success response (redirection url to the TPP): $tpp_redirect_url$?error=error&error_description=error description&state={TPP provide state}&response_code={encode-string-with-multiple-parameters}&auth_code={encode-string} |
||
|
GET: /personal/v*/payments/{payment-id}/status |
response 200 OK |
Check the "payment_status" field value to find out if the payment was successfully executed (should be "paid"). External-id, is the external_id used in the initiate payment step. Payment-id is the payment_id from the payment initiation response |
Request sample
{
"payment": {
"amount": 9.14,
"currency": "EUR",
"urgency":"standard",
"requested_execution_date":"2024-10-25",
"creditor": {
"account": {
"value": "FI1450000120236228",
"currency": "EUR",
"type":"IBAN"
},
"name": "Beneficiary name",
"message":"Message to Ben"
},
"debtor": {
"account": {
"currency": "EUR",
"value": "FI6915723500036470",
"type":"IBAN"
}
},
"external_id": "externalId",
"merchant":"Shoe shop"
},
"authentication": {
"state": "obi-supplied-state-FI",
"redirect_uri": "https://www.example.com",
"authentication_method" : "CCALC"
}
}
Response sample
{
"group_header": {
"message_identification": "1d77bb9196cdf20e",
"creation_date_time": "2021-10-10T14:13:33.012024141Z",
"http_code": 201
},
"response": {
"_links": [
{
"rel": "redirect",
"href":"https://nasa.nd.test.nordea.com?client_id=VjlDcKEAah8ioKuzUIDZ&code_challenge_method=S256&redirect_uri=https%3A%2F%2Fopen.dev01.qaoneadr.local%2Fpersonal%2Fv1%2Fpayments%2Fauthorization%2Fcallback&response_type=code&code_challenge=fZQV_6wpA_p7xHrkKFBA2NYfLmlP5pl.plPS6RilE8fi8&scope=openid+ndf+agreement%state=e5bac307-e67d-4735-8c54-7af41f863389&nonce=to3zgEjslhOE6CjMgVFzc2h5VGoKtyB2kcPDfHAP&login_hint=ccalc&signing_token=eyJjdHkiOiJKV1QiLCJlbmMiOiJBMjU2RONNliwiYWxnljoiUINBLU9BRVAtMjU2ln0.PtRPkksFxsOV9SBYim"
},
{
"rel": "status",
"href": "/v2/single-sca-payments/620dad35-6da2-44f6-96ce-6e810b90f531/status"
}
,
{"rel":"details",
"href":"/v2/single-sca-payments/620dad35-6da2-44f6-96ce-6e810b90f531"},
]
}
}
FAQ
Q:
How is this different than the normal PIS API?
A:
The Single SCA doesn't require initial authentication to to be able to initiate a new payment, instead, it requires only signing of the payment.
Q:
Which countries are supported?
A:
Denmark, Sweden, Finland and Norway.
Q:
What consents are required in order to initiate/create a single SCA payment?
A:
It requires only the end user sign of the payment.
Q:
What formats can be use for accounts (debtor, creditor)
A:
- For debtor we support BBAN_DK, BBAN_NO, BBAN_SE and IBAN
- For creditor we support BBAN_DK, BBAN, NO, BBAN_ SE, BGNR, GIRO_DK and IBAN type.
Please refer to:
"creditor": {
"account": {
"value": "FI1450000120236228",
"currency": "EUR"
},
"name": "Beneficiary name",
"message":"Message to Ben"
},
"debtor": {
"account": {
"currency": "EUR",
"value": "FI6915723500036470"
}
}
Q:
Can I do a cross border payment?
A:
Cross border payment is supported.
Q:
Can I enable decoupled flow with BankID for single SCA payments?
A:
Decoupled flow is in our long term roadmap but currently is not available yet.
Q:
Is the flow below correct?
- Create a SingleSCA payment with the endpoint:
POST /personal/v2/payments/authorization/domestic-credit-transfer
and redirect the user to the returned URL
- Catch the callback call and save the auth_code
- Use the saved code to get the authorization token using the endpoint:
POST personal/v5/authorize/token
The last step fails with 400 error - code: error.parameters.invalid, description: Parameters invalid
A:
It's not correct. You can use endpoint:
POST personal/v5/authorize/token
to complete authorization flow for MULTIPLE_PAYMENTS scope (plus AIS scopes) but in case of Single SCA payments please follow our documentation:
PIS API scenarios for Single SCA
Q:
Is it possible to retrieve the account holder name and IBAN via the payment details endpoint when the debtor account is not explicitly provided during initiation?
A:
We do not offer a single SCA flow where no debtor account is supplied. In single SCA, you must supply all payment details beforehand and therefore need to know the debtor information. However, if you are using the 2SCA flow, you can retrieve consented accounts with additional information through the payments/accounts endpoint.
Q:
Is it possible to reuse the token employed for payment confirmation in subsequent confirmation processes?
A:
Upon SCA completion, you will be issued a token that permits retrieval of single SCA payment details. In the 2SCA flow, you can obtain a long-lasting token.