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.  

data model for a single payment with multiple SCA

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.

SCA data model for Signing Baskets

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.

payment cancellation process

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
redirect

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

redirect SCA process for standing order with PSU Identification Token

redirect SCA process for payment transaction with Tpp App Token