learn about supported SCA approaches
- redirection
- embedded
- embedded-decoupled
Certain transactions must be authorised by several PSU (e.g. in corporate banking), so dedicated authorisation endpoints have been set up in K&H’s API besides the “payment initiation” and “establish consent” transaction endpoints. The resources created when payment or consent data is sent in are separated from the authorisation (sub)resources. A payment which needs to be signed multiple times will end up in a payment resource with more SCA (sub-)resources.
Signing basket
Grouping several transactions for one common authorisation process is supported by the signing-baskets endpoint. You can first submit payment and consent data without starting the authorisation. After having grouped the related payment and consent resources by using a grouping command through the signing-baskets endpoint, the authorisation then can be started by authorising this basket content. This results in a basket resource with the corresponding authorisation sub-resource.
The grouping of transaction is only a "signing vehicle", bundling authorisation processes for the grouped. Only one authorisation sub-resource can belong to a signing basket.
Single transactions of the signing basket could be authorised with additional SCAs directly on transaction level.
Signing multiple consents via account listing endpoint
After the PSU has a valid PSU Identification consent, the account listing endpoint can be used to query and list all the PSU’s payment-accounts (see API documentation for further details).
For each account, the consents have to be created (POST /consents) separately, after which a single signing-basket can be used to authorize all the required consents for all the available accounts in one SCA-flow.
Payment Cancellation
Cancellation process is handled by cancellation authorisation sub-resources in analogy to the actual authorisations. The authorisation sub resources will stay unchanged.
K&H’s API supports the following SCA approaches:
- redirection
- embedded
- embedded-decoupled
K&H Bank customers can use the following authentication tools/devices:
- SMS
- Mobile token
- ViCA
When using the redirect approach, TPP redirects the PSU to the K&H redirection screen for SCA, where they must enter their personal security credentials to approve the given transaction. An example of a redirect URL with parameters is the following: https://authentication.kh.hu/redirectpage/?ResourceURI=/v1/consents/161507ac-1229-4f8e-a16b-f1aca14a217c/authorisation/41e2d95b-ebff-457c-991e-64f41723f607&JWTToken=<JWTToken>&RedirectBackURI=<RedirectBackURI>
The following parameters need to be specified for the redirection (all of them are mandatory):
- ResourceURI
- the URL of the authorisation sub-resource to be authorised, e.g.
- /v1/{paymentservice}/{paymentproduct}/{paymentId}/authorisations/{authorisationId}
- /v1/consents/{consentId}/authorisations/{authorisationId}
- the URL of the authorisation sub-resource to be authorised, e.g.
- JWT Token
- PSU identification token, or
- application authentication token
- if TPP does not have a PSU identification consent yet, it can still redirect the PSU in the lack of that;
- in a situation like this, the process launched on the K&H redirection screen for customer authentication will start with creating an PSU identification consent, followed by transaction authorisation only afterwards;
- the identifier of the implicitly created PSU identification consent will be passed to TPP as a parameter when the PSU is redirected back to the TPP screen.
- RedirectBack URL
- This must contain the URL address where the K&H redirection screen for customer authentication must redirect back the PSU after customer authentication. Only redirect URL addresses starting with the host specified during application registration are allowed.
- When returning the PSU to this address, the following data are passed as URL parameters:
- success or error code (parameter name: resultCode)
- identifier of implicitly created PSU identification consent (parameter name: identConsentId)
- Example of a RedirectBack URL: https://my.tppapp.hu/tppApp?identConsentId=b0938ec2-d376-4681-b736-4a996318427f&resultCode=OK