GTK_Postilion 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 ([email protected]).

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

mailto:[email protected]

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

Getting to Know 1

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 for complex environments

Multi-institution—multiple institutions/acquirers can be managed within a single system, in turn providing merchant management services to merchants

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 performance and availability

High-volume processing—handling tens of millions of transactions per month and transaction processing throughputs in excess of 1,000 transactions per second

100% availability—active/active architecture ensures that cardholders can transact 24 x 7 without disruption

Advanced security and compliance

Secure payments application—sophisticated cryptographic support, which meets PA-DSS compliance requirements and is EMV-ready

Card scheme compliance—scheduled product enhancements ensure support for the latest card scheme specifications

Rapid implementation and deployment

Flexible terminal driving—supports a broad range of terminal models from leading vendors, and popular message protocols such as ISO 8583, Visa, APACS, and SPDH; support is also 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 operational management

Sophisticated operational tools—centralized control for terminal parameters and configurations, in conjunction with proactive real-time monitoring and alert management

Extensive back-office functionality—provides automated reconciliation, merchant settlement, and statement functionality, complemented by a broad range of standard and custom reports

Postilion for Merchant Acquirers 2

Postilion supports any transaction, anywhere, anytime, with any payment instrument.

Payment instruments Transaction types Payment channels

Magnetic stripe debit and credit cards EMV debit and credit cards Corporate purchasing cards Contactless chip cards Prepaid or stored value cards Private label cards Fleet and fuel cards EBT

Purchase Purchase with cashback Cash withdrawal Gratuity Refund Void Electronic benefits transfer Value-added services

Stand-alone POS terminals Integrated PIN pads Self-checkout terminals Internet Kiosks Call centers Mobile phones POS terminals

Getting to Know 3

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.


• 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

Getting to Know 5

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


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.

Getting to Know 7

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


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.

Getting to Know 9

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


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.

Getting to Know 11

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


• 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

Getting to Know 13

3 Central transaction processing KEY POINTS AT A GLANCE

• 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.


• 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.

Getting to Know 15

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.


• 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.

Getting to Know 17

• 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


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.

Getting to Know 19

4 Merchant back-office management KEY POINTS AT A GLANCE

• 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


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.

Getting to Know 21

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.


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.

Getting to Know 23

• 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.


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.

Getting to Know 25

• 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).


5 Adjustment processing (dispute management) KEY POINTS AT A GLANCE

• 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

Getting to Know 27

• 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.


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.

Getting to Know 29

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.


Figure 11: AdjustmentHub’s graphical dashboard

Getting to Know 31

6 Managing the solution KEY POINTS AT A GLANCE

• 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.


Figure 12: Grouping merchant characteristics

Figure 13: Grouping terminal characteristics

Getting to Know 33

• 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


• 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.

Getting to Know 35

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


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.

Getting to Know 37

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


• 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

Getting to Know 39

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.


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.

Getting to Know 41

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.


7 Availability and disaster recovery KEY POINTS AT A GLANCE

• 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

Getting to Know 43

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.


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.

Getting to Know 45

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.


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.

Getting to Know 47

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.


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.

Getting to Know 49

8 Regulatory and industry compliance KEY POINTS AT A GLANCE

• 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.


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

Getting to Know 51

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.


9 Performance KEY POINTS AT A GLANCE

• 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.

Getting to Know 53

Hour Debit Check Gift card Visa MasterCard American Express

Discover EBT Phone 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)


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.

Getting to Know 55

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.


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

Getting to Know 57

10 Sizing KEY POINTS AT A GLANCE

• 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.


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



Getting to Know 59

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.


11 Central switch deployment options KEY POINTS AT A GLANCE

• 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.

Getting to Know 61

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


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.

Getting to Know 63

12 Postilion professional services KEY POINTS AT A GLANCE

• 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.


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.

Getting to Know 65

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.


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 [email protected]. Alternatively, contact an area sales office directly.

Americas 705 Westech Dr Norcross, GA 30092 USA T +1 404 923 3500 Toll Free: +1 888 457 2237

Europe Culverdon House Abbots Way, Chertsey, KT16 9LE, UK T +44 1932 574 700

Middle East Alfa Building, Office 404 Dubai Internet City, Dubai PO Box 502504 United Arab Emirates T +971 4 364 2644

Asia-Pacific Level 1, 10-16 Queen St. Melbourne,3000, Victoria, Australia T +61 3 9695 8444

Africa Ground Floor Howick Gardens Building, Waterfall Park Bekker Road, Vorna Valley Ext. 21, Midrand, South Africa T +27 11 990 9000

http://www.s1.com/

http://www.postilion.com/

mailto:[email protected]

Getting to Know 67

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


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.

Getting to Know 69

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


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

Getting to Know 71

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 BankServ Credit BankServ Realtime Clearing NamSwitch AEGN Bankom Interswitch

Amex Credit Authorization System (CAS) BofA Merchant Services MultiLink(BAMS) CGI Relay Switch CNS (EPOC/EDS/Fiserv) Co-op Network 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

ALTO First Data Int (FDI) MasterCard RSC (Regional Service Center - Sydney) Megalink Paymark / ETSL Prima

EuroPay GlobalCollect International Forecourt Standards Forum (British Petroleum) VocaLink NETS (Norway) Orange (UK) PBS Denmark

UAESwitch KNet Benefit (GCC switch) Shva SAMA


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 FNS BANCS Flexcube Vision

Alaska Option (Denali) Bankway (Kirchman MQ) Cardinal CSI EDS Cube Elysium Fiserv

AFTECH CBS 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

FACTS Fiserv

ICBS iFlex / FlexCube Phoenix Jack Henry

Silverlake Temenos Vision Plus

TSYS (Prime) Metavante Tech (Cortex) Equation FDR Vision Plus Lloyds TietoEnator/RTPS

Getting to Know 73

C.5 Others Postilion has interfaces to the providers listed in the table below, among others.

Africa Americas Asia-Pacific Europe Middle East

RCS Base24SA

ABSA NEDCOR FNB

NedConnect Vagas Celtel Experian

TransAct

Amex Stored Value Card (Gift Cards) BCGI Prepaid Wireless Comdata e-Money ebitGuard EnCompass FDIS FleetOne JB Hunt MultiSerive PreSolutions Qwest Radiant SSA TChek TeleCheck TransComm (IPS) TravelersExpress MoneyGram TravelersExpress MoneyOrder TSYS GiftCard Verizon PrePay Western Union Money Order / Transfer

Australia and New Zealand Banking Group (ANZ) Auckland Savings Bank (ASB) Bank of Ayudhya (BAY) Bank of New Zealand (BNZ) Taranaki Savings Bank (TSB) Westpac Bank

Barclay Card Business BTCellnet DeutcheBank (Pago) Euronet One-2-One (T-Mobile) Streamline Telekurs TSysPrepaid Vodaphone

Emirates Bank International (EBI) LeumiCard

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.

Date post:	28-Nov-2014
Category:	Documents
Upload:	adrian-hope-bailie
View:	1,326 times
Download:	62 times

GTK_Postilion for Merchant Acquirers

Documents