This standard defines the messages used in electronic processing of credit and debit card transactions.
22.214.171.124 12:40, 26 October 2005 (UTC)Jonnosan
Deleting section on companies with ISO products
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)
- Fine with me -- I started the section, but it's kind of grown too much... Nathan Beach 15:50, 6 June 2006 (UTC)
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)
- 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)
- 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)
Advices are operations that doesn’t need an verification (approval) to be effective, ex if the system advice to annulet a transaction the server side should absolutely revert it. — Preceding unsigned comment added by 126.96.36.199 (talk) 16:21, 5 December 2012 (UTC)
Deleted ISO defined data elements
Why has the convenient ISO defined data elements list been removed? Pieterpoorthuis 10:13, 22 June 2007 (UTC)
The ISO-Defined Data Elements table belongs to 1993 version.
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 188.8.131.52 (talk) 22:30, 19 September 2007 (UTC)
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))
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)
Data element 41
Data element 41 is listed as having type ans 16; however, the information available at http://www.cooboy.com/program/body_iso8583.htm indicates the type to be of ans 8. I do not have an official ISO 8583 specification available to me, so I don't know which one is correct; I am merely pointing out the discrepancy so someone with access to the specification can hopefully confirm if it's correct or not.