About: This document describes the different possible combinations of steps and data request procedures to identify a cardholder that can be implemented on ATIOnet. These capabilities may vary according to the capture device, protocol and susbscription model.
| Document Information | |
| File: | AN-Identification_Scenarios-Concepts |
| Doc. Version: | 1.0 |
| Release Date: | 20, July 2014 |
| Author: | ATIO International LLC |
| Change Log | ||
| Ver. | Date | Change summary |
| 1.0 | 20/July/2014 | Initial version |
| 1.1 | 06/August/2014 | Splitted some scenarios to clarity |
- Definitions
- Overview
- Identifications and Prompts
- Relevant Configuration
- Prompting Rules
- Terminal / Controller Configuration
- Enforced Vehicle-Driver relation
- Use of PINs
- Scenarios
- Terminal
- The device or system in charge of handling the interaction with the cardholder and/or the attendant and, eventually, controlling the fuel delivery.
- Cardholder
- The person, vehicle or unit that is identified as the subject of the transaction
- Sub-account
- A particular account whithin a Contract with an assigned balance
- Identification
- Any mean to identify a cardholder regardless of the technology involved. It can be any type of media support or piece of information presented to a capture device in order to identify a cardholder
Every transaction on ATIOnet starts with a secure identification of a sub-account to be affected (debit or credit) by the transaction. A sub-account can be a Vehicle -or broadly a Unit- or a Driver -broadly a Person. On ATIOnet, every transaction impacts a single sub-account, it is called a sub-account because it is always part of a Contrat (its parent account). It is common to request two Identifications on the same transaction, usually to identify the Vehicle and the Driver or viceversa.
On ATIOnet Native Transaction Protocol, there are two sets of Identification fields, a Primary ID and a Secondary ID; it is up to the Terminal to decide which one is Primary or Secondary but the common practice is to send the ID presented first as the Primary. Most of the Terminals have the capability to capture a second ID and send it as a prompt on the authorization request. ATIOnet is capable of taking such prompt and processing it as a the secondary Identification.
It is important to note that only the sub-account linked to the Primary Identification will have their balance affected by the transaction; the Secondary Identification will be used to perform a two-fold identification capture and may have the related entities affected on its statistics and counters (like quotas or mileage calculation) but the money or volume sold will be accounted to the Primary sub-account only.
In ATIOnet's language, an Identification is the generic name given to any media support, device, or piece of information that could be used to identify a card-holder at transaction-capture time, for example magnetic cards, chipkeys, read-only TAGs, smart-cards, read/write TAGs, 1D and 2D bardcodes, eButtons, and manually-entered codes.
ATIOnet implements specific features for certain identification technologies, like the Vehicle Installation Flow for AVI's ring TAGs, or reusable and embossable attributes; but the minimum common functionality is that the Terminal is responsible to capture and send the proper Identification ID.
A Prompt is a piece of data captured at the site during transaction capture. Prompts are conditional, meaning that can be required or not by ATIOnet to process a transaction request, depending on a combination of configuration and/or business rules. If the Terminal fails to send all required Prompts for a given transaction request, ATIOnet responds with a specific decline code and message, also including the list of prompts that must be sent for the transaction. The Terminal should process the response and re-send the request with the complete information. Prompts usually are codes or values manually entered at the Terminal, but could be preconfigured or calculated values at the Terminal, or directly captured from the Identification media or device.
Common prompts include Truck ID, Trailer ID, Odometer and Engine hours, known as Customer data. But some prompts are related to the identification of the cardholder, as Driver ID and Vehicle ID.
Certain combinations of operation conditions and a business rules cause that a Prompt is treated as an Identification or a part of an Identification. For example, if a Vehicle is configured to require dual identification (Vehicle plus Driver), ATIOnet expects both the Primary and Secondary tracks to be present on the request or the transaction. But if the terminal system does not support two card swipes, the Terminal in ATIOnet may be configured to use the Driver ID prompt as the Driver's Identification Track.
Some prompts, when enforced via Rules, can help with the Identification. Terminals supporting re-prompt functionality can activate prompts of missing information dinamically reacting to specific decline codes received from the Host.
- Truck Number
- Vehicle ID (Unit Code)
- Vehicle PIN
- Secure numeric value associated to the Vehicle
- Driver ID
- Driver Identification number, must match the Driver Code on the system
- Driver PIN
- Secure number associated to the Driver
Note about Vehicle and Driver ID data-type: ATIOnet supports alphanumeric values in Vehicles and Drivers, but if you plan to use them as IDs, take into consideration that most capture terminals don't accept string input on those prompts, so numeric-only values should be used instead.
The flag Use Driver Id as Driver Card Track parameter forces the system to pass the Driver ID prompt as a Secondary Track (secondary identification), instead of taking it as an information-only prompt. This is useful to implement a two-fold authentication on terminals that doesn't accept dual card-swipe.
Vehicle can be linked to one or more Drivers and viceversa from the Vehicle and Driver administration tools. When the Primary sub-account is linked to another, ATIOnet will automatically enforce a two-fold authentication, meaning that both the Vehicle and the Driver should be identified successfully at capture time and the relation must be satisfied in order for the transaction to be approved.
PINs are not an identification per-se, they are supporting mechanisms to validate that the individual present at capture time is rightfully in posession of the Vehicle and/or Driver ID numbers. Meaning that the actual data to be used as the record locators are the Vehicle ID or the Driver ID, the PINs only add a security layer on top of a solely manual entry.
Although the parameter is Vehicle PIN or Driver PIN, the PIN is actually tied to the Identification (the card, hard-key, token, manual-entry etc.) and not directly to the Vehicle or Driver
| Scenario | Description / Configuration strategy & Comments |
| Single Vehicle | Only the Vehicle Identification is required.Assign at least one Identification to a Vehicle-type sub-account |
| Single Driver | Assign at least one Identification to a Driver-type sub-account |
| Dual ID, Vehicle(s) enabled for a/some Driver(s) | Configure a relation between the Vehicle(s) and the Driver(s). The Vehicle's balances, cummmulators, counters and mileage will be impacted; for the Driver, only their cummulators will be affected |
| Dual ID, Driver(s) authorized for a/some Vehicle(s) | Configure a relation between the Drivers(s) and the Vehicles(s). The Driver(s) balances, cummmulators and counters will be impacted; to the Vehicles, only their cummulators and mileage will be modified. Only applies to Terminals with dual swipe capability |
| Single Vehicle card with manual entry of Driver ID | Transaction is completed against Vehicle's sub-account, Driver ID is informative |
| Dual ID, Vehicle card with Driver ID manual prompt | If Terminal is configured to pass Driver ID as a secondary track, functions as a full dual ID scenario, validating the Vehicle ID and the Driver ID, if there are Vehicle/Driver relations configured those will be enforced. |
| Vehicle ID or Vehicle card plus Vehicle PIN | PIN entry used as an entry validation, it has to match the PIN for the Identification presented for the Vehicle. On a single Driver Identification scenario, where the Vehicle ID is not required, if the Vehicle ID prompt is active the content of the field is ignored, as there is no Vehicle ID to validate. |
| Driver ID or Driver card plus Driver PIN | Same as Vehicle case above, but applies to a Driver-type ID and sub-accounts |