Q: What's the difference between an access (bearer) token and a signing key?
Corporate Access Authorization API
Q: Are there any best practices around either saving the key_id or the key itself?
A: A personal signing key identifies users and allows them to make payments on their behalf. If you are sure that you can safely store the signing key, then you might consider doing it.
If you prefer to keep only an id and get the signing key value via:
GET corporate/v2/keys/{key_id}
then it's also an option. We don't have any official recommendations towards either of the options.
Q: How can I include multiple authorizers when creating a new signing key?
A: A personal signing key is used as an identification of specific user. You can't have two users share the same signing key. If you want to use signing keys for multiple users, then you need to create multiple signing keys - one per user.
Note: Regarding the personal signing key, only one authorizer is required to perform SCA. The generated key belongs to the authorizer with roles defined in the personal signing key authorization request.
Refer to:
Corporate Payout API - details
Personal signing key can be used during payment initiation request. We follow payment permissions configured for the agreement and the user in Corporate Netbank. There can be a scenario that the key used for payment initiation requires additional approval, so another authorizer with payment permissions should use his own personal signing key to perform payment execution.
Q: Can we use the same access token and signing key for many accounts in different countries?
A: There are two preconditions to use the same signing key and access token to execute payments from various accounts (including different countries):
- All those accounts need to be in the same agreement
- You need to use the same application when making those payments (same X-IBM-Client-ID)
Additionally, for a signing key to work, a user that generates signing key needs to have proper permissions to execute payments from those accounts.
Q: What is the timeout value for a strong customer authentication to get the signing key? When initiating the singing key with:
POST corporate/v2/keys/sign
how much time does the authorizer have to sign? How long, until:
GET corporate/v2/keys/{key_id}
returns FAILED?
A: The timeout for authentication session depends on the authentication method chosen. Right now it is 3 minutes for MTA (Nordea ID mobile application) and 5 minutes for BANKID_SE.
Q: Assuming that the client application has obtained a signing key and an access token, then if a payout is initiated by sending a request to:
POST corporate/premium/v2/payments
will there still be a need for an authorizer to manually accept the payout in his Nordea ID application for the payout to change its status to PAYMENT_EXECUTED?
A: In case of vast majority of payments, signing key generated for the user with required access rights is enough to successfully process the payment to execution state. Although there might be a need of an additional verification which requires manual authentication, for example in Nordea ID.
Refer to:
Payment Flow (Corporate Payout API)
Q: What is the process of performing an additional verification?
A: You could find details description of the flow in our documentation:
Payment Flow (Corporate Payout API)
But in short it could be described as:
- You need to initiate the payment with the signing key
- Next you poll the status until the status changes to AUTORHIZATION_PARTIAL and the reason "info.payment.verification_required"
- Use the verify endpoint to start the signing of the payment process. It will invoke strong customer authentication on the mobile of provided user.
- Poll the status again until it changes again to AUTORHIZATION_PARTIAL but this time, without any reason
- Use sign endpoint with the same signing key you used in step 1.
- Continue as per normal flow
Q: Is the order of the signing important? Does the signer that initiated the payment have to sign first? Can these two actions:
- Sign with the key that initiated the payment
- Sign with another key
be done sequentially or do we have to wait for the payment to change the status before the second signing can be made? Do we need to keep track of the state of the signing process on our side since we can not tell which signing to be made since the status is just AUTHORIZATION_PARTIAL?
A: Yes, the order of the signing is important. It needs to be in order as we need to evaluate the rights of the signing key in the first request to see if the second key is needed (a setup with the use of TWO_TOGETHER rules is not always the case).
Q (Sandbox): I try to test payment verification flow in sandbox, but the payment ends up in AUTHORIZATION_PENDING status.
A: We put 10 seconds delay to mimic the waiting time needed for manual action. After 10 seconds from verifying, the payment should switch to AUTHORIZATION_PARTIAL.
Note: The behavior might vary depending on the authentication_type and authentication_method used:
- For REDIRECT authentication_type we are waiting for the redirect link to be executed before moving forward with the status
- For DECOUPLED authentication_type and MTA authentication_method we are waiting 10 seconds before changing the status
- For DECOUPLED authentication_type and BANKID_SE authentication_method you need to follow:
GET corporate/v1/authentications/bankid_se/{authentication_id}
endpoint and wait until the status will change to SUCCESS.
Refer to:
Payment templates/Authentication Types (Corporate Payout API)
Get BankID SE authentication details (Corporate Payout API)
Corporate payout API examples/Get details of the BankID SE authentication