Online Message Specification

PayPoint Network Limited

1 The Boulevard Shire Park Welwyn Garden City Hertfordshire AL7 1EL Telephone: 01707 600300 Fax: 01707 600333

PAYPOINT ONLINE MESSAGE SPECIFICATION

Ann PetersenSenior Business Analyst

document.doc030th July 2008

Company Confidential

PAYPOINT ONLINE MESSAGE SPECIFICATION DEV_DOC-1438v6.0

TABLE OF CONTENTS

1 DOCUMENT HISTORY................................................................................................ 4

2 INTRODUCTION........................................................................................................... 5

3 ONLINE MESSAGE STRUCTURES...........................................................................6

3.1 PAYMENT OR REVERSAL (0200).................................................................................73.2 RESPONSE TO A PAYMENT OR REVERSAL (0210)........................................................93.3 VOID OF A PREVIOUS PAYMENT OR REVERSAL (0420).............................................103.4 RESPONSE TO A VOID (0430)....................................................................................12

4 ONLINE MESSAGE STRUCTURE/DATA CONTENT............................................13

5 SAMPLE ONLINE MESSAGES.................................................................................14

6 ONLINE MESSAGE DATA FIELDS..........................................................................18

6.1 FIELD 1..................................................................................................................... 186.2 FIELD 2 - PRIMARY ACCOUNT NUMBER (PAN).........................................................186.3 FIELD 3 - PROCESSING CODE.....................................................................................206.4 FIELD 4 - AMOUNT TRANSACTION.............................................................................216.5 FIELD 7 - TRANSMISSION DATE AND TIME.................................................................226.6 FIELD 11 - SYSTEMS TRACE AUDIT NUMBER.............................................................226.7 FIELD 12 - TIME, LOCAL TRANSACTION.....................................................................236.8 FIELD 13 - DATE, LOCAL TRANSACTION....................................................................246.9 FIELD 14 - DATE, EXPIRATION..................................................................................246.10 FIELD 15 - DATE, SETTLEMENT..............................................................................256.11 FIELD 18 - MERCHANT'S TYPE...............................................................................266.12 FIELD 22 - POS ENTRY MODE................................................................................266.13 FIELD 25 - POS CONDITION CODE..........................................................................276.14 FIELD 28 - AMOUNT, TRANSACTION FEE................................................................286.15 FIELD 30 - AMOUNT, TRAN PROCESSING FEE..........................................................286.16 FIELD 32 - ACQUIRING INSTITUTION ID CODE.........................................................296.17 FIELD 33 - FORWARDING INSTITUTION ID CODE.....................................................296.18 FIELD 35 - TRACK2 DATA...................................................................................... 306.19 FIELD 37 - RETRIEVAL REFERENCE NUMBER..........................................................316.20 FIELD 39 – RESPONSE CODE..................................................................................326.21 FIELD 41 - CARD ACCEPTOR TERMINAL ID.............................................................326.22 FIELD 42 - CARD ACCEPTOR ID CODE....................................................................336.23 FIELD 43 - CARD ACCEPTOR NAME LOCATION.......................................................336.24 FIELD 48 – ADDITIONAL RESPONSE DATA.............................................................346.25 FIELD 49 - CURRENCY CODE, TRANSACTION..........................................................346.26 FIELD 54 – ADDITIONAL AMOUNTS.......................................................................356.27 FIELD 56 - MESSAGE REASON CODE.......................................................................366.28 FIELD 59 - ECHO DATA.......................................................................................... 376.29 FIELD 90 – ORIGINAL DATA ELEMENTS.................................................................376.30 FIELD 95 - REPLACEMENT AMOUNTS.....................................................................386.31 FIELD 123 - POS DATA CODE................................................................................39

© PayPoint Network Ltd 2008 Company Confidential of 39


6.32 Field 127 – Postilion Private Field........................................................................40



1 Document History

Version Date Author Description

0.1 2nd January 2002 A. Petersen Draft Version

0.2 15th January 2002 A. Petersen Review Comments

1.0 21st January 2002 A. Petersen Issued Version

2.0 13th March 2002 A. Petersen Field 39 added

2.1 18th March 2002 A. Petersen Message Structures added

3.0 4th April 2002 A. Petersen Re-Issued Version

4.0 20th June 2002 A. Petersen Re-Issued Version – Binary Data added + additional communication information + Acquiring/Forwarding Institution Id set to 000020

5.0 18th September 2003 A. Petersen Field 59 – Echo Data Transaction Type changed from 2 to 4 characters

6.0 30th July 2008 Ann Petersen STAN changed for Reversals & Voids



2 Introduction

This document had been written to assist PayPoint Clients who wish to operate Online Schemes for the purpose of allowing their Customers to top up or access accounts online real time, and as such should be read in conjunction with the PayPoint Online Service Specification. The document details the structures of the different messages issued from and expected back by the PayPoint Generic Online Service and provides a detailed description of each data item within the messages interfaced to the Client’s application.

The Online interface to the Client’s application is based on the ISO8583 standard (August 1987 version) for Bank Card originated messages, where all data fields in messages are expressed in ASCII with the exception of Field 1 – the Bitmap, which is expressed in Binary. It is advised that Clients have access to a copy of this standard before reading this document.

The preferred communication protocol is TCP/IP via BT Frame Stream (64k – 1mB depending on traffic volume). Alternatively 4 kilostream links could be used, depending on whether the Client has a separate Disaster Recovery Site or not. The connection must, once opened be kept open, it must not be disconnected by the Client application, either before or after responding to a message. Should the connection be closed or lost, the online system will attempt to re-open it.

Messages will be sent to the Client application using standard streaming with standard TCP/IP sockets. These messages must be responded to by the Client application in the order that they are received, where the response is sent back to the same port from which the original message was sent. Messages may be multithreaded, in which case the responses will be sent back asynchronously.



3 Online message Structures

The structure of each message is made up of 3 parts as follows:

Message Type Identifier One or two Bitmaps A Series of Data Elements

Note: When using the TCP/IP network communications protocol, a 2 byte header (Network Byte Order) is prefixed to all messages sent from/to the Generic Sink Node. The header is used as an indicator of the length of the TCP/IP stream.

The Message Type Identifier is a 4 digit numeric field identifying:

the Message Class - the first 2 digits the Message Function – the last 2 digits

Message Types sent to the Client are 0200 and 0420. Message Types returned by the Client are 0210 and 0430. The second message component comprises one or two Bitmaps, each consisting of 64 bits. Each bit signifies the presence (1) or the absence (0) in the message of the data element associated with the particular bit. The primary bitmap (bits 1 – 64) is always present and the most frequently used data elements are indexed from these bit positions. Infrequently used data elements are indexed from the secondary bitmap (bits 65 – 128). The presence of the secondary bitmap is indicated by setting bit 1 of the primary bitmap.

The data content of the third message component is made up of a series of data elements (fields). Messages are reconstructed using the bitmap(s) as an indicator of data elements that are present. Some data elements are of fixed length, while others are variable in length. In the case of a variable length data element, the actual length of the data element is indicated in its fixed length prefix.

It should be noted that the first 2 bytes of a returned response message (0210 – response to a Payment or Reversal; and 0430 – response to a Void) indicates the length of the message following the 2 bytes. These 2 bytes are EXCLUDED from this value.

Please refer to section 5 (Samples Online Messages) for binary and character examples of typical messages sent to and returned by Clients.



3.1 Payment or Reversal (0200)

This message is created by the Generic Sink Node and passed to the Client’s application for processing by the Client.

ISO8583 Field Number

Field Name Content

1 Bitmap Binary Map denoting the fields and their lengths that are included in the message

2 Primary Account Number (PAN) The number of the card that has been swiped, scanned or manually enteredTypically contains: IIN, Product Code and Customer Number

3 Processing Code 000000 for Payments220000 for reversals requested at the terminal

4 Amount Transaction The amount requested at the terminal, in pence

7 Transmission Date and Time The date and time, expressed in Greenwich Mean Time (GMT), when the message was initiated by the PayPoint Online Service

11 System Trace Audit No An Audit Number assigned by the PayPoint Online Host System. Note Reversals, Voids and their original Payments have different System Trace Audit Numbers.

12 Time, Local Transaction Time the transaction took place at the terminal (hhmmss)

13 Date, Local Transaction Date the transaction took place at the terminal (mmdd)

14 Date, Expiration Expiry Date of the card swiped, if configured on the card. (yymm). Note Expiry Date will be set to zeroes for Barcodes and manually entered card details

15 Date, Settlement Date on which funds will be transferred (mmdd). Note set as Date, Local Transaction

18 Merchant Type The classification of the Merchant’s type of Business. Note set to 0000

22 POS Entry Mode Code identifying the type of data entry performed at the terminal

25 POS Condition Code Terminal’s Condition Code. Note set to




Field Name Content

0028 Amount, Transaction Fee The fee charged by the Acquirer to the

Issuer. Note set to C + zeroes32 Acquiring Institution Id Code identifying PayPoint. Note set to 2033 Forwarding Institution Id Code identifying PayPoint. Note set to 2035 Track 2 Data Data encoded (where applicable) on

Track 2 of the customer’s swiped magnetic card. Note this field will not exist for barcodes and manually entered card details

37 Retrieval Reference No Unique number associated with this transaction in the format Pccsssnnnnnn, where:P is fixedcc = the Client defined codesss = Unique Sink Node Numbernnnnnn = System Trace Audit Number

41 Card Acceptor Terminal Id Unique PayPoint Terminal Identification42 Card Acceptor Id Code Unique PayPoint Agent Site Number (5

digits). Note padded with leading zeroes43 Card Acceptor Name Location Name and Location of the Agent Site in

which the terminal resides49 Currency Code, Transaction ISO Numeric Currency Code. Note set to

826 for Pounds Sterling 59 Echo Data Data relating to the transaction to be

returned intact by the Client. Comprises 3 fields (Payment) or 4 fields (Reversal & Void) delimited by “|”:Sequence Number|Transaction Type|Retrieval Reference Number|Original Retrieval Reference No

123 POS Data Code Series of codes identifying the terminal’s capability

127.9 Additional Node Data Optional - Client Specific data captured at the terminal and held in TLV format

3.2 Response to a Payment or Reversal (0210)



This message is returned by the Client’s application to the Generic Sink Node to confirm the actions taken by the Client and to complete the transaction at the terminal.


Field Name Content



39 Response Code Code denoting the outcome of the transaction

48 Additional Response Data Optional.May contain Customer Specific Message for printing on the receipt.If transaction is rejected – may contain the reject description to be printed on the receipt

54 Additional Amounts Optional.May contain up to 3 balances to be printed on the receipt. Each balance has the format:1-2 N ISO Account Type 3-4 N ISO Amount Type5-7 N ISO Currency Code8 A C for Credit, D for Debit 9-20 N Amount

59 Echo Data Data relating to the transaction as sent in the original message and to be returned intact by the Client. Comprises 3 fields (Payment) or 4 fields (Reversal & Void) delimited by “|”:Sequence Number|Transaction Type|Retrieval Reference Number|Original Retrieval Reference No

3.3 Void of a Previous Payment or Reversal (0420)



This message is generated by the Generic Sink Node as a result of a system failure or as a result of no response being received from the Client’s application. Additionally this message can be generated as a result of the terminal failing to acknowledge that the transaction as completed successfully.


Field Name Content



3 Processing Code 000000 for Payments220000 for reversals requested at the terminal

4 Amount Transaction The amount requested at the terminal, in pence

7 Transmission Date and Time The date and time, expressed in Greenwich Mean Time (GMT), when the message was initiated by the PayPoint Online Service

11 System Trace Audit No An Audit Number assigned by the PayPoint Online Host System. Note Reversals, Voids and their original Payments have different System Trace Audit Numbers

12 Time, Local Transaction Time the transaction took place at the terminal (hhmmss)

13 Date, Local Transaction Date the transaction took place at the terminal (mmdd)

14 Date, Expiration Expiry Date of the card swiped, if configured on the card. (yymm). Note Expiry Date will not exist for Barcodes or manually entered card details

15 Date, Settlement Date on which funds will be transferred (mmdd). Note set as Date, Local Transaction

18 Merchant Type The classification of the Merchant’s type of Business. Note set to 0000

22 POS Entry Mode Code identifying the type of data entry performed at the terminal

25 POS Condition Code Terminal’s Condition Code. Note set to




Field Name Content

0028 Amount, Transaction Fee The fee charged by the Acquirer to the

Issuer. Note set to C + zeroes30 Amount, Transaction Processing

FeeThe fee charged by the Acquirer. Note set to C + zeroes

32 Acquiring Institution Id Code identifying PayPoint. Note set to 2033 Forwarding Institution Id Code identifying PayPoint. Note set to 2035 Track 2 Data Data encoded (where applicable) on

Track 2 of the customer’s swiped magnetic card. Note will not exist for barcodes and manually entered card details

37 Retrieval Reference No Unique number associated with this transaction in the format Pccsssnnnnnn:P is fixedcc = the Client defined codesss = Unique Sink Node Numbernnnnnn = System Trace Audit Number

39 Response Code Code denoting the outcome of the transaction

41 Card Acceptor Terminal Id Unique PayPoint Terminal Identification42 Card Acceptor Id Code Unique PayPoint Agent Site Number (5

digits). Note padded with leading zeroes43 Card Acceptor Name Location Name and Location of the Agent Site in

which the terminal resides49 Currency Code, Transaction ISO Numeric Currency Code. Note set to

826 for Pounds Sterling 56 Message Reason Code The reason for the message. Note set to

400159 Echo Data Data relating to the transaction to be

returned intact by the Client. Comprises 4 fields delimited by “|”:Sequence Number|Transaction Type|Retrieval Reference Number|Original Retrieval Reference No

90 Original Data Elements Original Transaction Data containing:Message Type (0200)Systems Trace Audit NumberTransmission Date and Time




Field Name Content

Acquirer Institution IdForwarding Institution Id

95 Replacement Amounts Actual Transaction, Settlement, Transaction Fee, Settlement Fee Amounts.

3.4 Response to a Void (0430)

This message is returned by the Client’s application to the Generic Sink Node to confirm receipt of the Void. The Void message cannot be rejected by the Client.


Field Name Content



39 Response Code Code denoting the outcome of the transaction. Note must be set to zero

59 Echo Data Data relating to the transaction as sent in the original message and to be returned intact by the Client. Comprises 4 fields delimited by “|”:Sequence Number|Transaction Type|Retrieval Reference Number|Original Retrieval Reference No



4 Online Message Structure/Data Content

Field Description Format 0200 Swipe

0200 Keyed

0420 AfterSwipe

0420 After Keyed

1 Bitmap Binary x x x x2 Primary Account No (PAN) n19, LLVAR x x x x3 Processing Code n6 x x x x4 Amount Transaction n12 x x x x7 Transmission Date and

Timen10,

MMDDHHMMSSx x x x

11 System Trace Audit Number

n6 x x x x

12 Time, Local Transaction n6, HHMMSS x x x x13 Date, Local Transaction n4, MMDD x x x x14 Date, Expiration n4, YYMM x x x x15 Date, Settlement n4, MMDD x x x x18 Merchant Type n4 x x x x22 POS Entry Mode n3 x x x x25 POS Condition Code n2 x x x x28 Amount, Transaction Fee X + n8 x x x x30 Amount, Transaction

Processing FeeX + n8 x x

32 Acquiring Institution Id n11, LLVAR x x x x33 Forwarding Institution Id n11, LLVAR x x x x35 Track 2 Data z37, LLVAR x x37 Retrieval Reference No an12 x x x x39 Response Code n2 x x41 Card Acceptor Terminal Id ans8 x x x x42 Card Acceptor Id Code ans15 x x x x43 Card Acceptor Name

Locationans40 x x x x

48 Additional Response Data ans999, LLLVAR49 Currency Code, Transaction n3 x x x x54 Additional Amounts an120, LLLVAR56 Message Reason Code n4, LLLVAR x x59 Echo Data ans64, LLLVAR x x x x90 Original Data Elements n42 x x95 Replacement Amounts an42 x x123 POS Data Code an15, LLLVAR x x



5 Sample Online Messages

0200: Payment

[LLVAR n ..19 019] 002 [9826132500000000181] [Fixed n 6 006] 003 [000000] [None n 012] 004 [000000001000] [Fixed n 10 010] 007 [0914225918] [Fixed n 6 006] 011 [000155] [Fixed n 6 006] 012 [235918] [Fixed n 4 004] 013 [0914][Fixed n 4 004] 014 [0201] [Fixed n 4 004] 015 [0914] [Fixed n 4 004] 018 [0000] [Fixed n 3 003] 022 [020] [Fixed n 2 002] 025 [00] [Fixed x+n 8 009] 028 [C00000000] [LLVAR n ..11 006] 032 [000020] [LLVAR n ..11 006] 033 [000020] [LLVAR ans ..37 037] 035 [9826132500000000181=02017650000000000] [Fixed an 12 012] 037 [PCZ257000155] [Fixed ans 8 008] 041 [02117986] [Fixed ans 15 015] 042 [000000000020553] [Fixed ans 40 040] 043 [Location2 Welwyn Garden01GB] [Fixed a/n 3 003] 049 [826] [LLLVAR ans ..255 028] 059 [0000456445|0000|PCZ257000155] [LLLVAR ans ..15 015] 123 [20010120402C101]

Binary Representation:



0000(0000) 30 32 30 30 F2 3E 44 91 A8 E0 80 20 00 00 00 00 0200.D.... .... 0016(0010) 00 00 00 20 31 39 39 38 32 36 31 33 32 35 30 30 ... 199826132500 0032(0020) 30 30 30 30 30 30 31 38 31 30 30 30 30 30 30 30 0000001810000000 0048(0030) 30 30 30 30 30 30 30 31 30 30 30 30 39 31 34 32 0000000100009142 0064(0040) 32 35 39 31 38 30 30 30 31 35 35 32 33 35 39 31 2591800015523591 0080(0050) 38 30 39 31 34 30 32 30 31 30 39 31 34 30 30 30 8091402010914000 0096(0060) 30 30 32 30 30 30 43 30 30 30 30 30 30 30 30 30 002000C000000000 0112(0070) 36 30 30 30 30 30 32 30 36 30 30 30 30 30 32 33 6000002060000023 0128(0080) 37 39 38 32 36 31 33 32 35 30 30 30 30 30 30 30 7982613250000000 0144(0090) 30 31 38 31 3D 30 32 30 31 37 36 35 30 30 30 30 0181=02017650000 0160(00A0) 30 30 30 30 30 30 50 43 5A 32 35 37 30 30 30 31 000000PCZ2570001 0176(00B0) 35 35 30 32 31 31 37 39 38 36 30 30 30 30 30 30 5502117986000000 0192(00C0) 30 30 30 30 32 30 35 35 33 4C 6F 63 61 74 69 6F 000020553Locatio 0208(00D0) 6E 32 20 20 20 20 20 20 20 20 20 20 20 20 20 20 n2 0224(00E0) 57 65 6C 77 79 6E 20 47 61 72 64 65 6E 30 31 47 Welwyn Garden01G 0240(00F0) 42 38 32 36 30 32 36 30 30 30 30 34 35 36 34 34 B826026000045644 0256(0100) 35 7C 30 30 30 307C 50 43 5A 32 35 37 30 30 30 5|0000|PCZ257000 0272(0110) 31 35 35 30 31 35 32 30 30 31 30 31 32 30 34 30 1550152001012040 0288(0120) 32 43 31 30 31 2C101

0210: Response to Payment

[LLVAR n ..19 019] 002 [9826132500000000181] [Fixed an 2 002] 039 [00] [LLLVAR ans ..999 052] 048 [Your Blockbusters e-card top-up has been

successful.] [LLLVAR an* ..120 020] 054 [0102826C000000012000] [LLLVAR ans ..255 028] 059 [0000456445|0000|PCZ257000155


0000(0000) 30 32 31 30 40 00 00 00 02 01 04 20 31 39 39 38 0210@...... 1998 0016(0010) 32 36 31 33 32 35 30 30 30 30 30 30 30 30 31 38 2613250000000018 0032(0020) 31 30 30 30 35 32 59 6F 75 72 20 42 6C 6F 63 6B 100052Your Block 0048(0030) 62 75 73 74 65 72 73 20 65 2D 63 61 72 64 20 74 busters e-card t 0064(0040) 6F 70 2D 75 70 20 68 61 73 20 62 65 65 6E 20 73 op-up has been s 0080(0050) 75 63 63 65 73 73 66 75 6C 2E 30 32 30 30 31 30 uccessful.020010 0096(0060) 32 38 32 36 43 30 30 30 30 30 30 30 31 32 30 30 2826C00000001200 0112(0070) 30 30 32 36 30 30 30 30 34 35 36 34 34 35 7C 30 00260000456445|0 0128(0080) 30 30 30 7C 50 43 5A 32 35 37 30 30 30 31 35 35 000|PCZ257000155

0420: Void of a previous Payment or Reversal



[LLVAR n ..19 019] 002 [9826132500000000181] [Fixed n 6 006] 003 [220000] [None n 012] 004 [000000001000] [Fixed n 10 010] 007 [0914230044] [Fixed n 6 006] 011 [000157] [Fixed n 6 006] 012 [000044] [Fixed n 4 004] 013 [0915] [Fixed n 4 004] 014 [0201] [Fixed n 4 004] 015 [0915] [Fixed n 4 004] 018 [0000] [Fixed n 3 003] 022 [020] [Fixed n 2 002] 025 [21] [Fixed x+n 8 009] 028 [C00000000] [Fixed x+n 8 009] 030 [C00000000] [LLVAR n ..11 006] 032 [000020] [LLVAR n ..11 006] 033 [000020] [Fixed an 12 012] 037 [PCZ257000157] [Fixed an 2 002] 039 [60] [Fixed ans 8 008] 041 [02117986] [Fixed ans 15 015] 042 [000000000020553] [Fixed ans 40 040] 043 [Location2 Welwyn Garden01GB] [Fixed a/n 3 003] 049 [826] [LLLVAR ans ..4 004] 056 [4001] [LLLVAR ans ..255 041] 059 [0000456449|2200|PCZ257000157|PCZ257000156] [Fixed n 42 042] 090

[020000015609142300440000000000200000000002] [Fixed an* 42 042] 095

[000000000000000000000000C00000000C00000000]




0000(0000) 30 34 32 30 F2 3E 44 95 8A E0 81 20 00 00 00 42 0420.D.... ...B 0016(0010) 00 00 00 00 31 39 39 38 32 36 31 33 32 35 30 30 ....199826132500 0032(0020) 30 30 30 30 30 30 31 38 31 32 32 30 30 30 30 30 0000001812200000 0048(0030) 30 30 30 30 30 30 30 31 30 30 30 30 39 31 34 32 0000000100009142 0064(0040) 33 30 30 34 34 30 30 30 31 35 37 30 30 30 30 34 3004400015700004 0080(0050) 34 30 39 31 35 30 32 30 31 30 39 31 35 30 30 30 4091502010915000 0096(0060) 30 30 32 30 32 31 43 30 30 30 30 30 30 30 30 43 002021C00000000C 0112(0070) 30 30 30 30 30 30 30 30 30 36 30 30 30 30 32 30 0000000006000020 0128(0080) 36 30 30 30 30 32 30 50 43 5A 32 35 37 30 30 30 6000020PCZ257000 0144(0090) 31 35 37 36 30 30 32 31 31 37 39 38 36 30 30 30 1576002117986000 0160(00A0) 30 30 30 30 30 30 30 32 30 30 35 33 4C 6F 63 61 000000020553Loca 0176(00B0) 74 69 6F 6E 32 20 20 20 20 20 20 20 20 20 20 20 tion2 0192(00C0) 20 20 20 57 65 6C 77 79 6E 20 47 61 72 64 65 6E Welwyn Garden 0208(00D0) 30 31 47 42 38 32 36 30 30 34 34 30 30 31 30 34 01GB826004400104 0224(00E0) 31 30 30 30 30 34 35 35 34 34 39 7C 32 32 30 30 10000456449|2200 0240(00F0) 7C 50 43 5A 32 35 37 30 30 30 31 35 37 7C 50 43 |PCZ257000157|PC 0256(0100) 5A 32 35 37 30 30 30 31 35 36 30 32 30 30 30 30 Z257000156020000 0272(0110) 30 31 35 36 30 39 31 34 32 33 30 30 34 34 30 30 0156091423004400 0288(0120) 30 30 30 30 30 30 30 30 32 30 30 30 30 30 30 30 0000000020000000 0304(0130) 30 30 30 32 30 30 30 30 30 30 30 30 30 30 30 30 0002000000000000 0320(0140) 30 30 30 30 30 30 30 30 30 30 30 30 43 30 30 30 000000000000C000 0336(0150) 30 30 30 30 30 43 30 30 30 30 30 30 30 30 00000C00000000

0430: Response to a Void

[LLVAR n ..19 019] 002 [9826132500000000181] [Fixed an 2 002] 039 [00] [LLLVAR ans ..255 041] 059 [0000456449|2200|PCZ257000157|PCZ257000156]


0000(0000) 30 34 33 30 40 00 00 00 02 00 00 20 31 39 39 38 0430@…… 1998 0016(0010) 32 36 31 33 32 35 30 30 30 30 30 30 30 30 31 38 2613250000000018 0032(0020) 31 30 30 30 33 39 30 30 30 30 34 35 36 34 34 39 1000390000456449 0048(0030) 7C 32 32 30 30 7C 50 43 5A 32 35 37 30 30 30 31 |2200|PCZ2570001 0064(0040) 35 37 7C 50 43 5A 32 35 37 30 30 30 31 35 36 57|PCZ257000156



6 Online Message Data Fields

6.1 Field 1

Format

Binary

Description

A Bit Map defining the data fields and their lengths which are included in the message.

Usage

Used by the receiving application to read the message.

6.2 Field 2 - Primary account number (PAN)

Format

n..19, LLVAR

Description

A number identifying the cardholder and the card issuer. Typically, this number is embossed on the front of the card and encoded on Track 2 of the magnetic stripe.The remainder of the description is applicable only if the PAN conforms to the ISO/IEC 7812 specification.

The PAN is made up of 3 or 4 components. These are the issuer identification number (IIN), optional Product Code, the individual account identification identifying the customer and a check digit.

The IIN is made up of 2 elements: the major industry identifier (MII) and the issuer identifier. The MII identifies the major industry of the card issuer and can contain one of the following values:

MMI Description



0 for assignment by ISO/TC 681 airlines2 airlines and other future industry assignments3 travel and entertainment (e.g. Diners Club)4 banking/financial (e.g. VISA)5 banking/financial (e.g. MasterCard)6 merchandising and banking (e.g. retail private label cards)7 petroleum8 telecommunications and other future industry assignments 9 for assignment by national standards bodies

The issuer identifier is normally a fixed length five digit number. Historically the first digit was used to indicate the length of the issuer identifier. However, all new numbers are issued as fixed length five digit numbers.

The individual account identification is assigned by the card issuer and identifies an individual customer account. It is variable in length with a maximum of 12 digits.The check digit is the last digit of the PAN and is calculated on all the preceding digits of the identification number using the Luhn formula for modulus 10 check-digit.

In the case of Visa Cash transactions (with the exclusion of a Visa Cash Funds Request), this field contains the Visa Cash Card Number. This is a fixed length field consisting of 3 data elements:

Visa Cash Card Issuer BIN (position 1 – 6) Visa Cash Serial Number (position 7 – 15) Visa Cash Check Digit (position 16)

Usage

Postilion expects the PAN for a customer transaction if the Track 2 is not available (typically if the card data was entered manually). If the PAN is not present in a message to Postilion, then the PAN will be extracted from the Track 2 field.

On receipt of a new customer transaction, Postilion attempts to retrieve the card product for the PAN from the database. If unsuccessful, the transaction is declined with a response code of 56 (no card record). If the card product requires PAN verification, Postilion performs a Luhn-check on the PAN.If the check digit is incorrect, the transaction is declined with a response code of 14 (invalid card number)



6.3 Field 3 - Processing code

Format

n6

Description

The customer transaction type and the account types, if any, affected by the transaction. This is a fixed length field consisting of 3 data elements:

n Transaction type (positions 1 - 2).n Account type affected for debits and inquiries and the “from”

account for transfers (position 3 - 4).n Account type affected for credits and the “to” account for

transfers

Usage

Transaction Type determines the nature of the transaction:

0 Payment22 Reversal

On receipt of a new customer transaction, Postilion attempts to retrieve the account profile for the card product using either the “from” or “to” account type (depending on the transaction type). If unsuccessful, the transaction is declined with one of the following response codes:

39 no credit account42 no universal account44 no investment account52 no check account53 no savings account

Postilion subsequently checks whether or not the type of transaction can be performed on the retrieved account profile. If not, the transaction is declined with a response code of 57 (transaction not permitted to cardholder). If the PAN was entered manually (see Field 22 - POS entry mode), Postilion also checks whether manual PAN entry is allowed for the account profile retrieved. If not, the transaction is declined with a response code of 62 (restricted card).Postilion uses the transaction type when performing stand-in processing. In this case only the transaction class (debit, credit, inquiries, etc.) is used. Therefore a Source or Sink Node can define new transaction types without affecting the Transaction Manager.



No further processing is done on the “from” or “to” account types and the user can define new account types without effecting the Transaction Manager.

Note that a Sink Node can override the original account type by returning it in an Authorisation Response or Transaction Response message.

6.4 Field 4 - Amount transaction

Format

n12

Description

The funds requested by the cardholder in the local currency of the acquirer or source location of the transaction exclusive of transaction fees. Values are expressed in the minor denomination (e.g. cents).Usage

The Transaction Manager interprets this field on receipt as follows:

0200 The transaction amount requested

0210 The transaction amount approved. If this field is not present in the 0210 and the response code is APPROVED, Postilion assumes the approved amount equals the requested amount. If not present and the response code is not APPROVED, Postilion assumes that the approved amount is zero.

0202 If replacement amounts are present in the message, this field contains the requested amount. If replacement amounts are not present, this field contains the final transaction amount (i.e. the actual amount).



When sending messages, the interpretation is as follows:

0100/0200 The transaction amount requested.0110/0210 The transaction amount approved.0120/0130 The transaction amount requested.



0202/0212 The transaction amount requested.0220/0230 The transaction amount requested.0420/0430 The transaction amount requested.

The amount approved is forwarded in additional amounts and the final amount in replacement amounts.

6.5 Field 7 - Transmission date and time

Format

n10, MMDDhhmmss

Description

The date and time, expressed in Co-ordinated Universal Time (UTC), when this message is sent by the message initiator

Usage

Postilion generates this field only for transactions it initiates (i.e. reconciliation transactions). In all other cases, Postilion does not perform any processing on this field other than saving it in the transaction table on receipt and forwarding it in the appropriate messages.

6.6 Field 11 - Systems trace audit number

Format

n6

Description

A number assigned by a transaction originator to assist in identifying a transaction uniquely.

Usage

For every transaction, Postilion maintains two (potentially different) systems trace audit numbers:

n Source Node systems trace audit number; andn Sink Node systems trace audit number.



When Postilion receives this field in a new customer transaction from a Source Node, it saves it as the Source Node systems trace audit number in the transaction table.

If Postilion is configured to generate systems trace audit numbers for the applicable Sink Node, Postilion generates a new Sink Node systems trace audit number. If not, Postilion assigns the Source Node systems trace number to the Sink Node systems trace audit number. Postilion stores the Sink Node systems trace audit number in the transaction table. Postilion uses the Sink Node systems trace audit number to calculate original data elements for the Sink Node.

Postilion sets this field to the Source Node systems trace audit number in all response messages to the Source Node. It sets this field to the Sink Node systems trace audit number in all messages (pertaining to a transaction) to the Sink Node.

Note: PayPoint configures System Trace Audit Numbers to be generated by the Sink Node – therefore every message (Sale, Reversal and Void) has a unique STAN

6.7 Field 12 - Time, local transaction

Format

n6, hhmmss

Description

The local time at which the transaction takes place at the card acceptor location in authorisation and financial messages.

For all other transactions, this field indicates the local time set by the initiator of the first message of the transaction.

Usage




6.8 Field 13 - Date, local transaction

Format

n4, MMDD

Description

The local date at which the transaction takes place at the card acceptor location in authorisation and financial messages.

For all other transactions, this field indicates the local date set by the initiator of the first message of the transaction.

Usage


6.9 Field 14 - Date, expiration

Format

n4, YYMM

Description

The year and month after which the card expires.

Usage

Postilion expects this field for a customer transaction if the Track 2 is not available (typically if the card data was entered manually). If the expiry date is not present in a message to Postilion, then it will be extracted from the Track 2 field. If the Track 2 field is also not present, the expiry date is set to 0000 and no expiry date checking is performed.



On receipt of a new customer transaction, Postilion checks the expiry date. If the card has expired, the transaction is declined with a response code of 54 (expired card).

6.10 Field 15 - Date, settlement

Format

n4, MMDD

Description

The month and day for which financial totals are reconciled between the acquirer and the issuer.

Usage

For each customer transaction, Postilion maintains two independent settlement dates for all messages

n to and from the Source Node; andn to and from the Sink Node.

Postilion ignores this field in all messages pertaining to customer transactions. When the initial message for a customer transaction is received, Postilion determines the settlement date of the Source and Sink Node batches to which the transaction belongs. Postilion returns the Source Node settlement date in this field in all subsequent messages to the Source Node. This field is set to the Sink Node settlement date in all messages to the Sink Node.

On receipt of a reconciliation request (0500) message, Postilion uses this field to retrieve the reconciliation totals for the appropriate settlement period (batch).

6.11 Field 18 - Merchant's type

Format

n4

Description



The classification of the merchant’s type of business product or service. Codes to be developed within each country.

Usage

Postilion does not perform any processing on this field other than saving it in the transaction table on receipt and forwarding it in the appropriate messages.

6.12 Field 22 - POS entry mode

Format

n3

Description

A series of codes that identify the actual method used to capture the account number and expiration date when a terminal is used, and the PIN capture capability of the terminal. This is a fixed length field consisting of 2 data elements:

n PAN entry mode (positions 1 - 2).

00 Unknown01 Manual (via Key Pad)02 Magnetic Stripe03 Bar Code04 OCR05 Integrated Circuit Card checked90 Magnetic Stripe Track 295 Integrated Circuit Card not checked

n PIN entry capability (position 3).

0 Unknown1 Terminal can accept PINS2 Terminal cannot accept PINS

Usage




6.13 Field 25 - POS condition code

Format

n2

Description

A code that describes the condition under which the transaction takes place.

00 Normal transaction of this type01 Customer not present02 Unattended terminal – card can be retained03 Merchant suspicious of transaction04 Electronic cash register interface05 Customer present, card not present06 Pre-authorization request07 Telephone device required08 Mail/telephone order09 POS security alert10 Customer identity verified11 Suspected fraud12 Security reasons13 Representation of item14 Public utility terminal15 Customer’s terminal16 Administrative terminal17 Returned item18 No check in envelope – return19 Deposit out of balance – return20 Payment out of balance – return21 Manual reversal22 Terminal error - counted23 Terminal error - not counted24 Deposit out of balance – apply25 Payment out of balance – apply26 Withdrawal error – reversed27 Unattended terminal – card cannot be retained

Usage

Postilion performs numeric validation only on this field.




6.14 Field 28 - Amount, transaction fee

Format

x + n8

Description

A fee charged, by the acquirer to the issuer, for transaction activity, in the currency of the amount, transaction.

Usage


6.15 Field 30 - Amount, tran processing fee

Format

x + n8

Description

A fee charged by the network for the handling and routing of messages, in the currency of amount, transaction. This field is usually inserted by the network into the applicable messages.

Usage


6.16 Field 32 - Acquiring institution id code

Format

n..11, LLVAR



Description

A code identifying the financial institution acting as the acquirer of this customer transaction. The acquirer is the member or system user that signed the merchant, installed the ATM or dispensed cash. This field usually contains the BIN (see PAN) of the acquirer, but could be any other number assigned to it by the relevant authorities.

When a processing centre operates for multiple acquirers, this is the code for the individual member or system user, not a code for the processing centre.

Usage

If an acquiring institution identification code is defined for the Sink Node associated with the transaction, Postilion uses this value as the acquiring institution identification code for the transaction. If not, Postilion uses the value in the message that originated the transaction as the acquiring institution identification code for the transaction.

Postilion uses this field to determine the transaction batch for the Source or Sink Node associated with the transaction if the Source or Sink Node has a settlement granularity of acquirer.

Postilion does not perform any additional processing on this field other than saving it in the transaction table and forwarding it in the appropriate messages.

6.17 Field 33 - Forwarding institution id code

Format

n..11, LLVAR Description

A code identifying the institution that forwards the transaction in an interchange system en route to the card issuer. For example, assume that an acquirer routes a transaction via a third-party EFT switch to the card issuer. In the request from the acquirer to the EFT switch, this field contains the code of the acquirer. When the request is forwarded by the EFT switch to the card issuer, this field contains the code assigned to the EFT switch.

Usage



If a forwarding institution id code is defined for the Sink Node associated with the customer transaction, Postilion uses this value as the forwarding institution id code associated with the transaction. If not, Postilion uses the value in the message that originated the transaction as the forwarding institution id code associated with the transaction.

Postilion does not perform any additional processing on this field other than saving it in the transaction table and forwarding it in the appropriate messages.

6.18 Field 35 - Track2 data

Format

z..37, LLVAR

Description

The information encoded on Track 2 of the magnetic stripe as defined in ISO7813, including field separators but excluding the begin sentinel, end sentinel and longitudinal redundancy check characters. The field separator (FS) can be either a ‘=‘ or a ‘D’ character. The layout of this field is as follows:

Field Length

Primary account number up to 19 digitsField separator 1 digitExpiry date (YYMM) 4 digits (or a field separator if not present)Service restriction code 3 digits (or a field separator if not present)Discretionary data balance of available digits

The primary account number, expiry date and service restriction code fields are described in further detail under fields 2, 14 and 40 in this document.

For Visa Cash load transactions, this field contains the Visa Cash load signature data from the chip that is sent to the issuer to allow the issuer to verify the Visa Load Request Signature (S1). The layout of this field is as follows:

Field LengthVisa Cash Card Number 16 digitsField separator 1 digit (can be a ‘=’ or a ‘D’ character)

Expiry date (YYMM) 4 digits. Only the YYMM portion of the Visa Cash expiration date.



Service restriction code 3 digits (must be 101)Visa Cash Balance 6 digiitsTransaction number 5 digitsGMT Offset 2 digits

The visa cash card number, expiry date and service restriction code fields are described in further detail under fields 2, 14 and 40 in this document.

Usage

When present, Postilion extracts the primary account number, expiry date and service restriction code fields from the Track 2 data.

6.19 Field 37 - Retrieval reference number

Format

an12

Description

A reference number supplied by the system retaining the original source information and used to assist in locating that information or a copy thereof.

Usage


If this field is not present in an Authorization Request or Transaction Request, Postilion allocates a new retrieval reference number for the transaction.

6.20 Field 39 – Response Code

Format

n2

Description

A code that defines the disposition of a transaction

Usage



Used to determine what processing is required by Postilion to generate the code to be returned to the Host.

6.21 Field 41 - Card acceptor terminal id

Format

ans8

Description

A unique code identifying a terminal at the card acceptor location.

Usage

Postilion uses this field to determine the transaction batch for the Source or Sink Node associated with the transaction if the Source or Sink Node has a settlement granularity of terminal.

Postilion does not perform any additional processing on this field other than saving it in the transaction table on receipt and forwarding it in the appropriate messages.

6.22 Field 42 - Card acceptor id code

Format

ans15

Description

A code identifying the card acceptor (typically a merchant).

Usage



Postilion uses this field to determine the transaction batch for the Source or Sink Node associated with the transaction if the Source or Sink Node has a settlement granularity of terminal or card acceptor.


6.23 Field 43 - Card acceptor name location

Format

ans40

Description

The name and location of the card acceptor (such as a merchant or an ATM). This is a fixed length field consisting of 4 data elements:

n The location information (positions 1 - 23), exclusive of city, state and country.

n The city (positions 24 - 36) in which the point-of-service is located.

n The state (positions 37 - 38) in which the point-of-service is located.

n The country (positions 39 - 40) in which the point-of-service is located.

For Visa Cash load transactions, this field contains the Visa Cash Service Identifier (‘SV:’) followed by the name and location of the card acceptor (such as a merchant or an ATM). This is a fixed length field consisting of 4 data elements:

The Visa cash service identifier (positions 1 - 3), a constant value of ‘SV:’

The card acceptor name (positions 4 - 23) in which the point-of-service is located.

The city (positions 24 - 36) in which the point-of-service is located. The state (positions 37 - 38) in which the point-of-service is located. The country (positions 39 - 40) in which the point-of-service is located

Usage




6.24 Field 48 – Additional Response Data

Format

ans..999, LLLVAR

Description

Used to provide mini statement information for a mini statement enquiry.

Usage

Data provided by the Client is returned unchecked to the Source Node for printing on the receipt.

6.25 Field 49 - Currency code, transaction

Format

n3

Description

The local currency of the acquirer or source location of the transaction. This is the currency code used for the following amount fields:

n amount, transaction n amount, transaction fee n amount, transaction processing fee

Usage


6.26 Field 54 – Additional Amounts

Format

an..120, LLLVAR



Description

Information relating to a maximum of 6 amounts, each with a fixed format in the following format:

Account Type (positions 1 – 2) Values 01 to 06Amount Type (positions 3 – 4) ISO ValuesCurrency Code (positions 5 – 7)Amount Sign (position 8) Value = C or DAmount (positions 9 – 20)

Valid Amount Types are:

01 = Ledger Balance02 = Available Balance20 = Remaining This Cycle40 = Cash

Usage

Data provided by the Client is returned unchecked to the Source Node for printing on the receipt.

6.27 Field 56 - Message reason code

Format

n4, LLLVAR

Description

A code that provides the received of a request, advice or notification message with the reason, or purpose of that message.



For original authorisations and financial transactions it identifies why the type of message was sent (e.g. why an advice versus a request); for other messages, it states why this action was taken.

1003 Card issuer unavailable1006 Under floor limit1510 Over floor limit1800 Negative card4000 Customer cancellation4001 Unspecified, no action taken4004 Completed partially4021 Time-out waiting for response

For place hold on card transactions (i.e. hot-card notifications), it states why a card should be put on the hot-card list:

1801 Card lost 1802 Card stolen

In the case of message to bank transactions, the message reason code specifies the type of message the cardholder wants to forward to the issuer. Note that in this case, the message reason code field is treated as a free-format field that the user can use for any user specific code.

6.28 Field 59 - Echo data

Format

ans…064, LLLVAR

Description

This is a Postilion specific addition to the ISO8583 standard. Contains data from the originator of the message that shall be returned unaltered in the response message.



The individual data items within Echo Data are delimited by “|”, the content of Echo Data is as follows:

Sequence Number 10 charactersTransaction Type + 00 4 charactersRetrieval Reference Number 12 charactersOriginal Retrieval Reference Number 12 characters

Usage

Postilion does not perform any processing on this field other than saving it in the transaction table on receipt and returning it in the appropriate messages.

This data can be used by the Client to match Reversals with their original Payments and Voids with their Payments or Reversals.

6.29 Field 90 – Original Data Elements

Format

n42

Description

Contains the data elements from the original message. It is a fixed format containing the following 5 elements:

Original Message Type (positions 1 – 4)Original Systems Trace Audit Number (positions 5 – 10)Original Transmission Date and Time (positions 11 – 20)Original Acquirer Institution Id (positions 21 – 31)Original Forwarding Institution Id (positions 32 – 42)

Usage

Used for transaction matching and identification of corrections and reversals.

6.30 Field 95 - Replacement amounts

Format



an42

Description

The corrected amounts of a transaction in a partial or full reversal (or the final amounts for the transaction). It is a fixed length field consisting of 4 data elements:

n Actual amount, transaction (positions 1 - 12) - the corrected, actual amount of the customer’s transaction, in the currency of the transaction.

n Actual amount, settlement (positions 13 - 24) - the corrected, actual amount of the customer’s transaction, in the settlement currency.

n Actual amount, transaction fee (positions 25 - 33) - the corrected, actual amount of the fee (in format x + n8) for this customer transaction, in the currency of the transaction.

n Actual amount, settlement fee (positions 34 - 42) - the corrected, actual amount of the fee (in format x + n8) for this customer transaction, in the settlement currency.

Usage

On receipt of a 0120, 0220, or 0420 message, Postilion uses this field to extract the amount transaction final and the amount settlement final. This field is ignored for all other messages received. The fee components are always ignored and never processed.

Postilion will always forward this field in 0202, 0212, 0120, 0130, 0220, 0230, 0420, 0430, 9120 and 9220 messages. The field forwarded is constructed from the final transaction and settlement amounts. The fee components are always set to zeroes.

6.31 Field 123 - POS data code

Format

an15, LLLVAR

Description



A Postilion specific addition to the ISO8583 standard used to identify terminal capability, terminal environment and presentation security data. It is used to indicate specific conditions that were present at the time a transaction took place at the point of service. This field consists of the following sub-fields:

n The card data input capability (position 1) of the terminal.n The cardholder authentication capability (position 2) of the

terminal.n The card capture capability (position 3) of the terminal. n The operating environment (position 4) of the terminal. n Indicates whether the cardholder is present (position 5). n Indicates whether the card is present (position 6). n The actual card data input mode (position 7) of the transaction.n The actual cardholder authentication method (position 8) of the

transaction.n The cardholder authentication entity (position 9) of the

transaction.n The card data output capability (position 10) of the terminal.n The terminal output capability (position 11) of the terminal.n The PIN capture capability (position 12) of the terminal.n The terminal operator (position 13).n The terminal type (positions 14 & 15).

Usage

Postilion performs alphanumeric validation only on this field. It uses the terminal type when it does track 2 service code checking.


6.32 Field 127 – Postilion Private Field

Format

ans..999999, LLLLLLVAR

Description

This is a Postilion specific addition to the ISO 8583 standard. Field 127 is a bitmap field containing up to 999999 bytes of data. Subfields of field 127 are identified as field 127.x.


Online Message Specification

Documents

Transcript of Online Message Specification