Dokumen - Tips Gtkpostilion For Merchant Acquirers

GETTING TO KNOW
Postilion for Merchant

Acquirers
Copyright © 2008. Postilion International Limited. All rights reserved. POSTILION is a registered trademark of Postilion International Limited. All
other registered or unregistered trademarks and service marks are properties of their respective companies and should be treated as such.
No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without
express written permission (info@postilion.com).
We are committed to ongoing research and development in order to track technological developments and customer needs in the market.
Consequently, the information in this publication is subject to change without prior notice and is provided without warranty of any kind.
Document distribution code: GTK/1/Dec-08/MerchantAcquirer/CC/PO Public distribution

Contents
1 Introduction.................................................................................................. 1
2 Architecture ................................................................................................. 2
2.1 Central EFT processing and switching .........................................................................................3
2.2 Acquiring transactions from stand-alone POS terminals...............................................................5
2.3 Acquiring transactions from integrated POS terminals .................................................................6
2.4 Acquiring transactions from the Internet .......................................................................................8
2.5 Merchant back-office processing ................................................................................................10
2.6 Supported platforms ...................................................................................................................11
2.7 Software development kits..........................................................................................................11
3 Central transaction processing ................................................................ 13
3.1 Central validation services..........................................................................................................13
3.2 Central stand-in authorization.....................................................................................................13
3.3 Transaction routing .....................................................................................................................14
3.3.1 Rules for advanced routing ..................................................................................................15
3.4 Cryptographic processing and key schemes ..............................................................................15
3.5 Reporting on transaction processing ..........................................................................................16
3.6 Batch management.....................................................................................................................17
3.7 Transaction reconciliation ...........................................................................................................18
4 Merchant back-office management.......................................................... 19
4.1 Overview.....................................................................................................................................19
4.2 Transaction screening ................................................................................................................20
4.3 Transaction clearing and network settlement .............................................................................20
4.4 Merchant settlement ...................................................................................................................21
4.4.1 Merchant settlement process and fee calculation strategies................................................22
4.4.2 Payment and posting file generation ....................................................................................23
4.4.3 Statement generation...........................................................................................................23
4.5 Flexible file formats and aggregation ..........................................................................................24
5 Adjustment processing (dispute management)...................................... 26
5.1 Overview.....................................................................................................................................26
5.2 Case management .....................................................................................................................26

5.3 Claims management...................................................................................................................27
5.4 Image and form management.....................................................................................................28
5.5 Resolution and exception management......................................................................................29

5.6 Reporting and graphical dashboards ..........................................................................................29
6 Managing the solution............................................................................... 31
6.1 Business administration..............................................................................................................31
6.1.1 Configuring stores and terminals .........................................................................................31
6.1.2 Merchant services ................................................................................................................34
6.2 Back-office administration...........................................................................................................35

6.2.1 Merchant transaction screening ...........................................................................................35
6.2.2 Merchant settlement.............................................................................................................36
6.2.3 Merchant statement .............................................................................................................37
6.3 System administration ................................................................................................................39
6.3.1 Monitoring system health .....................................................................................................39
6.3.2 Trend analysis and alert generation .....................................................................................40
6.3.3 Tracing .................................................................................................................................41
6.3.4 Field support ........................................................................................................................41
7 Availability and disaster recovery............................................................ 42
7.1 Introducing availability options....................................................................................................42
7.1.1 Active/passive disaster recovery..........................................................................................42
7.1.2 Active/active availability .......................................................................................................43
7.2 Active/active application-level design .........................................................................................43

7.3 Controlled failure recovery..........................................................................................................45
7.3.1 Unrecoverable hardware failure ...........................................................................................45
7.3.2 Site infrastructure failure ......................................................................................................47
7.3.3 Single software component failure .......................................................................................47
7.3.4 Planned downtime ...............................................................................................................48
8 Regulatory and industry compliance....................................................... 49
8.1 EMV............................................................................................................................................49
8.2 Payment application security standards .....................................................................................49
8.2.1 PCI DSS...............................................................................................................................50
8.2.2 Visa PABP ...........................................................................................................................50
8.2.3 PA-DSS................................................................................................................................50
8.3 SEPA ..........................................................................................................................................50
9 Performance............................................................................................... 52
9.1 Microsoft Windows Server platform ............................................................................................52
9.1.1 Transaction workload ...........................................................................................................52
9.1.2 Hardware and software configuration ..................................................................................53

9.1.3 Results .................................................................................................................................54
9.2 IBM Power Systems ...................................................................................................................54
9.2.1 Transaction workload ...........................................................................................................54
9.2.2 Hardware and software configuration ..................................................................................55
9.2.3 Results .................................................................................................................................56
10 Sizing ...................................................................................................... 57
10.1 Server sizing model ....................................................................................................................57
10.2 IBM Power Systems: example configurations.............................................................................57
10.3 Microsoft Windows Server platform: example configurations .....................................................58
10.4 Sizing for in-store component .....................................................................................................59
11 Central switch deployment options...................................................... 60
11.1 Postilion hosted services ............................................................................................................60
11.2 In-house deployments ................................................................................................................61
11.2.1 Benefits of IBM Power Systems.........................................................................................61
11.2.2 Benefits of Microsoft Windows Server technology .............................................................61
12 Postilion professional services ............................................................ 63
12.1 Implementation service delivery .................................................................................................63
12.2 Product training ..........................................................................................................................63

12.2.1 Course levels .....................................................................................................................63
12.2.2 Training delivery.................................................................................................................64
12.3 Product support ..........................................................................................................................64
Appendix A Company information .............................................................. 66

Appendix B Support for applications and devices .................................... 67
B.1 EPOS applications......................................................................................................................67
B.2 EPOS application interfaces .......................................................................................................67
B.2.1 API.......................................................................................................................................67
B.2.2 XML interface ......................................................................................................................68
B.2.3 Message front-end...............................................................................................................68
B.3 Terminal types ............................................................................................................................69
Appendix C External interfaces ................................................................... 70

C.1 Store to Postilion message formats ............................................................................................70
C.2 Card associations .......................................................................................................................70
C.3 Regional network associations ...................................................................................................71

C.4 Financial institution application systems .....................................................................................72
C.5 Others.........................................................................................................................................73
C.6 Card management systems........................................................................................................73
C.7 Check verification/authorization..................................................................................................73

1 Introduction
As the world’s most widely deployed open-systems payments platform, Postilion offers secure, field-proven transaction
processing that meets the requirements of any business that processes transactions on behalf of retail merchants.
Postilion provides support for multiple currencies in cross-border acquiring environments and switching to multiple
institutions.
Unique to Postilion is its active/active architecture, which provides the ultimate in high availability and disaster recovery.
Our solution provides for true application-level synchronization between two or more fully active and redundant servers
(which can be geographically separated), eliminating both planned and unplanned downtime and ensuring 100%
availability to your end-customer.
Postilion is highly flexible, utilizes service-oriented architecture (SOA) principles, and can be supplied with an advanced
software development kit (SDK). With the option of deployment on either IBM AIX or Microsoft Windows platforms,
Postilion caters equally for small through to very large installations.
Benefit to you Postilion feature

Merchant acquiring Multi-institution—multiple institutions/acquirers can be managed within a single system, in
for complex turn providing merchant management services to merchants
environments Multi-currency—merchant accounts within or across institutions can be specified in different
currencies
Multi-product—processes transactions from any type of payment card product, including chip
cards, and multi-application cards belonging to any card payment network
Multi-channel—provides a single customer view of a wide variety of payment instruments and
transaction types, such as stand-alone terminals, integrated POS systems, the Internet, and
call centers
Superior High-volume processing—handling tens of millions of transactions per month and
performance and transaction processing throughputs in excess of 1,000 transactions per second
availability 100% availability—active/active architecture ensures that cardholders can transact 24 x 7
without disruption
Advanced security Secure payments application—sophisticated cryptographic support, which meets PA-DSS
and compliance compliance requirements and is EMV-ready
Card scheme compliance—scheduled product enhancements ensure support for the latest
card scheme specifications
Rapid Flexible terminal driving—supports a broad range of terminal models from leading vendors,
implementation and popular message protocols such as ISO 8583, Visa, APACS, and SPDH; support is also
and deployment available for custom protocols
Reduced integration complexity—certified off-the-shelf interfaces to regional, national, and
international networks
Rapid development environment—modern architecture, together with the SDK option,
provides for fast, cost-effective enhancements, customizations, and new functionality
Reduced time to market—faster response to new initiatives and merchant demands enables
competitive differentiation
Simplified Sophisticated operational tools—centralized control for terminal parameters and
operational configurations, in conjunction with proactive real-time monitoring and alert management
management Extensive back-office functionality—provides automated reconciliation, merchant
settlement, and statement functionality, complemented by a broad range of standard and
custom reports
Getting to Know 1
Postilion supports any transaction, anywhere, anytime, with any payment instrument.
Payment instruments Transaction types Payment channels
Magnetic stripe debit and credit cards Purchase Stand-alone POS terminals
EMV debit and credit cards Purchase with cashback Integrated PIN pads
Corporate purchasing cards Cash withdrawal Self-checkout terminals
Contactless chip cards Gratuity Internet
Prepaid or stored value cards Refund Kiosks
Private label cards Void Call centers
Fleet and fuel cards Electronic benefits transfer Mobile phones
EBT Value-added services POS terminals
Postilion for Merchant Acquirers 2

2 Architecture
KEY POINTS AT A GLANCE
• Modular architecture designed for multichannel transaction acquiring
• The central component is used in all Postilion implementations, bringing Postilion’s proven stability and
performance capabilities to the merchant acquirer environment
• The component used for stand-alone POS provides a feature-rich set of services for terminal management
• The intelligent in-store component (integration component / EFT client) offers sophisticated functionality to
multilane merchants
• A component designed for card-not-present transactions enables acquiring from web sites and call centers
• The back-office component provides a range of data analysis and accounting functions
• This tried and tested “pre-integrated” product set offers powerful SDKs so that solutions can be extended quickly
2.1 Central EFT processing and switching

The central component for all merchant acquirer installations comprises the transaction switch Postilion Realtime,
designed for multichannel transaction acquiring and processing.
Postilion Realtime acts as the central switch for all consumer transactions initiated by all payment instruments. It
includes components that:
• Manage the integrity of transactions
• Manage security functions such as PIN processing and data encryption
• Control the routing of transactions
• Provide offline stand-in authorization if the connection between the acquirer and Postilion is lost
• Offer dynamic currency conversion
• Assist operators with terminal monitoring and event logging
At the heart of each Postilion Realtime deployment is the Postilion Realtime Framework, which provides all the
generic EFT processing required. It consists of several components:
• The Transaction Manager performs online transaction processing. It is responsible for, among others,
transaction integrity management, security processing, transaction routing, stand-in authorization, totals
management, and currency conversion.
• The File Merge Manager ensures that the files needed from different institutions (e.g. hotcard files, card and
account information, currency conversion table) are downloaded and merged into the Postilion Realtime
database.
• The Field Support Module provides a support infrastructure for ATM and POS terminals by alerting support
personnel through e-mail, mobile phone, or pager in the event of terminal failure. Personnel are able to monitor
the status of the system and of terminals in real time.
• The Hardware Security Module Interface allows Postilion Realtime to connect to a number of industry-
standard hardware security devices to provide the required cryptographic functionality, such as PIN processing,
certificate processing, and message authentication.
Getting to Know 3
• The Postilion Housekeeper performs various housekeeping tasks to ensure that old transactions and records
are removed from the database on a regular basis. These housekeeping utilities do not require the system to be
taken down at any stage.
Figure 1: Architecture of Postilion Realtime

Various message formats are used in the EFT industry to convey transaction information. For this reason, Postilion
interfaces translate messages between the formats expected by entities external to the system —such as terminals,
banks, and EFT networks—and the internal format expected by Transaction Manager.
All messages sent between Transaction Manager and the interfaces are formatted according to the ISO 8583 standard
(1987).
The different channels that the solution supports are represented by source interfaces. Each interface handles the
requirements of the channel it represents, e.g. the processing of transactions performed on stand-alone devices would
be provided by an interface specific to that task. These interfaces also provide other services, such as configuration
download management and key management.
The source interface passes transactions to the Postilion Realtime Framework, which provides all the generic
processing required.
The Postilion Realtime Framework then routes the transaction to the appropriate sink interface, which represents an
entity such as a processing network, host system, or card issuer network.
Postilion Realtime stores all of its configuration status and transaction data in an SQL database. Tools for configuring
and monitoring the system are provided as standard.
2.2 Acquiring transactions from stand-alone POS terminals

Postilion provides a wide range of transaction processing capabilities, including the processing of non-financial
transactions such as mobile prepaid top-up requests.
Postilion is used in a multi-protocol environment to acquire transactions from stand-alone POS, performing message
protocol conversion to communicate with terminals using their own protocols, including:
• ISO 8583
• SPDH
• IFSF
• APACS
• Others
Postilion offers the following terminal management capabilities (refer to the section on managing the solution for more
details):
• Merchant and terminal parameters
• Card parameters, including cards to be accepted, authorization limits, EMV parameters, PIN requirements
• EMV parameter management
• Hotcard file data management, loading, cleaning and incremental image building
• Terminal monitoring
• Receipt management
• Support for configurable receipt printing
• Support for multiple languages
Getting to Know 5
The functionality to drive stand-alone POS terminals is supplied by Postilion TermApp. The architecture of TermApp
separates the terminal management and message-handling features, enabling terminal-driving applications to handle
different message protocols, while benefiting from common terminal management features. All terminals supported on
all TermApp applications can be configured and monitored using the same infrastructure and tools.
Figure 2: Terminal-driving in a multi-protocol environment
The terminal-driving applications support Master/Session and DUKPT key management schemes for MAC and PIN
encryption keys, and message authentication is supported. Support for 3DES keys is standard.
The generic TermApp framework facilitates development of new terminal-driving applications, particularly those that
require sophisticated capabilities.
2.3 Acquiring transactions from integrated POS terminals

For multilane merchants, the in-store component eSocket.POS provides sophisticated payment authorization capability.
It interfaces to EPOS systems and manages peripheral payment devices such as PIN pads.
During a transaction, eSocket.POS will access the payment devices associated with each EPOS terminal to obtain
transactional and additional customer information. An example of this is the entry of a PIN, which eSocket.POS would
obtain from a PIN pad, physically located near to the terminal or connected to it but controlled by eSocket.POS. This
means that the EPOS application does not need to control peripheral devices that are used to collect customer input,
such as card readers, PIN pads, and check readers.

eSocket.POS is responsible for formatting and sending transactions to Postilion Realtime. It sends all data associated
with transactions, as well as events generated by the devices for centralized monitoring. It performs all the necessary
security functions and has sophisticated stand-in authorization capabilities.
This component can reside either on an EPOS terminal (cash register / till) or on a central server within the store.
Interfacing to the EPOS system is made possible through a Java API or a standard XML-based message interface.
Existing legacy message protocols are easily catered for. (Refer to Appendix C.)
Figure 3 depicts a multilane merchant using eSocket.POS on each EPOS terminal with a single Postilion
implementation at the head office or data center.
Figure 4 depicts a multilane merchant with eSocket.POS installed on each store server. The store servers communicate
with Postilion at head office or at the data center. All transaction initiations are sent to eSocket.POS on the store server
by each EPOS terminal. This may be via messages to eSocket.POS from each terminal, or via a store controller that
controls the terminals.
Figure 3: In-store component on each EPOS terminal
Getting to Know 7
Figure 4: In-store component on each store server
eSocket.POS is a platform-independent Java-based application. This means that local Java-based applications making
use of eSocket.POS can run on any operating system, provided that there is an implementation of a Java Virtual
Machine (JVM) available for the operating system. Through Java's platform independence, eSocket.POS supports
Windows, most flavors of Unix, Mac OS, Linux, and others.
There are eSocket.POS implementations live on the following platforms:
• Microsoft Windows (95, 98, NT v4, 2000, XP, and XP Embedded)
• Linux
• Unix
• IBM 4690 OS
• Mac OS X
2.4 Acquiring transactions from the Internet

Postilion offers merchants an Internet shopping component (eSocket.web) designed for card-not-present transactions.
This allows for the capture of:
• Card security code numbers
• Address verification details
This component is plugged into the merchant’s web server, depicted in the Figure 5. In exactly the same way that
eSocket.POS interfaces to a physical EPOS terminal, this component interfaces to the Internet store-front application so
that customers can shop via a web browser.

eSocket.web is also used in call center environments, allowing authorizations and other transactions to be performed by
staff using a Web-based payment console. This is often referred to as a secure PayPage.
eSocket.web will inject the appropriate transactions into Postilion Realtime. The console is effectively a web page that
allows merchants, as a back-office function, to add a request for authorization to the system as well as to schedule
fulfillments and process returns, reversals, and check payments.
Using Postilion, merchants can perform the following functions, among other things:
• Make funds reservations
• Authorize and capture purchases
• Make funds fulfillments
• Add requests for authorization
• Process reversals
• Refund purchases
• Reverse purchases
• Process check payments
• Schedule fulfillments
• Process returns
Figure 5: Internet shopping component on web server
Getting to Know 9
2.5 Merchant back-office processing
To enable merchant back-office processing, Postilion Office retrieves data from Postilion Realtime on a regular basis
and is optimized for post-transaction data processing services. Because Postilion Office operates on a database that is
independent of the Postilion Realtime database, Postilion Realtime is able to maintain performance and stability.
The architecture of Postilion Office, depicted in Figure 6, consists of:

• Postilion Office Framework
• Postilion Office components
• Postilion Office plug-ins
The primary function of the Postilion Office Framework is to retrieve data from the Postilion Realtime database and to
optimally organize this data for complex queries in the Postilion Office database. Postilion Office components provide
a range of data analysis and accounting functions:
• Transaction reconciliation (Recon Component)
Reconciliation between the POS system and Postilion is catered for. In this context, the POS system provides a
transaction file as input to a reconciliation process. Transactions in Postilion are then marked off against those
supplied in the POS transaction file; and reports are provided indicating the results of this process. Details in
these reports are of transactions in Postilion but not in the input file and vice versa, matching transactions with
unequal amounts, and matching and equal transactions. Likewise, reconciliation between Postilion and external
authorization entities is performed based on input files from these external entities.
• Transaction data extraction (Extract Component)

Transaction activity files, submitted to credit networks for end-of-day settlement, are created using the extract
capabilities. Extracts are also used to provide integration between Postilion and other systems in use, for
example CRM and loyalty systems.
• Reporting (Reports Component)

Postilion includes a number of standard reports to assist in making business decisions and enables the rapid
creation of other reports to meet more specific needs. The database schema is published so that developers
can use third-party tools such as Crystal Reports to develop these.
• Adjustment processing (Adjustment Component)

This component integrates with third-party tools to automate copy requests and chargebacks, translating the
latter into network-specific formats and sending as part of the daily file upload.
• Merchant settlement (Merchant Settlement Component)

Postilion offers a comprehensive solution to perform merchant settlement. In the settlement process, the
Merchant Settlement Component processes the Office transactions and any imported transactional data, and
applies the settlement and billing rules to the transactions. The output of the settlement process provides the
input for the posting and payment processes, which in turn create the posting and payment files.
Postilion Office plug-ins tailor the behavior of the components to particular needs. For example, plug-ins can be
developed to enable the Recon Component to reconcile Postilion transactions with those supplied in proprietary file
formats from third parties and from POS systems.

Figure 6: Architecture of Postilion Office
2.6 Supported platforms

Postilion Realtime supports two operating systems: Microsoft Windows and IBM AIX. The choice of operating system
determines the underlying database software: Microsoft SQL Server in the case of Windows or IBM DB2 in the case of
the AIX.
For Postilion Office, deployments are currently available on the Windows / SQL Server platform.
2.7 Software development kits

Postilion has been designed for easy extensibility. This approach enables rapid response to new market developments,
enabling Postilion’s own software developers, as well as those of resellers and customers, to adapt the system by
implementing:
• New payment channels
Getting to Know 11
• EFT interface extensions to Postilion Realtime
• Host interfaces
• Network interfaces
• Plug-ins to Postilion Office
Postilion is implemented in Java for the following reasons:
• Java offers strong, enterprise application robustness through language features like exception handling, memory
management, and protection from memory pointers.
• Java provides multi-threading capabilities, positioning Postilion for excellent performance on multi-processor
systems.
• Java offers a relatively simple language syntax when compared with languages like C++, which is desirable
when building large and complex applications like Postilion.
The Postilion software development kit (SDK)—available for Postilion Realtime and Postilion Office—consists of:
• Java class libraries
• Build tools
• Test utilities
• Documentation and examples
• A fully documented database schema
The Postilion Realtime SDK can be used to:
• Format, extract, and validate all incoming and outgoing messages
• Communicate with other applications on the same machine, over a LAN, or over a WAN via a suitable inter-
process communication (IPC) mechanism (these processes could be other Postilion processes or they could
originate from remote entities such as EFT switches and POS terminals)
• Start (and stop) application timers and perform certain actions if and when these timers expire
• Log events to the Postilion support subsystem (and operating system event log) to maintain a concise history of
application conditions
• Trace messages on all its IPC links, including those not directly related to its own processes
• Allow a system operator to control the application by processing commands submitted to it from a console
• Provide monitoring support, enabling operators to keep track of the status of the application
The Postilion Office SDK can be used to:
• Write extracted data in various formats
• Reconcile external transaction data in any proprietary file format with the Postilion view, and generate reporting
output
• Generate payment files in the required formats (ACH/ACB)
• Generate posting files in the required formats (GL)
• Generate custom reports; and because the database schema is published, an off-the-shelf tool such as Crystal
Reports can be used to create new reports

3 Central transaction processing
• Postilion offers a range of validation services
• Stand-in authorization is based on comprehensive limits
• Highly configurable transaction routing offers least-cost authorization options
• Cryptographic processing applicable to merchant acquirers
• Standard reports provide transaction processing details and summaries
• Flexible batch management facilitates reconciliation
• Enables automated transaction reconciliation to report on mismatches
• Produces transaction files that can be supplied to external parties for their reconciliation
3.1 Central validation services

Postilion performs a wide range of validation services, including:
• Card number validation (Luhn checking)
• Card expiry date checking
• Hotcard checking
• Track 2 validation
• Address verification (AVS) checking
• Velocity limit checking (using per transaction, daily, weekly, and monthly limits) at the card program, card number,
and account levels
• Account number lookup based on card number and account type
• Card verification: CVV1/CVC1, CVV2/CVC2/CID, CVV3, and iCVV

• EMV risk processing such as TVR, CVR, and ATC checking
• EMV cryptogram validation
• PIN verification, including verification using the Visa or IBM scheme
3.2 Central stand-in authorization

Stand-in authorization by Postilion is based on a comprehensive set of limits and rules, balanced against acceptable risk
subject to acquirer and processor agreements. When stand-in authorization is invoked, Postilion authorizes transactions
below these limits:
• Issuer local. The risk level that the merchant acquirer is prepared to take without the transaction being authorized
online by the acquirer or issuer. Postilion authorizes transactions below these limits without attempting to go online.
This is often referred to as a floor limit.
• Issuer offline. The risk level that the merchant acquirer is prepared to take if the system is offline. Postilion
authorizes transactions below these limits if the authorizing entity is offline.
Getting to Know 13
• Acceptor local. The risk level that the merchant / card acceptor is prepared to take without the transaction being
authorized online by the acquirer or issuer. Postilion authorizes transactions below these limits without attempting to
go online.
• Acceptor offline. The risk level that the merchant / card acceptor is prepared to take if the system is offline.
Postilion authorizes transactions below these limits if the authorizing entity is offline.
Postilion can also load card and account information and offer several stand-in authorization options on behalf of a card
issuer:
• Full authorization. Postilion can be loaded with account balances received from a host system or can maintain the
balances autonomously. It will approve or decline transactions based on these balances and not forward any
requests online to a host system. At end-of-day, a transaction file will be sent to the host system.
• Full authorization with advices. As with full authorization, Postilion will approve or decline transactions based on
account balances, but will also notify the host system of approved transactions, non-zero transactions, inquiry and
non-inquiry transactions, and declined/zero-value transactions.
• Balances stand-in authorization. Postilion is loaded with account balances received from a host system on a
regular basis. It will stand in whenever the host system is unavailable and approve or decline transactions based on
these balances.
• Velocity stand-in authorization. Postilion is configured with a range of limits and keeps a transaction count. It will
stand in whenever the host system is unavailable and approve or decline transactions based on these limits.
• No stand-in authorization. Postilion will not authorize transactions on behalf of the issuer.
Postilion maintains a store-and-forward queue for each upstream entity (e.g. host or network), and will forward advice
messages for transactions authorized in stand-in as soon as the link to the upstream entity is available (or immediately if
Postilion stood in on behalf of the entity even though it was online). Postilion can also provide throttling of store-and-
forward messages via intelligent queues , thereby preventing the system from overloading the upstream entity (host or
network) if response is slow.
Where there is no link to an upstream entity, such as when Postilion provides full authorization, Postilion will provide
extract files to the relevant parties to update card and account balances if required.
3.3 Transaction routing

Routing of transactions to other authorization systems is extremely dynamic and can be based on the following:
• Bank or institution identification number (BIN/IIN) of the card presented
• Account type selected
• Location of the transaction (merchant location)
• Payment method used (cash, check, etc.)
• Type of transaction (purchase, cash, purchase with cashback, bill payment etc.)
• Transaction destination (e.g. specific institution)
For total flexibility, Postilion offers advanced routing options that enable merchant acquirers to select the best possible
and “least transaction cost” route to the authorization authority. The priorities of transaction destinations can reflect
business considerations such as the interchange fees charged by connected networks.
These options ensure that Postilion will always attempt to route transactions to the network that is directly connected to
the issuer or to the preferred network if the issuer is not a direct member of the network.

3.3.1 Rules for advanced routing
An EFT network will generally supply the acquirer with a BIN file that contains multiple lists of BINs. The primary BIN list
contains all BINs associated with card issuers that are directly connected to the EFT network. Secondary lists contains
all the other networks that the EFT network is connected to. Generally a BIN file does not contain duplicate BINs.
Using these BIN files, Postilion can determine the best available option for routing the transaction to the card issuer.
The decisions made by Postilion to route financial transactions to the authorizing institution—for transactions that do not
have specific receiving institution code—are as follows:
1. Checks through each BIN list for BINs that best match the BIN of the card used.
2. Determines the card product for each BIN retrieved from each BIN list supplier selected.
3. Determines the list of all possible routes through the system. One route or more may be associated with this
transaction. The list of possible routes selected is based on the combination of the transaction source ( such as
POS, web etc.), the BIN, transaction type, card product, and the account (selected by the cardholder
performing the transaction).
4. Determines the list of possible destinations, with their priorities.
5. Determines if the selected destinations are issuer destinations. If so, all other routes are discarded.
6. Determines if the selected destinations are one step away from the card issuer connected. If so, these
destinations are selected and the others are discarded.
7. Determines if the selected destinations are connected directly to Postilion. If so, all destinations that are not
connected are discarded.
8. Selects the destination assigned the highest priority. If this authorizer is down, the transaction is declined or
stand-in authorization is done (depending on the type of service supplied by Postilion).
3.4 Cryptographic processing and key schemes

Postilion supports the following cryptographic operations:
• DES and 3DES key methods
• Derived Unique Key Per Transaction (DUKPT) key management scheme

The terminal is initialized with an Initial PIN Encryption Key (IPEK), together with an Initial Key Serial Number
(IKSN). After each PIN encryption, the terminal increments the KSN, and derives a new PIN key from previous
one using the DUKPT derivation algorithm.
• Master/Session key management scheme
The terminal can be initialized with a Master Key which is used by the terminal and Postilion to share the
Session Key. Periodically Postilion can deliver session keys requested by the terminal. Postilion supports
Master/Session encryption for PIN block translation and message authentication (MAC-ing).
• PIN verification for cards authorized by Postilion using Visa or IBM PIN verification schemes
The system maintains a configurable daily PIN try count that is automatically reset to zero at the end of a given
business day. This counts and limits the number of consecutive invalid PIN attempts allowed per day for a
specific card. To offer additional protection from fraudulent transacting, Postilion maintains a cumulative PIN try
count per card that is an accumulation of the daily PIN try counts. The cumulative PIN try count is incremented
whenever the daily PIN try count is incremented. However, the cumulative PIN try count is not cleared
automatically on a scheduled basis (as is the case with the daily limit) but is reset when the daily PIN try count is
reset after successful PIN entry.
Getting to Know 15
• PIN block pass through
Postilion is able to route transactions secured by keys that are loaded onto the PIN pads supplied by the
terminal owner (acquirer or bank). Postilion performs a pass through of the PIN block data and does not perform
any PIN validation or PIN translation. In such a scenario, merchants are usually restricted to one key (i.e. one
acquirer). If the device can hold different keys for multiple processors/acquirers and differentiate between card
types, multiple processors/acquirers could be implemented in this way.
• PIN translation between security zones
PIN translation between security zones is an alternative to PIN block pass through that delivers maximum
flexibility for transaction acquisition. Postilion manages security zones between terminals and itself as well as
between the network / host system and itself, using a hardware security module (HSM).
Postilion supports the following HSM types:
• The Thales HSM 8000 and RG7000 family (formerly branded Racal/Zaxus)
• The Atalla Network Security Processor (NSP) PCI card (A10000PCI) and the Atalla stand-alone device (100
00E NSP)
• Prism's Incognito Transaction Security Module (TSM) 310 or 410 series (formerly branded Nanoteq MCM)
• Devices that emulate these, such as Futurex
Postilion supports the following PIN block types:

• ISO-0 / ANSI X9.8 / VISA-1 / ECI
• ISO-1 / ECI-4
• VISA-4
• IBM3624 / OEM-1 / Diebold / NCR / DOCUTEL
3.5 Reporting on transaction processing

The following standard Postilion reports are supplied to merchant acquirers:
• Transaction summary. This report provides information on the transactions performed over a particular period.
Totals are provided per card type per acquirer/network per store.
• Transaction detail. This report provides detailed information on the transactions performed over a period. It is
typically used to investigate details supplied on the summary report. Merchant acquirers can use this data to
reconcile the information they have with that supplied by their acquirer.
• Authorizations not fulfilled. This report provides information relating to authorization transactions for which no
fulfillment transactions have been received. It could be used to indicate a decommissioned EPOS terminal that
still has transactions in its store-and-forward queues. Note that this report is only applicable to environments
where authorizations are followed by fulfillment transactions.
• Multiple transactions on same card. This report indicates when multiple transactions have been performed on
the same card at similar times, particularly at different stores. This behavior is a strong indication of fraud.
• EMV fallback transactions. This report highlights transactions where fallback from chip to magnetic stripe and
from magnetic stripe to manual PAN entry have occurred. This behavior is a strong indication of fraud.
• Transactions rejected due to hotcard. This report indicates transactions that have been rejected due to the
card tendered appearing on a hotcard list.
• Reversals and refunds per EPOS. This report is used to identify EPOS terminals processing an inordinately
high number of reversals and refunds. This behavior is a strong indication of fraud.

• Several reports used to balance with external systems (like general ledgers). These reports provide
information on the business dates of external entities, such as networks or host systems.
• Monthly transaction volumes. This report displays the total transaction volume for each network over a period
of one month. It displays the number of approved and declined transactions. This is used by merchant acquirers
to identify consumer trends over specific days of the week.
• Response codes analysis. This report gives an analysis of response codes for a monthly period, allowing
merchant acquirers to determine potential problems with authorizing entities in the network.
• Response times. This report displays the time in seconds that a host or network takes to respond to
transactions from Postilion. The response times for each host or network are displayed separately. It displays
different graphs for advice (offline) and request (online) transactions, as requests typically require a shorter
response time than advice transactions. The report is produced for a period of one month.
• Timed-out transactions. This report displays the number of request (online) transactions to which a given
host/network never responded. This report can indicate the existence of a serious problem at the host or
network, or it can indicate formatting problems with the transactions traveling to the host or network. The report
tracks these transactions over a period of one month.
• Declined transactions per EPOS. This report summarizes the number of approved and declined transactions
for each terminal for a monthly period. It also displays the number of occurrences of the most commonly used
declined response codes. This helps determine problems at the terminal and can identify problems at the host or
network if declined response codes occur frequently.
• System performance. This report displays general Postilion system information, such as the version numbers
of the operating system and the database. However, one of the primary uses for this report is to display the
Postilion system uptime results. This displays the average monthly system uptime of every Postilion application
for the last year.
• System volume growth. This report display the monthly transaction volume processed by Postilion over the
last year. Separate graphs indicate transaction volumes for each payment channel managed by Postilion.
• Single transaction detail. This report provides details on a single transaction. All fields associated with the
transaction in Postilion are available on the report.
3.6 Batch management

A terminal batch is maintained for each terminal connected to the Postilion system. When a batch is closed by a
terminal, the totals kept by the Postilion system are returned to the terminal. A balancing indicator (in-balance/out-of-
balance) is also returned to the terminal.
With Postilion, transactions are batched by terminal according to a period of time, which typically corresponds to a
business day (or reconciliation period) or between cutovers initiated by external entities (e.g. terminal, network, others).
During this period, transactions and their details are recorded along with the totals associated with the batch as a whole
(such as net settlement amount or amount of debits). Postilion maintains batches of transactions for a terminal, store, or
network.
At the end of the reconciliation period or after receiving a cutover message, the current batch is closed and a new batch
is opened. This action is referred to as batch cutover. Each batch is assigned an internal batch number that identifies its
specific reconciliation period. (Note that but the internal batch number within Postilion is not necessarily the same as the
batch number assigned by the terminal.)
A number of different options are available for terminal cutover and batch reconciliation:
• Internal business date, non-automatic cutover

Postilion assigns a business date, determined by a business calendar, to each transaction within the batch. The
Getting to Know 17
batch for the terminal is advanced only when a cutover message is received from the terminal. It is therefore
possible for more than one batch (or no batch) to be associated with a particular business date.
• Internal business date automatic cutover
This is same as the option described above, except that a current open batch that does not already have the
new business date is automatically cut over when the business date (as determined by a business calendar)
advances.
• External business date
Postilion determines the transaction batch based on the business date assigned by the terminal to the
transaction.
In cases where in-store component eSocket.POS is used, eSocket.POS has the capability to process reconciliation
request messages from the EPOS. If eSocket.POS determines that the net settlement amount can be accurately
determined, it will send the message online to Postilion Realtime, and return the totals received from Postilion Realtime
to the terminal.
However, if eSocket.POS is not connected to Postilion Realtime (for instance, if the network connection is down, or if a
timeout response is received), the message is put into the store-and-forward queue for later delivery to Postilion
Realtime.
When eSocket.POS determines that it is not possible to get the totals from Postilion, or if the net settlement amount is
incorrect, the EPOS totals will not be sent to Postilion, and Postilion’s totals will not be returned to the terminal.
3.7 Transaction reconciliation

Postilion automates reconciliation between its record of transaction activity and that of third parties. It allows merchants
to reconcile transaction records with the transaction activity files provided by external processors and networks, and with
files from the POS applications in merchants’ stores. As a result of this comparison, four reports are generated to assist
in investigating transaction exceptions:
• Matched transactions
• Matched but unequal transactions (e.g. amounts differ)
• Transactions that occur in Postilion but not in the third-party reconciliation file
• Transactions that are in the third-party reconciliation file but not in Postilion
Postilion enables merchants to view results for a specific entity and to filter these results by reconciliation session. This
detailed reconciliation reporting enables back-office staff to quickly identify exceptions and deal with them appropriately.

4 Merchant back-office management
• A feature-rich, flexible solution
• Imports transactional data from external entities
• Screens transactions and reports on risks
• Calculates amounts and fees owing to all stakeholders in a merchant acquiring environment
• Creates payment (clearing house) files destined for EFT institutions
• Creates posting files destined for general ledger accounting systems
• Performs settlement adjustments
• Performs multi-party settlement several times a day
• Provides comprehensive merchant statements
4.1 Overview
Postilion offers acquirers a comprehensive, reliable, and flexible solution to perform merchant back-office functionality,
including merchant settlement and payment. It ensures that payment files, containing payments of amounts owed to
stakeholders, are created correctly and on time. At the same time, it enables the necessary fees to be levied at the
agreed intervals.
In Postilion, the life cycle for merchant transaction processing involves the following processes:
• Transaction screening (process 1 in the Figure 7)
• Transaction clearing and network settlement (process 2)
• Merchant settlement (process 3)
• Payment and posting file generation

• Statement generation
Getting to Know 19
Figure 7: Merchant back-office management
4.2 Transaction screening

A transaction that is deemed suspect by the network can be rejected, declined, or open to chargeback. Transaction
screening mitigates potential risks associated with transactions or transaction batches, by enabling merchant acquirers
to screen for suspect transactions.
Postilion uses a number of screening rules to identify potentially fraudulent transactions or batches. For example, an
alert can be raised when a batch has an abnormally high total value or a high percentage of refund transactions, or
where the percentage increase in a transaction’s final amount over the authorized amount is too high.
If a transaction or batch fails the screening process, it can be held back. After the risk has been assessed and manually
investigated, it can be released for settlement, or held back for further action.
4.3 Transaction clearing and network settlement

The transaction clearing and network settlement process ensures that appropriate network clearing files are sent out to
various entities (such as networks and issuer systems). Postilion enables merchant acquirers to extract transaction
data, in the clearing file formats required by the card schemes.
During the process, each extract session makes a distinction between open and closed transactions. Postilion identifies
the transactions that must be extracted from the Postilion Office database and then compares these to certain other
criteria. Transactions that meet the criteria are marked as closed and are extracted to the clearing file. Depending on
client requirements, transactions that do not meet the criteria are marked as open, logged for manual investigation as
exceptions in a Postilion graphical user interface, and are not extracted.

When the next session starts, Postilion will first determine whether transactions previously marked as open now meet
the criteria. If they do, these transactions are closed and extracted to the clearing file with the other closed transactions.
Postilion extracts data for transaction clearing and network settlement using the following methods:
• Fixed (daily) window
• All unextracted transactions
• Settle date
• Business date
4.4 Merchant settlement

After transaction screening and clearing, the merchant settlement process settles transactions normalized from the
Postilion database (depicted in the following figure, step 1) or from a third-party online transaction source with
transactions imported via the settlement data import process (step 2). The external data imported could include fees or
other adjustments that have a financial impact on the funds to be settled.
Figure 8: The merchant settlement process
The results of the merchant settlement process are then recorded in the journal (step 3).
With this information, Postilion generates automated clearing house/bank (ACH/ACB) payment files (step 4)—such as
NACHA in the United States. These payment files are used to transfer funds automatically to and from participants who
have a financial interest in the transaction amounts and associated fees.
The system also generates general ledger (GL) systems posting files (step 5). These posting files are used as a direct
feed of debit and credit entries into back-end accounting systems. This allows the accounting records of participants to
be updated automatically and seamlessly.
Merchant statements are generated to summarize all the financial activities that were performed by the merchant during
a period (generally every calendar month) (steps 6 and 7).
These steps are detailed in the following sections.
Getting to Know 21
4.4.1 Merchant settlement process and fee calculation strategies
The purpose of merchant settlement is the allocation and the physical transfer—to the correct accounts—of:
• The fixed, principal monetary amount (i.e. the value of a purchase transaction)
• Fees involved in processing transactions
The process of identifying the principal transaction amount and the process of calculating the fees can occur in one of
two ways:
• These can take place simultaneously to allow for net settlement where amounts paid to stakeholders are
adjusted in advance for fees and incentives.
• These can be completely decoupled at the file generation level to achieve disjoint cycles (allowing, for example,
payment of the principal transaction amount daily and billing of the fees monthly).
4.4.1.1 Principal transaction amount

A key process in merchant settlement is therefore identifying the principal transaction amounts to reimburse merchants
for transactions performed. For example, if a shopper purchases good to the value of $100 from a store, this is the
principal transaction amount.
During the settlement process, Postilion will insert one entry per transaction into a journal, where the entry consists of a
debit account, a credit account, and an amount ($100 in the example given above).
Different processing models require different settlement rules. For ease of deployment, Postilion provides a standard set
of settlement rules that determine:
• Which types of transactions must be settled
• Which amounts must be settled
• Which accounts must be debited and credited
• Whether tax must be calculated
4.4.1.2 Fees
These charges may include transaction fees, merchant discount fees, commission fees, and incentives. In some cases,
incentives are offered to merchants for providing certain services. For example, a financial institution may offer its
merchants incentives for customers to perform balance inquiries at the point of sale.
To ensure that fees are levied at agreed intervals, they are subject to posting and payment cycles that determine how
often they are included in these files.
Postilion provides a standard set of billing rules that determine:
• Which fees must be charged
• Whether tax must be calculated
• Which accounts must be debited and credited
Fees can be calculated as follows:

• Fixed fees define a fixed value that must be paid, e.g. the commission fee may be 30c for purchases and 40c
for cashback.
• Percentage fees specify a percentage of a defined amount, e.g. a fee of 2.5% of the transaction amount should
be paid for purchases.

• Tiered amounts and fees are fixed values that can differ across bands, e.g. a commission fee of 20c may
apply for purchases less than $100; 30c for purchases between $100 and $500; and 40c for purchases above
$500.
• Split fees, a highly flexible option where fixed or percentage portions of the fee are allocated to different
stakeholders. A split may be based on the total fee, or on a remainder in a prioritized chain of splits. For
example, 10c of the fee may be paid to the processor; 1.5% of the total fee to the merchant; and 5% of the
remainder to a third party.
• Recurring or once-only non-transactional fees may recur daily, weekly, fortnightly, monthly, etc. (for
example, for terminal rental) or may be once-only (for example, for terminal repairs).
• Seasonal fees allow for the configuration of fees that apply only for a specific period. For example, a fixed fee of
20c may be bumped up to 30c for holiday periods.
This process makes one or more entries per transaction into the journal, where the entries indicate the fees involved.
4.4.2 Payment and posting file generation

The journal entries produced during the merchant settlement process are used to generate files, enabling the movement
of money and providing input to stakeholders’ GL systems and the third-party GL systems.
Postilion extracts entries from the journal using:

• Journal filters
Standard filters can, for example, include all entries that have not yet been included in a payment /posting file, or
exclude all entries for a specific type of fee or type of transaction. Custom filters can be developed.
• Aggregation strategies
Standard aggregation strategies can, for example, aggregate payments/postings based on the account to be
credited/debited, or based on the original transaction that causes the generation of the payments/postings.
• Residue management strategies
Standard residue management strategies can, for example, maintain a running residue amount for each
payment reference until it reaches a maximum amount that can be paid out, or rounding amounts up or down
depending on the number of criteria. Custom residue management strategies can be developed.
The file generation process therefore involves:
• Selecting the appropriate journal entries

• Aggregating them as required
• Writing them to a file in the desired format (multiple files can be created for multiple destinations)
All totals that need to effect funds transfer from one bank account to another (e.g. from merchant acquirer to individual
merchant account ) are written to a payment file, also known as ACH (clearing house) file.
All amounts and fees that need to be posted as debit and credit pairs to a GL system are written to a posting file.
Transactions can be settled continuously throughout the day and then rolled up into payment/posting files as regularly
as required—typically at the end of the day, week, or month. Running settlement at regular intervals eases the
performance load on the system at the end of business day.
4.4.3 Statement generation

The generation of merchant statements is one of the key functions of a merchant acquirer. These summarize all of the
financial activities performed by each merchant over a specified period (generally every calendar month, although
statements can be daily, weekly, monthly, bi-weekly, or for a specific day of the month). They are stored for reference.
Getting to Know 23
Merchant statements are used to reconcile the amount processed during the statement period with what has been
posted to the merchant’s bank account (or merchant’s bank account statement).
Statements are available in different forms (an example is depicted below): printed in a predefined format (as per
merchant acquirer specification) and mailed to the merchant, or available online for download.
Figure 9: Merchant statement
4.5 Flexible file formats and aggregation

Standard Postilion plug-ins govern the settlement processes. However, Postilion has been designed with various
customization entry points so that:
• Payment/posting plug-ins define the formats and content of ACH/ACB payment and GL posting files.
Architecturally, this allows for any file format to be catered for and any set of transactions to be considered.
Principal transaction amounts and fees can be considered together, or separately.

• Transaction retrieval plug-ins allow for isolation of the transactions that are due for settlement. These can be
used to ensure that only transactions of a certain type, or for a particular network, are settled. The default
transaction retrieval plug-ins support filtering by source or destination, but others may be added.
• Data import plug-ins allow data from external files to be imported into the system for settlement. A typical use
of this would be for the import of interchange fees. The plug-in defines the file format and the way the data is
mapped into Postilion Office.
• Aggregation plug-ins determine the rules used for summing the transactions.
• A merchant settlement plug-in may be added to provide a generic starting point with some domain-specific
configuration data (including common fee structures).
• Other plug-ins may also be required based on business needs (for example, to restrict the transactions that
are considered for payment file generation).
Getting to Know 25
5 Adjustment processing (dispute management)
• Postilion provides standard functionality for managing the entire dispute resolution life cycle
• Automated dispute case management workflows are available in standard modules
• This feature integrates Lean Industries’ AdjustmentHub™ with Postilion
• The integrated approach includes an imaging system for forms and claims documentation
5.1 Overview
AdjustmentHub can manage customer disputes for any transaction that is processed by the Postilion solution. Disputes
originating either from Postilion (issuer) or from networks (acquirer) are managed by AdjustmentHub. Postilion ensures
the disputes and adjustments received are automatically transmitted back to the correct point of origin. AdjustmentHub
processes disputes for any payment type, including credit, signature and PIN debit card, ACH, ATM, and POS, across
regional and global networks. With traditional solutions, claims from PIN and signature networks are typically presented
on network reports, which are generally handled manually by different claims and dispute systems.
The dispute management feature within Postilion automates most of the manual processes associated with disputed
transactions. This integrated feature:
• Defines analysts and managers and gives them roles and responsibilities executed via dashboards; roles
include maintaining case assignments and queues
• Defines workflows and resources to implement rules and regulations
• Interfaces with Postilion for transaction queries and financial adjustment receipts in any format, including
chargebacks, request for copy, and representments
• Opens new cases, pre-fills required fields (auto-research) and drives case processing through a set of pre-
defined workflow steps
• Assigns cases to various queues and analysts according to case variables and transaction contents
• Auto-represents particular business situations, when configured to do so
• Adds and manipulates images and forms for cardholder and network documentation purposes
• Generates financial records for chargebacks and representments for internal cardholders and customers, as
well as external networks
• Produces reporting modules for pre-defined and ad-hoc reporting
AdjustmentHub uses the data security facilities provided by Postilion applications, enabling the entire offering to operate
in an environment that complies with the PCI DSS. AdjustmentHub operates on Windows Server 2003 with
Apache/Tomcat. The internal claims dispute database supports Microsoft SQL Server 2005. JDBC database technology
methods are used to access external enterprise databases for research and other functionality.
5.2 Case management

AdjustmentHub can create cases to control all activities associated with disputes and claims. Each case maintains:
• The original transaction details
• Any communication or information exchanged with the recipient

• Any actions taken
• The results of the adjustment
• Any other pertinent details
While the transactions are under dispute or investigation, they are marked to ensure that duplicates are not created.
Cases may be grouped together in a parent/child hierarchy, enabling analysts to manage and execute group operations
across the group.
AdjustmentHub accesses Postilion Office’s database to obtain sufficient information to pre-fill a new case. In order to
locate the appropriate record, queries are issued against a specific card number or date range, and every qualifying
record is retrieved.
If only one record is retrieved, AdjustmentHub can select this record and auto-commit the case. If multiple records
qualify, AdjustmentHub will create the case and queue it for analyst review and transaction selection.
When a transaction has been selected, AdjustmentHub will update the Postilion Office database to indicate that the
transaction is now under dispute.
5.3 Claims management

Within AdjustmentHub, the sequence of tasks (workflow) in processing a case is defined as a simple flowchart.
Workflows are maintained in the system’s database control tables, separate from the application.
Claims management operates with a workflow engine that can, among many other functions:
• Generate forms
• Create debits and credits
• Interact with the analyst user
• Control the flow of adjustment processing
The engine provides specific business advantages. Firstly, when an appropriate workflow needs to be selected to
process a complex adjustment, transaction features may be used to identify the best course of action. For example,
adjustments involving the purchase of airline tickets will follow a workflow that differs from an adjustment involving rental
car services. Within the system, issuer and acquirer roles can also be used to define workflow logic and processing
elements.
Secondly, chargebacks, request for copy, representments, and second chargebacks can be completed automatically by
the workflows. In more complex cases, a dispute analyst can enter data manually via a user-friendly dispute console
(item 1 in Figure 10). The decision to opt for manual entry is varied based on card type, transaction type, merchant type,
and other parameters located in the transaction record.
Another business advantage includes automatically creating diary entries. These entries are private by default, but may
be made public for display to interested parties via an external portal.
Getting to Know 27
Figure 10: Claims, image, and form management
5.4 Image and form management

A comprehensive image and form management system includes the ability to:
• Create forms from templates or standard text patterns

• Auto-complete forms with dynamic database values (for example, PAN, dates, amounts, and reason codes)
• Combine forms with other cardholder and merchant documentation (for example, fulfillment of request for copy
drafts)
The resulting dispute documentation can then be sent to image delivery systems, including printers, e-mail addresses,
and fax numbers. Bar-coded identifier information can be generated onto forms, and used for auto-recognition when
they are returned; the forms will then be automatically attached to the relevant case.
The documents are also collected and stored within the system, and transported between issuers and acquirers as
required. Transportation of the document may use various methods (item 2 in the preceding figure), such as PIN
networks, signature networks such as Visa and MasterCard (VRO Bulk and MCOM), fax, mail, and e-mail.
Images may be generated by an existing enterprise application: for example, images of cardholder statements and
checks processed that may be required to complete case research and analysis. These image applications can be
accessed by AdjustmentHub using application-specific plug-in modules, for example ViewDirect interfaces.

5.5 Resolution and exception management
Multiple error resolution options are available, each carrying out actions to affect an automatic resolution. Error
resolution is subject to the already defined workflow. Actions include:
• Adjust the relevant transaction amount or transfer the disputed transaction to another account for further
investigation
• Write off transactions based on certain parameters; for example, disputes valued less than $15
• Reinstate a transaction after it is resolved, and re-apply interest and fees accrued during investigation
When Postilion Office reconciliation detects an exception, this can be fed into the AdjustmentHub’s exception
management system. An environment can be designed where parameter triggers detect exceptions in real time, in turn
generating an exception record that is then queued and processed.
These parameters can be set up to identify and classify exception items, according to:
• The card number, card status information, or other transaction data elements or available customer information
• Any other data element available to AdjustmentHub
5.6 Reporting and graphical dashboards

AdjustmentHub’s reporting system provides a large set of standard reports. Analysts or other authorized users can
manually select and execute such reports at any time. Automation tools allow scheduled execution of reports, providing
dynamic parameter substitution, data conversions for the most popular data output formats, and distribution to printers,
e-mail addresses, and web sites.
A number of graphical dashboards, illustrated in the following figure, are available for various user needs, such as
executive, operational, and technical personnel. These representations provide end-users and managers access to key
system information.
Getting to Know 29
Figure 11: AdjustmentHub’s graphical dashboard

6 Managing the solution
• Central management of configuration information, software updates, and business rules
• Simplified back-office configuration and auditing of changes
• Terminal status can be monitored remotely
• Sophisticated trend analysis and alerts ensure proactive management
6.1 Business administration

Postilion enables merchant acquirers to manage heterogeneous environments centrally, so that organizations deploying
large numbers of terminals do not need to configure the operating parameters associated with each terminal
individually.
Standard day-to-day administration includes defining terminals and their capabilities. Postilion enables operators to do
this manually using graphical user interfaces (GUIs) or via the following types of batch loads:
• Incremental file loads for updating some of the configuration information
• Full file loads for updating all of the configuration information
6.1.1 Configuring stores and terminals

Postilion supports a wide range of parameters governing the actions taken by terminals in the field, making it possible to
manage many of the business processes that terminals will perform during transaction acceptance. It is possible to
distribute the parameters to each terminal using the mechanisms supplied by Postilion, or by interfacing to third-party
applications.
The distribution mechanism ensures that these changes are rolled out quickly and cost-effectively. The system owner
can react quickly to changes in the market and to demands for new products by simply amending the parameters.
Parameters, which can be managed at the merchant level or the terminal level, include:
• Merchant and terminal characteristics
• Card characteristics
• Hotcard management
• Software download management
6.1.1.1 Merchant and terminal characteristics

These can be managed by Postilion, enabling merchant acquirers to specify operating parameters. Postilion uses the
concept of a profile to group common characteristics.
• Merchant profile
Depicted in Figures 12 and 13, this includes merchant-level characteristics such as the settlement currency,
acceptable card programs, and receipt printing header/ footer and terminal-level characteristics such as terminal
identity and functionality.
Getting to Know 31
Figure 12: Grouping merchant characteristics
Figure 13: Grouping terminal characteristics

• Hardware profile
Illustrated in the following figure, a hardware profile specifies the functioning of the terminal hardware (such as
card data input capability) and the operating environment.
Figure 14: Grouping terminal hardware characteristics
• Application profile
Defines a set of functions (e.g. EMV card data input capability, EMV security capability) that can be associated
with a terminal. These functions are agreed between the merchant acquirer and terminal vendor. This enables
the merchant acquirer to centrally manage the functions and services available to a merchant and their
customers on any given terminal.
• Product profile
This profile enables the system owner to manage the kinds of services offered on terminals typically used to
provide electronic merchandise, such as prepaid account top-ups. This profile includes details such as the menu
structure that terminals display to the user of the terminal, allowing selection of various options. Based on the
selection made, the terminal will follow a configured course of action.
• Host and communication profile
Identifies the types of services that a host will provide to the terminal. These include authorization, settlement,
check verification, software download, and security module download services. The communication profile
identifies how the terminal will communicate with the host.
6.1.1.2 Cards
Card parameters govern the business rules that terminals will use during transaction processing:
• Cards that may be accepted at the terminal
• Stand-in limits
• Whether PIN entry is required
Getting to Know 33
• Full EMV parameters (such as accepted application identifiers (AIDs) and public keys)
Postilion groups these parameters into profiles for allocation to merchants and terminals, then integrates these profiles
with the BIN lists supplied by card associations.
6.1.1.3 Hotcard management

When a card is reported as lost or stolen, the issuing bank places the card on a hot list and provides this list to acquirers
to reduce fraud at merchant locations. Postilion provides for management of hotcard files and their distribution to
terminals. Different file sets can be managed for different terminal groupings. This enables terminals to perform hotcard
checking when offline from the host system or as part of the process of generating an online transaction message.
6.1.1.4 Software download management

Postilion itself does not handle the downloading of terminal software (firmware) provided by device manufacturers. It
does, however, enable the management of downloads so that that the system owner is in control of the terminal
software on the terminal estate.
Postilion enables the management of parameters such as the address to which the terminal should connect, for
downloading terminal software. This address typically specifies a terminal software host, often managed by the terminal
vendor. Postilion also enables the terminal owner to schedule downloads of specific software versions for terminals.
6.1.2 Merchant services

Postilion offers merchant services using real-time information, such as terminal status monitoring and end-customer
transaction queries.
Advanced transaction queries are performed in real time against the back-office database. Queries can be performed
using a range of criteria and filters. For example, a search can be performed on a card number and a date range,
filtered by the terminal ID; or a query can be performed on the last 10 transactions processed by the system.
The information displayed includes the message flow, the amounts and fees involved, the authorization type and
reason. Other more detailed information required for troubleshooting is available, such as the following message
content:
• ICC request and response data relating to chip cards (depicted in Figure 15).
• Structured data fields that may be present in a transaction. Structured data is a Postilion extension to the ISO
8583 specification that provides a flexible mechanism for transporting data in XML format.

Figure 15: Detailed transaction information
6.2 Back-office administration

Back-office operators perform a number of configuration, query, and investigatory tasks using standard Postilion GUIs.
6.2.1 Merchant transaction screening

The transaction screening process enables merchant acquirers to define or use preconfigured risk rules to screens all
the merchant batches for potential fraudulent transactions before they are settled with the network. The following figure
depicts such configuration.
Figure 16: Defining risk rules
Getting to Know 35
If a rule is broken, the options are as follows:
• Generate warning only. Processing of these transactions will continue as normal.
• Hold transaction processing back. These transactions will only be processed after they have been released.
In transaction mode, individual transactions are marked as having broken a rule. In batch mode, the entire batch
is marked has having broken a rule. Back-office operators can use the Postilion screening GUI (illustrated in the
following figure) to check on batches or transactions that were held back. After appropriate investigation, a
transaction or batch can be released for settlement or discarded so that it does not undergo further processing.
Figure 17: Investigating transactions that have been held back
6.2.2 Merchant settlement

Merchant settlement is configured through a Postilion GUI, illustrated in the following figure. It is possible to configure
amounts and fees to be settled and the rules to be used for these, quickly and with great flexibility. The generation of
payment and posting files can be set up according to the required frequency and granularity.

Figure 18: Configuring merchant settlement
The configuration process is designed to assist the operator by providing a settlement entity relationship tree (illustrated
in the preceding figure). This tree is a representation of the business relationships between all settlement entities
involved in the settlement environment.
The tree visually represents business relationships:

• In an interactive, hierarchical structure
• Using “parent” and “child” relationship
• Enabling inheritance, voiding, and overriding
The structure of the tree is fully configurable to allow the best representation of the relationships that exist. As a result,
operators can specify fees in the visual context of the relationship where the fees apply.
With Postilion, back-office managers can:

• Specify the exact time when configuration changes should come into effect
• Keep an audit trail of which operator made which configuration changes
• Record the history of configuration changes and view the state of configuration at any point in the past
Configuration changes are versioned. At some point in time, when any new configuration has been verified and signed
off by a manager, it can be switched into production. Each new version always begins as a copy of the currently active
configuration, meaning that small changes can be made with minimal effort. All configuration versions are stored in the
database. Any previously activated (committed) version may be viewed at any time. However, only the pre-production
version can be edited.
6.2.3 Merchant statement

One of the primary functions of a merchant acquirer is the generation of a merchant statement that summarizes all the
financial activities that were performed by the merchant during a specified period.
Postilion uses the concept of statement profiles to create a template that contains all the information that will appear in
the merchant statement:
• Card acceptor ID code
Getting to Know 37
• Terminal ID
• Business date
• Card product (MasterCard/Visa)
• Transaction type
• Extended transaction type
• Entry type (amount / fee / non-transactional fee)
• Entry name (amount name / fee name / non-transactional fee name)
• GL account name
• Debit/credit
• Adjustment/normal journal entry
• Custom field
These profiles are defined by back-office operators (in the GUI depicted in following figure) to indicate:
• How statement data is summarized
• Statement output method
Figure 19: Configuring merchant statement profiles

A profile and other, specific parameters are then associated with each settlement entity in the GUI, as illustrated below.
Figure 20: Associating merchant statement profile with a merchant
6.3 System administration

Postilion enables merchant acquirers to reduce operational overhead and speed up problem resolution, ensuring that
SLAs are met and customer satisfaction improved. Organizations can become aware of operational issues before they
become critical, using remote access to Postilion system data.
6.3.1 Monitoring system health

Postilion enables organizations to choose the system statistics that they want to monitor. This monitoring solution has
been designed so that organizations can customize the presentation layer, allowing data to be segmented into different
business units for viewing on different pages. The monitoring tools are presented as a dashboard where alerts and dials
can be arranged as required, depicted in the following figure. These controls are easily configured using HTML and are
customizable to corporate branding standards.
Getting to Know 39
Figure 21: Postilion system monitoring dashboard
Postilion monitoring and analysis have no impact on processing performance as these run on a server distinct from the
Postilion Realtime server. Live, advanced performance counters are used. These counters record the arrival and
departure times of messages in the Postilion system and distribute them to a monitoring server for processing.
Processing includes output for operators to analyze trends, react to generated alerts, trace the system to process
reported problems, and monitor the performance of the Postilion system.
6.3.2 Trend analysis and alert generation

As incoming and outgoing messages on the Postilion system are processed, the messages are immediately grouped,
as counters, for ease of interpretation as well as accurate timing measurement. While a wide variety of counters is
available to provide advanced system trend analysis, the flexible nature of Postilion makes it easy to add additional
customer counters.
Standard counters include various:

• Rates of transaction arrival and departure
• Rates transactions arrival and departure showing the percentage above a configured acceptable threshold
• Network connection rates
Postilion analyzes each message that enters the system, and can group messages from the same logical entity, even if
those messages arrive over different network connections. Operators can view performance data for a particular
merchant, such as transactions per second or average response time. It is also possible to group messages by BIN
range, currency code, or transaction type. In fact, any logical grouping can be derived from a message or its EFT
network origin. For example, a counter can monitor the percentage of declined transactions from a particular EFT
network.

Users can set alert thresholds on trends of their choice, causing an alert to be triggered when these thresholds are
reached or exceeded. Examples of threshold triggers include:
• A high percentage or number of declined transactions from a host or network
• Increased response times
• An unusual percentage of reversals or deferrals
For example, merchant acquirers can configure an alert to trigger if the number of transactions received in a one-minute
period drops below or exceeds a configured threshold for transactions. Alternatively, they can configure an alert to fire if
the response time drops below 95% of the configured ideal response time over a 30-second period.
These alerts are written to the standard Postilion field support framework and forwarded to a support operator. Support
staff alerts may take the form of an e-mail, pager alert, or text message. This feature can be extended to interact with
SNMP, and provide customer alerts in the required format.
Additionally, Postilion can track trends for any logged event. For example, the system can raise an alert if the number of
events logged for messages with badly formatted chip card data exceeds the chosen threshold.
6.3.3 Tracing
During the lifetime of any EFT system, occasional investigation into system errors may require message debugging.
Postilion logs all messages that it receives or sends in their raw format and in their interpreted format, where the
individual fields are extracted and shown in a standard Postilion trace file. These traces can be stored for a prolonged
time, making dispute resolution and message debugging very simple. Message logging is run in a manner that fully
complies with the PCI DSS, so tracing conforms to standards that protect sensitive cardholder data.
6.3.4 Field support

Should any problems occur with a particular terminal, pager and e-mail alarms can be configured to automatically alert
staff of problems. Postilion provides a support structure that caters for a large deployment.
All the terminals are divided into regions, where each region is supported by a number of teams, and each team
consists of a number of support members. Support staff members have their on-duty hours configured so that only the
appropriate staff member is alerted. Problems that are not attended to within a specific time are escalated to another
member in the support group.
Postilion’s field support framework will automatically inform a member of the support staff assigned to a specific terminal
when the terminal logs an operator message. The message classifies the event as critical or suspect, including
warnings to:
• Investigate possible security violations
• Fix faulty hardware such as a card reader
To keep track of the reaction time of support staff, reports are available on the event, its duration, as well as the
responses provided by the support staff.
Getting to Know 41
7 Availability and disaster recovery
• Postilion offers the ultimate high availability strategy
• An active/active Postilion deployment provides merchant acquirers with complete transaction data integrity and
system availability
• An active/active Postilion deployment requires no failover procedures and no additional training or resources
• Scalability and flexibility make such a deployment ideal for POS driving and transaction authorizing
7.1 Introducing availability options

Organizations that deploy payment solutions often do so on a single server with fault-tolerant capabilities. By adding
RAID storage, an uninterruptible power supply, and redundant network interface cards, it is possible to create a server
hardware environment that is very robust and can withstand typical day-to-day computing infrastructure failures.
7.1.1 Active/passive disaster recovery

Beyond the server hardware, it is necessary to consider how best to protect the database-resident transaction
information in the event of a system failure. There are two main approaches to ensuring data availability: an
active/passive approach and an active/active approach.
An active/passive approach achieves availability through hardware and software duplication. This approach also
focuses on data recovery—the “time to data availability”. That is, it is concerned with how long it will take to restore data
after a failure and to return to normal processing.
One way to handle failure is to implement a replicated Postilion solution at a backup site. The backup site can take over
from the primary site because all system-critical Postilion-related information is stored in a single SQL database. All that
is required is that a fresh copy of the primary database be available on the backup server.
Synchronization of the primary and backup servers can be done in one of the following ways:
• Cold backup. A full database backup of the primary system is restored to the backup server once a day. In this
way, on average, only the last 12 hours of transaction data is unavailable.
• Warm backup (or log shipping). The database transaction log is truncated periodically (for example, every five
minutes) and copied to the backup server and applied to its database. The time lag between the primary and
backup servers is never more than a few minutes.
• Hot backup (or data mirroring). An add-on solution writes file updates on the primary server to corresponding
files on the backup server. Data lag between the primary and backup server is rarely more than a few seconds.
Regardless of how the primary and backup servers are synchronized, it is still necessary to perform manually executed
operational steps on the backup server to complete a system failover. These include:
• Changing the IP address of the server
• Renaming database files
• Starting database software
• Starting Postilion applications

Because failover to the backup server is a reactive and manual process (which can seldom be done in under 15
minutes) unavoidable downtime is incurred. In environments where stand-in authorization can be performed
downstream, this amount of downtime may be acceptable. In others, especially in retail environments, any amount of
downtime is expensive. Merchants cannot afford to have customers wait a couple of minutes at the checkout for a
payment to be processed for goods they have purchased.
How can the failover duration be reduced or eliminated? One could automate as many of the manually executed failover
steps as possible. However, an operator still has to initiate the failover operation in person, as a fully automated failover
solution can be problematic.
After a failover, when the database server is restarted on the backup server, it may be necessary to perform a
consistency check on the data files. This can take up to an hour on large databases, further increasing the amount of
system downtime incurred. A successful failover to a backup site requires that at some point in the future a failback
must be performed to reactivate the primary production site, again incurring downtime.
7.1.2 Active/active availability

As described, the operational costs of switching from the primary site to a backup site and then back to the primary are
high. In contrast, an active/active approach is simpler and is centered on maintaining system availability—even during a
system failure.
The alternative to an active/passive solution is to have the primary and backup servers running at the same time,
working concurrently as a fault-tolerant team to offer processing redundancy. Such an approach has the following
benefits, among others:
• No failover, failback, or reconfiguration required.
• The system is demonstrably correct 24 x 7.
• Upgrade complexity is minimized.
• Planned downtime affects only part of the server team.
• Downtime is invisible to parties upstream or downstream from the system.
• Operational uptime is increased.
• There is less risk during failover testing.
• Risk is minimized during actual failover.

• Operational skill requirements are reduced.
7.2 Active/active application-level design

Postilion offers an application-level active/active deployment for the ultimate in business continuity and increased
service levels, which has been in use at a number of payment organizations, including multilane retail merchant
acquirers for several years. It is the only solution of its kind providing EFT software service that enables continuous
transaction processing.
As depicted in the following figure, in an active/active Postilion environment, two active production servers are deployed
to maintain online transaction processing services during failures at either site—whether the failure is a
communications, network, server, or other data center disruption. These production servers are independent and can
run different versions of the operating system, database, and Postilion software.
Getting to Know 43
Figure 22: Active/active Postilion environment
These two cooperating Postilion Realtime systems process transactions simultaneously. This allows for load balancing
during normal operations, but both servers are capable of handling 100% of the transaction load in case of a failure at
one of the two sites.
So that only a sub-set of the terminals deployed needs to switch over when one of the Postilion systems becomes
unavailable, terminals at the same store location are configured so that half of the deployment has the one system as its
primary system and the other half of the deployment has the other system as its primary system (although a specific
terminal uses only one system at a time to process transactions). In the case of a stand-alone POS deployment,
terminals are connected to their primary system via a WAN.
Postilion provides the following functionality, with some dependencies on the terminal protocol:
• Realtime authorization of requests via either of the Postilion Realtime systems
• Delivery of advice messages to either of the Postilion Realtime systems
• Re-routing of advice messages to the correct system, in case the advice message refers to the original requests
that were delivered to the other Realtime system; this is done via a store-and-forward mechanism if the
connection is not immediately available
• Cutover message from the terminal will be sent to both Postilion Realtime environments
• Parameter download to terminal from either of the active Postilion Realtime systems
• Replicating critical information such as terminal Master/Session keys
If a failure prevents the one set of terminals from sending transactions to their primary server, these transactions are
automatically—and transparently—routed to the other server for processing. Transaction and reversal processing will
continue seamlessly, maintaining the integrity of transaction and balances data.

Another major benefit of an active/active Postilion implementation is that, instead of ensuring that each Postilion
Realtime system has a copy of every transaction processed system wide, Postilion Office is enhanced to be the central
transaction data store to retrieve transactions from more than one Postilion Realtime system. This means that,
irrespective of which Postilion Realtime system captured a transaction in an active/active environment, Postilion Office
will have a copy of all the transactions that were processed by all the POS terminals. As a result, all the back-office
activities remain unchanged, including funds activity (settlements with network and merchants) and transaction activities
(transaction extract and reconciliation processes).
An added advantage of such a Postilion deployment is that scheduled server maintenance (including Postilion and
database upgrades) can be performed at one of the sites with no downtime experienced externally.
Because Postilion performs synchronization at the application level, the two sites need not run the same version of the software.
This means that one of the sites can be upgraded to a new version of software, without upgrading the other site. This is not
possible where synchronization is performed at the database level. A further advantage of this approach is that a database
corruption at the one site will not be propagated to the other site.
7.3 Controlled failure recovery

The main aim of any disaster approach is to minimize the impact on customers. All of this must be done in an
environment where transaction integrity is ensured. A Postilion active/active deployment provides an intelligent,
controlled switchover mechanism, whether downtime is planned or unplanned.
Moreover, the Postilion solution does not require changes at the POS terminals because, as described below, all
switchover occurs at the network level or on the Postilion system, depending on the type of failure and terminals.
7.3.1 Unrecoverable hardware failure

Depicted in the following figure, when processing transactions from stand-alone POS terminals, automatic
switchover occurs at the level of the network (WAN), seamlessly routing all new transactions from the stand-alone POS
group affected to the secondary system for authorization or routing on to the appropriate networks and issuers.
Because the network infrastructure routes traffic, it is not necessary for a new TCP connection be opened for a POS
terminal when it switches over from its primary to its secondary Postilion system.
For transactions from EPOS terminals, automatic switchover is handled by the eSocket.POS component. This is
seamless because eSocket.POS always attempts to maintain open connections to both Postilion Realtime systems. It is
therefore not necessary for a new TCP connection to be opened for an EPOS terminal when it decides to switch over
from its primary to its secondary Postilion system.
Both Postilion Office systems normalize transactional data from the Postilion Realtime system now doing all the
processing. This ensures that any incomplete transactions disputed by customers will be available for customer
processing via Postilion Office, whether their internal mechanisms include automated reconciliation, balancing reports,
or using Office consoles.
Getting to Know 45
Figure 23: Recovering from hardware failure
After the problem has been remedied on the system that failed and this system has synchronized data with the site that
was performing all the processing, the solution will wait for each terminal to be idle for a configurable amount of time
before switching traffic back to the recovered system. This approach ensures that no transactions are lost.
Note that eSocket.POS maintains a store-and-forward queue for each Postilion system to which it is connected. If a
switchover occurs while a customer transaction is being processed, eSocket.POS automatically queues a reversal
transaction to the failed Postilion system. The failed transaction can then be retried on the terminal’s secondary Postilion
system. When a connection is re-established with the failed Postilion system, eSocket.POS trickle-feeds all the queued
reversals upstream.

7.3.2 Site infrastructure failure
During site infrastructure failure, switchover is as described for hardware failure. However, as depicted in the following
figure, only the Postilion Office system that partners the Postilion Realtime system now doing all of the processing will
normalize transactional data.
Figure 24: Recovering from site failure
7.3.3 Single software component failure

If a single software component fails on the Postilion server, automatic switchover occurs at the level of the Postilion
server, routing all new transactions from the terminal group affected to the secondary system for authorization or
routing on to the appropriate networks and issuers (refer to Figure 25). Current transactions are aborted.
Both of the Postilion Office systems in the active/active deployment will normalize transactional data from the Postilion
Realtime system now doing all of the processing.
Getting to Know 47
Figure 25: Recovering from software component failure
7.3.4 Planned downtime

Postilion enables operational staff to perform software updates and patch applications. A Postilion operator will trigger
switchover by issuing a command via a Postilion console. The system will complete any existing transactions and start
routing new traffic to the other Postilion system gracefully. After switchover completes, the operator will be notified that
all traffic has been sent to the secondary system and the current Postilion system can be taken down from a software
perspective.
After the software upgrades have been completed, the operator can fail back to the usual processing by issuing another
command that will gracefully revert the necessary transaction processing back to the updated Postilion server.

8 Regulatory and industry compliance
• Postilion offers protection against mandated changes
• Because validation takes place at the Postilion software level, merchant acquirers can focus on delivering new
features and services to customers, knowing that they are in compliance with the most recent regulations
• Postilion is EMV ready
• Postilion is compliant with regional security requirements such as SEPA
• The solution has attained Visa PABP validation—and is currently transitioning to the Payment Application Data
Security Standard (PA-DSS)—streamlining merchant acquirer PCI DSS compliance programs
8.1 EMV
Postilion is EMV compliant (across all acquiring channels) and offers rapid time to market for a certified and accredited
EMV solution.
The preferred mechanism for achieving EMV at the POS is to interface to EMV Level 2 approved chip card readers.
This means that all interactions between the card and the card reader, as defined by the EMV transaction process, are
managed by the card reader.
Postilion caters for the complex key management requirements of EMV, including storing, managing, and potentially
revoking public keys used for data authentication.
8.2 Payment application security standards

The theft of cardholder account data is a major concern for all participants in the payment industry.
Postilion provides numerous built-in measures to protect sensitive information stored in its database because those
transaction records stored in the database contain card data information and sometimes cardholder information.
For example, Postilion protects sensitive cardholder data in the database by doing the following:
• As soon as a transaction processed by Postilion Realtime is completed, the entire track 1 and part of track 2 are
removed from the database so that no one can access this data. (For track 2 this means that discretionary data
—such as service restriction code, card verification value, PIN offset / PIN verification value, and any other
discretionary data—is removed.)
• Postilion Realtime supports Triple DES encryption of the PAN in the Postilion database.
• Encryption of the PAN and clearing of the track 1 and track 2 data are enabled by default for new installations.
• eSocket.POS does not, by default, store track 2 data in its database. eSocket.POS provides support for
encryption of the PAN in its database using strong cryptography (up to 2048-bit RSA). Encryption of the PAN is
configurable.
• The PIN offset or PVV is never stored.
• The CVV2/CVC2/CID is not stored.
• The PIN or the encrypted PIN block is not stored.
Postilion protects sensitive cardholder data processed at all transaction acquisition channels by providing the
option to mask any data printed on receipts and presented on the POS screen.
Getting to Know 49
8.2.1 PCI DSS
The major card associations developed a set of requirements—the Payment Card Industry Data Security Standard (PCI
DSS)—to govern the safekeeping of account information.
These requirements apply to all members, merchants, and service providers that store, process, or transmit cardholder
data. Also, these security demands apply to all “system components”: any network component, server, or application
included in, or connected to, the cardholder data environment.
Card associations are urging organizations that store, process, or transmit cardholder data to use only those payment
applications that are validated, and they are phasing in mandates to eliminate the use of vulnerable payment
applications.
8.2.2 Visa PABP

Distinct from the PCI DSS but aligned with it, Visa guidelines for payment application vendors (called Visa Payment
Application Best Practices or PABP) were designed to help develop secure applications that do not store prohibited data
and that support overall compliance with the PCI DSS.
An application that is validated against the PABP is known not to store any prohibited data—such as full content of the
magnetic stripe, CVV2, or PIN data—following transaction authorization. Storage of this type of data is in violation of the
PCI DSS.
Various Postilion applications are PABP validated. This includes Postilion applications that make up the solution for
merchant acquirers, the most commonly used network interface applications, applications used to transaction-enable
integrated EPOS devices, and the back-office application.
In fact, Postilion was the first payment switch to achieve Visa PABP validation in Europe, in July 2006.
8.2.3 PA-DSS
A new comprehensive standard that is intended to help organizations to minimize the potential for security breaches due
to flawed payment applications has been developed.
This Payment Application Data Security Standard (PA-DSS) is based on the Visa PABP and, like the PABP, is distinct
from but aligned with the PCI DSS and defines the security requirements designed for payment application software
vendors to facilitate their customers’ PCI DSS compliance.
Postilion is an early adopter of this standard and is, at the time of writing, in the process of formally adopting this new
standard and is working on transitioning solutions from PABP validation—which does currently recognize these
solutions as acceptable for new deployments—to recognition as validated per PA-DSS.
Note: Contact us for detailed point-by-point indications of how Postilion meets payment application data security
standards. However, it is incumbent on the system owner to implement additional security measures outside the scope
of the Postilion system.
8.3 SEPA
In Europe, the introduction of the Single Euro Payments Area (SEPA) is a business challenge for all payment service
providers. SEPA instruments will provide direct debit, credit transfer, and card payments in euros for all retail
transactions (i.e. transactions other than interbank ones); it will eventually be mandatory to use one of these instruments
for all non-cash payments in euros within Europe. The provisions of the Payment Services Directive, which sets a

common legal framework for all retail payment transactions in the EU, must be enacted in law in all EU countries by 1
November 2009, and will apply to all retail payment transactions.
This has implications for processing platforms such as Postilion. For example, the SEPA Cards Framework requires the
use of open standards, particularly EMV. Processing systems that do not follow these standards should be replaced
with a system that is based on open standards and uses ISO 8583 messaging throughout, such as Postilion.
Postilion can help merchant acquirers meet the SEPA requirement of 100% EMV transactions by 2010. Postilion can
help organizations meet SEPA requirements in other ways too. The introduction of SEPA is a business challenge for all
payment service providers. There is little time to develop a market, so investments and business cases must rely on a
belief that businesses and consumers will change their payment habits in the ways predicted. Postilion’s flexibility
reduces the risk in such decisions: it can adapt to any channel, settlement and clearing system, or scheme rules.
A further benefit is Postilion’s SDK, which gives customers the flexibility to support future innovations and to customize
interfaces without affecting the core functions.
Postilion is installed in many European countries and the Postilion organization is familiar with the relevant national
standards and business requirements in those countries.
SEPA will offer multinational retail merchants operating in Europe the opportunity to standardize their payment systems
and consolidate all transactions on a single Postilion installation and submit these to one acquirer. Postilion is ideally
suited to addressing these new opportunities thanks to the flexibility of its architecture and reputation for reliability. One
of the largest oil companies in central and eastern Europe is an early adopter of SEPA and now processing all its card
transactions from 12 countries on a single Postilion platform.
Getting to Know 51
9 Performance
• Postilion can handle performance levels and transaction volumes for high-volume merchant acquiring
• Performance benchmarks on Microsoft Windows Server and IBM Power Systems platforms are available
• These measure the performance of Postilion when used to process transactions originating from large numbers
of EPOS terminals connected via TCP/IP, simulating the transaction workload of a top-tier retail merchant
• To mirror a real-world multilane environment as realistically as possible, the tests used a range of cryptographic
operations and message types that would typically be encountered on a day-to-day basis
• The results indicate that Postilion is an extremely efficient and scalable transaction processing platform
9.1 Microsoft Windows Server platform

This section describes the results of a performance test of Postilion on the Microsoft Windows Server operating system
and Microsoft SQL Server database product, running on a Stratus Technologies ftServer system.
9.1.1 Transaction workload

The transaction acquisition environment for merchant acquirers simulated by the test consisted of 15,000 integrated
POS devices connected via TCP/IP to Postilion. Nine authorization interfaces connected Postilion to a range of
transaction authorization services.
All terminals were connected to Postilion for the duration of the test. The EPOS devices were simulated using a custom
software application capable of managing thousands of virtual terminals (each with a dedicated TCP connection).
Instead of connecting to real-world networks that provide the required authorization services, a custom software
application was developed to simulate the authorization services: debit, check, gift card, Visa, MasterCard, American
Express, Discover, EBT, phone card.
The virtual terminal simulator, as well as the authorization services simulators, was deployed on a dedicated server
separate from the machine on which the Postilion switch was hosted. The simulation environment therefore had no
impact on the performance of Postilion.
Postilion was subjected to a workload that reflected a representative transaction profile of a large merchant for a 24-
hour period. Over a period of 24 hours, 10.9 million transactions were injected. The TPS rate was varied continuously
throughout the benchmark, ranging from 2 TPS to 280 TPS.
The following table represents the reference workload, which was increased four-fold to ensure optimal usage of the
server hardware platform that the benchmark was run on.

Hour Debit Check Gift card Visa MasterCard American Discover EBT Phone
Express card
0 17,956 951 1,730 8,948 3,014 1,090 724 2,256 90
1 9,416 435 886 4,555 1,407 467 323 1,222 45
2 3,400 190 336 1,810 601 183 117 462 17
3 1,413 107 124 837 304 60 60 210 10
4 1,004 103 69 499 198 40 25 137 6
5 1,237 148 118 556 301 84 60 123 18
6 2,541 504 285 1,408 800 203 134 210 28
7 6,809 1,710 1,006 4,004 2,375 680 465 588 81
8 13,565 4,186 2,377 8,649 4,816 1,635 1,236 1,450 128
9 20,390 6,904 4,262 14,753 8,181 2,941 2,308 2,474 161
10 30,647 10,783 6,831 22,793 12,384 4,542 3,957 3,878 212
11 41,232 14,534 8,458 31,425 17,194 6,135 5,282 5,341 308
12 52,069 16,912 9,581 39,619 20,246 6,992 6,346 6,575 315
13 60,369 17,706 10,707 44,207 21,556 7,782 6,807 7,588 415
14 66,072 18,175 10,144 48,079 22,862 8,269 6,875 8,121 411
15 74,198 19,705 11,071 52,208 24,798 9,104 7,365 8,669 440
16 83,906 21,825 11,522 57,128 27,574 9,809 7,760 9,387 483
17 94,982 23,036 11,997 62,953 29,436 10,409 7,946 10,308 557
18 100,602 22,407 12,006 64,278 28,565 9,965 7,287 11,000 578
19 99,366 17,740 11,864 59,808 25,573 8,713 6,306 11,181 568
20 90,258 13,077 10,144 51,374 20,774 7,125 4,999 10,004 479
21 75,791 9,391 8464 41,309 16,576 5,557 4,038 8,550 387
22 60,424 6,138 6172 31,973 12,025 3,964 2,851 6,985 311
23 43,474 3,226 4353 22,465 7,816 2,755 1,877 5,443 213
9.1.2 Hardware and software configuration

The test was performed on a Stratus ftServer 6200 server (supplied by Stratus Technologies), using a Thales HSM
8000 hardware security module (supplied by Thales e-Security), with the following configuration.
Hardware:
• Stratus ftServer 6200
• 2 x 2.66 GHz Quad Core Intel Xeon CPUs with 2 x 4 MB L2 cache
• 12 GB of RAM
• 6 internal disks
Software:
• Windows 2003 operating system (SP2)
• SQL Server 2005 database server (SP2)
• Postilion Realtime v5.0 (SP1)
• Source node interface: PosConnect v5.0

• Sink node interface(s): PostBridge v8.0
• Sun Java Virtual Machine 1.5.0 (server version)
Getting to Know 53
Hardware security module:
• Thales HSM 8000
• TCP/IP network interface
• Capable of 220 PIN translations per second
Stratus ftScalable Storage external RAID:

• Postilion database data file (75 GB) 6 disks (RAID 10)
• Postilion database data log (200 GB) 2 disks (RAID 1)
9.1.3 Results
Hour Average TPS No. trans processed CPU utilization Average response time
0 40.8 147,037 3.1% 10.2ms
1 20.8 75,025 1.5% 9.2ms
2 7.9 28,464 0.6% 9.3ms
3 3.5 12,500 0.3% 9.6ms
4 2.3 8,324 0.2% 10.0ms
5 2.9 10,580 0.3% 10.0ms
6 6.8 24,452 0.5% 9.2ms
7 19.7 70,872 1.4% 8.6ms
8 42.2 152,166 2.9% 8.9ms
9 69.3 249,497 4.8% 10.3ms
10 106.7 384,106 7.5% 13.8ms
11 144.3 519,634 10.2% 16.0ms
12 176.2 634,620 12.6% 23.1ms
13 196.6 707,642 14.3% 25.3ms
14 210.0 756,030 15.8% 48.5ms
15 230.3 829,303 17.3% 53.1ms
16 252.9 911,204 19.9% 24.6ms
17 277.6 999,227 22.0% 25.6ms
18 283.1 1,019,468 22.1% 24.8ms
19 265.9 95,7215 21.4% 21.2ms
20 229.9 827,500 18.6% 23.9ms
21 188.9 680,259 14.4% 27.7ms
22 145.3 523,375 10.6% 18.2ms
23 101.8 366,490 7.2% 12.6ms
9.2 IBM Power Systems

This section describes the results of performance tests of Postilion on the IBM Power System platform.
9.2.1 Transaction workload

The simulated environment consisted of 30,000 integrated POS terminals connected via TCP/IP to Postilion, as well as
nine authorization networks.

Transactions were routed by Postilion, based on the card presented and the account selected (such as savings and
credit), to the appropriate network.
All EPOS terminals were connected to Postilion for the duration of the test. The EPOS terminals were simulated using a
custom software application capable of managing tens of thousands of virtual EPOS devices (each with a dedicated
TCP connection to Postilion). DUKPT PIN encryption was used by all the terminals and a single global base derivation
key (BDK) configured on Postilion.
A 1,000 transaction per second (TPS) stream of purchase transactions (with DUKPT-encrypted PIN blocks) was
randomly received from the terminals over a period of 24 hours. Each of the 30,000 terminals performed one transaction
every 30 seconds.
The EPOS terminal simulator and the issuer authorization simulators were deployed on dedicated servers separate from
the main server on which Postilion is deployed. This machine also hosted the Postilion HSM Simulator, responsible for
interpreting all the cryptographic operations (PIN translate, etc.) issued by Postilion.
The simulation environment therefore had no impact on the performance of Postilion.
9.2.2 Hardware and software configuration

The test was performed on an IBM Power 570 server (supplied by the IBM Innovation Center for Business Partners
located in Waltham, Massachusetts, US) with the following configuration.
Hardware:
• IBM Power 570 server
• 16 x 4.7 GHz POWER6 CPUs
• 64 GB of RAM
• 4 x 73 GB internal Ultra320 SCSI disks
Software:
• IBM AIX v5.4 (TL06) (Fix Pack 3)
• IBM DB2 v9.1 (Fix Pack 3)
• IBM Java v1.5 (SR5)
• Postilion Realtime v5.0
• Postilion Realtime Framework v5.0 (Service Pack 1)

• PosConnect v5.0
• PostBridge v8.0
• Postilion HSM Simulator
RAID storage solution IBM DS4800 (54 disks):

• Postilion database data file (1,000 GB). The Postilion database tables are spread over four RAID 5 disks sets
(/db2data1, /db2data2, /db2data3, and /db2data4). Each RAID 5 disk set consists of 11 (10+P) disks.
Postilion database log files (200 MB). The Postilion database log files reside on a single RAID 5 disk set (/db2log)
consisting of 10 (9+P) disks. A total of four log files are assigned to the Postilion database. Each log file is 256 MB in
size.
Getting to Know 55
9.2.3 Results
Hour Average TPS No. trans processed CPU utilization Average response time
0 1,000.0 3,587,467 64.8% 154.6 ms
1 1,000.8 3,604,663 67.3% 133.4 ms
2 1,000.2 3,602,467 68.0% 145.9 ms
3 1,000.7 3,604,321 70.5% 163.2 ms
4 1,000.7 3,604,002 69.7% 146.4 ms
5 1,000.4 3,603,625 64.0% 115.6 ms
6 1,000.4 3,603,480 66.4% 136.1 ms
7 1,000.5 3,603,633 67.9% 136.0 ms
8 1,000.2 3,602,388 69.2% 148.1 ms
9 1,000.8 3,604,838 69.8% 141.8 ms
10 1,000.4 3,603,687 66.7% 122.4 ms
11 1,000.1 3,602,632 65.2% 124.5 ms
12 1,000.8 3,604,538 67.2% 139.9 ms
13 998.9 3,598,306 68.5% 142.7 ms
14 987.2 3,556,706 69.1% 134.6 ms
15 1,014.7 3,655,793 70.4% 201.3 ms
16 889.1 3,203,193 59.2% 241.1 ms
17 1,111.4 4,003,749 70.9% 130.8 ms
18 1,000.2 3,603,663 69.0% 117.0 ms
19 1,000.4 3,603,652 70.2% 112.0 ms
20 1,000.3 3,603,599 71.3% 111.6 ms
21 1,000.4 3,603,716 69.1% 107.0 ms
22 999.8 3,602,926 65.% 118.3 ms
23 997.6 3,594,030 65.8% 124.5 ms

10 Sizing
• A simplified model helps with appropriate sizing for Postilion servers
• Postilion transaction per second rating should match anticipated peak workload
10.1 Server sizing model

A Postilion server should be sized to process a peak transaction workload at no more than 50% of the CPU processing
capacity. This leaves ample CPU capacity for the relational database system and the Postilion software to periodically
perform data maintenance operations.
However, sizing a server is not simply a matter of ensuring that there are enough CPUs. It is also important to ensure
that Postilion can sustain a peak processing workload over a lengthy period of time.
The following simplified model helps in sizing a server to handle a given transaction processing workload.
Because the number of SQL database transactions required to capture a single Postilion transaction overwhelmingly
determines the transaction rate of a Postilion system, knowing the number of SQL transactions that a database server
can execute per second (i.e. the SQL TPS rating), together with the relative number of SQL transactions that is required
to capture a single Postilion transaction, allows one to predict how many Postilion transactions a server can sustain per
second (Postilion TPS rating).
Postilion on average uses three SQL database transactions (select, insert, and update in that order) to capture a single
Postilion transaction. This means that the ratio of SQL transactions to Postilion transactions is 3:1, at a minimum. This
ratio is larger when terminals are connected to the system.
Therefore, if the database management system on a given server is rated at 6,000 SQL transactions per second and
Postilion requires 3 SQL transactions to capture a single transaction, the server is able to process 2,000 Postilion
transactions per second (6,000 / 3).
Similarly, if the database management system on a given server is rated at 1,000 SQL transactions per second and
Postilion requires 5 database transactions to capture a single transaction, the server is able to process 200 Postilion
transactions per second (1,000 / 5).
A suitable server configuration is therefore one where the Postilion TPS rating matches the peak required.
10.2 IBM Power Systems: example configurations

A Power 550 server configured as specified below is rated at 625 SQL transactions per second:
• 1 processor / 2 cores / 4 threads
• 6 GB of RAM
• Connected to a SAN with sufficient disk I/O capacity

Roughly 200 GB is required for Postilion database storage space. Additional storage space is required for
database backups and other storage requirements that the system might have.
Getting to Know 57
A Power 550 server configured as specified below is rated at 1,250 SQL transactions per second:
• 2 processors / 4 cores / 8 threads
• 12 GB of RAM

A Power 550 server configured as specified below is rated at 2,500 SQL transactions per second:
• 24 GB of RAM

10.3 Microsoft Windows Server platform: example configurations

ftServer 4400 server configured as specified below is rated at 625 SQL transactions per second:
• 1 processor / 2 cores / 2 threads
• 6 GB of RAM

ftServer 4400 server configured as specified below is rated at 1,250 SQL transactions per second:
• 12 GB of RAM
ftServer 6200 server configured as specified below is rated at 2,500 SQL transactions per second:
• 24 GB of RAM


10.4 Sizing for in-store component
For a store server deployment:
• CPU: 2 GHz (or more)
• Memory: 1 GB
• Disk: 20 GB
The above configuration depends on the number of lanes connected and the amount of data retained on the store
server.
For a deployment on the EPOS terminal:
• CPU: 2 GHz (or more)
• Memory: 256 MB
• Disk: 1 GB
The above configuration depends on the amount of data retained at the EPOS terminal.
Getting to Know 59
11 Central switch deployment options
• Postilion is designed for deployment flexibility
• Merchant acquirers can choose the level of control required to meet operational needs and strategic objectives
• Postilion is available as a dedicated hosted service in our US data center
• Alternatively, merchant acquirers can deploy Postilion in-house
11.1 Postilion hosted services

To speed up time-to-market, reduce operational costs, and eliminate the need for upgrades to in-house infrastructure,
merchant acquirers are able to outsource the administration and operational requirements of their Postilion solution to
the Postilion data center.
The Postilion hosted services team ensures that the merchant acquirers benefit from extensive experience in delivering
best practices in data center operations, security, disaster recovery, change management, network operations, and
regulatory auditing.
These hosted services help merchant acquirers to focus on business strategies by deploying Postilion in a data center
that maintains the highest possible level of network and application uptime, as well as meeting and exceeding
compliance standards required by the Payment Card Industry Data Security Standard (PCI DSS), Safe Harbor
certification, SAS 70 Type II certification, and FFIEC audits.
The US-based Postilion data center—in Norcross, Georgia—is a state-of-the-art technical hosting facility that can help
merchant acquirers reduce costs, increase customer retention, and decrease risk. Postilion is deployed on a dedicated
set of servers in a logically separated network environment, which offers the following:
• Secure systems. The data center is a physically and logically secure environment that adheres to PCI and
FFIEC standards. All information in the data center is backed up both on-site and off-site, ensuring that a copy
exists in multiple locations. The entire data center infrastructure undergoes constant surveillance to protect
customer assets, and the grounds are monitored by guards 24 x 7. Additional physical security measures
include access by badge, PIN, and biometric devices.
• Constant operation and high performance. In order to prevent the loss of data from a power outage, Postilion
data servers are located on redundant power grids. To further safeguard the servers, the facility is supplied with
on-site uninterruptible power supply units (UPS) and diesel backup generators, ensuring that operations never
experience any downtime due to a loss of power. All servers, networks, and storage systems in the Postilion
data center are high performance, high availability. To ensure continued high performance, the physical
environment—such as temperature and humidity—as well as the network, server hardware, third-party software,
and Postilion solutions are all proactively monitored.
• Dedicated operations personnel. The data center is continuously staffed by industry-certified operations
personnel trained to respond to automated alerts and client calls, as well as implement approved production
changes at times that ensure the least impact to clients.
• Disaster recovery. In the event that Postilion’s data center facility is rendered inoperable (for example as a
result of a natural disaster, act of terrorism, or other events that would make it impossible to continue
operations), disaster recovery services are provided in a secondary facility. Different SLA options exist with
regards to maximum allowable recovery times and data loss.
• Detailed reports. Detailed management reports, including system availability and performance statistics, (such
as hit rates, processing times, and download times) are generated monthly and posted to the customer extranet.

11.2 In-house deployments
For merchant acquirers wanting to bring their payment solutions in-house, Postilion deployments are available on the
IBM Power Systems platform (for AIX) or Microsoft Windows Server platform (such as the Stratus Technologies ftServer
platform).
11.2.1 Benefits of IBM Power Systems

Postilion is available on IBM Power Systems servers, running the AIX 5L operating system. IBM’s DB2 V9 data server is
the optimal choice of database on this platform.
IBM’s DB2 family of relational database products delivers powerful, reliable, and cost-effective solutions that can be
tailored for specific business needs.
DB2 V9 is IBM’s next-generation database that includes native support for XML and advanced compression techniques.
Because of the jointly engineered nature of IBM products, many of the features available in DB2 databases are
enhanced when run on System p hardware under the AIX operating system.
By running Postilion on IBM Power Systems servers, organizations can benefit from the proven reliability of a UNIX
operating system and IBM’s leading hardware solution for the AIX operating system.
11.2.2 Benefits of Microsoft Windows Server technology

Postilion is the most widely installed Microsoft Windows Server-based transaction processing platform in the world, by a
large margin.
Postilion recommends Stratus Technologies ftServer systems for installations running the Microsoft Windows Server
operating system and Microsoft SQL Server. The ftServer series of fault-tolerant servers from Stratus Technologies Inc.
are recommended for hardware reliability, because they bring the highest level of availability to applications running on
the Microsoft Windows Server platform.
The ftServer models from Stratus Technologies, a leading provider of fault-tolerant computer platforms, are considered
to be the optimal platform for providing 24 x 7 services for Windows Server 2003.
With Postilion on an ftServer server system, an EFT business can take advantage of the uninterrupted delivery of
services, minimized downtime for repair and maintenance operations, and a reduction in the total cost of ownership of
the systems.
ftServer extends the availability of Windows Server 2003 by adding the following reliability features:
• Hardened device drivers
Stratus provides device drivers specially developed for the PCI adapters on ftServer models. These drivers
detect and prevent memory allocation errors, a condition that causes system crashes when left unchecked.
Also, the device drivers perform self-monitoring operations on each adapter to check for hardware problems. To
protect against an operator replacing the wrong PCI adapter, the device drivers support status indicators that
specify the state of the adapter.
• VERITAS volume manager

The volume management interface, VERITAS, provides a central domain-wide view of disk storage resources. It
simplifies administrative tasks, such as adding, configuring, and removing volumes, and can be used to improve
volume performance. For instance, the volume manager can identify bottlenecks, balance input/output (I/O)
loads, and stripe data across multiple disks for optimal performance.
• Software Availability Manager

The Software Availability Manager extends the Windows Server 2003 system monitoring tools to help
Getting to Know 61
administrators manage system resources, such as memory, CPUs, and disks. The manager can execute
predefined procedures, log errors, and send e-mail notifications to support personnel.
• ftMemory RAM disk

ftMemory RAM disk provides an interface for protecting memory-resident data – a feature that is especially
important for mission-critical environments. It enables applications to access protected memory areas and
provides administrators with a tool to define and manage these areas. The tool also reduces application
recovery time by retaining in-memory data during a reboot operation.
• Online dump
In the event of an operating system failure, the online dump feature ensures that one redundant CPU or memory
unit retains information about the failure and remains offline during the reboot process. When the system is back
online, a memory dump takes place and this data provides support staff with information about the problem.
After the memory dump, the unit is brought back into normal operations.
• Active Upgrade
Active Upgrade technology allows an ftServer system to be split into two independent computer systems for
software upgrades and patches. After they have been decoupled, the hardware components do not run in
lockstep. The internal RAID 1 disk sets are also split and the disks evenly divided between the two systems. The
first system (production) continues to run the application software while on the second system (upgrade) the
production application software is safely terminated, allowing the operating system software to be upgraded.
After testing is complete, the two systems are merged and run in lockstep again.
• Monitoring and support

In the case of a Stratus ftServer implementation, each server monitors its own operation and immediately
reports any exception condition to the Stratus Customer Assistance Center, which provides a worldwide 24 x 7
service. This operates together with the Stratus Service Network, which is a global server management network
that can diagnose, isolate, and respond to any problems.

12 Postilion professional services
• Comprehensive implementation services available globally
• In-depth product training for operators, administrators, and developers
• Holistic technical support
12.1 Implementation service delivery

All implementation services are managed by Postilion’s professional services teams based in the following regional
support centers, as appropriate:
• Atlanta, Georgia, US
• London, UK
• Melbourne, Australia
• Cape Town, South Africa
• Johannesburg, South Africa
• Dubai, UAE
These teams consist of delivery and project managers, architects, technical leads, developers, and system engineers;
and will adapt to the project management methodology of each customer.
To ensure global coverage, the regional teams are supported by a global team that can be called on to implement
projects where the regional teams require additional delivery capacity.
12.2 Product training

The Postilion organization recognizes the importance of assisting and training Postilion administrators and operators so
that they can configure and maintain a Postilion system with confidence.
The Postilion training division offers a broad spectrum of training courses on Postilion-related topics. Delivered by in-
house trainers with expert product knowledge, the courses are practically oriented and designed to meet the needs of
Postilion customers.
12.2.1 Course levels

The following levels of Postilion training are offered to merchant acquirers, addressing distinct audiences:
• Postilion User Training (PUT). User training provides a modular introduction to the Postilion product family. It
is aimed primarily at systems administrators and operators across the EFT spectrum (financial institutions,
retailers, EFT processors, telecom operators, etc).
• Postilion Specialization Training (PST). Specialization training provides in-depth coverage of particular
Postilion products and is aimed at personnel who need to be able to install and then configure these products.
Specialization courses typically require participants to have completed a PUT course.
• Postilion SDK Training. SDK training is aimed at developers who want to learn to use the Postilion Software
Development Kit to extend either Postilion Realtime or Postilion Office. These courses are only suitable for
participants who have a Java development background.
Getting to Know 63
12.2.2 Training delivery
Postilion courses are instructor-led. All Postilion courses have a practical orientation and include hands-on, skills-based
exercises (labs). Participants work with representative installations for a consistent training experience. Materials for
each course include a training manual, accompanying PowerPoint presentation, and a course feedback form. Postilion
user training courses end with an optional evaluation test, while specialization courses have an in-depth summary
exercise intended to assess how well participants can put what they have learned into practice.
User training, specialization training, and SDK training for Postilion payment solutions are presented in face-to-face
classes of eight to 10 participants. Sessions vary from one to five days and can be presented at clients’ training
facilities, or at Postilion training centers located in the following cities:
• Boca Raton, Florida, US
• London, UK
12.3 Product support

The Postilion product support philosophy is that proactive systems maintenance is always superior to reactive systems
maintenance.
Postilion customers enter into a legally binding support agreement with their primary support provider (either Postilion or
a Postilion reseller) that offers:
• Help desk support
• 24 x 7 telephone hotline support
• Unlimited number of calls
• Product maintenance releases, which includes new mandates from the network associations
• Capabilities to download software and fixes
The Postilion customer takes initial support responsibility. Validated support issues are then raised to the primary
support provider.
The customer's first line of support is a dedicated Postilion support team located in one of the following offices:
• Atlanta, Georgia, US
• London, UK
• Melbourne, Australia
• Dubai, UAE
These teams consist of staff skilled at troubleshooting configuration and operational problems at the transaction and
system functional levels.
When an incident is logged, the team analyzes it to determine the priority level and assigns a rating that reflects the
severity of impact on the customer’s business. This is done in close co-operation with the customer. Incidents are
acknowledged, prioritized, and resolved within response times appropriate to each priority level.

Dedicated software is used to log and track the reported incidents; the customer is provided with a unique reference
number for status reporting purposes. This software is used to ensure that even if there is a high volume of logs, no
issue is ever lost or ignored. An issue is open until a resolution is found. Escalation ensures that long periods do not
pass with an issue going unnoticed.
Postilion has a customer support web site that provides the following services:
• Ability to log support issues
• 24 x 7 access to support issue status reports
• Documentation resource center
• Software distribution system
The cost of Postilion product support is included in the annual maintenance fee charged to every customer.
Getting to Know 65
Appendix A Company information
Postilion, a division of S1 Corporation (Nasdaq: SONE), provides the world’s most widely deployed payment software
solutions running on an open-systems platform.
Over 300 customers in 50 countries depend on Postilion for end-to-end payment solutions. Our software processes over
7 billion transactions annually, driving more than 100,000 ATMs and 500,000 POS devices globally.
Our extensive implementation expertise encompasses the full project cycle, from inception through to go-live and
continued maintenance. We are committed to research and development and are proud to see this reflected by our
workforce, of which 65% are engineers.
Postilion solutions drive consumer-generated payments, seamlessly and intuitively, through ATMs, POS terminals, IVR
systems, mobile phones, and the Internet. We support cutting-edge new technologies and standards including 3DES,
PCI DSS, PA-DSS, gift cards, prepayment, and contactless payments.
Designed for deployment flexibility, Postilion solutions allow you to choose the level of functionality and control required
in your environment. New channels and services can be added as you need them.
Advanced high availability options, including an active/active Postilion deployment option, provide complete transaction
data integrity and the ultimate in business continuity, require no failover procedures, and demand no investment in
additional training and resources.
By delivering consolidated management information, Postilion solutions equip businesses for success. Pre-defined
reporting covers such areas as consumer behavior trend analysis, system performance, fraud detection, network
response times, and volume growth. Custom reports can be created easily and rapidly, using off-the-shelf tools.
Our parent company, S1 Corporation, delivers customer interaction software for financial and payment services and
offers unique solution sets for financial institutions, retailers, and processors under three brand names: Postilion, S1
Enterprise, and FSB Solutions.
For more information, visit www.postilion.com and www.s1.com, or e-mail us at info@postilion.com. Alternatively,
contact an area sales office directly.
Americas Europe
705 Westech Dr Culverdon House
Norcross, GA 30092 USA Abbots Way, Chertsey, KT16 9LE, UK
T +1 404 923 3500 T +44 1932 574 700
Toll Free: +1 888 457 2237
Middle East Asia-Pacific
Alfa Building, Office 404 Level 1, 10-16 Queen St.
Dubai Internet City, Dubai Melbourne,3000, Victoria,
PO Box 502504 Australia
United Arab Emirates T +61 3 9695 8444
T +971 4 364 2644
Africa
Ground Floor
Howick Gardens Building, Waterfall Park
Bekker Road, Vorna Valley Ext. 21, Midrand,
South Africa
T +27 11 990 9000

Appendix B Support for applications and devices
Postilion offers standard support for a wide range of message protocols, terminals, interfaces, and file formats. An
interface specification is available to explain how EPOS application developers should interface to Postilion.
B.1 EPOS applications

EPOS applications listed in the table below have interfaced to eSocket.POS. Support for interfacing to others can be
added with ease.
Vendor Application
Retalix StoreLine; StorePoint
Torex NewPos
Matra FreedomPos
HRK POS
Fujitsu Global Store
PCMS BeanStore
Alpha Retail Inc Alpha Sell POS
Extenda POS Extenda
360 Commerce
IBM 4690 Supermarket application
Emirates Computers
NCR NDS Advanced Store @ retail
CTS
Pivotal
Leaf Systems
B.2 EPOS application interfaces

eSocket.POS presents three methods of interfacing with the EPOS application. These are the application programming
interface (API), XML interface, and message front-end.
B.2.1 API
eSocket.POS provides a Java-based Application Programming Interface (API) that can be used by the EPOS developer
to integrate with eSocket.POS.
The eSocket.POS API was designed to be used by the EPOS application to perform the following tasks:
• Provide a Java-based interface between the EPOS application and the eSocket.POS application
• Allow a transaction with the necessary data elements to be created, in the form of a collection of objects and
their properties
• Translate transaction objects into messages and pass the messages to eSocket.POS
• Receive response messages from eSocket.POS and present them to the local application as a new transaction
with the response code and other properties set
Getting to Know 67
The local EPOS application need not concern itself with the construction of messages by eSocket.POS or the Postilion
system. All the local application needs to do is to create various objects and set their properties to the required values.
The objects and their descriptions have been designed to be intuitive to the developer of the local application, without
requiring an understanding of the underlying message formats. The construction of messages from the objects is
handled transparently by eSocket.POS.
eSocket.POS implements an object-oriented design. Each transaction supported by eSocket.POS is represented as an

object. The data elements associated with a transaction are the properties of the transaction object.
Each property must conform to a specific data element format. A developer guide defines the data element format of
each property.
B.2.2 XML interface

In cases where using the eSocket.POS API is not feasible, eSocket.POS allows the EPOS system to communicate with
it via a message based on TCP/IP. The XML interface provides a standard message-based interface to eSocket.POS,
based on a defined XML message format that has a direct correspondence to the eSocket.POS API and does not
require any custom development.
B.2.3 Message front-end

Where neither the API nor the XML interface is feasible (for instance, where the EPOS terminal already uses a legacy
message format) eSocket.POS presents a message front-end which can be customized to support different message
formats.
In the same way as the XML interface does, the message front-end allows one or more EPOS terminals to
communicate with eSocket.POS via TCP. Different message formats are supported by means of a translator, which
translates EPOS messages and the format used internally by eSocket.POS. Custom development of such a translator is
required in order for eSocket.POS to support different message formats.

B.3 Terminal types
The terminal types and models listed in the table below have interfaced to eSocket.POS. Support for interfacing to
others can be added with ease. Please discuss your needs with a Postilion area sales office: factors such as firmware
version, interface connection type, and regional security requirements may impact compatibility.
Terminal type Model

VeriFone SC5000
Omni7000
MX8x0 series
VX810
Secura
Xplorer
Ingenico i3100
i3300
i6100
i6210
i3070
Hypercom HFT EMV Hybrid
Optimum P2100
Optimum P1100
H2210
S7SC
ICE 6000/6000a
Artema
Getting to Know 69
Appendix C External interfaces
The lists of interfaces given in this appendix are not exhaustive, but merely an indication of some of those available at
the time of writing. Postilion has extensive experience in building interfaces and develops them on an ongoing basis.
Contact a Postilion area sales office for details.
C.1 Store to Postilion message formats

When eSocket.POS is not used at the store level, EPOS systems can send messages directly to Postilion in a number
of formats, including:
• APACS 70
• ISO 8583
• VisaPOS
• Hypercom ISO 8583
• SPDH
• International Forecourt Standards Forum (IFSF)
• Many others
C.2 Card associations

Postilion has off-the-shelf interfaces to the global card associations listed below:
• American Express Globe
• JCB International
• MasterCard Worldwide
• Discover Network
• Visa Inc

C.3 Regional network associations
Postilion has off-the-shelf interfaces to the regional network associations listed in the table below, among others.
Africa Americas Asia-Pacific Europe Middle East

BankServ Debit Amex Credit ALTO EuroPay UAESwitch
BankServ Credit Authorization System First Data Int (FDI) GlobalCollect KNet
(CAS)
BankServ Realtime MasterCard RSC International Forecourt Benefit (GCC switch)
Clearing BofA Merchant Services (Regional Service Standards Forum
MultiLink(BAMS) Shva
NamSwitch Center - Sydney) (British Petroleum)
CGI Relay Switch SAMA
AEGN Megalink VocaLink
CNS Paymark / ETSL NETS (Norway)
Bankom (EPOC/EDS/Fiserv)
Interswitch Prima Orange (UK)
Co-op Network
PBS Denmark
CyberGateway
Deluxe Data
eFunds Network
Elan Financial Services
First Data Merchant
Services
BuyPass(Atlanta)
North (Credit)
South (Debit/Credit)
Omaha
FiservEFT
GreenDot
MAC
Mellon
Metavante
Moneris IDP (POS)
Moneris SCD (ATM)
MPS (Midwest Payment
Systems)
NBS
NYCE
Paymentech
Pemco
PLUS
Pulse
RBSLynk
Rex
Shazam
Servibanca
STAR
VisaDPS
Paymentech (On-Line)
TSYS Credit
Getting to Know 71
C.4 Financial institution application systems
Postilion has off-the-shelf interfaces to the financial institution application systems listed in the table below, among
others.
Africa Americas Asia-Pacific Europe

CTL Prime Alaska Option (Denali) FACTS TSYS (Prime)
FNS BANCS Bankway (Kirchman MQ) Fiserv Metavante Tech (Cortex)
Flexcube Cardinal ICBS Equation
Vision CSI iFlex / FlexCube FDR Vision Plus
EDS Cube Phoenix Lloyds
Elysium Jack Henry TietoEnator/RTPS
Fiserv Silverlake
AFTECH Temenos
CBS Vision Plus
Galaxy Plus
Summit
USER
Harland Financial
Phoenix
UltraData
LondonBridge (XAPI)
Jack Henry
Silver Lake
Symitar
Kirchman
McCoyMyers
Miser (FIS)
MultiPoint (QBT)
Open Solutions Inc (OSI)
SymConnect

C.5 Others
Postilion has interfaces to the providers listed in the table below, among others.
Africa Americas Asia-Pacific Europe Middle East

RCS Amex Stored Value Australia and New Barclay Card Business Emirates Bank
Base24SA Card (Gift Cards) Zealand Banking Group BTCellnet International (EBI)
BCGI Prepaid Wireless (ANZ) LeumiCard
ABSA DeutcheBank (Pago)
Comdata Auckland Savings Bank Euronet
NEDCOR (ASB)
FNB e-Money One-2-One (T-Mobile)
Bank of Ayudhya (BAY)
NedConnect ebitGuard Streamline
Bank of New Zealand
Vagas EnCompass (BNZ) Telekurs
Celtel FDIS Taranaki Savings Bank TSysPrepaid
Experian FleetOne (TSB) Vodaphone
TransAct JB Hunt Westpac Bank
MultiSerive
PreSolutions
Qwest
Radiant
SSA
TChek
TeleCheck
TransComm (IPS)
TravelersExpress
MoneyGram
TravelersExpress
MoneyOrder
TSYS GiftCard
Verizon PrePay
Western Union Money
Order / Transfer
C.6 Card management systems

Postilion’s card management component provides the range of card management services required by retailers and
merchants, including fleet and fuel card management (using product code) and management of in-house prepaid card
programs.
A generic card management interface is also supported by Postilion, which enables the solution to interface with various
third-party card management systems, such as FirstData VisionPlus, McX, Greentech, Fiserv CBS, Essentis.
C.7 Check verification/authorization

Postilion’s check management component provides a complete range of check/cheque management services, such as
check validation, customer verification, online authorization, duplicate and velocity checking, and overrides.
A generic check verification interface is also supported by Postilion.
Getting to Know 73

Dokumen - Tips Gtkpostilion For Merchant Acquirers

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dokumen - Tips Gtkpostilion For Merchant Acquirers

Uploaded by

Copyright:

Available Formats

GETTING TO KNOW

Postilion for Merchant

Document distribution code: GTK/1/Dec-08/MerchantAcquirer/CC/PO Public distribution

2.1 Central EFT processing and switching .........................................................................................3

2.2 Acquiring transactions from stand-alone POS terminals...............................................................5

2.3 Acquiring transactions from integrated POS terminals .................................................................6

2.4 Acquiring transactions from the Internet .......................................................................................8

2.5 Merchant back-office processing ................................................................................................10

2.6 Supported platforms ...................................................................................................................11

2.7 Software development kits..........................................................................................................11

3 Central transaction processing ................................................................ 13

3.1 Central validation services..........................................................................................................13

3.2 Central stand-in authorization.....................................................................................................13

3.3 Transaction routing .....................................................................................................................14

3.3.1 Rules for advanced routing ..................................................................................................15

3.4 Cryptographic processing and key schemes ..............................................................................15

3.5 Reporting on transaction processing ..........................................................................................16

3.6 Batch management.....................................................................................................................17

3.7 Transaction reconciliation ...........................................................................................................18

4 Merchant back-office management.......................................................... 19

4.2 Transaction screening ................................................................................................................20

4.3 Transaction clearing and network settlement .............................................................................20

4.4 Merchant settlement ...................................................................................................................21

4.4.1 Merchant settlement process and fee calculation strategies................................................22

4.4.2 Payment and posting file generation ....................................................................................23

4.4.3 Statement generation...........................................................................................................23

4.5 Flexible file formats and aggregation ..........................................................................................24

5 Adjustment processing (dispute management)...................................... 26

5.2 Case management .....................................................................................................................26

5.4 Image and form management.....................................................................................................28

5.5 Resolution and exception management......................................................................................29

6 Managing the solution............................................................................... 31

6.1 Business administration..............................................................................................................31

6.1.1 Configuring stores and terminals .........................................................................................31

6.1.2 Merchant services ................................................................................................................34

6.2 Back-office administration...........................................................................................................35

6.2.2 Merchant settlement.............................................................................................................36

6.2.3 Merchant statement .............................................................................................................37

6.3 System administration ................................................................................................................39

6.3.1 Monitoring system health .....................................................................................................39

6.3.2 Trend analysis and alert generation .....................................................................................40

6.3.3 Tracing .................................................................................................................................41

6.3.4 Field support ........................................................................................................................41

7 Availability and disaster recovery............................................................ 42

7.1 Introducing availability options....................................................................................................42

7.1.1 Active/passive disaster recovery..........................................................................................42

7.1.2 Active/active availability .......................................................................................................43

7.2 Active/active application-level design .........................................................................................43

7.3.1 Unrecoverable hardware failure ...........................................................................................45

7.3.2 Site infrastructure failure ......................................................................................................47

7.3.3 Single software component failure .......................................................................................47

7.3.4 Planned downtime ...............................................................................................................48

8 Regulatory and industry compliance....................................................... 49

8.2 Payment application security standards .....................................................................................49

8.2.1 PCI DSS...............................................................................................................................50

8.2.2 Visa PABP ...........................................................................................................................50

8.3 SEPA ..........................................................................................................................................50

9.1.1 Transaction workload ...........................................................................................................52

9.1.2 Hardware and software configuration ..................................................................................53

9.2 IBM Power Systems ...................................................................................................................54

9.2.1 Transaction workload ...........................................................................................................54

9.2.2 Hardware and software configuration ..................................................................................55

9.2.3 Results .................................................................................................................................56