Talk:ISO 8583

AS 2805 was nominated for deletion. The discussion was closed on 26 September 2023 with a consensus to merge. Its contents were merged into ISO 8583. The original page is now a redirect to this page. For the contribution history and old versions of the redirected article, please see its history; for its talk page, see here.

This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Finance & Investment Mid‑importance This article is within the scope of WikiProject Finance & Investment, a collaborative effort to improve the coverage of articles related to Finance and Investment on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Finance & InvestmentWikipedia:WikiProject Finance & InvestmentTemplate:WikiProject Finance & InvestmentFinance & Investment articles Mid This article has been rated as Mid-importance on the project's importance scale. Computing Low‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles Low This article has been rated as Low-importance on the project's importance scale.

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)Jonnosan[reply]

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)[reply]

Fine with me -- I started the section, but it's kind of grown too much... Nathan Beach 15:50, 6 June 2006 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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 194.204.239.194 (talk) 16:21, 5 December 2012 (UTC)[reply]

Advices are used to "advise" and Issuer that they have to affect their books for a txn that was approved by an authorized 3rd party on their behalf becuase of "any" issue that caused a timeout. (authorized 3rd party= has a balance/credit to do standins) and to keep settlment up to date. — Preceding unsigned comment added by 161.113.11.13 (talk) 00:45, 9 May 2018 (UTC)[reply]

Why has the convenient ISO defined data elements list been removed? Pieterpoorthuis 10:13, 22 June 2007 (UTC)[reply]

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)[reply]

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))[reply]

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)[reply]

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.--Iitywybmad (talk) 19:22, 2 June 2011 (UTC)[reply]

This site is no longer active - see the archived version: https://web.archive.org/web/20140222200727/http://www.cooboy.com:80/program/body_iso8583.htm

For the 1993 version it is ans 8.

For 2003 it is ans 16. JoSSte (talk) 13:48, 7 October 2022 (UTC)[reply]

Wus up 72.24.196.147 (talk) 13:17, 2 April 2024 (UTC)[reply]

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)[reply]

200335 111.92.131.53 (talk) 17:02, 8 October 2022 (UTC)[reply]

Noman Toffique 09 103.26.83.46 (talk) 12:16, 10 December 2022 (UTC)[reply]