Making Transactions ‘Fatter’


Shopping cart clip art vector


In the early days, when computer networks and processing power of point-of-sale and payment terminals was limited by then current-technology, the focus was on efficiency. Payment transactions generally only contained a few data elements of data required to process the transaction, and implemented technically in a manner that saved as many bytes as possible.  This was important so all of this would work over a dial-up line and only send required data for transaction processing. Much of the payment message formats are tied to this legacy heritage to this date.

In the world of ‘Big Data’ there is a growing trend of providing fatter transactions, and providing more data in these transactions.  These transactions consist of more then the final amount of the transaction and payment information, but now with market basket data and line item detail.

What does this involve from a payments system perspective ?

1) Expanding message formats and APIs to include list of skus and UPCs and other meta-data of market basket items.

2) Processing against a catalog to perform various value added services and processing.

3) Parallelism in transaction processing as certain items require processing that would take too long if processed in a serial manner.

4) Development of systems including robust engines and processing logic leveraging Machine Learning techniques to mine and process such data.

This isn’t new in concept as it has been performed locally in retailers for sometime now, as well as in some level-3 purchase/commercial cards.  Now there is a trend of more value added services to enhance payment processing such as item based loyalty rewards, when such data is available you have more options and capabilities to enhance the payment transaction.

Is that Transaction Result Code Hard or Soft ?

Soft Decline vs Hard Declines

We were discussing Result Codes (aka. Response Codes) during a call today. We were discussing both “Soft” and “Hard” Declines and the differences of them in the context of reviewing a payment interface and which transactions could be Store-and-Forwarded (‘SAF’).

Result codes are returned in Field or Data Element 39 in an ISO-8583 message.

We use the term “Soft” decline when a subsequent transaction request containing the same pertient information could recieve a different result.

These typically occur from a transient system issue or payment network issue and are  temporary in nature.

Examples of some result codes that come to mind:

  • “19” Re-Enter Transaction
  • “91” Issuer Unavailable or Switch Inoperative
  • “96” System Malfunction or System Error

Hard declines contrast from Soft declines in that on a subsequent transation request, the responses are repeatable; you will recieve the same result.

Idempotent Transactions

We recently were talking a lot about reversals this week in the OLS HQ, especially time-out reversals. Andy even mentioned his ever so famous “Refunds are not Reversals” So I was happy we were talking about reversals and not refunds 😉

Situation: What happens if you send a financial transaction to a payment system and we don’t get a response back? You are obligated to reverse it and keep on trying to reverse it (reversals are normally Store-and-Forwared (SAF) until you get a response back that the reversal was accepted.

You would be surprised how many implementations of payment software do not implement this important step, a disaster of not performing this is duplicate charges to cardholders during system or communication issues. This needs be be implemented in each path of a transaction. Terminal to Gateway, Gateway to Switch, Switch to EndPoint. for example. Many applications get-by, by ignoring reversals on Credit product types where cardholder have large open-to-buys and on Authorization Only Transaction Types. Reversal for Debit and and other financial transaction sets are a must.

On our Switch we handle Reversals with Idempotence. Wikipedia defines this as:

Idempotence ( /ˌaɪdɨmˈpoʊtəns/ eye-dəm-poh-təns) is the property of certain operations in mathematics and computer science, that they can be applied multiple times without changing the result beyond the initial application. The concept of idempotence arises in a number of places in abstract algebra (in particular, in the theory of projectors and closure operators) and functional programming (in which it is connected to the property of referential transparency).

Another website describes the problem as:

Problem: Network and server hardware failure can lead to lost messages, resulting in cases where a service consumer receives no response to its request. Attempts to reissue the request message can lead to unpredictable behavior within the service and the service consumer logic.

Solution : Design service capabilities capable of safely supporting repeated message exchanges.

Our implementation of reversals can handle multiple attempts of a reversal, we only process one but will accept any number of them. This is very important, Reversals are not “approved” or “declined” as the endpoint may or may not need to unwind anything. You as a caller don’t know whether the timeout was actually not processed at all, or if it was processed but you just didn’t get the response back.

We have the following ISO8583 v2003 based result codes in OLS.Switch for this so we can note the difference.

4000 Advice Accepted

4999 Advice Accepted – no Action Taken

That also means your logic is very simple – “send this reversal repeatedly on an interval until I get a response”

Q&A: Some questions on Payment Terminals

From the Mail Bag:

“I have a couple of questions you can help answer. Is it normal for a manufacturer to program POS terminals themselves? I have received contradicting answers to this question. Also, from the terminal, the [encrypted] cardholder information is sent to a processor. Do processors possess unique internet addresses that they give to the merchant to where the terminal can send this information?”

Great questions – let me take a stab at answering them:

“Is it normal for a manufacturer to program POS terminals themselves?”

It really depends – There are two models in play here, a) you can pay a terminal manufacture to development a terminal application, b) terminal manufactures also generally will sell SDKs, Software Development Kits, as well as required or optional training courses for independent developers to write payment applications for. From my personal experience, we have worked with both terminal manufactures as well as independent developers, as well as wrote very few in house.

” Also, from the terminal, the [encrypted] cardholder information is sent to a processor. “

This is true in certain situations and depending on the application, terminal, and communication methods. Most dial terminals send cardholder information in the clear across a private dial line. Many IP/SSL terminals will just use SSL encryption as a transport mechanism for encryption/security. More recent generation of terminals and those that implement End-to-End Encryption (E2EE) or Point-to-Point Encryption will use both a data level and transport level encryption/security. Our message specifications and when we can enforce it, we always try to use tokenization, or surrogate numbers for subsequent transactions (Refunds, Captures, Voids, Reversals, – do not require the full PAN to be passed in many of our systems that we develop)

“Do processors possess unique internet addresses that they give to the merchant to where the terminal can send this information?””

Payment Processors and/or payment gateways will provide either dial 800 numbers for dial payment terminals or an IP address or https/SSL based URL for IP/SSL based terminals to send transaction data. OLS has integrates to various dial concentrator devices/networks – Hypercom NAC, TNS, HB.Net, now Phoenix Managed Networks, for Dial delivery. We have developed our own secure SSL Transaction Servers with various interface options for our customers, IP SSL Sockets, HTTPS Post, RESTful as well as SOAP based web services.

Q&A: What is the difference between a Cash Dispersement or a Cash WithDrawal Transaction

Q & A Time from the mailbag:

Scott Asks:

In MasterCard, transactions Cash Disbursement and Withdrawal are regarded as two different transactions (They have different transaction type codes). What are the differences between these two transactions? What are their individual usage scenario ? “

Great question, A cash withdrawal is generally associated to a ATM or Debit Transaction where the full transaction amount can be immediately debited by the Card Issuer and Cash Provided to the Card Holder. While a Cash Disbursement transaction is generally something a Card Holder can request at a financial institution that he may not have a relationship with – Think of a cash advance of your Visa or MC card at a Bank, or if you have prepaid card or payroll card that you need to get money or cash from at a credit union that you don’t have an account with.

SSL / VPN / Direct Connection connecivity options

I came across this exchange discussing connectivity when reviewing some specifications for an interface that we are writing:

“Since both companies will utilize web services for the exchange of information, it is proposed that we use SSL instead of a VPN or Direct connection. SSL (https over port 443) provides security by encrypting the communications channel. This arrangement provides all the security of a VPN or Direct connection. Plus it requires less network configuration, less maintenance, greater flexibility (in case platforms move on either end) and eliminates a VPN or direct connection as a potential point of failure.”

I have a lot of problems with this.

1) Encryption isn’t security.

2) I find it hard to dispute that: Direct Connection > VPN > SSL over internet from a general security perspective.

3) SSL used in this manner lacks authentication, compared to a IP SEC point-to-point VPN (AH/ESP)

4) Exposing a web server to the internet introduces the risk of web server vulnerabilities, application layer vulnerabilities, among others ever more recent SSL vulnerabilities[1]. (Note that source based ACL’s are not recommend here either, nor are client side certificates for authentication)

5) The concept of “least privilege” from a networking perspective is not followed – only two parties need to talk to each other, why open it up to the world to attempt to connect to ? Another interface stated “We restrict all traffic by third party connections to the least access needed to support business. ” <– I like this much better.

6) SSL over the internet will require our customer to expose a secure internal system to the internet, when it was designed to have very controlled network access, as compared to a VPN and general firewall rules for network control.

7) I haven’t discussed direct connections or leased lines, mostly due to the nature and volume of this application. Normally this is our first choice for high volume, sensitive transaction data to third parties with multiple data centers. Where we use 2 leased lines on different carriers to different data-centers.

My Vote for this? SSL over a VPN – (Defense in depth) Could SSL be used ? Sure but we would need to add a list of controls around its implementation and quite possibly add a layer of applications (proxy the requests) to design around this which is more work and has a higher change of configuration failure then a standard site-to-site VPN connection.


Whats the difference between Current and Available Balance ?

Andy and I were having a conversation with a group that we are working with on a new project.  When discussing integration to our API, transactional sets and fields within them. One of them asked the following question:

In the Balance Response message that you send us, can you tell me the difference between the “AvailableBalance” field and the “CurrentBalance” field?


Our response:


Current balance is the real, financial balance.
Available balance is the current balance minus any holds.
On the open loop side…
An auth does a hold – it affects only available.

A completion releases the hold and decrements both the available and current by the final transaction amount.




Sometimes you don’t get to define the requirements, they sometimes appear to serve a higher purpose that you can’t begin to understand. All you know is that they are requirements, and there were decisions made for various reasons. Sometimes you have to play the cards that you are dealt. But it is still your choice in how to play them.

I’m talking about message formats here, In a specific transaction processing system there are two requirements that we must adhere to:

  1. Accept a 8,000 – 10,000 bytes incoming fixed message format.
  2. Log the Raw Message Request and Responses for all interface connections

Regarding #1 I’d prefer to see a variable message format here instead, but I understand the need of an existing system to talk in the language this it is used to. Item #2 had me very concerned when I first heard of it, with my PCI background, I was ready to put my foot down and call people crazy – (Imagining the request to log raw messages that contained track data, pin blocks, card verification numbers)  To my surprise this was not for a financial transaction processing system but for one of a different purpose.  One that exists in a highly regulated word with data retention requirements and the need integrity of the raw transaction messages for compliance and legal reasons.

The challenge I had logging the raw messages where their sheer size – 10K and when you are looking at 4-6 legs of a transaction – client request, client response, endpoint request, endpoint response, and other transaction paths that sometimes seem recursive, we have 50K of logging for a single transaction – times 3 to 5 million transactions per day – that is 150 GB to 250 GB per day of logging !

The easiest solution was to look into compression – how much time would compressing the data stream before logging it take ? Would this impact transaction processing time ? How was the raw messages used ? If we compress the message, what needs to occur on applications on the other end, what language and platform are they written in, what is a portable algorithm ?

It turns out the these messages contains many repeating unused fields with default values – these compress very well:




Enter gzip – On our platform Java’s GZipInputStream and for our clients tools the .NET GZipStream.

How did this work out ?


raw_size    comp_size   Compression %
3975        393         90.1    
10599       484         95.4


How much disk storage and SAN space and upgrades were saved 😉 Priceless.


Swiping the Card at a Customer’s location



I had the opportunity recently to visit one of our OLS.Switch customer’s retail locations. This particular customer doesn’t have a presence in the region that I work in, so I was very excited to Swipe my Card.  Probably too excited, actually, because I think I explained every line of the receipt, including the myriad of transactions that occurred, the number of message formats, transaction types, database entities, application logic, and network connections to various internal and external endpoints to my wife, who after twenty minutes didn’t share the same level of enthusiasm that I maintained throughout the conversation.

It is always fun to know what happens “inside the box” and that which seems magical to others. When I started my career at a small Third party processor this exercise was quite common, after we did system maintenance in the middle of the early morning, we would drive to the nearest corner store or gas station to test our issuing systems and connections via performing transactions on cards that we issued for.  We even got to reward ourselves with transaction amounts over $25, as we couldn’t allow Stand-In-Processing to approve these transactions, we wanted to ensure that our Issuing system authorized these transactions.

It is even more exciting to have taken part in the design, development and implementation of a given transaction. The exhilaration continues when you realize that I’m only 1 of about 5 million transactions per day that our software powers here.

Let’s do a walkthrough of the transaction that I performed:

Cashier:  Hi, Welcome. Are you enrolled in our ________ rewards program ?

Me: Yes, I don’t have my card – can you lookup by phone number ? 

Cashier:  Sure  <Enters in number that I provide>

Transaction #1 : Loyalty Card Lookup based on Phone Number also includes my point balance, level

Cashier: Can you confirm your address ?,great, that’s you. Your total is $ xx.xx , Debit or Credit ?

Me:  <Swipes my Mastercard >

Transaction #2 : Transaction Market Basket Analysis, Discount calculation, interfacing to an Offering Engine, Serializing of Coupons to print on receipt for future usage and coupon validation requests.

Transaction #3 : Credit Card Authorization

Cashier: Thank you very much for shopping at _______, By using your _________ card you saved $ x.xx, Hope you have a nice day.

Me: Thank you and running outside to share the exiting world of transaction processing to my wife.


The 20 mintues that followed including me discussing the following.

  • The finer points of Loyalty Card Lookups, including how to return a list of cards, and how to address multiple requests as the cashier scrolls to fetch the next batch of card numbers for folks with common names, the challenges of either cardholders or cashiers using common phone numbers.
  • Card Type and BIN Based Routing to external endpoints and message translation from one interface to another
  • Sending large transaction requests with detailed shopping cart detail.
  • Algorithms to generate coupon numbers that are difficult to be abused by coupon generation scripts.
  • Substitution logic and the template engine to display various messages and transaction variable on to cashier receipts.
  • The various batch jobs and processes that are ran to import, extract various data to support the processes.


Just another day in the life of payment application software developer.