Crelan
Introduction
This container supports functionality for Crelan bank cards
Get Crelan Module
Initialise a Trust1Connector client:
Get the Crelan module:
Call a function for the Crelan module:
Obtain the Reader-ID
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
.
Reading data
Applications
List the supported applications on the Crelan card
An example callback:
Response:
Application data
The application data contains information of the holder of the card, the validity, the primary account number, ...
An example callback:
Response:
Issuer Public Key Certificate
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:
ICC Public Key Certificate
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:
Verify PIN
Verify PIN without pin-pad
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:
Verify PIN with pin-pad
When the pin entry is done on the pin-pad, the following request is used to verify a given PIN:
Response:
Verify PIN - retries left
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
.
Code | Description |
| Warning: the user can try twice more to verify his PIN |
| Warning: the user has only 1 retry left |
| Error: the PIN is blocked |
Sign
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 padlanguage
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:
Error Handling
Error Object
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.
Last updated