Andy Orrock | Payment Systems

Auspicious week on the compliance front

It was an auspicious week for us on the compliance front.  After some significant work, we hit two milestone achievements...

First, our payment systems switching engine was awarded the VerAfied security mark by Veracode.  There's an official announcement of this achievement in the works.  I'll post that when it comes out. 

Second, we concluded a very productive stretch of work with K3DES, our Payment Application (PA) QSA, culminating in a successful outcome of certification against the PA-DSS v1.2 standard.

That's all I'm going to say here - my colleague Dave Bergert has a feature piece in the works on these subjects.  His credentials (CISSP, CISA, CPISM/A, and former QSA) give him a perspective on these matters that I can't begin to touch.

-------------------------

UPDATE - February 5, 2011:  See my new post entitled VERAFIED by Veracode

A [not so] great way to prevent unauthorized usage of your card

I'm not sure I get the wisdom of this approach:  I was looking to update the photo on my Citicard (it's a circa 1991 shot of me and - 19 years on - is looking a bit dated).  I searched the Citicard website looking for info on how I could upload the photo I'd selected.  No such feature exists.  So, I sent an e-mail to customer service asking: "How can I do this?"

Silence.  Or, so I thought.  Then yesterday in the mail comes this doozy accompanied by a form letter - "Thank you for your inquiry about Citi Photocard..."

Let me get this straight: all I have to do to 'prevent unauthorized use of [my] card' is to provide you with my full name, Social Security Number and account number...

...and then stick it into the ultra-secure US Postal system, which - if I follow the mailer's directions ("Detach Photocard Request Form, complete, seal and return postage-free!") - leaves me with this image as the exposed backside...

...which just SCREAMS OUT what someone is to find inside.

I know the intentions are good here.  But this entire process feels like it's in direct contradiction to the stated goal of preventing unauthorized usage.

Schuman on ‘the Out-Of-Scope PCI Charade’

Here is an excellent post from Evan Schuman – Editor/Publisher and founder of the excellent (and relentless) StorefrontBacktalk – about what he calls ‘the dangerous out-of-scope PCI Charade.’

Money quote:

“If it’s potentially out of scope, I think you’re mad to consider it out-of-scope,” [Walter Conway, a QSA with 403 Labs] said. “I think you’re juggling razor blades if you treat it as out-of-scope data for PCI purposes.”

Schuman notes that “[s]tandards change, and nothing changes faster than security standards”…so, “[t]he only wise route is to simply assume that everything declared out-of-scope could later be declared back in-scope.”

Making the list

Visa just released its October 15, 2008 update to the list of validated payment applications that have been assessed for compliance with the Payment Application Best Practices (“PABP”).  OLS.Switch is on it.  See more about our efforts and my colleague Dave Bergert’s role in it here.

Our thanks to the K3DES team – Jim Richardson, Wayne Varga and Davi Ottenheimer.  As our QSA, they were instrumental both in the audit itself and in making sure the submission stayed on-track at Visa.  [As you can imagine, Visa has been swamped with assessors’ reports as vendors the world over look to meet this year’s deadlines.]

‘Metrocard Mayhem Blamed on Encryption Device’

Perhaps you read about New York City Transit’s  ‘Metrocard Mayhem’ – a two-day customer service and public relations fiasco in which they were unable to authorize Metrocard purchase attempts using debit and credit cards during peak processing periods.  What’s worse, the riders’ cards got billed for these failed purchase attempts.  How to win friends and influence people.  Not.

Yesterday, the NYT reported as follow-up on the root cause:

A faulty encryption device caused the widespread breakdowns of vending machines on Monday and Tuesday…The system normally uses at least two and sometimes three of the devices. The one functioning encryption device could not handle the load during peak hours…The source of this latest problem was discovered after the Tuesday morning rush, officials said. Agency officials said they were slow to detect the problem because a monitor showed that two encryption devices were active when in fact only one was.

Wait.  The head-shaking, double-take part of the story is this:  the fiasco happened Monday and you only discovered after it happened again on Tuesday that one of the Hardware Security Modules had taken itself out of play?!?  Wow.  Wow. 

I have to assume – since both debit and credit cards were affected – that the HSMs are being used as part of the Transit Authority’s PCI compliance strategy.  So, they’re decrypting cardholder account or track data here, not just PINs.

Lots of things in this story resonate as ‘lessons learned’ over the years in our OLS.Switch experiences.  We’ve already solved these problems and have prevented our clients from re-living history and getting splashed into the press in such a brusque manner.  It’s been said that “all PR is good PR.”  Wanna make that case here?

Some commentary:

• We’ve seen clients do this and strongly advise against it: they go the cheap route, try to save a couple of thousand dollars and buy the lowest-rung HSM on the TPS scale.  One example is a vendor who’s got HSMs rated at the 50, 100+ and 220 TPS scales.  A client tried to save a couple of bucks and went with the 50 TPS version, even though the vendor’s datasheets clearly targets the 50 TPS box as ‘entry level.’  The 50 TPS quote is the classic YMMV scenario – the vendor straps that thing down to 50 by basically putting ‘go slowers’ into the box.  So to get anywhere near that promised threshold, you’ve got to code and manage a significant number of simultaneous threads into your payment switch code.  Asking the vendor how many threads is the right number (there is a tipping point) is like asking Gillette how often you should change your razor blade.  Rest assured, the answer is NOT ‘ONE THREAD.’  If MetroCard had a system that made one connection to each HSM, that was a fiasco waiting to happen.
• I can be brief about this one:  Sure, you can employ a pool of HSMs (see #8 here)…but one HSM alone must be capable of handling your peak volume.  The end. 
• Let me lay out the possibility that MetroCard sized and purchased their HSMs prior to implementing a PCI compliance strategy.  Then, let’s assume that their PCI compliance approach involves touching the HSM once for every debit and credit card transaction for PAN or track decryption.  Let’s also assume that, say, 50% of their transaction mix is online (i.e., PIN-based) debit and the other 50% in credit and offline (i.e., no PIN) debit (in other words, your bank ‘check card’).  Now, instead of touching the HSM once for 50% of all transactions, you’re touching it once (PAN decrypt) for 50% of all transactions, and twice (PAN, then PIN) for the other 50%.  In other words, you just tripled your HSM capacity requirements.  If that’s what happened, and if MetroCard did not re-evaluate their HSM capacity needs in light of this substantially material change in needs, then that’s an oversight of the highest order. 
• In our user interface, we monitor all system components and ‘touch’ each piece occasionally to assess its viability.  If we’re unable to communicate with an HSM – either with a PIN translation, key exchange, or heartbeat – within a one-minute period, then we’re turning the light red on our status screen – which is intently monitored 24x7 in our clients’ operations centers - and throwing warning messages into our ‘syslog.’  Really, two days to notice this?  Two days??
• Note the most outrageous part of the tale – it’s not that the transaction couldn’t reach the HSM, it’s that it took too much time getting to the top of the request queue, by which time the transaction had already timed out at the point of sale.  But, ah, the MetroCard application no doubt steamed ahead blissfully and diligently, sending the transaction to a payment gateway or authorizer.  My friends, you are lacking the single most important piece of a payment switch:  a threshold mechanism.  I feel your pain.  Readers out there everywhere, you need this feature.  Don’t re-live this misery yourself.  The consequences are laid out plainly in this saga.

Cracking down on SAF queue content

My OLS colleague, Dave Bergert, wrote recently about changes to SAF processing on payment switches as a result of evolving and ever-tightening PCI PA-DSS standards.  Dave notes the standard bears down on the storage of sensitive track data “subsequent to the authorization” and that smart people have figured out that this has store and forward (‘SAF’) implications in addition to the more obvious effects on tranlogs, traces and settlement processes.  He noted that one of our gateway providers had stripped Field 35 (Track II) out of its 0400/0420 field set and replaced it with mandatory inclusion of Fields 2 (PAN) and 14 (Expiration Date)…regardless of whether the original transaction was swiped or key-entered.  Dave called this a ‘good trend in the industry’ that he hoped others would continue.

That’s indeed what is happening.  I make note of the fact in the latest FDR North authorization specification, Field 35 has gone missing from the 0400 on the Credit Reversal.  As a result, we had to do some jujitsu to build the appropriate reversal message.  We got dinged in a cert attempt because we populated Field 35 in the SAF request.  The analyst’s exact words in the report were “Please omit.  Track data cannot be stored.”  Well, in fairness to us, it wasn’t a track we had placed there, nor were we in violation of the standards.  The spec had always called for Field 35 and our “copy from original” logic only has access to the PAN and Expiration Date, so we’d create a truncated ‘pseudo-track’ there consisting of “PAN, FS, Exp Date” and no discretionary data.  This approach was a very common and successful technique to bridge the gap between what the endpoints and gateways required on the reversals vs. what we could store per PCI mandates.  With the ‘Strip Out Field 35’ initiative, there’s serious momentum put that all in end-to-end alignment, from origination to endpoint.

[NOTE:  FDR uses the 0400 for its SAF processing on the North platform.  A strict interpretation of the ISO8583 spec should result in using the 0420 for SAF reversals, and the 0400 for the less commonly implemented real-time reversal option, but it’s very typical that that nuance get overlooked.]

[NOTE (2):  At this moment, Field 35 is still in play on FDR North’s Debit and EBT reversals.  This isn’t an oversight:  as a gateway provider, FDR is going to be beholden to the requirements and specifications of the networks to which it, in turn, connects.]

The ‘P’ in ‘TPK’

The advent of PCI-compliant Card Track/PAN encryption schemes at the point-of-sale and the payment switches that support them has brought with it no small amount of confusion, especially with Online Debit and EBT, where two types of encryption are now in flight on all transactions.  There’s one scheme for the PIN, and a second fundamentally different scheme for the Card Track/PAN.  As a result, we get exchanges like this (and these are smart people on all sides, trust me):

Our client – looking to on-board a new POS hardware vendor– sends a communication to the vendor rep and says:

We will be sending your key custodians their respective components for one Terminal Master Key (TMK) and two Base Derivation Keys (BDK-DUKPT).

They get a response back from the vendor that says:

I am filling in for the Key Manager that is currently out on vacation.  I informed him of your intentions to send a TMK along with two BDKs.  He informed me that we do not usually accept TMKs from our customers.

Okay, this is a reasonable misinterpretation.  The guy sees ‘TMK’ and throws up a red flag, thinking we must be using Master Session to encrypt our PINs.  The prevailing standard for PINs is Triple DES DUKPT.  Our client's security guy clarifies with a nice summary of operations and how everything fits:

We use a Thales TRSM to decrypt/encrypt the debit PINs from our stores.  The store PEDs encrypt the PINs with the BDKs we have injected into them.  For credit card processing, we encrypt the credit card data at the PED using our own TPKs, decrypt on our host, and send to [the authorizer].  Our Thales is used to produce the TMK and BDKs that are loaded into the PEDs. These keys are all encrypted using our own Local Master Key (LMK).  The TMK is used to encrypt our TPKs that are sent to the PED’s from our host.

He asked me to follow-up with any further clarification I could add.  I said this:

[You are] absolutely 100% correct.  The TMKs and TPKs have nothing to do with Debit/EBT PIN encryption.  They are used in exactly the manner you describe.  They are thinking of the TMK in its traditional usage of Master Session encryption for PINs.  [You] have re-purposed the TMK/TPK infrastructure to play a part in a PCI-compliant track/PAN encryption scheme.  This brings some additional confusion and concern because the ‘P’ in ‘TPK’ stands for ‘PIN.’  That’s some unfortunate nomenclature.  They are not used for PINs.  Period.  You use a master session scheme for the PAN/track info, and Triple DES BDK-based DUKPT for PINs.

08D7B4

Those are the Check Digits for the notoriously weak double-length key that everyone uses for their test ZMK:

0123456789ABCDEF FEDCBA9876543210

I did a Google search to see if anyone else had posted this number.  Nope.  I own the Weak ZMK Space as of this moment. 

Frankly, the weak key serves a good purpose:  it’s my touchstone to ensure that I’ve not accidentally crossed my test and prod versions of the keys file.  That would be most unfortunate.  As Egon Spengler has duly noted: don’t cross the streams. 

Bridging the gap on HSM testing

We see the transaction mix in the payment processing world moving inexorably towards PIN-based attempts and away from signature-based attempts.  For example, one of our clients is in the process of loading BIN tables (provided and updated by their sponsoring bank) into their store systems - this data allows the POS team to identify those cards which have Online Debit capabilities and prompt for the PIN...no more 'Credit or Debit?' option for those cardholders.  They get steered directly into Online Debit - no alternatives.

For those of us who are in the business of putting together payment solutions with jPOS, that means that dealing with a Hardware Security Module is a reality you will face.  This can be a thorny situation for some of you - suppose you're developing a solution, or doing a Proof of Concept, or doing some local tests in your lab...you're trying to pull something together (usually in a time crunch) for a client or a prospect, but you don't have direct access to the HSM  model that they're using.  It's tough bridging that gap.  It's typical that your budget doesn't allow you to buy one...at least until you get a deal or two under your belt.  Getting one on loan isn't easy.  And connecting directly to the client's HSMs from your lab is always going to be problematic, because those devices are usually embedded in the deepest, safest core of their Intranet scheme, securely ensconced in the innermost ring - what one client of ours calls "The PCI Zone."  Your client or prospect is going to be rightly skeptical of any request along the lines of "Hey, let us connect to your HSM remotely from our lab."  We've fought those battles.  Not fun.

Iain McRobie and I have had some good conversations about this situation.  Many have faced it.  Others will continue to face it.  Iain's a reader of my blog and real subject matter expert - his company 'Encryption Key Management' (aka, 'eK(m)') is the New Zealand-based distributor / reseller of the Thales HSM product range.   I think the Thales HSM  product line is superb - it has really performed great for us in high-volume situations (refer to this previous piece, which in turn refers to a series of other other related pieces - or search my entire blog for 'Thales' references).

Iain is in the process of putting a really great and useful idea into practice.  I'll let him explain it:

---------------
RemoteHSM – eK(m) has developed a remote HSM capability whereby organisations that are new to the use of HSMs are able to utilise this service to remotely access / address an HSM for (Pilot) testing purposes prior to committing to the capital expense associated with acquiring the technology in-house.  This service can also be combined with a Consultancy service where the eK(m) staff can assist in the development and debugging of system code that is used to call the HSMs.
---------------

That's the missing piece that a lot of us in the payment systems development community need to bridge the gap.

The RemoteHSM web site is still under development and will be up shortly.  For more information in the meantime, you can contact Iain directly via e-mail.  

Implementing a Thales HSM 8000 Adapter - PIN Translation

In my blog, I have a lot of posts about the Thales HSM 8000 and how we implemented an adapter for it in OLS.Switch, our jPOS-based payment system.  In two recent posts, I discussed how to use jPOS' FSDMsg facility to implement the Thales command set, and a suggestion on how to start your integration efforts - by implementing the Thales Diagnostic command (the 'NC/ND') as Step One.  I also have a post breaking down the command ('CI/CJ'), the one that does "Single DES BDK to Interchange Key Translation."  [Make sure you read through the comments on that post, too.] 

Recently, we were asked to augment our PIN Translation capabilities in order to support a population of PIN Pads that generate PIN blocks using either Single and Triple DES BDKs.  I mentioned briefly in other posts that there's a separate command to do "Triple DES BDK to Interchange Key Translation" - the G0/G1.  In this particular situation, the devices could only support double-length keys (Triple-length keys are an option when working with Triple DES BDKs), so our keys configuration file was going to have all double-length BDKs.  We couldn't use cryptogram length to signal what's what to our program, so we needed some type of indicator.  So, we came up with the idea of these '1des' and '3des' tags in the file to act as identifiers, like this (where '129908' and '184402' are examples of KSIs - the first six positions of the KSN in this particular implementation...read that Single DES BDK..." post referenced above for more details):

bdk.129908=1des:99BF6A880305B37775AE1E129676E421 bdk.184402=1des:80B7F397139F99A01266394CA96384D9

Then, we have our translatePinblk code in our adapter.  We modified it to handle both key types and generate 'CI' or 'G0' commands (for Single or Triple DES BDK Translation respectively).  Behind the scenes, what makes this code work is the jPOS FSDMsg facility.  We've got the 'CI' and 'G0' structures defined, and that bolded line there fills in the key value (the 'command' field).  You can see that the 'G0' has one extra field in its message format:

public FSDMsg translatePinblk (
String bdk, String zpk, String ksnDescriptor,
String ksn, String pinblk, String accountNumber)
{
boolean threeDesBdk = false;
if (bdk.startsWith ("3des:")) {
threeDesBdk = true;
bdk = bdk.substring(5);
} else if (bdk.startsWith ("1des:")) {
bdk = bdk.substring(5);
}
FSDMsg r = createRequest (threeDesBdk ? "G0" : "CI");
r.set ("bdk-type", "U");
r.set ("bdk", bdk);
r.set ("zpk-type", "U");
r.set ("zpk", zpk);
r.set ("ksn-descriptor", ksnDescriptor);
r.set ("ksn", ksn);
r.set ("pinblk", pinblk);
r.set ("destination-pinblk-format", "01"); // ANSI
r.set ("account-number", accountNumber);
if (threeDesBdk)
r.set ("source-pinblk-format", "01");

return command (r);
}

Now, here are some resulting traces ; I turned on tracing to the test HSM, so you can see all six legs (not presented in order, but you'll get the idea):

• Request from the device
• Request to the Thales (The Single DES example is first, followed by the Triple DES example).
• Response from the Thales
• Request to the Debit/EBT Gateway (the Translated PIN block goes into Field 52 on the outgoing message - the 'FFFFFF' in the middle is a mask applied for tracing purposes only).
• Response from the Debit/EBT Gateway
• Response to the device

<log realm="org.jpos.security.thales.ThalesAdapter" at="Tue Apr 24 16:09:45 EDT 2007.378">
<trace>
<fsdmsg schema='file:cfg/hsm-base'>
command: 'CI'
bdk: '3A796910699174AEEF512C5A489AB008'
zpk-type: 'U'
zpk: 'C6087BAD7B9827F553DDF858709E7030'
ksn-descriptor: '605'
ksn: '0407030000200016'
pinblk: '32D23493EC13C57F'
destination-pinblk-format: '01'
account-number: '777999999901'
</fsdmsg>
request: 'CI3A796910699174AEEF512C5A489AB008UC6087BAD7B9827F553DDF
858709E7030605040703000020001632D23493EC13C57F01777999999901'
response: 'CJ0004D354D87634C043FE01'
elapsed: 156ms
<fsdmsg schema='file:cfg/hsm-resp-base'>
response: 'CJ'
error: '00'
pin-length: '04'
pinblk: 'D354D87634C043FE'
</fsdmsg>
</trace>
</log>
<log realm="Debug" at="Tue Apr 24 16:09:45 EDT 2007.909">
<commit>
<id>9</id>
<context>
<transient>
<entry key="PROFILER">
<profiler>
open [0/0]
parse-request [0/0]
create-debit-tranlog [15/15]
populate-debit-tranlog [16/31]
validate-terminal [16/47]
find-duplicate [15/62]
translate-pin [172/234]
create-fdr-request [16/250]
query-host-or-reverse [453/703]
prepare-debit-response [0/703]
close [62/765]
send-response [0/765]
end [765/765]
</profiler>
</entry>
<entry key="DB">org.jpos.ee.DB@e47e9b</entry>
<entry key="REQUEST">
<fsdmsg schema='file:cfg/v2-base'>
header: '94538660'
record-format: 'G'
application-type: '0'
field-sep-1: '.'
acquirer-bin: '628702'
message-version: '02'
shift-number: '00006'
merchant-number: '0010'
store-number: '01856'
terminal-number: '0001'
category-code: '4444'
country-code: '987'
city-code: '97208'
timezone-differential: '010'
transaction-code: '93'
terminal-serial-number: '12345678'
encryption-indicator: '3'
transaction-sequence-number: '2480'
card-id-source: 'A'
account-entry-mode: 'D'
magnetic-strip-info: '401777______9011=_________________'
cid-device-attached: 'X'
pin-action-code: 'F'
pin-function-code: '0'
pin-length: '00'
pin-block: '00'
encrypted-pin-block: '32D234______C57F'
pin-dukpt-ksn: '040703______0016'
amount: '322'
additional-amount: '0'
register-number: '04'
tran-id: '0000276'
tender-attempt-indicator: '1'
tender-number: '0001'
tender-attempt: '0203'
</fsdmsg>
</entry>
<entry key="switch-key">G.93</entry>
<entry
key="TRANLOG">org.jpos.ee.DebitTranLog@1b98775[id=1987442]</entry>
<entry key="AUDIT">true</entry>
<entry key="MERCHANT">org.jpos.ee.Merchant@46e3f0[id=0010]</entry>
<entry key="TERMINAL">org.jpos.ee.Terminal@1b8be78[id=1]</entry>
<entry key="STORE">org.jpos.ee.Store@72ca69[id=01856]</entry>
<entry key="RESPONSE">
<fsdmsg schema='file:cfg/v2-debit-resp-base'>
header: '94538660'
record-format: '0'
terminal-serial-number: '12345678'
encryption-indicator: '3'
transaction-sequence-number: '2480'
magnetic-strip-info: '401777______9011=_________________'
register-number: '04'
tran-id: '0000276'
tender-attempt-indicator: '1'
tender-number: '0001'
tender-attempt: '0203'
response-code: 'AA'
display-message: 'APPROVAL'
approval-number: '210220'
date: '042407'
capture-date: '042407'
</fsdmsg>
</entry>
</transient>
<persistent>
<entry key="TIMESTAMP">Tue Apr 24 16:09:45 EDT 2007</entry>
<entry key="OUTSTANDING">0</entry>
<entry key="TRANLOG_ID">1987442</entry>
<entry key="CAPTURE_DATE">Tue Apr 24 00:00:00 EDT 2007</entry>
<entry key="ISO_REQUEST">
<isomsg direction="outgoing">
<field id="0" value="0200"/>
<field id="3" value="009000"/>
<field id="4" value="322"/>
<field id="7" value="0424200945"/>
<field id="11" value="003716"/>
<field id="12" value="160945"/>
<field id="13" value="0424"/>
<field id="18" value="5912"/>
<field id="22" value="901"/>
<field id="24" value="001"/>
<field id="25" value="00"/>
<field id="35" value="401777______9011=_________________"/>
<field id="37" value="711401856480"/>
<field id="41" value="00389999"/>
<field id="42" value="000452002888888"/>
<field id="49" value="840"/>
<field id="52" value="D354D8FFFFFF43FE" type="binary"/>
</isomsg>
</entry>
<entry key="ISO_RESPONSE">
<isomsg direction="incoming">
<field id="0" value="0210"/>
<field id="3" value="009000"/>
<field id="4" value="000000000322"/>
<field id="7" value="0424200945"/>
<field id="11" value="003716"/>
<field id="12" value="160945"/>
<field id="13" value="0424"/>
<field id="24" value="001"/>
<field id="25" value="00"/>
<field id="37" value="711401856480"/>
<field id="38" value="210220"/>
<field id="39" value="00"/>
<field id="41" value=" 00389999"/>
<field id="63" value="415050524F56414C2020202020202020" type="binary"/>
</isomsg>
</entry>
<entry key="RC">0000</entry>
</persistent>
</context>
</commit>
</log> <log realm="org.jpos.security.thales.ThalesAdapter" at="Wed Apr 25 09:49:55 EDT 2007.56">
<trace>
<fsdmsg schema='file:cfg/hsm-base'>
command: 'G0'
bdk: 'D76FCCC0AB5F4A74875B39B9ADE6E900'
zpk-type: 'U'
zpk: 'B381A477B49A67C9581DFC81E9CA404C'
ksn-descriptor: '605'
ksn: '3D07040000000003'
pinblk: '661C4571C8A88998'
destination-pinblk-format: '01'
account-number: '765111111111'
source-pinblk-format: '01'
</fsdmsg>
request: 'G0D76FCCC0AB5F4A74875B39B9ADE6E900UB381A477B49A67C9581DFC81E9
CA404C6053D07040000000003661C4571C8A889980101765111111111'
response: 'G1000449FDE47BE6B24C1F01'
elapsed: 94ms
<fsdmsg schema='file:cfg/hsm-resp-base'>
response: 'G1'
error: '00'
pin-length: '04'
pinblk: '49FDE47BE6B24C1F'
</fsdmsg>
</trace>
</log>
<log realm="Debug" at="Wed Apr 25 09:49:55 EDT 2007.369">
<commit>
<id>12</id>
<context>
<transient>
<entry key="PROFILER">
<profiler>
open [0/0]
parse-request [0/0]
create-debit-tranlog [16/16]
populate-debit-tranlog [15/31]
validate-terminal [16/47]
find-duplicate [15/62]
translate-pin [94/156]
create-fdr-request [16/172]
query-host-or-reverse [281/453]
prepare-debit-response [0/453]
close [16/469]
send-response [0/469]
end [469/469]
</profiler>
</entry>
<entry key="DB">org.jpos.ee.DB@10457b4</entry>
<entry key="REQUEST">
<fsdmsg schema='file:cfg/v2-base'>
header: '3F0FD3C0'
record-format: 'G'
application-type: '0'
field-sep-1: '.'
acquirer-bin: '628702'
message-version: '02'
shift-number: '00006'
merchant-number: '0010'
store-number: '01856'
terminal-number: '0001'
category-code: '4444'
country-code: '987'
city-code: '97208'
timezone-differential: '010'
transaction-code: '93'
terminal-serial-number: '12345678'
encryption-indicator: '3'
transaction-sequence-number: '2500'
card-id-source: 'A'
account-entry-mode: 'D'
magnetic-strip-info: '421765______1119=____________________'
cid-device-attached: 'X'
pin-action-code: 'F'
pin-function-code: '0'
pin-length: '00'
pin-block: '00'
encrypted-pin-block: '661C45______8998'
pin-dukpt-ksn: '3D0704______0003'
amount: '2500'
additional-amount: '2000'
register-number: '04'
tran-id: '0000300'
tender-attempt-indicator: '1'
tender-number: '0003'
tender-attempt: '0203'
magnetic-strip-info-encrypted: 'kOGgk2__________________IsD+'
</fsdmsg>
</entry>
<entry key="switch-key">G.93</entry>
<entry
key="TRANLOG">org.jpos.ee.DebitTranLog@1fc68f[id=1987462]</entry>
<entry key="AUDIT">true</entry>
<entry key="MERCHANT">org.jpos.ee.Merchant@1cd36a5[id=0010]</entry>
<entry key="TERMINAL">org.jpos.ee.Terminal@1c914c3[id=1]</entry>
<entry key="STORE">org.jpos.ee.Store@2e0ecb[id=01856]</entry>
<entry key="RESPONSE">
<fsdmsg schema='file:cfg/v2-debit-resp-base'>
header: '3F0FD3C0'
record-format: '0'
terminal-serial-number: '12345678'
encryption-indicator: '3'
transaction-sequence-number: '2500'
magnetic-strip-info: '421765______1119=____________________'
register-number: '04'
tran-id: '0000300'
tender-attempt-indicator: '1'
tender-number: '0003'
tender-attempt: '0203'
response-code: 'AA'
display-message: 'APPROVAL'
approval-number: '312521'
date: '042507'
capture-date: '042507'
</fsdmsg>
</entry>
</transient>
<persistent>
<entry key="TIMESTAMP">Wed Apr 25 09:49:54 EDT 2007</entry>
<entry key="OUTSTANDING">0</entry>
<entry key="TRANLOG_ID">1987462</entry>
<entry key="CAPTURE_DATE">Wed Apr 25 00:00:00 EDT 2007</entry>
<entry key="ISO_REQUEST">
<isomsg direction="outgoing">
<field id="0" value="0200"/>
<field id="3" value="099000"/>
<field id="4" value="2500"/>
<field id="7" value="0425134954"/>
<field id="11" value="003730"/>
<field id="12" value="094954"/>
<field id="13" value="0425"/>
<field id="18" value="5912"/>
<field id="22" value="901"/>
<field id="24" value="001"/>
<field id="25" value="00"/>
<field id="35" value="421765______1119=____________________"/>
<field id="37" value="711501856500"/>
<field id="41" value=" 00389999"/>
<field id="42" value="000452002888888"/>
<field id="49" value="840"/>
<field id="52" value="49FDE4FFFFFF4C1F" type="binary"/>
<field id="54" value="2000"/>
</isomsg>
</entry>
<entry key="ISO_RESPONSE">
<isomsg direction="incoming">
<field id="0" value="0210"/>
<field id="3" value="099000"/>
<field id="4" value="000000002500"/>
<field id="7" value="0425135031"/>
<field id="11" value="003730"/>
<field id="12" value="094954"/>
<field id="13" value="0425"/>
<field id="24" value="001"/>
<field id="25" value="00"/>
<field id="37" value="711501856500"/>
<field id="38" value="312521"/>
<field id="39" value="00"/>
<field id="41" value=" 00389999"/>
<field id="63" value="415050524F56414C2020202020202020" type="binary"/>
</isomsg>
</entry>
<entry key="RC">0000</entry>
</persistent>
</context>
</commit>
</log>