User Tools

Site Tools


Transaction support

You can follow these steps to integrate no-code transaction support to your application:

  • Send transaction HTTP request to ADUCID Binder
  • Process authentication on ADUCID Binder
  • Read transaction JSON response

See chapters below for details.


At first, transaction must be prepared and sent to ADUCID Binder. ADUCID Binder accepts transaction HTTP requests at /aducid-binder/prepareTransactionUpload. Before ADUCID Binder call, unique identifier (aka transactionId) must be generated. This identifier is neccessary to successfully pair transaction request and response. Let's see ADUCID Binder transaction interface parameters:

Name Values Mandatory Description
transactionId String Yes transaction unique identifier
peigMessage MultipartFile No transaction message in plain or HTML format
factor PERSONAL or COMFORT or empty value No required personal code level
redirectUrl String Yes URL to redirect after ADUCID Binder successful authentication
errorPage String No URL to redirect after ADUCID Binder unsuccessful authentication
udi String No if defined, security attack check is realized
peigId String No if defined, mobile push notification is realized

It is neccessary to add transactionId parameter to redirectUrl attribute to successfully pair transaction request and response. If errorPage is not defined, redirectUrl is used in case of error. Now we can send prepared request to /aducid-binder/prepareTransactionUpload and check successful transaction upload (HTTP code 200).

We must also remember to provide generated transaction identifier to web view, e.g. Ajax JSON response or JSP expression language.

Transaction itself

When transaction data are successfully uploaded, we can start transaction itself. It can be done with use of Client API for Web Integration. We only need to specify right ADUCID Binder methods to serve transaction:

aducid.setStartOperationUrl("/aducid-binder/transactionJson?transactionId=" +;

Expression contains unique transaction identifier pushed from backend to view. After transaction run, user is redirected to redirectUrl value (or to errorPage if defined and error occurs).

Response processing

User is now redirected to redirectUrl, where we must process transaction operation result. Operation result is saved in HTTP request attributes. We try to read attribute with prefix AAA_UTR_ with transaction identifier at the end. When value exists, we must invoke base64 decoding on value to get readable JSON response.

Positive response

When transaction was successful (status = OK), JSON response will be:

  "status": "OK",
  "data": null,
  "redirect": null

Negative response

Transaction can be also unsuccessful (status = ERROR). There are two types of failures - failure directly on AIM and second level failure. Failure on AIM can be:

  "status": "ERROR",
  "data": {
    "message": "Wrong personal factor.",
    "key": null,
    "arguments": null,
    "statusAIM": "active",
    "statusAuth": "OK",
    "statusLF": "KO"
  "redirect": ""

In case of AIM failure, values statusAIM and statusAuth will be filled, statusLF only in case of personal code use. You can find statusAuth and statusLF meanings in chapter Error statuses of authentication process. Meanings of statusAIM can be found in Semantics of individual statuses of the authentication session (AIMStatus) chapter. Attribute message is technical readable text describing error.

Secondary level failure can look like:

  "status": "ERROR",
  "data": {
    "message": "Potential security attack.",
    "key": "web.potentialSecurityAttack",
    "arguments": [],
    "statusAIM": null,
    "statusAuth": null,
    "statusLF": null
  "redirect": "\u003dac39bc24-edc8-477d-95f5-6793a452bd80"

In this case, value key is filled, arguments only in situation of existing error message arguments. Possible values of key can be found at Client Status or Web Status. Attribute message is technical readable text describing error.

nocode/transactions.txt · Last modified: 2020/03/29 11:34 by