ASCert is a toolkit designed from the ground up as a comprehensive environment for helping in the design and development of payment networks and payment applications, including EMV, magstripe, stored value and others.
Transaction Testing
ASCert divides the payment world into five parts, as shown in the following diagram. ASCert can be deployed in each of these five roles and is relevant to terminal vendors (both hardware and software), transaction acquirers, networks and card issuers.
ASCert – Design
ASCert, pronounced to rhyme with ‘assert’, is a multi-threaded component-based software architecture and application programming interface (API) which has been designed to simplify the task of developing and testing transaction-based Electronic Funds’ Transfer (EFT) and payments' applications.
The diagram above shows ASCert's basic design, its major components and interactions between each. The external comms world lies at the bottom and is dealt with through the comms handler layer which converses with the protocol handler layer, responsible for converting raw data into comprehensible information for dispatch to the topmost layer, the router, for authorization or switching.
Comms
The lowest layer of the architecture, the communications layer, is responsible for the physical details of transferring data back and forth from ASCert’s upper layer and the external world. The layer is managed by components known as Communication Handlers, or CH’s for short and, at the time of writing, these exist for TCP/IP, Eicon X25 cards, modems and standard RS-232 serial communications.
Protocol
Above the CH, lies the Protocol Handler, or PH, which acts as a translator, either translating the incoming CH data and packaging it for the topmost layer for further processing, or receiving data from the topmost layer and dispatching it to the CH for delivery. PH’s exist for all non-settlement versions of APACS, for Visa Base II as well as several custom handlers for various clients.
Router
Above the PH, sits the final layer, the router (or Routing Engine, RE) which is responsible for receiving data in ASCert’s internal format, known as ‘txdata’ format, and, according to (a) the RE’s configuration, (b) the transaction details presented in the txdata, and (c) the contents of the backend database, the RE will attempt one of the following actions, either (a) to deliver the transaction to another PH, (b) to authorize the transaction against the backend database or (c) return the rejected transaction to the PH from which it came.
ASCert - Protocols
Internally, between each protocol handler as well as between the protocol handler layer and the router, ASCert uses an internal data structure, known as a txdata, to permit the exchange of payment data from one location to another.
It's the job of each protocol handler to perform two distinct tasks:
 Convert inbound raw data from the comms handler into txdata form.
 Convert outbound txdata into raw data in a form suitable for the comms handler to deliver to its ultimate destination.
ASCert supports a wide range of protocol handlers, including Visa BASE I, Mastercard CIS, Mastercard Host-EM, APACS 30/40, BASE24 Host ISO, ISO 8583, SPDH, iPOS, GICC and two special handlers, the first which operates as a Level-2 EMV interface, permits ASCert to work with physical cards, and to generate transaction data from them. The second, generates fully virtual transactions, extracting transaction content from the backend database's transaction, issuer, PAN, terminal, merchant and other tables.
|
