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:

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.

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=" + response.data);
aducid.setResultOperationUrl("/aducid-binder/transactionCheck");
aducid.setProxyUrl("/aducid-binder/proxy");

Expression response.data 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).

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.

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

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

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": "https://dev-bank.demo.aducid.com:443/bank-nc/loginPage"
}

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": "https://dev-bank.demo.aducid.com:443/bank-nc/paymentCheck?transactionId\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.