Availability Digest. Payment Authorization A Journey from DR to Active/Active December, 2007

Transcription

1 the Availability Digest Payment Authorization A Journey from DR to Active/Active December, 2007 A major provider of merchant services to over four million small to medium-sized merchants throughout the world provides, among other services, payment authorization for Visa, MasterCard, American Express, Diner s Club, Discover, and other credit and debit s. Card transactions made at merchant point-of-sale (POS) devices and ATMs are verified to ensure that they are proper. The company s payment authorization services are extremely critical. Should these services become unavailable, shoppers all over the world will not be able to use their credit or debit s processed by the company. Therefore, the company has worked diligently to guarantee that its authorization services will always be available. It turned to ication technology to satisfy this need. Over a period of several years, the company has expanded its use of ication technology from disaster recovery to active/active systems to application integration. This has been a slow and careful process as the company learned the benefits of ication. Today, this effort has resulted in a system that indeed is continuously available. Payment Authorization Credit and debit s are issued by banks. They are used by consumers to purchase items from brick-and-mortar and online stores and to withdraw cash from ATMs (automated teller machines). Each transaction must be approved by the issuing bank before it can be accepted by a merchant or by an ATM. The payment authorization process begins when a consumer s credit is presented for payment. This might occur at a point-of-sale (POS) device, such as a credit- reader attached to a cash register in a store. It might be initiated when a consumer gives his credit number and other information to a sales person over the telephone or when this information is entered into a form on a web site. It might begin at an ATM (automated teller machine). merchant POSs and ATMs authorization switch banks exception files Merchant Authorization Services 1

2 The POS device, the ATM, or the system hosting the sales support for telephone or online ordering is connected by a communication channel to an authorization switch established and managed by an organization providing merchant services. The authorization switch receives the transaction and analyzes it. It determines which bank is servicing the credit or debit and sends the transaction to that bank. It will check if the has been lost or stolen and may also check the transaction for suspicious charge activity. If the bank responds positively, and if the switch detects no other problems, an authorization message is returned to the originating device or system. If the bank rejects the transaction, if the has been reported as lost, stolen, or frozen, or if the transaction is suspicious (i.e., a potentially fraudulent use of the ), the transaction is rejected. A Start with Disaster Recovery The merchant services provider operates a major authorization switch in North America. It has two centers 1,000 miles apart on the East Coast of the United States. We will call these centers and. The switch functions are duplicated in each center to provide recovery from any disaster that might take down one of the provider s centers. In normal operation, the processing load is distributed between the two sites. The company s first use of ication was to keep its Card Management Application (CMA) systems in each center synchronized with each other. Hosted on servers, the CMA systems provide a base of all s issued by participating banks. These s include Visa, MasterCard, American Express, Diner s Club, Discover, and others. Banks send batch ftp files to the CMA system for new s they issue, s they report as stolen or lost, and other status changes. These batches are received by the CMA system and stored in its base. This base is then icated to the Center South CMA system via the Shadowbase ication engine from Gravic ( Thus, both CMA systems always have the complete and up-to-date of all s that have been issued. banks updates ication switch Card Management Application switch The CMA base specifies which issuing bank services each, what the s characteristics are (its number, its expiration date, its credit limit, its PIN, and so on), and its status (active, lost, stolen, frozen, an so on). Additions and changes to this base are sent by each CMA system to the switching s local to it. Therefore, each switching has direct local access to all, a requirement for fast authorization. Fast authorization is needed since a consumer is waiting to complete his transaction. Also, while he is waiting, the POS, ATM, or telephone sales clerk is occupied and cannot service the next customer. 2

3 By maintaining a copy of the CMA base at each site, the company ensures that the CMA is available at all times even in the event of the failure of one of the systems. Should one system fail, all batch updates from the issuing banks will be routed to the other CMA system; and this system will take on the responsibility for keeping all s at both sites updated. This architecture also allows rolling upgrades to be made to the CMA systems. One system can be taken down and its operating system, application, base, or hardware upgraded while the other system carries the CMA load. The first system can then be returned to service and the second system taken down for upgrade. The Move to Active/Active After several years of successful operation with the disaster recovery (DR) uration for the CMA systems, the service provider moved to an active/active uration for its authorization switch. The switch contains four s two in and two in. Each is connected to thousands of communication lines that connect to the company s massive IP network. When a transaction is received from a merchant, the job of the switch is to validate the /transaction, route it to the issuing bank, and then to return the response to the merchant. Switch Configuration Though all switching is kept in memory, the switch urations are kept on disk in a uration base. Configuration contains information about each and each issuing bank as well as state for each ongoing transaction. The uration base also contains failover urations so that surviving s can take over the functions of a failed. Consequently, the uration base is fundamental to proper switch operation. A copy of the uration base is maintained on each for local access. These copies are kept synchronized by the Shadowbase bidirectional ication engine. admin switch switch transaction CMA authorization bank ication POS or ATM transaction authorization switch switch active/active authorization switch 3

4 The credit and debit s are partitioned across the s by number. As a consequence, each is owned by one of the s. This prevents collisions on updates due to transaction activity from occurring. All transactions for a are routed to the owning that. That makes transactional updates to its base, and its changes are icated to the other base copies in the network by Shadowbase. Thus, no two s can be making simultanous changes to a due to transaction activity; and collisions are avoided. Transaction Processing When a transaction for a is initiated, the authorization switch s IP network routes the transaction to the owning that based on the number range reflected in the transaction. When a transaction request is received by its owning, the uration base is accessed to determine which bank issued that and therefore to which bank the transaction should be sent. The uration base specifies the IP address of the issuing bank, and the owning forwards the transaction request to that bank. When the issuing bank returns a response to a transaction request, the company s IP network returns that response to the owning the. An authorization or rejection message is sent by the owning to the initiating device to complete the transaction. The transaction is authorized if the issuing bank authorizes it and if the authorization switch has detected no other problems, as described later (lost or stolen, frozen, suspicious activity, and so on). Node Failover Equally important is the failover uration maintained in the base. Should a fail, the uration base tells the surviving s for which s they should take responsibility. The surviving s then assume ownership of their newly assigned s so that switching services can continue. The uration failover base also tells each which applications it should take over to continue operations. Thus, should a fail, all s that are owned by the failed are switched to surviving s as are the failed applications. Authorization services continue without interruption. In fact, this procedure is repeated for multiple failures so that operations can continue even if more than one fails. Replicating Changes The redistribution of s, transactions, and applications to surviving s is one of the requirements for an active/active system. Equally important is that each must have a current copy of the application base. In the case of the authorization switch, there is no real-time to be icated since it is all kept in memory. If a fails during the processing of a transaction, the originating system will time out and will resubmit the transaction. The transaction will then be processed by the new uration. However, there must be a current copy of the uration base resident at each. The uration base is accessed and may be updated during each transaction. In addition, changes are received from the CMA system. The uration base may also be modified by administrative operators. All of these changes are icated to each of the other s by the Shadowbase ication engine so that each has a current copy of the uration base. Though transactional changes to a are made only by its owning and are icated to the other s from that, it is possible that administrative changes to a may be made at other s. This, of course, opens up the possibility of collisions should a change to the same credit or debit be made at two different s almost simultaneously (within the ication latency interval). Though this is unlikely due to the nature of the partitioning, if 4

5 there is a collision, the collision resolution algorithm selected by this customer is that the later change is accepted. The other change is rejected and is logged for subsequent manual review. The Shadowbase ication engine performs another important function. As the failover uration is modified (which it must be for every new ), it is entered with respect to the receiving the uration updates. However, this uration is different for each since each will take a different action on failover. For instance, 1 might handle A. Should 1 fail, 2 might handle A. Should 2 then fail, 3 might handle A. Via built-in business rules, the Shadowbase ication engine automatically adjusts the uration for each as it icates the. Thus, the company has converted its four- switch to an active/active uration that can recover almost instantly from any fault in the system, including a total (or multi) failure. Recovery is transparent to the users. Heterogeneous Application Integration A major function of authorization is to detect the potential fraudulent use of s. If a transaction looks suspicious for instance, it is for a purchase in a New York store whereas the last transaction one hour ago was for a purchase in a Los Angeles store - it may be rejected. The company implemented a fraud detection application using an Oracle system. Each transaction received by the authorization switch is sent to the Oracle fraud detection system. This system maintains a log of recent transactions and checks each transaction against other recent transactions for the same. If a transaction appears to be suspicious, the result is passed to the authorization switch, which may then reject the s transaction. The switch may also notify the issuing bank of its action; and the bank, at its discretion, may freeze the. The holder is notified and must call in to verify his credentials and recent transactions. The fraud detection system is also periodically sent a list of s that have been reported lost or stolen or that have been frozen by the issuing bank. If a transaction is made against such a, this situation is reported back to the switch, which will reject the transaction. lost/stolen s Oracle fraud detection authorization switch Fraud Detection At each center there is one fraud detection system serving the s at that site. The company implemented the communication between the fraud detection system and the authorization switch s again via the Shadowbase ication engine. When a transaction is received, a notation is made in the s base on the authorizing switch. This notification is icated to the fraud detection system, where Shadowbase detects the request as it is updating 5

6 the Oracle base. The request is passed to the fraud detection application, which logs a response by updating its base. When Shadowbase icates this change back to the authorization switch, the Shadowbase software on the receiving end detects it and passes the response to the authorization switch s switching logic. This is a case of heterogeneous application integration since the authorization switch s are systems and the fraud detection systems are Unix/Oracle-based. The authorization switch maintains its own base an exception file of all s against which transactions have been initiated and that have been reported as lost, stolen, or frozen. Included in this exception file is also a list of s that have been rejected by the switch due to suspicious activity. A is cleared from this list when the issuing bank so notifies the switch during one of its batch updates of changes. The authorization switch is heavily involved in the authorization decision. When it receives a transaction, it first checks its exception file. If the is not listed in the exception file, the switch sends the transaction to the fraud detection system and to the issuing bank. Only if all tests are positive it is not in the exception file, it is not suspicious, and the issuing bank authorizes it is the transaction accepted. The originating device is then notified to accept the transaction. If any of these tests fail, the originating device is instructed to reject the transaction. The Integrated Authorization Switch This merchant services company has carefully expanded its use of Shadowbase s ication over the years. The company initially used ication to provide a uni-directional active/passive -recovery capability for its Card Management Application. After feeling comfortable with this use of ication, the company expanded its use of ication technology to provide continuous availability for its multi switch. Finally, it integrated heterogeneous applications (the fraud detection system) via ication. ication CMA CMA lost/stolen s lost/stolen s Oracle fraud detection authorization switch Oracle fraud detection This case study is important in that it demonstrates the many uses of ication engines in mission-critical applications. 6