Talk:ISO 8583

message: This standard defines the messages used in electronic processing of credit and debit card transactions. --60.229.85.178 12:40, 26 October 2005 (UTC)
thread_title: Credit and debit cards

message: I'm proposing deleting this section. There must be hundreds of companies with these products, and it's not encyclopedic to list them here.  Actually, I'm going further than proposing deleting this section. I'm deleting it. If there are any objections, discuss them here, or put it back if you must. Zaian 22:33, 5 June 2006 (UTC)
replies: text: Fine with me -- I started the section, but it's kind of grown too much... Nathan Beach 15:50, 6 June 2006 (UTC)
thread_title:  Deleting section on companies with ISO products

message: What are those Advices used for? I understand the requests and responses, but I have no idea, what the advices are needed for. An example would be helpful. --jpp 13:25, 17 July 2006 (UTC)
replies: text: For example (someone else correct me if I'm wrong), when a decision is made by an authorizer for a transaction to be reversed at the acquirer side of an authorization point, an advice message is sent to the issuer notifying it of the reversed transaction.  This is in order to let the issuer know to adjust its settlement totals.  Or something like that.  The main point being that no response is required from the recipient (it's just some good advice) --nathanbeach 07:56, 30 July 2006 (UTC)

text: For example, advices are used by MasterCard when performing stand-in authorization. When standing in for the normal processor, MasterCard sends an advice to the actual processor. This advice can be responded to or ignored. Pieterpoorthuis 10:07, 22 June 2007 (UTC)
thread_title:  Advices 

message: Why has the convenient ISO defined data elements list been removed? Pieterpoorthuis 10:13, 22 June 2007 (UTC)
thread_title:  Deleted ISO defined data elements 

message: I propose that we include in the table the three available versions , 1987, 1993, 2003; but I am not sure if there is a copyright violation involved.  —Preceding unsigned comment added by 200.67.139.88 (talk) 22:30, 19 September 2007 (UTC)
replies: text: I have a doubt on field 60. I've seent it as an .7 field (like it is here) but I have also seen it in 3 other sources with this format: LLLVAR	ans..999, just as 61,62,63...
Would one of these be correct or may it depend on the implementation ?   (Marcelr (talk) 16:29, 23 January 2009 (UTC)
thread_title:  The ISO-Defined Data Elements table belongs to 1993 version. 

message: The Data Elements section needs work.  I tried to clarify wherever the meaning was not clear.  But there are several things that are still not clear.  It does not make clear whether the data elements are in data-element-type sequence in a message.  Since a bit map is used to specify if a data element is present or not, I assume they are in sequence.  If so that should be explicitly stated.  It does not make clear whether LL and LLL can be a mixture of hex for some data elements and ASCII for other data elements.  And if it can be either, what is the format of each byte in LL and LLL?  Is it 2-bytes for hex and 3-bytes for ASCII?  Or is the length field hex for numeric fields and ASCII for non-numeric fields?  It says "if numeric it will be compressed"  Compressed as hex (two digits per byte) or binary?  Are binary numbers used anywhere in these messages?  If not it should say so.  What does "or (..xx)" mean, where "xx < 100" ?  What does xx mean?  Hex-hex?  Does it mean 100 hex or 100 decimal?  It says LL can be 1 or 2 bytes, but doesn't say whether that is determined by the data element type or whether there is some other indicator.  It doesn't say whether VAR always begins on a byte boundary or whether VAR can share a byte with LL.  It used to say "23x means there are 23 elements to follow" but that cannot possibly be true (not 23 different account numbers in the same message).  I changed it to "23x means there are 23 VAR bytes to follow."  i.e. 23 hex means there are 23 (decimal) bytes to follow.  It says "if numeric it will be compressed" and then gives an example of LL = 87 represented by byte '87x.  But what if "it" means a variable length numeric data field, for example data element 34 (extended primary account number)?  If it means that both LL and the variable length data field will be compressed, and both are in hex with 2 digits per byte, it should say so.  The field length and the data field should be described separately and I did so.  Greensburger (talk) 00:22, 21 July 2008 (UTC)
thread_title: Data Elements

message: ISO 8583 exists in three different versions (:1987 :1993 :2003) at the time of writing (with a fourth not yet established) I have edited a section (on field 22 (POS Code)), splitting it up into three subsections, one for each of the three... I am unsure if this is the smartest approach JoSSte (talk) 13:40, 7 October 2022 (UTC)
thread_title:  Discussing several versions 

message: 200335 111.92.131.53 (talk) 17:02, 8 October 2022 (UTC)
thread_title:  200335 

message: Noman Toffique   09 103.26.83.46 (talk) 12:16, 10 December 2022 (UTC)
thread_title:  Bsek. Rollno 560