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.

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}
         
  • 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

When using the embedded approach, the PSU will enter their personal security credentials on the TPP screen.

SMS based authentication

We distinguish two main SMS authentication cases based on the type of the token used:

  • When authorising a PSU identification consent and TPP only has the application authentication token, the PSU must enter his/her user name and password first. When that is done, a one-time password (OTP) is sent to him/her in an SMS message, and the PSU must enter that one-time password too.

  • The PSU identification consent token must be used in all other cases. Here, the PSU has to enter only his/her password (but not the user name) first. When this is done, a one-time password (OTP) is sent to him/her in an SMS message, which must be entered too.

When using the embedded-decoupled approach, the PSU uses a separate, secondary device to authenticate.

MToken based authentication

We distinguish two main Mobile token authentication cases based on the type of the token used:

  • When authorising a PSU identification consent and TPP only has the application authentication token:
    • The PSU must either provide his/her K&H eID, after which he/she receives a push notification in the K&H mobile bank application and can use that to authorise the order

or

  • When selecting mobile token authentication, API response contains a CRONTO image which must be displayed by TPP for the PSU. Then the PSU can take a photo of the CRONTO image using the K&H mobile bank application and authorise the PSU identification consent.

  • The PSU identification consent token must be used in all other cases, after which the PSU will receive a push notification in the K&H mobile bank application and can use that to authorise the order.

ViCA based authentication

We distinguish two main ViCA authentication cases based on the type of the token used:

When authorising a PSU identification consent and TPP having the application authentication token only, the PSU must enter his/her K&H eID, after which he/she receives a push notification in the ViCA application, where he/she can use it to authorise the order;

  • The PSU identification consent token must be used in all other cases, after which the PSU will receive a push notification in the ViCA application and can use that to authorise the order.