I’ll just say it; I’m proud of our release cycle for OLS.Switch.

It has been my experience (YMMV) both first hand running an authorization host/switch (issuing and acquiring) and as an IT Security Auditor and QSA – that either Core Banking applications or Payment Switches fall into one of the following when it relates to upgrades, changes, or security updates:

• "The Vendor set it up, we don’t touch it"
• "We don’t patch it because we are afraid"
• "We cringe everything we need to install a new release of the software"
• "Last time we did an upgrade, we had x amount of downtime"
• "It all goes smooth like clockwork" 

During Vulnerability Assessments and Penetration Testing on the Internal Networks that I performed– My observations from an operating system, database and application perspective – these systems are typically not keep current or run on a platform that the organization is not very familiar which and relies on outside support. The application was not cohesive to the rest of their operating environment: systems, technologies, and procedures.

Installing new releases of our software (or rather our clients installing releases of new software) is something that does not make me cringe. (and I used to not sleep very well in the past)  At least one of our clients seems to agree as well. (See Andy’s "A very simple platform to support")

We just rolled out a new release that was quite large (see Flexible Spending Accounts (New Initiatives, Part 3) and had changes that impacted pretty much every transaction path due to partial authorization and credit reversal support, and required heavy regression testing. Our agile based SDLC is a big help with this, we have very iterative development processes and frequent testing which also means less large bulking updates that break everything.

Another success factor is our simplicity of upgrading our program code and binaries. It is really as simple as:

• Stop the OLS.Switch Service or Daemon
• create a backup copy of the directory or file path where OLS.Switch is installed
• Start the OLS.Switch Service or Daemon
• Perform test transactions and monitor.
• The Back-Out plan is to stop the service and revert back to the backup copy.

Further, System Implementation Design can have a big impact on Up-time;  we run multiple independent application servers behind load balancers, that allows us to gracefully stop an application – which stops accepting new transactions when finishing to process those in its queue, and the load balancer stops routing transactions to this application server. Allowing an upgrade to be made while other application servers are still processing transactions. Uptime, not system uptime, but uptime processing transactions doesn’t have to suffer for "scheduled maintenance", or security related patches and reboots.

I think we have a low-risk upgrade/update path that our clients are very comfortable with – So in 7 months into the year – we have had a dozen releases to add additional functionality, address endpoint changes, and implement new transaction types.

As I wrote earlier in Credit Card Transactions to be Reported to the IRS – in Foreclose Prevention Act of 2008, This bill was signed into law by President Bush today.

The Electronic Transaction Association (ETA) has a good write up on the Merchant Card Information provisions that are part of the American Housing Rescue and Foreclosure Prevention Act of 2008 (HR3221)

"The major outlines of the requirement are clear: Acquirers must report to the IRS the aggregate dollar amounts of credit and debit card transactions for each merchant that has more than $20,000 in transactions and more than 200 transactions per year. Reporting will have to be done by taxpayer identification number (TIN). In certain cases, acquirers may also have to subject merchants to backup withholding."

See the ETA article here for more info and a summary of the final legislation here.

Looks like the burden of this is mostly on Third Party Processors and Acquring Banks who settle transactions directly with the Card Brands, also note that cards types also include ACH, Paypal. and goes into effect at the end of 2010.

Stratus Technologies, famous for fault tolerant computers, the operating system VOS, and its newer ftServers line that can run Red Hat Enterprise Linux or Windows Server 2003 is giving away a book offer on Fault-Tolerance and/or Virtualization for dummies.  Get your copies here.

Stratus has two Virtualization options one for its hardware, another product is a software solution for commodity boxes.  1) VMWare, using the VMWare Infrastructure 3 on ESX,  2) Avance, which uses Citrix’s Xen and other HA components to build a pair of HA Virtual Servers.

I just launched www.paymentsystemsjobs.com a Payment System Job Board.

If you are a blog reader and payment professional – use www.paymentsystemsjobs.com for job opportunities.

If you are an employer or and would like to post a job opportunity for a payment systems professional please see this link:

For the first 20 Job Posts I’m offering a discount code of 100% off,  This is the coupon code to use: PSB20FREE

In the House Amendments to the Senate Amendment to H.R. 3221 – Foreclosure Prevention Act of 2008

See Page 11 and 12 here:

Payment Card and Third Party Network Information Reporting. The proposal requires
information reporting on payment card and third party network transactions. Payment settlement entities, including merchant acquiring banks and third party settlement organizations, or third party payment facilitators acting on their behalf, will be required to report the annual gross amount of reportable transactions to the IRS and to the participating payee. Reportable transactions include any payment card transaction and any third party network transaction. Participating payees include persons who accept a payment card as payment and third party networks who accept payment from a third party settlement organization in settlement of transactions. A payment card means any card issued pursuant to an agreement or arrangement which provides for standards and mechanisms for settling the transactions. Use of an account number or other indicia associated with a payment card will be treated in the same manner as a payment card. A de minimis exception for transactions of $10,000 or less and 200 transactions or less applies to payments by third party settlement organizations. The proposal applies to returns for calendar years beginning after December 31, 2010. Back-up withholding provisions apply to amounts paid after December 31, 2011. This proposal is estimated to raise $9.802 billion over ten years.

This will be very interesting…    

Some commentary here: