Sample code uses ES6 language features such as arrow functions and promises. For compatibility with IE11, code written with these features must be either transpiled using tools like Babel or refactored accordingly using callbacks.
This container supports functionality for Crelan bank cards
Initialise a Trust1Connector client:
Get the Crelan module:
Call a function for the Crelan module:
The constructor for the Crelan expect as the parameter to be a valid reader-ID. A reader-ID can be obtained from the exposed core functionality, for more information see Core Services. Core services responds with available card-readers, available card in a card-reader, etc. For example: In order to get all connected card-readers, with available cards:
This function call returns:
We notice that a card object is available in the response in the context of a detected reader.
The reader in the example above is VASCO DIGIPASS 870
, has pin-pad capabilities, and there is a card detected with given ATR and some descriptions.
An ATR (Answer To Reset) identifies the type of a smart-card.
The reader, has a unique ID, reader_id
; this reader_id
must be used in order to request functionalities for the Crelan card.
This must be done upon instantiation of the Crelan container:
All methods for crelan
will use the selected reader - identified by the reader_id
.
List the supported applications on the Crelan card
An example callback:
Response:
The application data contains information of the holder of the card, the validity, the primary account number, ...
An example callback:
Response:
On some applications there is an issuer public key certificate present. The aid parameter indicates which application you want to use, this can be fetched using the applications endpoint.
An example callback:
Response:
On some applications there is an icc public key certificate present. The aid parameter indicates which application you want to use, this can be fetched using the applications endpoint.
An example callback:
Response:
When the web or native application is responsible for showing the password input, the following request is used to verify a card holder PIN:
Response:
When the pin entry is done on the pin-pad, the following request is used to verify a given PIN:
Response:
After an unsuccessful PIN verification, the error code indicates the number of retries left. For example, when executing:
The following error message will be returned when PIN is wrong:
After a second wrong PIN verification:
Note that, when the user has at least one retry left, entering a correct PIN resets the PIN retry status
.
A Base64-encoded string representation of the digest bytes must be included in the data
property of the request.
txId
will be displayed on the PIN pad
language
determines the language displayed on the PIN pad
Additionally, it is possible to bulk sign data without having to re-enter the PIN by adding an optional bulk
parameter set to true
to the request. The PIN will not need to re-entered until a request with bulk
being set to false
is sent, or the Bulk PIN Reset method is called.
When using bulk signing, great care must be taken to validate that the first signature request was successful prior to sending subsequent requests. Failing to do this will likely result in the card being blocked.
The PIN can provided/entered in the same way as Verify PIN
Response will look like:
The functions specified are asynchronous and always need a callback function. The callback function will reply with a data object in case of success, or with an error object in case of an error. An example callback:
The error object returned:
For the error codes and description, see Status codes.
Code
Description
301
Warning: the user can try twice more to verify his PIN
301
Warning: the user has only 1 retry left
301
Error: the PIN is blocked