Need an ISO8583 Application Switch for card transactions?
What is ISO8583: ISO 8583 Financial transaction card originated messages — Interchange message specifications is the International Organization for Standardization standard for systems that exchange electronic transactions made by cardholders using payment cards. The first two digits in the ISO8583 message aren't important. However, the next four are what tell us about the type of message we are processing. For more information: http://en.wikipedia.org/wiki/ISO_8583 Using the rule below as a template you should be able to dynamically switch any ISO8583 message to the desired server. See if this helps: when CLIENT_ACCEPTED{ TCP::collect } This section collects the first 6 bytes and then uses 'switch' to find a match. It allows to you decide where to send a request based on its message type. You could also use this to simply log without performing a pool selection. when CLIENT_DATA { log local0. "in CLIENT_DATA" set clientData [TCP::payload 6] log local0. "Client Data raw: $clientData" switch -glob $clientData{ "??0800"{ pool pool_EchoTestMessage log local0. "This is a Network Management Message." } "??0810"{pool pool_ForClientAuthorizations} } TCP::release } when SERVER_CONNECTED { TCP::collect } This section allows you to perform an action base on the message type of the response from the server. You could log the message type or even manipulate it before sending it out. when SERVER_DATA{ set serverData [TCP::payload 6] log local0. "Response Data raw: $serverData" switch -glob $serverData{ "??0810"{ log local0. "This is a Network Management Message." } "??0820"{log local0. "This is type XXX" } } TCP::release }ISO8583 payload interpreter/switch
The previous verion of ISO8583 switch only processed the MTI (Message Type Identifier). This version goes far beyond and dives into the bitmap and payload. What does it do: 1) It reads and interprets the ISO8583 bitmap 2) It calculate the offset based on the fields present in the message With these two points we now have access to the message payload allowing one to pick out client identifier or location information (bits 41 & 42) or anything else you want access to. This information can be used for simple logging, routing or anything else you might be after. The following rule grabs field 63. Being a variable length field, it must retrieve the field length from within the payload before being able to locate the desired field data. when RULE_INIT { Build list of Bitmap Attribute Lengths 'var' represents a variable length field set static::bmAttrLengths [list 64 LL 6 12 12 12 10 8 8 8 6 6 4 4 4 4 4 4 3 3 3 3 3 3 2 2 1 8 8 8 8 LL LL LL LL LLL 12 6 2 3 8 15 40 LL LL LLL LLL LLL 3 3 3 64 16 LLL LLL LLL 12 12 12 LLL LLL LLL LLL 64] } when CLIENT_ACCEPTED { TCP::collect } when CLIENT_DATA { set clientData [TCP::payload] log local0. "Client Data raw: $clientData" Collect the bitmap from the payload - it follows the MTI. binary scan [binary format H* [string range $clientData 6 21]] B* data Start the offset at 22 for MTA & BitMap padding set offset 22 set i 0 while { $i < [string length $data]} { if {[string index $data $i] == 1} { set attr [lindex $static::bmAttrLengths $i] if { $attr == "LL" } { This is a variable length field. The next 2 values in the string tell us how long the field is. set beginData [expr { $offset + 2 }] set endData [expr { $beginData + [scan [string range $clientData $offset [expr { $offset + 1 }]] %d ]}] log local0. "Value for the field length is: [string range $clientData $offset [expr { $offset + 1 }]]" log local0. "Value for the Field is: [string range $clientData $beginData $endData]" } elseif { $attr == "LLL" } { This is a variable length field. The next 3 values in the string tell us how long the field is. set beginData [expr { $offset + 3 }] set endData [expr { $beginData + [scan [string range $clientData $offset [expr { $offset + 2 }]] %d ]}] log local0. "Value for the field length is: [string range $clientData $offset [expr { $offset + 2 }]]" log local0. "Value for the Field is: [string range $clientData $beginData $endData]" } else { We got a 1 in the bitmap - increment the offset. incr offset [lindex $static::bmAttrLengths $i] } } incr i } TCP::release } Tester feedback welcom and encourage - I only have access to an ISO8583 emulator written in python.
newcomer to iso 8583
Hi, we acquired our first bigip this summer and one of our projects has to deal with a customized version of iso 8583. Honestly we don't know where to start to implement parsing of this protocol. Are there implementations or resources we can start with, or any information on this topic you can point us to ? Thank you for helping a beginner ! Alain
ISO 8583 Field Formatting
Hi guys, I am new to ISO 8583. I want to know how to package my response to a Balance enquiry that in addition to the balance value (Field 54), should also show the Earning and Redemption history (if any) I want to package the earning and redemption history in Fields 62 and 63. I want to put the last 5 Earnings and last 5 Redemptions. This fields are designated as ans..999. I am developing this soultion in C (Visual Studio 2012). Any ideas on how i will cram 5 distinct values in either field. I will really appreciate it. Thanks, O. MosetiUptime vs. Service Improvement
The terminology might not be accurate, but let’s think of the people that process credit card transaction authorisations from retailers and check their veracity with the VISAs and MasterCards of the world as Financial Service Providers (FSPs). The basics of this authorisation process work as follows: The Point-of-Sale (PoS) device or commercial website take an end-user’s details and, in some cases using the backend messaging protocol standard ISO8583, request the transaction be authorised. This request goes to the FSP, which in turn – always using the ISO8583 standard – validates the authorisation request with the credit card provider. The FSP isn’t merely a conduit, either – they actually hold business bank accounts that funds are paid into. PoS devices and commercial website authorisation requests clock up at alarmingly high levels. This webpage says that there were, in 2009, c.50 million dial-up PoS transactions PER DAY in the US. For the FSP, then, Quality of Service (QoS) is kind of an important issue. Downtime, dropping transactions, service outages and the like represent really bad news. Which leaves them with a couple of issues when it comes to launching new services, maintenance, upgrades – all things that in themselves are unavoidable for organisations selling infrastructure services. Launching a new service, for instance, might imply all hands on deck as the new service is cut in, just in case the worst happens. This is a scary situation. ‘Call us if it doesn’t work’ is not an acceptable customer relationship stance in the retail environment. The alternative, of course, is to manually craft traffic, but this is still lab testing without real world exposure, which means the situation above still applies at some point. A better option is to clone traffic and do testing in a way that doesn’t threaten QoS. The BIG-IP TMOS platform makes this possible because it’s a full proxy. It copies traffic, forks it off to the test lab and receives, reads and interprets the message so live testing can happen without risk. To understand the importance of this, think about it in terms of how much money is being made by the FSP. Another issue arises when authorisation requests come in. The requests are generally machine-gunned, without intelligence, to a random UNIX server. This ignores the fact that some transactions are more important than others and, in turn, means QoS isn’t being applied to these requests. Just as in the first example, a full proxy platform allows interception, interpretation and intelligent routing of message types, which number in the hundreds. On top of being able to treat some message types differently for commercial reasons, this also allows fault finding and diagnosis. Transactions can be isolated and examined on a per-customer basis, which means you can diagnose faults per customer and therefore apply better QoS. A final point to demonstrate the useful application of full proxy architecture for FSPs: Say there’s an intermittent authorisation problem, and you have a suspect device in the network. TMOS means you can isolate this device, mirroring the traffic so none of it is dropped, but maintaining the flow of traffic to the suspect device until the problem is identified. F5 brings resilience and agility to these situations and more in the FSP space. I’d love to hear of any practical examples you’ve come across.