I did a Flash presentation to accompany and illustrate this piece. See it here.
In sports like basketball and football - both the US and ROW (rest of the world) versions - your game is bound to improve as you increase your number of 'touches.' It's the same way with transaction processing: the more you control, the number of transactions you see, the variety of the business interactions in which you're called upon to add value...all these things add up to making you better at what you do.
So, it's a notable to take a look at our growth over the past couple of years. Our peak days at our largest customers have gone from one million to eight million. What's driving the growth? We're increasing our touches. Circa 2006, when a customer came into one of our clients' locations, our acquirer-side switch executed the payment card transaction. One and done.
Now, by contrast, I can detail a very plausible 15-touch scenario.
To set this up: envision the all-too-familiar task of going to a retail location that has an in-store pharmacy. You've gone in to get a prescription filled and to make a few incidental purchases. Here's the tale of the tape...
Touch #1: You present your benefits card and prescription information to the pharmacist. They perform a 'local edit' to pre-validate certain aspects of the transaction before submitting it to an external adjudicator. This touch hits our Rx Edit Engine for internal processing.
Touch #2: Next up, the adjudication step. This touch hits our Rx Adjudication Engine and involves us switching out transactions to Relay Health and Emdeon, the country's leading connectors of payers, providers and patients.
Touch #3: The customer belongs to our client's excellent loyalty program! But, alas, they've forgotten their card. ¡Qué lástima! Never fear, phone look-up is here! In this touch, the customer provides a phone number and we find and return the hits from our Loyalty Engine (internal processing).
Let's assume that we found three cards with that phone number (this happens A LOT -- various members of the household sign up for the program).
Touch #4: At the point of sale, the customer is presented with the three account records we located. He or she selects the account that is theirs. At that point, the point-of-sale fires a Loyalty Look-up transaction at us. In this touch, we do an internal look-up in our Loyalty Engine to find the card, determine the customer's 'discount tier' and see what type of 'targeted messages' are currently associated with the account.
If targeted messages are available and contain embedded serializable coupons, we serialize the coupon(s), record them on our coupon database, add them to our reply. [NOTE: The goal of a serialized coupon is to create a degree of lock-in for a return visit.]
If electronic coupons are available, we add them to the reply as well. [Unlike serialized coupons, electronic coupons can be used immediately.]
Touch #5: The customer has two serialized coupons from a previous visit that they're looking to use in this sale. It's up to us to validate them. In this touch, our Loyalty Engine checks our internal database to determine if (a) the coupon is on file; (b) the offer is still valid; and (c) the coupon was not already used.
Touch #6: We validate the second serialized coupon.
Touch #7: One of the products the customer is seeking to purchase contains Pseudoephedrine ('PSE'). It's MethCheck time. In this touch, the non-PCI branch of our Financial Engine formats an external request to PSE national database provider Appriss, Inc.
Touch #8: Market basket analysis! We get a transaction consisting of (a) all the goods (item by item) a customer is purchasing; and (b) the electronic coupon offers that the customer chose to activate at the point-of-sale. This touch is a thick, complex internal/external undertaking by our Loyalty Engine - we tick off the electronic coupons locally and assemble a series of external transactions consisting of the market basket items. We send these requests to an external 'offer engine' (like this one).
In response, the offer engine sends us back a series of 'triggered' messages ('triggered' in this context meaning that the presence of a specific item in the market basket has triggered an offer for another product). We analyze those messages and - if they contain serializable coupons - perform the serialization routine described in Touch #4.
Touch #9: Payment time! The customer has some SIGIS Eligible Products in their market basket, so they decide to use their Health Savings Account ('HSA') card to make this purchase. The point-of-sale's SIGIS-approved IIAS catalog figures out what products are eligible and sends us a transaction that denotes the total amount, the sub-total of over-the-counter medical items and the sub-total of prescription Rx items.
In this touch, the PCI branch of our Financial Engine does some pretty heady transformation of the message and sends an authorization request to the card issuer, either via a payment gateway like FDR North or Fifth Third (to cite two examples) or direct to an association (i.e., MasterCard, Visa, Discover, etc.).
Because of the byplay of item qualification and varying HSA program coverage rules, the instances of partial approval in these situations are frequent. So, let's put that in play here. We format a partial approval back to the originator, making note of what amount got authorized.
Touch #10: Confronted with news of the partial authorization, the customer is asked to provide a second form of payment. What to do next? They have options: void the sale and provide a new form of payment; void the sale and walk; provide a second form of payment to cover the difference; modify the market basket (i.e., take enough items out of the market basket so that the approved amount covers the purchase).
Let's go for a combination of the last two: the customer also has in-hand a store-branded stored value card ('SVC') they want to use...except they don't know how much money they have on the card. So, they ask the associate to do a balance inquiry. In this touch, PCI branch of our Financial Engine goes external to format and send a balance inquiry transaction to the SVC's program provider.
Touch #11: Balance in hand, the customer makes a decision: they remove two items from their market basket and use the SVC to cover the remainder of the purchase. In this touch, we go external to the same provider (see Touch #10) with a purchase authorization request.
Touch #12: Now, we have to notify the offer engine to void one or more of the products from their historical database. And, if a serialized coupon had been previously validated in conjunction with the purchase of one of those products (see Touch #5 and #6), we need to roll back that usage. In this touch, our Loyalty Engine receives a follow-up market basket analysis transaction in which we decrement the usage counter on the serialized coupon (internal) and format a void notification to send to the offer engine (external).
Touch #13: Now, let's suppose that among the items purchased was a gift card from one of those near ubiquitous gift card malls that populate the end-caps of retailer aisles everywhere. That card needs to be activated! That's us again. In this touch, the PCI Financial Engine formats and sends a card activation transaction to the appropriate stored value card network (in a typical implementation we manage a series of these interfaces).
Touch #14: Lastly, the customer came into the store carrying a good they bought last time they were in. They wish to return it. Returns (a.k.a., refunds) are a source of major retail fraud. These are unalloyed - systematically - from the related purchase from a payment systems perspective (as opposed to reversals, in which we need to seek for and find an original purchase in order to execute the transaction). To minimize fraud, many retailers put an "authorized return" service into place.
In this touch, our Non-PCI Financial Engine routes the incoming 'authorized return' request to an internal service sitting elsewhere in our client's data center.
Touch #15: If the authorized return request in the previous touch is approved, the ability to do a payment card refund is unlocked at the point-of-sale (I'm assuming the original purchase was performed on a card). In this touch, our PCI Financial Engine process the refund. Credit card refunds (and those of their offline debit card brethren) are handled offline. We write the transaction to our logs and extract it later that evening in the file we prepare to send to our gateway sponsor.
Final Word: Not only could this happen, it does happen. Repeatedly and consistently.