Analysis by Transaction Class at an Acquirer

Here’s a summary of some transaction analysis I was performing this morning at one of our OLS.Switch acquirer implementations…

I took all the transactions from yesterday at this customer location (1,077,556 at approx 5,000 locations across four US continental time zones), grouped them into transaction class (e.g., Debit/EBT, Credit, Stored Value, etc.) and card type (different credit card authorizers, various subclasses of internal transactions, etc.), gave the resulting categories meaningful names, arranged in ascending order by average duration of the transaction (in milliseconds) and provided the associated number of transactions for the class.

Here’s what I came up with:

Transaction Class   No. Txns   Avg Dur
=================   ========   =======
Discount Coupon       14,484        33
Loyalty (1)               25        36
Loyalty (2)              107        38
Loyalty (3)               63        39
Rewards                  440        42
Employee Validation   60,674        44
Loyalty (4)              180        51
Loyalty (5)               35        53
Check (Internal)      12,010        55

--------------------------------------
Authorized Returns       652       140
Stored Value (1)      17,941       255
Stored Value (2)         897       269
Stored Value (3)       8,367       606
MethCheck             14,544       669
FSA/HSA               10,584       742
Credit/Offline Debit 389,038       747
EBT Cash                3049       857
Electronic Check      74,733       863
Stored Value (4)      16,521       868
Stored Value (5)      25,470       935
Online Debit         399,286      1215
Stored Value (6)         756      1313

The presence of the red line is of interest:  for any of the transaction categories above the red line, our authorization path is completely internal, i.e., no QueryHost action inside our TransactionManager is required to get an authorization.  So, when staying internal, we get the work done in 1/20th of a second or less (on < $20k in combined, core application/DB server hardware).

Below the red line, we have to query either an internal server somewhere else in the enterprise (where another application has better knowledge and can make a more informed decision than we can) or an external server, like for example routing a Credit/Offline Debit request to the FDR North payment gateway for forwarding to the appropriate card issuer or authorizing agent.

I put these into graph format for reader review and further use.  Here’s the Excel 2007 (.xlsx) version; and here’s the Excel 2003 (.xls) version.

Two follow-up notes (added subsequent to my original post):

• I’ve tallied and compared only the approved transactions for the day, so as to eliminate the skewing effect of timed-out transactions (i.e., because no response was received from the remote authorizer) on the smaller transaction classes.
• All durations are inclusive of time spent ‘off box,’ i.e., waiting for a response from a remote authorizer.

Comments

[Scott Loftesness]

Andy,

Thanks for sharing!

I'm curious about the online debit transactions taking 1.6 times longer than credit/offline debit? Curious!

Best,
Scott

[Andy Orrock]

Hi Scott -

Thanks for reading and for your great observation. It's an interesting tale to tell!

It has to do with PIN translations. At each step in the transaction path (acquirer, gateway, regional debit network - at times, issuer/authorizing agent), the PIN block associated with an online debit transaction has to be put through a translation step. That puts three or more calls 'off box' to a Hardware Security Module in play along the transaction path.

For example, if suppose this is a Chase debit card:

1. At the Acquirer, the HSM performs a translation from the device's incoming DUKPT PIN block to an outgoing PIN block encrypted under the gateway's ZPK.

2. Then, at the gateway, assume for example that they identify that the transaction needs to get routed via NYCE. So, the gateway does a second HSM-enabled translation (from under the ZPK it shares with the Acquirer to under the ZPK it shares with NYCE).

3. Now NYCE gets the transaction...same deal: it recognizes this request as a Chase BIN and does the ZPK- --> ZPK-based translation to obtain a PIN block with keys it shares with Chase.

4. Lastly, Chase (or its authorizing agent) gets the transaction request and, ultimately, must do a PIN Validation. This, too, requires an HSM operation.

Those four calls exact a penalty as you note - an Online Debit transaction is about 1.6x the length of its credit/offline debit brethren. I can pick any day at any acquirer and that basic relationship will hold true.

Andy