Milan / Paylink System Manual
Issue 1.5 29 January 2020
CONFIDENTIAL
Not to be disclosed without prior written permission from Aardvark Embedded Solutions Ltd
Page 8 of 71
Supported Facilities
It should be noted that this document cover all versions of the Milan / Paylink system, even those
versions that are not yet generally available.
Where a facility may not be available with the version that you are running, the topic titles are suffixed
with a version indication in brackets
Version Numbering
All AES software releases have a 4 part version number. This is made up from 4 separate fields,
coded as:
L L - P P - V V - M M
where:
M M Is a minor release, representing an upgrade in facilities or bug clearance, but where the
application code will remain the same (both source and executable).
V V
is a significant release, where the application will at a minimum need to be re-compiled, and
where facilities may hay have changed to the point where the application code needs to
change.
P P
Is a product code. This is 1 for Paylink and is 25 for DES Paylink
L L
Is the release level. This is a code, rather than a level, and has meaning as follows:
4 is a full release, and should never contain any errors or omissions. These release happen
relatively rarely and a full history of the code is maintained. A code starting 4 uniquely
identifies a particular build of the software.
3 is a beta release. This may contain errors as it has not been fully regression tested, but it is
intended to be sufficiently stable that development, or even live running is possible. Again, a
code starting 3 uniquely identifies a particular build of the software.
Normally the full release of a version will be almost identical to the beta release.
2 is an alpha release. These are only usually issued at the start of a major version. They
should
be stable and bug free, but are not fully tested, especially they will only have had
minor regression testing. This release is to enable developers to “get started” with a new set
of facilities. Again, a code starting 2 uniquely identifies a particular build of the software.
1 is an engineering release. These are generated during our internal development process,
and are occasionally released to customers is response to specific requests. A build code of
1 can only be distinguished by the date / time stamp embedded in the code, and no internal
record is kept of the items / changes that have gone into such a build.
Document Structure
This document is divided into three overall parts:
Concepts
Where the document describes the ideas behind how Paylink works
Details
Where the specifics of how Paylink handles peripherals and situations are described
Configuration
Which defines the configuration file (which is essential to Paylink operation).
