Andy Orrock | Payment Systems

ISO8583 Secondary Bit Map

There was some good dialogue over the past 24 hours on the jPOS Users mailing list about how to implement the ISO8583 secondary bit map.  I find that most ISO specs gloss over this concept or don't do a good enough job explaining the implementation.  It's a fairly tricky concept.  I bet I've had to explain it in-depth about half a dozen times over the past year.

The best and most comprehensive description of the secondary bit map is something I ran across in Total Systems' ('TSYS') ISO8583 specs.  It says:

BIT MAP, SECONDARY

The first bit of the Bit Map, Primary indicates the presence or absence of a second map called the Bit Map, Secondary. Like the Primary map, the secondary map is a control field consisting of 64 bits (8 bytes). It can be considered an extension of the primary map, since it is associated with fields 66 through 128. Data field 65 does not exist. This position is used to indicate the present of another bit map. However, as no third bit map is currently defined, the first bit of the secondary bit map must always 0 (zero). The Bit Map, Secondary is included only when the message contains information in any field from 66 through 128. When present, the secondary map immediately follows the primary one and precedes the data fields.

Perfect.  Hey, they even describe the possibility of a tertiary bit map.  You can't get any more comprehensive than that.

So, you implement the secondary (and placeholder for the tertiary!) bit map(s) as follows:

<isopackager>
  <isofield
      id="0"
      length="4"
      name="MESSAGE TYPE INDICATOR"
      pad="true"
      class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield
      id="1"
      length="16"
      name="BIT MAP"
      class="org.jpos.iso.IFB_BITMAP"/>
  <isofield
      id="2"
      length="19"
      name="PAN - PRIMARY ACCOUNT NUMBER"
      pad="false"
      class="org.jpos.iso.IFA_LLNUM"/> 

[snip]
 
  <isofield
      id="65"
      length="1"
      name="BITMAP, EXTENDED"
      class="org.jpos.iso.IFB_BINARY"/>

NOTE:  That's a packager that implements an ASCII, character-based implementation with a BCD bit map.  While your choice of classes will vary based upon your specific implementation needs, the roles of Fields 0, 1, 2 (showing 2 here simply as a boundary for the Bit Map) and 65 should look exactly like this.  I've got half a dozen different ISO8583 implementations running in jPOS, and each one looks like this in terms of the names and roles.

As Alejandro noted in his reply to the e-mail that started this discussion, jPOS takes care of the secondary bit map behind the scenes.  It doesn't need to be explicitly defined.  In other words, you see the bit map here is 16 in length.  If Field 1 is present, then the bit map you receive or build is 32 in length...but the underlying jPOS packager takes care of constructing (or deconstructing) that for you.  That's the beauty of what Alejandro has done:  everyone around the world was dealing over and over again with these quirky ISO8583 complexities, but he solved them for everyone once and for all.  As I've noted before:  if you're about to tackle an ISO8583-based project, why reinvent the wheel?

Credit vs. Debit - Part 2

This post expands on my previous post on this subject, in which I try to differentiate 'credit' vs. 'debit' as it relates to payment card processing.  This is a constant source of confusion, especially as it relates to the various nuances of debit card processing.  As background to this piece, I suggest you read the excellent Wikipedia entry which defines online vs. offline debit.

Back in the 1980s, we had a simple, bifurcated world:  there were credit cards (PIN-less and tied to a credit line); and there were ATM cards (always requiring a PIN and tied to a bank account).  Muddying the waters was the advent of the so-called 'check card,' which can be thought of as a 'dual mode' card - it can be used without a PIN as sort of a 'secured' credit card ('secured' in the sense that the cardholder is dipping into real money in a bank account) or with a PIN as a debit card.

Now, we get into some rather misleading definitions that this muddying has caused...

• When you use that check card with a PIN, it's called Online Debit.  For those of you familiar with ISO8583, that PIN-ed request is going to result in you (as the acquirer) formatting an 0200 (the typical MTI used for a Purchase/Sale) request to the Debit/EBT gateway.
• The card issuer (or its authorizer) authorizes that request and treats it as the 'letter of record' (my term) to debit the account in its nightly posting cycle.
• The Debit/EBT gateway may or may not require the inclusion of that Debit transaction in a nightly extract/settlement file (prepped and sent by the acquirer).  As a case in point: the FDR North implementation requires that you put Debit/EBT transactions into a combined settlement file; the FDR Nashville (formerly 'Envoy' before parent Concord/EFS was scooped up by FDR) implementation has no associated extract requirement for Debit/EBT.  [Same company...go figure.]   Even for FDR North, those Debit/EBT transactions in the settlement file aren't there for issuer posting purposes; instead, they provide the basis for gateway-to-acquirer settlement, and they also feed into a 'suspense' process.
• When you use the same card without a PIN, it's called Signature Debit, i.e., because you sign for the transaction like a credit card - of course, new regulations muddy the waters further: at some merchant categories, a signature is no longer required for purchases of < US$ 25, as frequenters of Starbuck's know. 
• Now, the ultimate in misleading definitions: Signature Debit is often called Offline Debit, this despite the fact that 99 times out of 100 (you're not obligated to authorize these, but you open yourself up to chargebacks), the acquirer sends an online transaction request to get an approval decision (for ISO8583-savvy folks, you send an 0100 - the auth MTI - in these situations).  Where the 'offline' designation comes from is that this online auth is not the letter of record.  In these situations, you (as the acquirer) are obligated - assuming the transaction isn't subsequently reversed - to put these 'offline debit' transactions into the settlement/extract file.  And it is these items that the Issuer uses to debit the related bank account.  In other words, the 'offline' appellation here refers to the manner in which the bank account ultimately gets debited, not whether you sent an online request at the time of purchase.
• Okay, to further complicate matters: this Offline Debit transaction is often referred to as a Credit .  Ugh.  Why?  Well, you auth it via a 0100, like credit.  And, when you stick the related entry into the nightly extract file, you format it as a Credit record.  For example, in the FDR North extract file, these transactions get formatted as the Credit 'D' record, not the Debit/EBT 'Q' record.  Indeed, from the perspective of a host-based payment system, you can't tell the difference between a purchase conducted with a 'true' credit card and one conducted with check card in PIN-less mode.  In the words of Dan Rather, "If it looks like a duck, walks like a duck, and quacks like a duck, it must be a duck."

Dynamic Key Exchange Models

I've had a number of people ask me recently about how to implement Dynamic Key Exchange models within jPOS.   Specifically, I'm talking here about ISO8583-based financial payment gateways.  This post pertains to situations where you're acting either as the Card Issuer (in which case you're receiving payment transaction requests from the gateway) or the transaction acquirer (in which case you're sending payment transaction requests to the gateway in order that they route it for appropriate authorization decisioning).

There's some terminology to square away first:

Local Master Key ('LMK') - This is the key you store in the HSM in order to encrypt and do software-based storage of the current Working Keys (and Base Derivation Keys if you're using DUKPT).  Also called the Master File Key ('MFK')

Zone PIN Key ('ZPK') - The ZPK is what's used to encrypt the PIN blocks that traverse the wires between institutions.  Also referred to as the 'Working Key.'  This is the key that the Dynamic Key Exchange is acting upon.  You're obligated to change the Working Key at agreed-upon intervals (I typically advocate every 12 hours).

Zone Master Key ('ZMK') -  Think of the ZMK as the key transportation vehicle.  It's the key that the two parties use to encrypt and exchange new ZPKs.  This key is established via a key ceremony.  You keep a copy of the ZMK encrypted under the LMK in a file somewhere (you'll see how it's used here further down this post).  Also called the Key Exchange Key ('KEK').

Now, I'll pass along some hard-earned 'lessons learned' (Alejandro and I have the scars on our backs to prove it):

1. From the moment you start planning discussions with the gateway, establish RIGHT AWAY that you want field-by-field level specifics of how the Dynamic Key Exchange is to be performed.  It'll be within the context of some  Network Message Exchange (e.g., 0800/0810), but that's not granular enough - you need to know the thing down to the field-content level.
2. Scour the documentation you've been provided to see if those details are in there.  I've done two different gateway projects recently, and in both cases the Key Exchange details were notably absent from the doc.  But, that doc exists somewhere within the gateway institution.  Track it down.  Get your hands on it. 
3. Knowledge of the Key Exchange model is - by design - not widespread throughout the gateway provider's project personnel.  Insist on getting their expert in on at least one of the planning calls.  Make note of this person's name and contact details.  Establish that information channel.  This is a critically important point to your success.

At a high level, there are two models:

• You request a new ZPK from the gateway, and they provide it in the response.  [I call this the 'Pull' model (for obvious reasons - you pull the key from them).]
• The gateway sends you a new ZPK and you respond with a message indicating success or failure.  [This, by contrast is the 'Push' model.]

Your implementation will be one of those.

Now, I'll provide two examples, one push, one pull.  In both cases, I'll reference some files that I prepared that will show you the model explained as implemented in fine detail. 

Here's the push model.  [I've done some annotating there within Acrobat.]  We're the Issuer in this example.  The gateway sends us a new key every 12 hours.  Behind the scenes in this example we're using a Key-Up II box from IDS as our HSM.   The sequence of events is:

1. The gateway sends us a new ZPK (under ZMK) in an 0800 (MTI) Network Request.
2. We obtain the ZMK (under LMK) from our files.
3. We use the cryptograms from Steps 1 and 2 to create the appropriate command to the Key-Up (here, a '12')
4. We get the response from the Key-Up (the '13') and validate that the Check Digits match those provided by the Issuer.
5. Assuming the check in Step 4 is okay, we store the result (the ZPK under LMK) as the new Working Key.
6. We send an 0810 (MTI) Network Response back to the Issuer (Note that Field 39 on our response is '00' - indicating success). 

There's so much detail here worthy of comment.  I'll touch on a few things (these are the types of detail you want to bring to the surface in your reviews):

• This gateway uses '162' in Field 70 to tip to us that it's a Key Exchange in play.
• Note how we have to pluck the incoming cryptogram out of the esoteric morass of Field 123.
• We have to construct an equally cryptic Field 123 on our response.

For reference - the push example provided here is a working model for Genpass (now called Elan Financial Services - a division of US Bank) interface.  Nice people!

Here's the pull model.  [Here, I had to do a did a bit of redacting in Acrobat.  The redactions don't spoil the flow.]  I won't go into too much detail in-line here, because you'll see I've provided entirely TMI (Too Much Information!) in the file.  The flow here is:

1. We request a new key from the Gateway in an 0800.
2. The new key (ZPK under ZMK) comes back in an 0810.
3. We fire off an 'FA' to the Thales 8000.
4. We get the 'FB' back and validate the check digits.
5. If okay, we store the result (the ZPK under LMK) as the new Working Key.

Now, since we're the initiator here we have to have a way to determine when to trigger the exchange request.  We do that through a channel Logon Manager.  Here's a 30_fdr_logon_mgr.xml we have defined:

<fdr-logon-mgr class="org.jpos.fdr.LogonManager" logger="Q2">
<property name="persistent-space" value="jdbm:fdrlogon:log/fdrlogon" />
<property name="mux"            value="fdr-mux" />
<property name="channel-ready"  value="fdr.ready" />
<property name="timeout"        value="900000" />
<property name="echo-interval"  value="600000" />
<property name="logon-interval" value="43200000" />
<property name="pseudo-tid"     value="00599999" />
<property name="pseudo-mid"     value="000452009999999" />
<property name="sm"             value="Thales" />
<property file="cfg/keys.cfg" />
<property name="initial-delay"  value="5000" />
</fdr-logon-mgr>

You can see the 'logon-interval'  - 43,200,000 milliseconds is every 12 hours  (behind the scenes, our logon sequence does a logon exchange and a key exchange.]

For reference, the pull example provided here is a working model for the FDR North interface.

You get the idea, I hope!  Nail down all those details in order to maximize your chances of success.  Otherwise, feel free to beat your head against a wall, because that's what will happen if you don't get this information.

What is a Switch?

A question posed in the jPOS Users' Group asked to define the terms Issuer and Acquirer and asked the function of a switch (meaning, in this case, the function of a payment gateway to which the user is connecting).  Here was my answer:

Formal definitions for Acquirer and Issuer can be found here:

Acquirer

Issuer

More informally, note that any card-initiated transaction that needs to traverse a financial network is initiated at Institution A (i.e., they are the transaction's Acquirer or 'point of origin'), and routed through a network to Institution B, the organization that issued the card to the cardholder (i.e, they are the card's Issuer).

This next part will reinforce the definitions and also address the additional inquiry regarding a "what is a switch" (also known as a payment gateway):

Suppose you are a pharmacy chain and you allow your customers to pay at your point of sale by Debit card.  You are the Acquirer.  When a customer initiates a Debit transaction, they do so with a card issued by a major bank.  For the sake of example, let's assume this card was issued by Bank of America.  So, BofA is the Issuer here.

Now, as an acquirer you do not know programmatically that this card was issued by Bank of America.  In fact, the next customer could have a card from Bank of Angola and you'd be obligated to try to take that card for payment as well.  Of course, it’s totally out of scope and beyond an Acquirer's span of control to maintain a complete BIN routing table AND it’s certainly out of scope to manage direct connections to all possible institutions.

That's where the switch/payment gateway comes in to play.  You route all your Debit transactions to a single point (a gateway switch) and then it's their business to determine routing from there.

Behind the scenes, that switch/gateway probably does something like this:

• Maintains connections to each of the regional debit networks like STAR, Pulse and CIRRUS (this is a US-centric example...my apologies)
• Maintains direct connections to some of the major Issuers, like BofA, Wells Fargo

Consider a transaction initiated at a pharmacy in Pennsylvania (US) by a cardholder holding a Debit (or Visa Check card) issued by Banco Davivienda in Colombia.  A probable routing path is like this:

Acquirer ---> Genpass (switch provider in US) ---> CIRRUS ---> CIRRUS International ---> Switch Gateway in Colombia Banco ---> Davivienda

AUTH TAKES PLACE AT DAVIVIENDA...

...and response tracks back to Acquirer (by re-tracing the steps above)

Again, my apologies for the US-centric viewpoint here which is provided for example only...you could envision similar set-ups in other locales.

Credit vs. Debit

A list member of the jPOS Developers Group asked a series of questions wanting to know the difference between a Debit transaction and a Credit transaction.  It's actually a deceptively complex question which can be given a multi-part answer.

Essentially, the Debit/Credit terminology has (in my mind) three distinct meanings in a payment systems setting...

First, there's Debit Card vs. Credit Card.  Alpha list member Mark Salter provided a great answer to that:

A credit card transaction reduces the available credit on an account, which a company backs, think of this as a purchase on credit (that someone lends you).  You settle this account at a later date, probably in reaction to receiving a statement.

A debit card transaction results in money being debited from an account in your name at the *time* of the transaction.  There is no loan made and the money must be available in the source account.  You are spending your money in real-time.

Great stuff. 

To delve further and clear up any remaining uncertainties, I noted that it would be worthwhile to read the Wikipedia entry for Credit Cards:

http://en.wikipedia.org/wiki/Credit_card

...and then the Wikipedia entry for Debit Cards:

http://en.wikipedia.org/wiki/Debit_card

Those are really great write-ups.

The Wikipedia entry for Debit speaks to the second definition of debit vs. credit in this setting: namely whether one of these 'dual use' check cards is deployed at the point-of-sale in "debit" or "credit" mode:

In some countries (e.g., the U.S.), terminals allow the user of a Visa or MasterCard debit card to choose whether the purchase is a "credit" or "debit" purchase. In a "credit" purchase, the user signs a charge slip (as in a traditional credit card purchase); in a "debit" purchase, the user enters a PIN. In either case, the user's bank account is debited.

So in the first definition, the card products themselves are identfied as credit vs. debit.  In the second definition, the card is flexible while it is the transaction itself which is either a credit or debit variety.

To further muddy the waters, there's the third situation in which the term "credit" may be used in conversations of this nature: certain POS applications allow for a Merchandise Refund.  In this regard, the Refund is often categorized as a "credit" (vs. the original sale being a "debit").  In this situation, the credit and debit terms are related purely to their accounting nature, i.e., when you're looking to place the transactions into one of two categories for accounting and reporting requirements.

Good Glossary of Payment Industry Terms

First Data publishes a nice glossary of terms related to the electronic commerce and payment service industry.  Some of the terms are First Data-specific...for example, I stumbled over this resource while trying to figure out what the heck "FSP Merchant" meant.  A quick Google search and a hit on the glossary revealed:

Full Service Processing (FSP):  A relationship with a Bank whereby First Data provides a series of services on an outsourcing basis. First Data is paid fees for the services performed and does not hold the risk for Credit/Fraud losses. 

Undoubtedly esoteric!  But for every First Data-centric definition there are 10 brief provider-agnostic definitions that are helpful.  For example, there's a nice clarification on the various Acquirer roles:

Acquirer:  A licensed member of MasterCard® and/or Visa® (or its agent) which maintains merchant relationships, receives all bankcard transactions from the merchant, and initiates that data into an interchange system.

Acquiring Bank/Merchant Bank:  The bank that does business with merchants enabling them to accept credit cards. A merchant has an account with this bank and each day deposits the value of the day's credit card sales.Acquirers buy (acquire) the merchant's sales slips and credit the tickets' value to the merchant's account.

Acquiring Processor:  The processor provides credit card processing, billing, reporting and settlement, and operational services to the acquirer. Many financial institutions hire a third party for more cost-effective bankcard processing.

While the glossary entries pretty much just scratch the surface, a quick review of these terms can help you sound knowledgeable in client or vendor meetings.