Andy Orrock | Payment Systems

The Light –> Heavy Spectrum

More thoughts on the Light Switch, Heavy Switch thing – when I think about categorizing our project efforts to date, I see there’s a spectrum of possible payment switch implementations over which we operate:

Lightest Implementation…

• XML-based transaction acceptance
• “Bridge” to real-time, PIN-less authorization link to gateway or issuer
• Endpoint Channel Management
• Endpoint Network Message Management

Heaviest Implementation…

The ‘lightest’ components, plus…

• Transaction acceptance from multiple, custom origination points
• Integration of customer’s PCI-compliant cardholder data encryption strategy
• Duplicate checking
• Custom reversal/original match-up logic
• Three-level (merchant, store, terminal) validation
• Merchant External Identifier and Terminal External Identifier mapping for multiple endpoints
• SQL-based tranlog with PABP-compliant logging features
• Hardware Security Module (‘HSM’) interface
• Dynamic Key Exchange
• PIN-enabled authorization link
• Extract and formatting for external settlement
• Custom reports
• Application health monitoring and transaction visibility via a UI
• Advanced Project Management  (e.g., managing telco tasks)

We can place our OLS.Switch clients anywhere along the Light –> Heavy spectrum, depending upon their business models and specific project needs. 

We’ve focused on building and refining a repeatable, efficient process for on-boarding institution-to-institution payment switch endpoints.  By implementing these ‘host-to-host’ gateways, organizations can take advantage of lower per-transaction pricing options from processors.  In our stable of built interfaces, we have:

• American Express
• Discover
• ELAN Financial Services
• FDR North (Debit, EBT, Credit, Prepaid, FSA, Check Authorization)
• FDR Omaha
• Fifth Third
• Green Dot
• Incomm
• MasterCard
• Stored Value Systems (‘SVS’)
• Verizon
• Visa

We’ve also got specs in-house for a number of other interfaces, and are only awaiting the opportunity from a client to roll out an implementation.

"A very simple platform to support"

As I’ve mentioned in previous posts, key contributions and ongoing involvement by our clients’ core application support, DBA, telecom and SysAdmin teams are instrumental in our successes to date.  We’re grateful for their support and enthusiasm.  I had an interesting dialogue last week with the very smart and capable guy who heads up the Tech Services group at one of our OLS.Switch payment switch client sites.  Economic times being what they are, there were some, how to say, involuntary personnel moves there.  The result:  we ‘lost’ our main SysAdmin contact.  But the manager’s take on our application and his training plan is worthy of note for payment systems managers:

We can start with [another guy in the group] and we will get everyone up to speed. Honestly it is a very simple platform to support compared to the [legacy platform].

Wow, that’s basically our whole business proposition expressed in two, short sentences.  I responded:

Thanks, I consider that a compliment!  You’re right:  it is very simple because it leverages standard Microsoft Windows support practices.  It requires no specialized knowledge.

They are a Windows shop, so OLS.Switch there runs on Windows Advanced Server 2003 in conjunction with MS SQL Server 2005.  His response to that:

Exactly!  FYI – If it were Linux it would be no different. We are solid there too.

Agreed.  Thanks to OLS.Switch’s jPOS underpinnings, we can deploy readily on anything with a JVM and an RDBMS.  The operational efficiencies there would be similar. 

Some short takeaways here:

• Unsolicited affirmation from a key client of our support advantages: no esoteric knowledge required like there is on legacy payment system platforms.
• If you can do administrative support of a Windows (or Linux) environment, you can support our stuff.
• The client chooses the operating platform that plays to its enterprise strengths; no platform mandates from us. 

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.]

Amounts and Reversals and Voids (continued)

Yesterday, I wrote about partial authorizations in OLS.Switch and how we populate ‘originalAmount’ and ‘amount’ columns in various scenarios.  I actually ended up re-posting it late last night when I realized I’d left out some key pieces.  In an effort to further clarify things, I made a quick table that reviews each of the cases in play. 

Over the next coming months, we’ll extend our partial auth coverage to all supported credit card brands.  Each of the four big credit card players is getting heavily into the pre-paid market now.  We can increase our clients’ POS acceptance rates on these vehicles considerably via partial auth.  [The caveat is that you’ve got to have a good partner on the store system side (at any point of origination, for that matter) who can initiate and see through split-tender scenarios.]  We started in the FSA corner because partial auth is pretty much a mandate if you’re accepting FSA cards.  So, FSA means partial auth, and partial auth means online reversals of credit card auth requests.  Sometimes there are reversals of partial authorizations.  This nuance is reflected on my little table. 

And to clarify some confusion, a full reversal of a partial auth is not a partial reversal.  A partial reversal is a different animal entirely. 

Amounts and Reversals and Voids. Oh, my.

With our upcoming installation (fingers crossed) of Flexible Spending Account (‘FSA’) functionality at one of our OLS.Switch client sites, we’ve implemented a new tranlog column called ‘originalAmount’.  FSA is joined at the hip to partial authorization and real-time credit reversals.  We’ve implemented partial auth before for our Stored Value Systems (‘SVS’) interfaces, but we were more ad-hoc about that.  Now, with the advent of FSA and the overall partial auth focus in the payment switch industry, we’re taking a more permanent approach on this thing.

I summarized the key points to our flagship client like this:

1. The originalAmount column will always get populated with the incoming <amount> field from the incoming store request – this is true for all financial applications (Debit, EBT, all Credit, all SVC and Check)
2. For all financial requests except sales/purchases authorized by Stored Value Systems (‘SVS’) and FSA transaction originals (i.e., not reversals) authorized through FDR North, partial auths are not in play.  The incoming <amount> field is also placed into the amount column. 
3. For SVS-authorized sales/purchase requests and FSA sales/purchase requests authorized by FDR North, partial auths are in play.  The amount authorized – as returned from the endpoint in the ISO8583 response – is placed into the amount column. [NOTE:  Though we support SVS partial auths today, we currently retain no evidence of the original request amount on the tranlog.]
4. For FSA voids, the incoming <amount> on the store’s request reflects the authorized amount of the corresponding original.  To be safe, we pluck the amount to reverse from the amount column of the corresponding original and use that to populate the reversal.  Unlike ‘basic’ credit, FSA terminal voids and reversals must be sent to FDR North via Store and Forward (‘SAF’) processing.
5. For FSA timeout reversals (at the terminal), the device is not aware of any partial auth that might have occurred, so the incoming reversal request has the amount originally requested.  That’s what ends up in the originalAmount column of the reversal.  The amount column of the reversal will contain the amount we pluck from the same column in the corresponding original.
6. The FDR North switch interface does not support Host timeout reversals of Credit (which includes FSA).
7. SVS voids and terminal timeout reversals are not implemented by the store system.
8. The SVS switch interface does support Host timeout reversals. 

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.

No Circuit Diversity = SPOF

The death blow of any mission-critical payment switch is a SPOF.  There are the obvious ones – like relying on one application server with no architected high availability or fault tolerance built into the design.  There are also some unobvious factors, like a lack of circuit diversity.  I’ll pass along some lessons learned over the past week. 

We urge our OLS.Switch clients to take a number of steps to maximize the up-time of their payment switch implementations.  These include:

• Replicated application nodes with connections to all endpoints from each node (establish this need early with your authorizers)
• Content Service Switch (‘CSS’) – aka a “load balancer” - fronting the nodes (and taking this to its logical conclusion, you want two of these)
• Virtual DB clusters
• OLS.Switch DB schema on a SAN
• QMUX configuration with two or more channels in the MUX definition connecting to physically separate lines
• The two lines provisioned by separate carriers – this practice is called ‘circuit diversity’…no sensitivity training required! Hey, it even has its own research initiative. 
• HSRP built into the authorizer connections

Furthermore, we appreciate authorizer/endpoints that offer geographical diversity in their data centers, like in AMEX’s nice configuration where one connection goes to Phoenix (their ‘IPC’) and one to Greensboro, NC (their ‘NROC’).  You have little control over this from your side, but I like to put this on the table early in planning meetings.  If the authorizer doesn’t do it, we go on the record as comparing them to their peers and noting their shortcomings vs. best practices.

You can do all that and still get bitten by an unforeseen SPOF.  Earlier this week, one of our clients got it, big-time.  That ‘circuit diversity’ initiative referenced above?  It states in part that “Manual assessment and periodic manual assurance are required to ensure that circuits are diverse and remain diverse over time.”  Man, no truer words were ever written.  One authorizer had what it thought was a dual-carrier approach, only to find out that both lines traced through the same CO.  When the CO tanked, so did 100% of the point-of-sale authorizations serviced by that endpoint…to the tune of > $1M USD in lost sales.  “Ouch” doesn’t do that justice.  Now, our client’s excellent network team is working aggressively with this endpoint to engineer the SPOF out of the path.

I write here to prevent you from having similar problems.  Question your authorizers very carefully about their circuit diversity.  Don’t take the words for proof – ask them to demonstrate via manual assessment that the circuits are indeed diverse.

 

Adding timeout, keep-alive properties to your channel

I’ve written in the past about some of the operational improvements we’ve made in our QMUX configurations over time.  As a prime example, we’ve had two situations where an authorizer’s tight disconnect model has forced us to go with a MUX Pool approach.  Now here recently, we’ve been presented with another ‘opportunity’ for improvement.  Specifically, we’ve wanted to address a situation seen in production at a client site where our connections to Stored Value Systems (‘SVS’) channels disconnected, then got into a hung state after reconnect.  The status lights stayed green and transactions repeatedly timed-out over the impacted channel.  [NOTE:  SVS is a really good service provider; the issue here was on our end, so it makes for a good, real-life example.]

Alejandro advised us to implement a property value that will set a socket-level timeout.  The ‘receive’ function in the multiplexer’s ‘Channel Adapter’ will fail (with log event ‘<io_timeout>’) if nothing is received within the specified timeout period.  The channel will disconnect and then attempt a reconnection. 

While you can apply these property values to any QMUX channel, we had to take some special care for this one because of the MUX Pool considerations.  The specified value of the <timeout> property should be greater than the related <echo-interval> specified in the related logon manager.  SVS features a tight (3 minutes 30 seconds) disconnect model, leading us to have to implement the ‘MUX pool’ approach with aggressive echo intervals (180000 ms, or three minutes).  The timeout property value specified needs to provide breathing space to allow the echoes to operate in their intended fashion.  An appropriate value is 300000 (five minutes).  Since the MUX pool forces an echo on each channel in the SVS MUX every three minutes, not getting ‘receive’ activity in five minutes raises the possibility of a ‘hung’ line.  Accordingly, we put the channel through a disconnect/reconnect cycle as a proactive measure.

The final result:  our channel configuration now looks like this – see new lines in bold, red (NOTE: I’ve obfuscated the ‘host’ value here):

<channel-adaptor name='svs'
    class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
<channel class="org.jpos.iso.channel.NACChannel" logger="Q2"
       realm="svs-channel"
       packager="org.jpos.iso.packager.GenericPackager">
  <property name="packager-config" value="cfg/svs.xml" />
  <property name="host" value="299.999.999.999" />
  <property name="port" value="24110" />
  <property name="timeout" value="300000" />
  <property name="keep-alive" value="true" /> 
</channel>
<in>svs-send</in>
<out>svs-receive</out>
<reconnect-delay>10000</reconnect-delay>
</channel-adaptor>

For the record, the corresponding Logon Manager configuration – which remains unchanged in this exercise – looks like this:

<svs-logon-mgr class="org.jpos.svs.LogonManager" logger="Q2">
<property name="persistent-space" value="jdbm:svslogon:log/svslogon" />
<property name="mux"            value="svs-mux-0" />
<property name="channel-ready"  value="svs.ready" />
<property name="timeout"        value="900000" />
<property name="echo-interval"  value="180000" />
<property name="logon-interval" value="43200000" />
</svs-logon-mgr>

Flexible Spending Accounts (New Initiatives, Part 3)

We’re going through the steps right now to certify our OLS.Switch payment switch (on the acquirer side) regarding its ability to support Flexible Spending Accounts (‘FSA’).  This post is Part 3 in my ‘New Initiatives’ series.  The goal of these posts is to show how OLS.Switch’s make-up (most notably its jPOS-based transaction processing framework) facilitates the consideration and on-boarding of new payment initiatives.  As usual, the Good Switch, Bad Switch caveat is in place: jPOS is not a panacea, as even its esteemed creator (btw, he’s in the lower, right-hand corner here, a screen capture from his CNN appearance) will acknowledge…with the wrong team, a craptastic outcome is within reach.  With the right team, you can make magic happen.

FSA installation is, however, the classic ‘slippery slope’ situation – the dominoes start toppling here pretty quickly: your core FSA work leads you partial authorization.  You’re obligated to handle those in the FSA world.  And, in turn, partial auth means you’ve got to start handling credit reversals online, i.e., you’ve got to SAF the 0400 or 0420 reversal to the endpoint.  In most implementations I encounter, Debit/EBT reversals are SAF-able (btw, I never used ‘SAF’ as a verb until I met The Gladiators…they’ve turned me), but credit reversals “stay local” and – as I am wont to say – everything washes out in the settlement.  Moreover, the SAF-ed credit reversals in our situation look and behave differently than the Debit/EBT reversals.  That’s a subject for an upcoming post, which I’ll definitely entitle “All Reversals Are Not Created Equally.”  But, for now, here’s a summary of the work we did to prep for FSA certification…

[NOTE: Remote auth here is performed on the FDR North platform.  Some details here are masked.]

Core FSA

1. Add base support for the store system’s new FSA transaction set (x.xx through x.yy comprises sales, returns, plus associated voids and reversals; x.zz – Balance Inquiry – not implemented at POS or tested by OLS).
2. Add support for x.xx through x.yy to main TransactionManager.
3. Parse ‘flex-info’ and place in new column ‘flexInfo’.
4. Make FSA cards card type “FS” (card brands remain unaffected).
5. Adjust in-place model for FDR North Field 63, Table 14 (now populated differently for FSA vs. non-FSA).
6. Add new routine to populate FDR North Field 63, Table 68 for FSA cards.  Of special note:  Parser to pluck the Total Rx amount out of <flex-info> and use it to populate the ‘4S’ amount on the outgoing request.
7. Build FSA response to device using Gift Card model (approved amount and balances); special attention paid to duplicate approvals; new ‘balance map’ to extract balance (if present) from Field 63, Table 68 of response.
8. ALWAYS lock out manager overrides on all FSA transaction responses.
9. Modify populating of FDR’s ‘XD05’ record (PTS) for approved FSA transactions that are Visa branded.
10. Add new routine to build FDR PTS Special Condition (‘S’) record for approved FSA transactions that are MC branded.
11. Add support for card type ‘FS’ to internal reports – backbone report handlers now have to treat ‘CR’ & ‘FS’ report handlers in the same vein.  On the “real” extract side, these new transactions get extracted - without change - by FDRExtractHandler.  On the internal report side, you can drive the decision as to whether these get extracted as part of the Current XXXExtractDSMCVI or broken out into a separate report.
12. Related UI changes – add recognition of FSA transaction types; add support for visibility of originalAmount and flexInfo columns.

Partial Auth

1. Put ‘amount’ from request in ‘originalAmount’ column (new).
2. Put approved amount from FDR gateway in ‘amount’ column (right now, do this for FSA transactions only).
3. For Online Credit Reversal (see next), need to grab ‘amount’ from tranlog of original (in Timeout Reversal scenario, the device does not know a partial auth was consummated) and use it populate Field 4 of outbound ISO request (which, in turn, will end up as the ‘amount’ on the tranlog – see previous bullet).
4. In new FDR North Field 63, Table 68, make note that we can accept partial approvals on these FSA transactions.
5. Recognize and treat FDR North Remote Response Code ‘10’ as Approval.
6. Inform store system of Approved Amount on all FSA responses.

Online Credit Reversal

1. If original is found, then TransactionManager needs to do real-time Credit reversal.  Make TransactionManager changes to support that.  [NOTE: Sale only; Return is handled locally, like it is today.]
   Add SAF support in FSA Void and FSA timeout reversal.  [NOTE: Sale only; Return is handled locally, like it is today.]
2. Need to populate Fields 38 (Approval Number) and 39 (Remote Response Code) from tranlog of original.  [Differs from FDR North’s Debit/EBT reversal model.]
3. Add additional logic to not SAF sale reversal or void if original was a Manager Override (supposed to be locked out of doing this, but this is prevent defense).
4. Adjust in-place model for FDR North Field 63, Table 14 (now populated differently for original vs. reversal – needs amounts, BankNet or PS/2000 info from the original).

jPOS Runs Your Peaks

July 3rd brought another surge in pre-holiday buying at our flagship OLS.Switch client location.  We hit 1,087,254 transactions, supporting US residents from coast to coast in efforts to stock up on goods for their Independence Day BBQ.  Granted, these US festivities pale in comparison to the Uruguayan BBQ, the world’s league table leader.  But we get by.  And OLS.Switch is there to serve, fueled by the underpinnings of the super-efficient jPOS payment processing framework.  I think this was the 2nd highest day.  December 24, 2007 still holds the trophy, and probably will until the same day later this year. 

Some guy asked us the other day about our “scaling strategy.”  My straight answer was: 

First, two moderate sized servers (one application, one DB) will easily support millions of transaction a day, or > 300 TPS in our tests. [NOTE: These results may vary depending upon speed and capacity of external authorizers.] However, in our configuration we use additional machines for achieving high availability levels. We use also load balancer technology to allow us to replicate and extend application server capacity; on the database side, we use clustering. We also have the ability to split processing and provide multiple instances of the environment.

My flip answer is that we do more than a million transactions a day on $28,000 worth of core server technology…purchased over two years ago, mind you, so less than $14,000 for the same firepower today.  We never average more than 25% CPU on the application servers, and less than 5% on the primary DB (in the virtual cluster) machine.  This is one of the country’s biggest retailers.  So, for the majority of acquirers out there, scalability concerns are simply not on the table.    Find other things to worry about.  My blog shows there’s plenty else to weigh on your mind.

My one caveat is the Good Switch, Bad Switch warning:  You do have it in your power as a manager to assemble a crappy, ill-suited team.   In which case, jPOS is no magic elixir.  We know of software vendors who implemented solutions where the client found out later – much to their shock – that it was incapable of doing more than one transaction at a time.  We know because we took the panicky phone call from the manager looking for a bailout.

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. 

Even more on QMUX configurations

The jPOS QMUX feature forms the backbone of OLS.Switch’s remote authorization infrastructure.  I talk about QMUX configuration models in my On-Boarding Guide.  I’ve also blogged about how tight disconnect models can lead you to consider a sub-species of the QMUX model called the MUX Pool.  We make use of that in our connectivity to Stored Value Systems (‘SVS’), a good provider of branded gift card services and a very reliable authorizer.  They use a wicked tight disconnect model:  3 mins 30 secs or so of no traffic raises a peer disconnect on their end.  It’s a good, proactive approach.  What I liked about the conversation with SVS is that they could clearly articulate their approach.  By comparison, we’ve had some frustrations with organizations who can’t describe or only hazily describe what the connection model will be like in production…especially with our replicated application node strategy in play at our client locations.

QMUX has proven to be extraordinarily resilient and efficient in the face of large authorization transaction volumes.  Lines go up, down, up, down…QMUX does the channel management with great skill.  However, we did see a recent situation where an SVS line got in a hang-up situation for a number of hours.  We had the line marked as a connected.  QMUX kept the channel in the mix (only one of the two active connections was affected).  Yet, transaction after transaction timed out because neither we nor SVS saw the line as being disconnected or in any type of situation requiring some type of programmatic reset. 

I reviewed the scenario with Alejandro.  He suggested that what we need to do is to add ‘timeout’ and ‘keep-alive’ properties to SVS channel definitions. The timeout value will set a socket-level timeout.  The ‘receive’ function in the multiplexer’s ‘Channel Adapter’ will fail (with log event ‘<io_timeout>’) if nothing is received within the specified timeout period.  The channel will disconnect and then attempt a reconnection.

The specified value of the <timeout> property should be greater than the related <echo-interval> specified in the related logon manager.  SVS features a tight (3 minutes 30 seconds) disconnect model, leading us to have to implement the ‘MUX pool’ approach with aggressive echo intervals (180000 ms, or three minutes).  The timeout property value specified needs to provide breathing space to allow the echoes to operate in their intended fashion.  An appropriate value is 300000 (five minutes).  Since the MUX pool forces an echo on each channel in the SVS MUX every three minutes, not getting ‘receive’ activity in five minutes raises the possibility of a ‘hung’ line.  Accordingly, we put the channel through a disconnect/reconnect cycle as a proactive measure.

What we end up with is a Logon Manager (one per defined channel in the Mux) that looks like this…

<svs-logon-mgr class="org.jpos.svs.LogonManager" logger="Q2">
<property name="persistent-space" value="jdbm:svslogon:log/svslogon" />
<property name="mux"            value="svs-mux-0" />
<property name="channel-ready"  value="svs.ready" />
<property name="timeout"        value="900000" />
<property name="echo-interval"  value="180000" />
<property name="logon-interval" value="43200000" />
</svs-logon-mgr>

…and a Channel Manager (one per defined channel in the Mux) that looks like this (“host” and “port” values are examples only):

<channel-adaptor name='svs'
    class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
<channel class="org.jpos.iso.channel.NACChannel" logger="Q2"
       realm="svs-channel"
       packager="org.jpos.iso.packager.GenericPackager">
  <property name="packager-config" value="cfg/svs.xml" />
  <property name="host" value="127.0.0.1" />
  <property name="port" value="36000" />
  <property name="timeout" value="300000" />
  <property name="keep-alive" value="true" /> 
</channel>
<in>svs-send</in>
<out>svs-receive</out>
<reconnect-delay>10000</reconnect-delay>
</channel-adaptor>