ISO8583 Starting Points

A lot of readers come to my blog as a result of doing searches like "ISO8583 download" or "ISO8583 XML Schema."  That's understandable since ISO8583 is the 'lingua franca' of payment systems.  And, as I've mentioned many times, facilitating the implementation of ISO8583 is the original challenge that sent Alejandro along the path to his jPOS vision and its increasing success and market acceptance. 

Yesterday, a had a nice chat online with a work friend, Vipul.  The two of us just concluded a successful payment system project (my client's system is now 'talking' to his company, which provides stored value authorization services).  Now, Vipul is interested in doing a 'deeper dive' into ISO8583.  He asked for some recommendations.  I'll recap them here:

• You can buy a copy of the spec from ISO here, but you can see that it's a pretty steep price.  [This document is a good luxury to have in your possession.  But, it's not essential to your ability to learn the standard.]
• Alejandro's key document - the jPOS Programmers' Guide - has an outstanding nine-page 'primer' on ISO8583.  Even if you're not a programmer, if you want to know ISO8583, you've got to read his write-up because - better than any official doc - he gets to the essence of the thing and how to construct and deconstruct messages.  If you're serious about learning, then the Guide is something you need to have for your reference.  So, please - Do the Needful and make this excellent investment.  And, even if you're not a Java programmer, its still a good reference.
• Some of you seek to tackle ISO8583 in a way in which you separate yourself from a deep-dive into the standard.  This is the reason for the "ISO8583 XML Schema" searches.  Your best path to success there is to consider the jPOS 'ISOBridge' offering.
• Those of you who like what they see in jPOS but are a C shop, not a Java shop, ought to consider Alejandro's ISO8583 C Lightweight Library.
• I think this is my best post on ISO8583 and Getting Things Done in jPOS - its called Implementing the jPOS Packager.   I go step-by-step on how you take someone's ISO8583-based auth interface spec (AMEX in my example) and translate that into an implementable model.

My key point is always that the best single thing you can do is to study how other institutions have implemented their ISO8583-based auth interfaces - in the right-hand column here in my blog, you'll see references as to how to obtain the AMEX and FDR specs.  In both cases, you have to go through a short registration process, but it's free and there's no commitment.  These are much better references for you than the standards doc.  It's a tough leap from that fairly antiseptic document into a working model.  By contrast, with the AMEX and FDR specs you can see how others have implemented the standard, pick up best practices that you can leverage, note the similarities and divergences in the approaches, etc.  I'll make special note of the FDR North platform choice - we've a working implementation of that interface.  Since it encompasses Debit, EBT and Credit, you get a real flavor for a full range of working techniques as put into practice.  And, with Debit/EBT, the bar is raised really high since you've got to tackle real-time reversals, PIN translation and dynamic key exchange.

Comments

[Thomas L. Kjeldsen]

The wikipedia page may also be useful: http://en.wikipedia.org/wiki/ISO_8583

[kai fen]

Hi,
I am connecting to a switch using ISO8583. My Banking Host is using Thales HSM and the switch is using Bull, Switch using pin format 01 and i am using format 03, i am using FA , and follow by EA command, somehow, i still can not verify their pin block. What is the issue i need to consider ? Pls advise. Urgent

[Syed Mahmood Ali]

hi,
ISO 8583 is suitable for card based transaction like ATM or Credit Cards...Can't we use it in mobile and e-banking solutions

[Charles Okwuagwu]

Please has anyone tried to integrate with the FLEXCUBE banking system from iflex.

also, is there a .net library you would recommend for ISO8583 MESSAGING.

I am building my own library. i have made some good progress, i am able to generate the exact same byte patterns as generated by jpos (i confirm this using Packetyzer from Etheral). My challenge is that i never get any responses.

Pleas any help would be welcome.

bless you.

Charles

[Joko H.Wibowo]

what about using .net ??

[Andy Orrock]

The 'j' in jPOS is for Java. There's no nPOS partner project, and no port.

We have some MSFT-centric clients who have taken responsibility for all UI aspects, and have done it all in .NET. The jPOS OLTP engine and our client's .NET UI have a point of intersection only at the SQL Server level. It's an approach that works well. It allows these clients to meet internal requirements such as LDAP integration, without distracting the jPOS team from its core vision.

But, in terms of the engine itself, in a word, no. You want a payment systems engine in .NET, go for it. But you'll find nothing in these pages, nor in the jPOS project.