If Postbridge

PostBridge Interface Specification Version 8
Document status: Copyright:
Final Postilion International Limited
ii
Scope
This document defines the interface between a Postilion system and a third party (Issuer or Acquirer), using the PostBridge Interface. The document defines the content of and rules according to which messages are transmitted between a Postilion system and a third party application. Message content is defined in terms of the data elements (or fields) which compose messages. Message field definitions are based on the ISO 8583 standard (1987) for bank card originated messages. Messages must be constructed according to: the Postilion implementation of the ISO 8583 standard (bitmap format) or an XML message format derived from the Postilion implementation of the ISO 8583 standard.
Rules for message exchange are defined in terms of the flows or sequences of messages transmitted between a Postilion system and a third party application. Message flows are based on the ISO 8583 standard (1987).
Contents
iii
Contents
1. Concepts.......................................................................................................................................1 1.1 1.2 MESSAGE TYPES .....................................................................................................................1 MAC SUPPORT .......................................................................................................................1 1.2.1 1.2.2 1.2.3 1.2.4 1.3 1.3.1 1.3.2 1.3.3 1.4 2. 2.1 Messages supported ................................................................................................2 MAC Code ................................................................................................................2 Dynamic Key Exchange ...........................................................................................2 Exception Processing ...............................................................................................3 Acquirer ....................................................................................................................3 Issuer ........................................................................................................................4 Example....................................................................................................................4
MAC KEY MANAGEMENT .........................................................................................................3
ACTIVE/ACTIVE ........................................................................................................................5
Implementation.............................................................................................................................6 BITMAP MESSAGE FORMAT ......................................................................................................6 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.2 Message type identifier.............................................................................................6 Bitmap(s) ..................................................................................................................7 Data elements ..........................................................................................................7 TCP/ IP Header ........................................................................................................8 Implementation Guidelines .......................................................................................8
XML MESSAGE FORMAT .......................................................................................................10 SOURCE NODE INTERFACE .....................................................................................................11 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.1.8 3.1.9 Messages to PostBridge.........................................................................................12 Messages from PostBridge ....................................................................................13 Authorization transactions ......................................................................................14 Financial transactions singe message pair .........................................................17 Financial transactions dual message pair ...........................................................20 Reconciliation .........................................................................................................22 Administration.........................................................................................................27 Sign On / Sign Off...................................................................................................30 Key Management ...................................................................................................33
3.
Message Flows...........................................................................................................................11 3.1
3.1.10 Echo test.................................................................................................................36 3.1.11 MAC enabled transactions .....................................................................................37 3.2 SINK NODE INTERFACE ..........................................................................................................39 3.2.1 3.2.2 3.2.3 3.2.4 Messages from PostBridge ....................................................................................40 Messages to PostBridge.........................................................................................41 Authorization transactions ......................................................................................42 Financial transactions single message pair.........................................................45
Contents 3.2.5 3.2.6 3.2.7 3.2.8 3.2.9 Financial transactions dual message pair ...........................................................48 Reconciliation .........................................................................................................50 Administration.........................................................................................................55 Sign On / Sign Off...................................................................................................57 Key management ...................................................................................................61
iv
3.2.10 Echo test.................................................................................................................64 3.2.11 Notification..............................................................................................................65 3.2.12 MAC enabled transactions .....................................................................................66 4. Message Content .......................................................................................................................69 4.1 MESSAGES TO POSTBRIDGE ..................................................................................................69 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6 4.1.7 4.1.8 4.1.9 Receive - Authorization Request (Repeat) (0100/0101) ........................................69 Receive - Authorization Request Response (0110) ...............................................71 Receive Authorization Advice (Repeat) (0120/0121) ..........................................72 Receive - Authorization Advice Response (0130)..................................................74 Receive - Transaction Request (Repeat) (0200/0201) ..........................................75 Receive Transaction Completion (Repeat) (0202/0203).....................................78 Receive - Transaction Request Response (0210) .................................................78 Receive Transaction Completion Response (0212)............................................80 Receive Transaction Advice (Repeat) (0220/0221) ............................................80
4.1.10 Receive - Transaction Advice Response (0230)....................................................82 4.1.11 Receive Acquirer File Update Advice (Repeat) (0320/0321) ..............................83 4.1.12 Receive Issuer File Update Advice (Repeat) (0322/0323)..................................84 4.1.13 Receive Acquirer File Update Advice Response (0330) .....................................85 4.1.14 Receive Issuer File Update Advice Response (0332).........................................85 4.1.15 Receive - Reversal Request (Repeat) (0400/0401) ...............................................85 4.1.16 Receive - Reversal Request Response (0410)......................................................87 4.1.17 Receive Reversal Advice (Repeat) (0420/0421).................................................88 4.1.18 Receive - Reversal Advice Response (0430).........................................................91 4.1.19 Receive Acquirer Reconciliation Request (Repeat) (0500/0501) .......................91 4.1.20 Receive Card Issuer Reconciliation Request (Repeat) (0502/0503) ..................92 4.1.21 Receive Acquirer Reconciliation Advice (Repeat) (0520/0521) ..........................92 4.1.22 Receive Card Issuer Reconciliation Advice (Repeat) (0522/0523).....................93 4.1.23 Receive Acquirer Reconciliation Advice Response (0530) .................................94 4.1.24 Receive Card Issuer Reconciliation Advice Response (0532)............................94 4.1.25 Receive - Administration Request (Repeat) (0600/0601) ......................................95 4.1.26 Receive - Administration Request Response (0610) .............................................97 4.1.27 Receive - Administration Advice (Repeat) (0620/0621) .........................................97 4.1.28 Receive Administration Advice Response (0630) ...............................................99 4.1.29 Receive Network Management Request (Repeat) (0800/0801) .........................99 4.1.30 Receive Network Management Response (0810) ..............................................99
Contents 4.1.31 Receive Authorization Notification Advice Response (9130) ..............................99 4.1.32 Receive Transaction Notification Advice Response (9230) ................................99 4.1.33 Receive Acquirer File Update Notification Response (9330) ............................100 4.1.34 Receive Reversal Notification Advice Response (9430)...................................100 4.1.35 Receive Administration Notification Advice Response (9630) ..........................100 4.1.36 Receive Format Error Response (0xx0)............................................................100 4.2 MESSAGES FROM POSTBRIDGE ...........................................................................................100 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.2.7 4.2.8 4.2.9 Send - Authorization Request (Repeat) (0100/0101)...........................................100 Send - Authorization Request Response (0110)..................................................102 Send - Authorization Advice (Repeat) (0120/0121) .............................................105 Send - Authorization Advice Response (0130) ....................................................107 Send - Transaction Request (Repeat) (0200/0201) .............................................108 Send Transaction Completion (Repeat) (0202) ................................................111 Send - Transaction Request Response (0210)....................................................112 Send Transaction Completion Response (0212) ..............................................114 Send - Transaction Advice (Repeat) (0220/0221)................................................116
4.2.10 Send - Transaction Advice Response (0230).......................................................118 4.2.11 Send Acquirer File Update Advice (Repeat) (0320/0321).................................120 4.2.12 Send Issuer File Update Advice (Repeat) (0322/0323) ....................................120 4.2.13 Send Acquirer File Update Advice Response (0330)........................................121 4.2.14 Send Issuer File Update Advice Response (0332/0323) ..................................122 4.2.15 Send - Reversal Request (Repeat) (0400/0401)..................................................122 4.2.16 Send - Reversal Request Response (0410).........................................................124 4.2.17 Send Reversal Advice (Repeat) (0420/0421) ...................................................127 4.2.18 Send Reversal Advice Response (0430) ..........................................................129 4.2.19 Send Acquirer Reconciliation Request Response (0510) .................................131 4.2.20 Send Card Issuer Reconciliation Request Response (0512)............................132 4.2.21 Send Acquirer Reconciliation Advice (Repeat) (0520/0521).............................133 4.2.22 Send Card Issuer Reconciliation Advice (Repeat) (0522/0523) .......................134 4.2.23 Send Acquirer Reconciliation Advice Response (0530)....................................135 4.2.24 Send Card Issuer Reconciliation Advice Response (0532) ..............................136 4.2.25 Send - Administration Request (Repeat) (0600/0601) .........................................137 4.2.26 Send - Administration Request Response (0610)................................................138 4.2.27 Send - Administration Advice (Repeat) (0620/0621)............................................140 4.2.28 Send - Administration Advice Response (0630) ..................................................141 4.2.29 Send Network Management Request (Repeat) (0800/0801)............................142 4.2.30 Send Network Management Response (0810) .................................................142 4.2.31 Send - Authorization Notification Advice (Repeat) (9120/9121)...........................143 4.2.32 Send - Transaction Notification Advice (Repeat) (9220/9221).............................145 4.2.33 Send Acquirer File Update Notification (Repeat) (9320/9321)..........................147
Contents 4.2.34 Send Reversal Notification Advice (Repeat) (9420/9421).................................147 4.2.35 Send - Administration Notification Advice (Repeat) (9620/9621).........................150 4.2.36 Send Format Error (0xx0)..................................................................................151 5. Fields .........................................................................................................................................152 5.1 5.2 FORMAT .............................................................................................................................152 DEFINITIONS .......................................................................................................................153 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 5.2.7 5.2.8 5.2.9 Field 2 Primary Account Number ......................................................................153 Field 3 Processing Code ...................................................................................153 Field 4 Amount Transaction ..............................................................................155 Field 5 Amount Settlement ................................................................................155 Field 7 Transmission Date and Time.................................................................155 Field 9 Conversion rate, Settlement ..................................................................155 Field 11 - Systems Trace Audit Number ..............................................................155 Field 12 - Time, Local Transaction .......................................................................156 Field 13 - Date, Local Transaction .......................................................................156
vi
5.2.10 Field 14 - Date, Expiration ....................................................................................156 5.2.11 Field 15 - Date, Settlement...................................................................................156 5.2.12 Field 16 - Date, Conversion..................................................................................156 5.2.13 Field 18 - Merchant Type......................................................................................157 5.2.14 Field 22 - POS Entry Mode ..................................................................................157 5.2.15 Field 23 Card Sequence Number.........................................................................157 5.2.16 Field 25 - POS Condition Code ............................................................................158 5.2.17 Field 26 - POS PIN Capture Code .......................................................................159 5.2.18 Field 27 - Authorization ID Response Length.......................................................159 5.2.19 Field 28 - Amount, Transaction Fee .....................................................................159 5.2.20 Field 29 - Amount, Settlement Fee.......................................................................159 5.2.21 Field 30 - Amount, Transaction Processing Fee ..................................................159 5.2.22 Field 31 - Amount, Settle Processing Fee............................................................160 5.2.23 Field 32 - Acquiring Institution ID Code................................................................160 5.2.24 Field 33 - Forwarding Institution ID Code.............................................................160 5.2.25 Field 35 - Track 2 Data .........................................................................................161 5.2.26 Field 37 - Retrieval Reference Number................................................................161 5.2.27 Field 38 - Authorization ID Response...................................................................162 5.2.28 Field 39 - Response Code....................................................................................162 5.2.29 Field 40 - Service Restriction Code......................................................................164 5.2.30 Field 41 - Card Acceptor Terminal ID...................................................................165 5.2.31 Field 42 - Card Acceptor ID Code ........................................................................165 5.2.32 Field 43 - Card Acceptor Name Location .............................................................165 5.2.33 Field 44 - Additional Response Data....................................................................166 5.2.34 Field 45 - Track 1 Data .........................................................................................167
Contents
vii 5.2.35 Field 48 - Additional Data .....................................................................................168 5.2.36 Field 49 - Currency Code, Transaction ................................................................169 5.2.37 Field 50 - Currency Code, Settlement ..................................................................169 5.2.38 Field 52 - PIN Data ...............................................................................................169 5.2.39 Field 53 - Security Related Control Information ...................................................170 5.2.40 Field 54 - Additional Amounts ..............................................................................170 5.2.41 Field 56 - Message Reason Code........................................................................171 5.2.42 Field 57 - Authorization Life-cycle Code...............................................................173 5.2.43 Field 58 - Authorizing Agent Id Code ...................................................................173 5.2.44 Field 59 - Echo Data.............................................................................................173 5.2.45 Field 66 - Settlement Code...................................................................................173 5.2.46 Field 67 - Extended Payment Code .....................................................................174 5.2.47 Field 70 - Network Management Information Code .............................................174 5.2.48 Field 73 - Date, Action ..........................................................................................174 5.2.49 Field 74 - Credits, Number ...................................................................................175 5.2.50 Field 75 - Credits, Reversal Number ....................................................................175 5.2.51 Field 76 - Debits, Number.....................................................................................175 5.2.52 Field 77 - Debits, Reversal Number .....................................................................175 5.2.53 Field 78 - Transfer, Number .................................................................................176 5.2.54 Field 79 - Transfer, Reversal Number ..................................................................176 5.2.55 Field 80 - Inquiries, Number .................................................................................176 5.2.56 Field 81 - Authorizations, Number........................................................................176 5.2.57 Field 82 - Credits, Processing Fee Amount..........................................................176 5.2.58 Field 83 - Credits, Transaction Fee Amount.........................................................177 5.2.59 Field 84 - Debits, Processing Fee Amount...........................................................177 5.2.60 Field 85 - Debits, Transaction Fee Amount..........................................................177 5.2.61 Field 86 - Credits, Amount....................................................................................177 5.2.62 Field 87 - Credits, Reversal Amount ....................................................................177 5.2.63 Field 88 - Debits, Amount .....................................................................................178 5.2.64 Field 89 - Debits, Reversal Amount......................................................................178 5.2.65 Field 90 - Original Data Elements ........................................................................178 5.2.66 Field 91 - File Update Code .................................................................................179 5.2.67 Field 95 - Replacement Amounts .........................................................................179 5.2.68 Field 97 - Amount, Net Settlement .......................................................................179 5.2.69 Field 98 - Payee ...................................................................................................180 5.2.70 Field 100 - Receiving Institution ID Code .............................................................180 5.2.71 Field 101 - File Name ...........................................................................................180 5.2.72 Field 102 - Account Identification 1 ......................................................................181 5.2.73 Field 103 - Account Identification 2 ......................................................................181 5.2.74 Field 118 - Payments, Number.............................................................................181
Contents
viii 5.2.75 Field 119 - Payments, Reversal Number .............................................................181 5.2.76 Field 123 - POS Data Code..................................................................................182 5.2.77 Field 125 - Network management information .....................................................186 5.2.78 Field 127.1 - Bitmap .............................................................................................186 5.2.79 Field 127.2 - Switch Key.......................................................................................186 5.2.80 Field 127.3 - Routing Information .........................................................................187 5.2.81 Field 127.4 - POS Data ........................................................................................187 5.2.82 Field 127.5 - Service Station Data........................................................................187 5.2.83 Field 127.6 - Authorization Profile ........................................................................188 5.2.84 Field 127.7 - Check Data......................................................................................189 5.2.85 Field 127.8 - Retention Data ................................................................................190 5.2.86 Field 127.9 - Additional Node Data ......................................................................190 5.2.87 Field 127.10 - CVV2 .............................................................................................190 5.2.88 Field 127.11 - Original Key...................................................................................190 5.2.89 Field 127.12 - Terminal Owner.............................................................................190 5.2.90 Field 127.13 - POS Geographic Data...................................................................191 5.2.91 Field 127.14 - Sponsor Bank................................................................................191 5.2.92 Field 127.15 - Address Verification Data..............................................................191 5.2.93 Field 127.16 - Address Verification Result ...........................................................192 5.2.94 Field 127.17 - Cardholder Information..................................................................192 5.2.95 Field 127.18 - Validation data...............................................................................192 5.2.96 Field 127.19 - Bank details ...................................................................................193 5.2.97 Field 127.20 - Originator / Authorizer date settlement .........................................193 5.2.98 Field 127.21 - Record identification......................................................................193 5.2.99 Field 127.22 - Structured Data .............................................................................194 5.2.100 Field 127.23 - Payee name and address .............................................................195 5.2.101 Field 127.24 - Payer account ...............................................................................195 5.2.102 Field 127.25 - Integrated circuit card (ICC) Data .................................................196 5.2.103 Field 127.26 - Original Node ................................................................................200 5.2.104 Field 127.27 - Card Verification Result.................................................................201 5.2.105 Field 127.28 - American Express Card Identifier (CID)........................................201 5.2.106 Field 127.29 - 3D Secure Data.............................................................................201 5.2.107 Field 127.30 - 3D Secure Result ..........................................................................202 5.2.108 Field 127.31 - Issuer Network ID..........................................................................202 5.2.109 Field 127.32 - UCAF data.....................................................................................202 5.2.110 Field 127.33 - Extended Transaction Type ..........................................................203 5.2.111 Field 127.34 - Account Type Qualifiers ................................................................206 5.2.112 Field 127.35 - Acquirer Network ID ......................................................................206 5.2.113 Field 127.39 - Original Response Code ...............................................................206 5.2.114 Field 128 - MAC Extended ...................................................................................206
Contents 5.3 XML SCHEMAS....................................................................................................................208 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.3.6 5.3.7 5.3.8 5.3.9 Iso8583PostXml ...................................................................................................208 ICC Data ...............................................................................................................214 StatementData......................................................................................................219 CardManagementUpdateData .............................................................................223 CardManagementUpdateLoad .............................................................................224 PrepaidMerchandise.............................................................................................225 PurchasingCardData ............................................................................................230 FleetCardData ......................................................................................................236 CheckData............................................................................................................238
ix
5.3.10 AirlineItineraryData ...............................................................................................241 5.3.11 VehicleRentalData................................................................................................244 5.3.12 LodgingData .........................................................................................................248
Concepts
1.
1.1
Concepts
Message types
The following message classes are defined: Authorization message class (1); Financial message class (2); Issuer File Update Advice message class (3); Reversal message class (4); Reconciliation message class (5); Administration message class (6); Network management message class (8); and Notification message class (9).
An authorization is an approval or guarantee of funds given by the card issuer to the acquirer. Authorization messages are not intended to permit the application of the approved transaction amount to the cardholders account for billing. It is typically only used to update the open-to-buy limit of the cardholder. Another way of putting this would be to say that the cardholders available balance changes, but their ledger balance remains unchanged. A financial transaction permits the application of the approved transaction amount to the cardholders account for billing. In other words, the cardholders ledger balance is affected. An Issuer File Update Advice is used to request an Issuer file update function. A reversal is used by the acquirer to partially or completely nullify the effects of a previous financial or authorization transaction. A reconciliation transaction is used to provide financial totals between Postilion and the card issuer host application. An administration transaction is used for hot-card notifications and to send messages to an issuing institution for administrative purposes e.g. request new check book. A network management transaction is used to synchronize cryptographic keys between Postilion and the third party. A notification message is used to notify a third party, called a Control Node, of a switched transaction that took place between a source and sink node interface.
1.2
MAC Support
When a message is sent from one system to another in an EFT network, it may be important to ensure that the message is not tampered with. This is achieved with message authentication. Message authentication operates by sharing an operational Message Authentication Key (KWA) between two systems. Depending upon the requirements of each system this key can be defined statically or exchanged dynamically under a Key Encrypting Key (KEK). If message authentication is required, each party uses the Message Authentication Key (KWA) and the message data to derive a four byte code called the Message Authentication Code (MAC). This MAC is then stored in the message before transmission. The receiving party takes the message and calculates the MAC using the same KWA. If the codes match, then the message is intact and the parties can be sure that only systems in the same security zone could have communicated the message. If the codes do not match, an error is logged. The MAC generation algorithm is based on the DES CBC mode and is specified in the ANSI X9.9 standard.
Concepts
1.2.1
Messages supported
The PostBridge Interface supports MACing on all message types except Network Management (0800) messages. The PostBridge MAC Configuration Console can be used to configure the set of message types which should be MACed.
1.2.2
1.2.2.1
MAC Code
The four byte MAC code is based upon the MAC key and message data.
MAC Key
The MAC key is a single length cryptographic key called a MAC Working Key (MWK). This can be either a static or dynamic key. In the case of a static key there will be one key which will be used for all MAC functions. In the case of dynamic there will be two keys both of which will be used for MAC functions (Key 1 and Key 2). At any one stage only one key will be used to generate MAC codes but both keys could be used to authenticate MAC codes. The one key used to generate the MAC codes is called the active key; the other key will be called the inactive key. During the key exchange process the active / inactive keys will switch. I.e. the active key will become the inactive key and the inactive key will become the active key (See below for more information). When the active key generates a MAC code for a message it places this MAC code in Mac Extended (field 128). It also puts its key number in this field. I.e. if key 2 is currently the active key it will be used to generate all MAC codes, and it will place its number (2) in field 128 along with the MAC code. When authenticating the MAC code the system will first retrieve the key number from MAC Extended. It will then use the key number to decide which key to use when authenticating the code. I.e. if the key number in MAC Extended is 2 the system will use key 2 to authenticate the code.
1.2.2.2
Message Data
The message data consists of a combination of fields from the message. The values in these fields will be concatenated together and the value resulting from this will be used along with the MAC key to generate a MAC code. The PostBridge interface allows for any combination of fields to be used per message type. The combination of fields per message type can be configured in the PostBridge MAC Configuration Console.
1.2.3
Dynamic Key Exchange

The PostBridge Interface supports both static MAC Working Keys (MWK) and the dynamic exchange of MWKs.
1.2.3.1
Static MWKs
Using this scheme the PostBridge interface will use one MWK which will be statically defined on the Postilion System using the Hardware Security Module Configuration Console. This value of this key must be manually loaded and maintained. All MAC codes will be generated using this key. The PostBridge interface will use static MWK's per default.
1.2.3.2
Dynamic MWKs
In this scheme the PostBridge interface will use two MWK's (Key 1 and Key 2). At any particular time one of these keys will be marked as the Active Key and one as the Inactive key. The Active key will be used to generate all MAC codes on outgoing messages. Each of these outgoing message will contain an identifier which will indicate which key (1 or 2) was used to generate its MAC value. Depending on the identifier in the message either key 1 or 2 will be used to authenticate the MAC. E.g. if the message contains the identifier '1' it indicates that key 1 was used to calculate its MAC and key 1 will be used to authenticate the MAC. The values of keys 1 and 2 are dynamic and will be changed periodically by the PostBridge interface. Please refer to MAC Key Exchange Management section for more information on the key exchange process.
Concepts Support for dynamic MWK's in the PostBridge interface can be enabled using the PostBridge MAC Configuration Console.
1.2.4
Exception Processing
Various exceptions related to MACing can occur on the PostBridge interface. They will be processed as follows:
Exception Condition The PostBridge interface received a message from the remote entity containing an invalid MAC Code. The PostBridge interface received a message from the remote entity containing a MAC code, but MACing has not been enabled for that particular message type on the Postilion system. The PostBridge interface received a message from the remote entity which did not contain a MAC code, but MACing is enabled for that particular message type on the Postilion system. Processing The interface will respond to the remote entity with a Format Error Response message and an error event will be logged in the NT event log. The interface will respond to the remote entity with a Format Error Response message and an error event will be logged in the NT event log. The interface will respond to the remote entity with a Format Error Response message and an error event will be logged in the NT event log.
1.3
MAC Key Management

The PostBridge Mac Working Key (MWK) exchange process is based upon the Master/Session Key exchange process but uses two keys rather than one. One key can be viewed as a new or active key, while the other will be an old or inactive key. The active key will always be the key that has most recently been exchanged, while the inactive key will always have the value of the previous active key. The MAC code will always be generated using the active key, but the code will be authenticated using either the active or inactive key depending on which key was used to originally generate the code. Using this scheme the PostBridge interface can process transactions throughout the key exchange process and messages that still contain a MAC code generated by the previous key can still be correctly processed. (This could occur under various exception conditions. For example a message sent to the remote before key exchange but arriving after the key exchange request due to a communications problem will still contain a MAC code generated by an "old" key). The actual key exchange process will only differ slightly from the normal Master/Session Key exchange process. In the normal process there is only one key and this key's value is periodically generated and exchanged. In this scheme there are two keys and while their values are also periodically generated and exchanged the keys alternate between periods. For example: In the normal process you have key A, and every 24 hours key A's value is newly generated and exchanged. In this scheme you have key B and C. At the end of the first 24 hours key B's value is exchanged. After another 24 hours key C's value is exchange. After another 24 hours key B's value is again exchanged. This process continues ad infinitum. The names of the keys are not important. During processing the keys will be referred to as Key 1 and Key 2. The actual keys referred to must be configured on the system. On the Postilion system this can be done using the PostBridge Configuration Console. The detail of the key exchange process varies between Acquirer and Issuer systems.
1.3.1
Acquirer
The key exchange process uses the concept of an active and inactive key. The active key is the key that has most recently been exchanged; the inactive key is the key that was active before that key exchange. The acquirer will always initiate the key exchange process by sending a Network Management Request (0800) message to the issuer. This message will indicate that a key exchange is required, and which key should be exchanged. The acquirer will always exchange the inactive key. The MAC Extended (field 128) will contain the key number of the current inactive key (1 or 2). The issuer will generate a new value for the specified key and send this value back in the Network Management Response (0810). Upon receipt of this message the acquirer will apply the new value to
Concepts the inactive key. If this value could not be successfully applied or the acquirer did not receive the response within a certain interval the acquirer will resend the original request. This will continue until the value can be successfully applied to the inactive key. Once this value has been successfully applied the inactive and active keys are switched. I.e. the current active key is marked as inactive, and the current inactive key is marked as active.
1.3.2
Issuer
The issuer does not concern itself over which key is active and which key is inactive. The issuer will receive a Network Management Request (0800) for a key exchange from the acquirer. This message will contain the number of the key that should be exchanged (1 or 2). The issuer will generate a new value for this key and respond back to the remote with this value.
1.3.3
Example
For this example assume that the 2 keys defined on the acquirer system are ACQUIRER_KEY_A and ACQUIRER_KEY_B. On the issuer system the 2 keys defined are ISSUER_KEY_A and ISSUER_KEY_B. ACQUIRER_KEY_A and ISSUER_KEY_A have the same values, as do ACQUIRER_KEY_B and ISSUER_KEY_B. On the acquirer system key 1 is configured as ACQUIRER_KEY_A and key 2 is configured as ACQUIRER_KEY_B. On the issuer system key 1 is configured as ISSUER_KEY_A and key 2 is configured as ISSUER_KEY_B.
1.3.3.1
Acquirer Processing
Action (1) (2) (3) (4) (5) Key exchange request sent to remote for Key 2 Receive key exchange response Apply new key value to key 2 Active Key 1 Key 1 Key 1 Key 2 Key 2 Inactive Key 2 Key 2 Key 2 Key 1 Key 1
(1) As we start our example we assume that Key 1 is currently active and Key 2 is currently inactive (2) The Key exchange timer expires and a key exchange request is sent to the remote (issuer). As the inactive key is always exchanged the request for Key 2. (3) The Key exchange response is received with the new value for key 2. (4) The new value for key 2 is successfully applied and the active and inactive keys are switched. (5) 24 hours later the process repeats with key 1 inactive and key 2 active.
1.3.3.2
Issuer Processing
The issuer processing for key exchange messages is simple. The issuer will receive a key exchange request and as part of this request the affected key will be given (1 or 2). It will then generate a new value for the relevant key and respond back to the remote entity with the new value.
Concepts
1.4
active/active
PostBridge can be configured as part of an active/active issuer deployment (refer to the PostBridge User Guide - Interface Configuration). The purpose of this configuration is to keep issuer systems (e.g. PostCard) in sync with each other. PostBridge alters its processing of notification advices (9x20) when configured for active/active. A typical scenario would be as follows:
a. Postilion sends a 0x20 (advice) to the authorizing system. b. The authorizing system processes the 0x20 (advice) and responds with a 0x30 (advice response). c. Postilion sends a 9x20 (notification advice) to the control node to notify it of the transaction that took place. The PostBridge control node interchange changes the message type to a regular advice and forwards it to an alternate/fallback Postilion system. d. The alternate Postilion system processes the 0x20 (advice) and responds with a 0x30 (advice response). The message type is changed to a 9x30 (notification advice response) and forwarded to the Postilion that initiated the notification.
Implementation
2.
Implementation
Information transmitted between a third party system and the PostBridge interface must comply with the format expected by the interface. The interface expects information to be in either Bitmap or XML format. A system communicating with the PostBridge interface must construct messages according to either of these two formats. Messages sent to the PostBridge interface are typically transmitted across a physical communication medium such as a network cable. Information transmitted in this manner is usually treated by a network application as an array of bytes. A system communicating with the PostBridge interface must therefore be able to process an array of bytes received, as well as to pack information into an array of bytes for transmission across a physical communication medium. Typically the following functionality must be provided by such a system. Unpack and validate incoming messages. Extract field values from unpacked messages. Set and validate field values for outgoing messages. Pack outgoing messages.
2.1
Bitmap Message Format

A system that communicates with the PostBridge interface must construct messages according to the Postilion implementation of the ISO 8583 standard. Messages constructed as such have three main components: Message type identifier One or two bitmaps Series of data elements
2.1.1
Message type identifier

The message type identifier is a 4-digit numeric field with the following sub-fields: the first 2 digits are the Message class and the last 2 digits are the Message function.
An example of a message type identifier for a financial request transaction sent to the PostBridge interface is: '0200'.
2.1.1.1
Message class
00 reserved for ISO use 01 authorization 02 financial 03 file action 04 reversal/chargeback 05 reconciliation 06 administrative 07 reserved for ISO use 08 network management 09 to 99 reserved
Implementation
2.1.1.2
Message function
00 request 01 request repeat 02 completion 03 completion repeat 10 request response 12 completion response 20 advice 21 advice repeat 30 advice response
2.1.2
Bitmap(s)
The second message component is made up of one or two 8-byte bitmaps. 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. Less frequently 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. For example, consider the following bitmap fragment: 11110010 00111100 ...... From this we can see that a second bitmap is present - the first, most significant bit of the first byte is set to 1. Field 2 (the PAN) will be present in the message, because the second bit is set to 1. Field 3 (the Processing Code) will be present, because the third bit is set to 1.
2.1.3
Data elements
The third message component is made up of a series of data elements (fields). Some data elements are of fixed length, while some are variable in length. In the case of a variable length data element, the actual length of the data element is provided by a length indicator. The length indicator is either 2 or 3 numeric digits, depending on the definition of the field. For example, the Primary account number (PAN) can have a length of up to 28 digits. A PAN with value 5412193376721126 (i.e. length of 16 digits) will have a length indicator of 16. The value of the PAN in a message to the PostBridge interface will be 165412193376721126. A data element has restrictions in terms of the type of content that it can contain. For example, the Processing code (field 3) can contain numeric data only, while the Card acceptor name location (field 43) can contain alphanumeric data only. A number of Postilion specific data elements have been defined, such as Echo data (field 59), and the Postilion private field (field 127). The Postilion private field (field 127) is the last field of the message, and contains a number of sub-fields. It has a 6 digit length indicator, and consists of an 8-byte bitmap
Implementation followed immediately by the sub-fields. The presence (1) or absence (0) of each sub-field is indicated by the bitmap. The bitmap will always be present if any sub-fields are present.
2.1.4
TCP/ IP Header
When using the TCP/IP network communications protocol, a 2-byte header is prefixed to all messages sent to/from Postilion. The header is used as an indicator of the length of the TCP/IP stream. The first byte contains the quotient of the length of the message (excluding this header) and 256. The second byte contains the remainder of this division.
2.1.5
Implementation Guidelines
What follows are guidelines for developing an application communicating with the PostBridge interface by means of the Bitmap message format. There are many possible ways of implementing such an application, each have their own advantages and disadvantages. The data types used to store the message type identifier, bitmaps and data elements message components must be determined. These components are typically treated as a stream of binary digits when received from a network link. It therefore makes sense to store each of these components as an array of bytes. Throughout the following explanation we will assume that each of these components is stored as a byte array.
2.1.5.1
Compose Message to PostBridge

When constructing a message to the PostBridge interface, the following three components: the message type identifier, one or both of the bitmap fields, and the data elements component,
must be concatenated together into a single byte array. The following code shows how this can be done (the '+' sign is used to represent the byte array concatenation operator):
msg_to_postbridge = msg_type_identifier + bitmap_1 if (first position of bitmap_1 == '1') { msg_to_postbridge = msg_to_postbridge + bitmap_2 } for (all data elements with set values) { msg_to_postbridge = msg_to_postbridge + set_field }
2.1.5.2
Unpack a Message from PostBridge

In order to unpack a message received from the PostBridge interface it is necessary to check that every field present in the message conforms to the relevant fields' content specifications i.e. each field has pre-defined specifications for the length, format and type of packing that field content must have. If the field conforms to the specification, it can be unpacked; else an exception should be raised. The byte array that is received from a network device is unpacked by referring to the bitmap field that indicates which fields are present in the message. Fields are unpacked sequentially, starting at the first field in the byte array. The length indicator associated with a field, that precedes the field content in the byte array, indicates whether a field is a fixed length field or a variable length field. A check should be made as to whether the length indicator received in the byte array for a specific field, corresponds to the one defined by the ISO 8583 standard. If this is the case, the number of bytes equal to the length of the field can be extracted from the byte array, and these bytes can then be checked against the format and packing specifications for the field in question. The format and packing specifications are determined by the ISO 8583 standard. The standard specifies that the format of the content of message fields must conform to the format class which is
Implementation pre-defined for each message field. Examples of ISO 8583 format classes are 'numeric', 'alphanumeric', 'binary' etc. The packing specification specifies how a message field is packed (or encoded) into a byte array. Examples of packing specifications are the Hexadecimal or Base64 packing methods (these methods are typically used for the encoding of binary data into the ASCII text representation). The following code shows how a byte array received from a network device could be processed:
for (all fields in message from postbridge as indicated in bitmap component(s)) { if(isLengthIndicatorValid(msg_from_postbridge, offset, field_num)) { field_length = getLength(msg_from_postbridge, offset, field_num) if(isPackingValid(msg_from_postbridge, offset, field_num, field_length) && isFormatValid(msg_from_postbridge, offset, field_num, field_length)) { message_fields[field_num++] = getField(msg_from_postbridge, offset, field_length) offset += field_length } else { throw exception } } else { throw exception } }
The 'msg_from_postbridge' variable holds a byte array with the message as received from the network device. The 'offset' variable holds the index in the byte array where the next message field to be processed starts. The 'field_num' variable holds the number of the field being processed as specified by the ISO 8583 standard. The code iterates through all the fields in the message. The code checks the length, format and packing of each field. The length indicator is firstly checked for validity. If the indicator is valid, the field length is extracted from the byte array, else an exception is thrown. Now that the field length is known, the format and packing of the field can be checked. If both of these are valid, the field is extracted and stored in an array, and the offset variable is incremented by the field length. If either the format or packing of the field is invalid, an exception is thrown.
Implementation
10
2.2
XML Message Format

The PostBridge interface supports the processing of ISO 8583 messages in XML format. Messages sent to the interface in XML format should be formatted according to the following DTD/ XSD: Iso8583PostXml DTD Iso8583PostXml XSD
Binary fields i.e. fields 52, 53, 127.29 and 127.32, must be encoded in hexadecimal text format. All other fields must be formatted as ASCII text. In order to construct an XML formatted message to the PostBridge interface, message fields are populated by means of providing content to the relevant XML element e.g. a typical 0200 message would look as follows:
<?xml version="1.0" encoding="UTF-8"?> <Iso8583PostXml> <MsgType>0200</MsgType> <Fields> <Field_002>4839123456709012</Field_002> <Field_003>000000</Field_003> <Field_004>000000001500</Field_004> <Field_007>0604074705</Field_007> <Field_011>804058</Field_011> <Field_012>074808</Field_012> <Field_013>0604</Field_013> <Field_014>0812</Field_014> <Field_015>0905</Field_015> <Field_022>901</Field_022> <Field_025>02</Field_025> <Field_026>05</Field_026> <Field_028>000000500</Field_028> <Field_030>000000500</Field_030> <Field_032>483912</Field_032> <Field_035>4839123456709012=08125876305082011</Field_035> <Field_037>D000A0030000</Field_037> <Field_040>507</Field_040> <Field_041>FOFUGUT1</Field_041> <Field_042>191121119111112</Field_042> <Field_043>Postilion Cafeteria Rondebosch ZA</Field_043> <Field_049>710</Field_049> <Field_056>1510</Field_056> <Field_059>0000000072</Field_059> <Field_123>211401213041013</Field_123> <Field_127_002>0007713856</Field_127_002> <Field_127_009>013040604040604016501100330000</Field_127_009> <Field_127_012>My Terminal Business</Field_127_012> <Field_127_020>20100604</Field_127_020> </Fields> </Iso8583PostXml>
Message Flows
11
3.
3.1
Message Flows
Source node interface
This section describes message flows between a remote entity and Postilion using the PostBridge source node interface. It explains which message types are used and how messages are exchanged. The processing of authorization and financial transactions under normal conditions is described. In addition, the following exception conditions are covered: lost request lost response connection to Postilion down transaction not completed as authorized
Whenever the remote entity sends a message to Postilion, it should start a timer. If the timer expires before the response to the message is received, the message can be retransmitted with the message type indicator showing that it is a repeat transmission. If the message is a request and no response is received after a number of retransmissions, the remote entity should decline the transaction and send an acquirer reversal advice (0420) message. All advice messages must be retransmitted until acknowledged by Postilion.
Message Flows
12
3.1.1
0100/0101
Messages to PostBridge
Authorization request (repeat) Sent to initiate inquiry transactions, such as balance inquiries. The message can be repeated a number of times. If no response is received within a certain time, the acquirer should decline the transaction.
Message Type ID Description
0120/0121
Authorization advice (repeat) Sent to inform of an authorization transaction (e.g. stand-in authorization) which has completed at the point of service. The message can be repeated a number of times.
0200/0201
Financial request (repeat) Sent to initiate inquiry, debit, credit, payment and transfer transactions. The message can be repeated a number of times. If no response is received within a certain time, the acquirer should decline the transaction.
0202/0203
Financial completion request (repeat) Sent to complete inquiry, debit, credit, payment and transfer transactions (if dual message on-line draft capture is used). A completion must be preceded by a 0200 (or 0201).
0220/0221
Financial Transaction Advice (repeat) Sent to advise Postilion of a Financial transaction that has taken place. This can be for a transaction which was authorized by the remote entity, or for a transaction that was authorized by a preceding 0100 message.
0320/0321 0332 0400/0401
Acquirer File Update Advice (repeat) Sent to request an Acquirer file update function. Issuer File Update Advice Response Sent to respond to a prior 0322 or 0323. Reversal request (repeat) Sent to fully or partially reverse a previous authorization or funds transfer. Can be received from a Source Node Interface. Sent to a Sink Node Interface.
0420/0421 0500/0501
Reversal advice (repeat) Sent to inform the issuer of a complete or partial reversal of a previous authorization or financial transaction. Acquirer reconciliation request (repeat) Sent to request the confirmation of totals (number and value). The message can be repeated a number of times. If no response is received within a certain time, the acquirer should decline the transaction.
0520/0521
Acquirer reconciliation advice (repeat) Sent to initiate batch cut-over and request the confirmation of totals (number and value). The totals contained in the message are those maintained by the acquirer.
0532
Card issuer reconciliation advice response Sent in response to a card issuer reconciliation advice It indicates whether or not the totals accumulated by the acquirer matches the totals received from Postilion.
0600/0601 0620/0621
Administration request (repeat) Sent to request an administrative function such as flagging a card as 'hot' or sending a message to the bank. Administration advice (repeat) Sent to advise the issuer of administrative functions that must be performed such as flagging a card as 'hot' or sending a message to the bank.
0800/0801
Network Management request (repeat) Sent to synchronize cryptographic keys between Postilion and the third party.
Message Flows
13
3.1.2
0110
Messages from PostBridge

Authorization request response Sent in response to an authorization request (inquiry). In the case of an approval it contains the requested information. If declined, it contains the declined action to be taken.
0130 0210 0212 0230 0322/0323 0330 0410 0430 0510 0522/0523
Authorization advice response Sent in response to an authorization advice. It indicates if the Postilion accepts or rejects the transfer of financial liability. Financial request response Sent in response to a financial request. It can indicate a full approval, partial approval or the declined action to be taken. Financial completion response Sent in response to a 0202 (financial completion request). Applicable when the dual message-pair protocol is used. Financial Transaction advice response Sent in response to a Financial Transaction advice. Issuer file update advice (repeat) Sent to request an Issuer file update function. Acquirer File Update Advice Response Used to respond to a prior 0320 or 0321. Reversal request response Sent in response to a prior 0400 or 0401. Reversal advice response Sent in response to a reversal advice. Acquirer reconciliation request response Sent in response to an acquirer reconciliation request. It contains the totals maintained by Postilion for the acquirer. Card issuer reconciliation advice (repeat) Sent to initiate batch cut-over and request the confirmation of totals (number and value). The totals contained in the message are those maintained by Postilion.
0530
Acquirer reconciliation advice response Sent in response to an acquirer reconciliation advice It indicates whether or not the totals accumulated by Postilion matches the totals received from the acquirer.
0610
Administration response Sent in response to an administration request. It indicates whether or not the administrative function was performed successfully or not.
0630
Administration advice response Sent in response to an administration advice. It indicates whether or not the administrative function was performed successfully or not.
0810
Network Management request response Sent in response to a network management request.
Message Flows
14
3.1.3
3.1.3.1
Authorization transactions
Normal Condition
This is the normal pre-authorization scenario where an authorization, requesting reservation of funds (accurate or estimate) is followed by the corresponding financial advice indicating the actual amount.
a. The remote entity sends a 0100 (authorization request) to Postilion to request reservation of funds. b. Postilion approves or declines the request by sending a 0110 (authorization request response) to the remote entity with the appropriate action code. c. The transaction completes for the same or different amount. The remote entity forwards a (new) financial transaction by sending a 0220 (financial advice) indicating the amount for which authorization was obtained, the actual amount and the fact that the advice was previously authorized. The data identifying the original 0100 is sent in the original data field. d. Postilion captures the financial transaction and responds to the remote entity with a 0230 (financial advice response).
3.1.3.2
Lost Request
Message Flows
15
a. The remote entity sends a 0100 (authorization request) to Postilion to request reservation of funds and starts a timer. The message is lost on the network. b. The timer expires and the remote entity performs stand-in authorization. This might result in a voice call to the card issuer requesting approval for the transaction. The remote entity forwards a (new) reversal transaction by sending a 0420 (reversal) indicating a time-out condition and an actual amount of zero. The original 0100 is identified by the original data field. c. Postilion received the reversal but can not match it to any 0100. It therefore assumes that it never processed the 0100 and therefore no additional processing is required. Postilion responds with a 0430 (reversal response). The following steps are only applicable if the stand-in authorization resulted in funds transfer. The remote entity sends the transaction to Postilion once the connection to Postilion is re-established. d. The remote entity forwards a (new) financial transaction by sending a 0220 (financial advice) indicating the reason for the advice and the actual amount. e. Postilion captures the financial transaction and responds to the remote entity with a 0230 (financial advice response).
3.1.3.3
Lost Reply
a. The remote entity sends a 0100 (authorization request) to Postilion to request reservation of funds. b. Postilion approves or declines the request by sending a 0110 to the remote entity with the appropriate action code. The message is lost on the network. c. The timer expires and the remote entity performs stand-in authorization. This might result in a voice call to the card issuer requesting approval. The remote entity forwards a (new) reversal transaction by sending a 0420 (reversal) indicating a time-out condition and an actual amount of zero. The data identifying the original 0100 is sent in the original data field. d. Postilion received the reversal and matches it to the related 0100. It performs the necessary processing to negate the effect of the 0100 before responding with a 0430 (reversal response). The following steps are only applicable if the stand-in resulted in funds transfer. The remote entity sends the transaction once the connection to Postilion is re-established. e. The remote entity forwards a (new) financial transaction by sending a 0220 indicating the reason for the advice and the actual amount. f. Postilion captures the financial transaction and responds to the remote entity with a 0230 (financial advice response).
Message Flows
16
3.1.3.4
Not Completed
This happens when an authorization requesting reservation of funds does not result in a cardholder transaction, because the cardholder decided to cancel the transaction.
a. The remote entity sends a 0100 (authorization request) to Postilion to request reservation of funds. b. Postilion approves or declines the request by sending a 0110 (authorization request response) to the remote entity with the appropriate action code. c. The actual transaction does not take place (e.g. is cancelled by the cardholder). The remote entity forwards a (new) reversal transaction by sending a 0420 (reversal advice) indicating the reason for the reversal and the actual amount. The data identifying the original 0100 is sent in the original data field. d. Postilion received the reversal and matches it to the related 0100. It performs the necessary processing to negate the effect of the 0100 before responding with a 0430 (reversal response).
3.1.3.5
Postilion Down
a. The remote entity attempts to send a 0100 (authorization request) to Postilion to request reservation of funds, but the connection to Postilion is down. The remote entity performs stand-in authorization. This might result in a voice call to the card issuer requesting approval for the transaction.
Message Flows The following steps are only applicable if the stand-in authorization resulted in funds transfer. The remote entity sends the transaction to Postilion once the connection to Postilion is re-established. b. The remote entity forwards a (new) financial transaction by sending a 0220 (financial advice) indicating the reason for the advice and the actual amount.
17
c. Postilion captures the financial transaction and responds to the remote entity with a 0230 (financial advice response).
3.1.4
3.1.4.1
Financial transactions singe message pair

Normal Condition
a. The remote entity sends a 0200 (financial request) to Postilion to request authorization for a financial transaction. b. Postilion captures the transaction and approves or declines the request by sending a 0210 (financial request response) to the remote entity with the appropriate action code.
3.1.4.2
Lost Request
Message Flows a. The remote entity sends a 0200 (financial request) to Postilion to request authorization for a financial transaction and starts a timer. The message is lost on the network.
18
b. The timer expires and the remote entity performs stand-in authorization. The remote entity forwards a (new) reversal transaction by sending a 0420 (reversal) indicating a time-out condition and an actual amount of zero. The data identifying the original 0200 is sent in the original data field. c. Postilion received the reversal but can not match it to any 0200. It therefore assumes that it never processed the 0200 and therefore no additional processing is required. Postilion responds with a 0430 (reversal response). The following steps are only applicable if the stand-in authorization resulted in funds transfer. The remote entity sends the transaction to Postilion once the connection to Postilion is re-established. d. The remote entity forwards a (new) financial transaction by sending a 0220 (financial advice) indicating the reason for the advice and the actual amount. e. Postilion captures the financial transaction for cardholder billing purposes and responds to the remote entity with a 0230 (financial advice response).
3.1.4.3
Lost Reply
a. The remote entity sends a 0200 (financial request) to Postilion to request authorization for a financial transaction and starts a timer. b. Postilion captures the transaction and approves or declines the request by sending a 0210 (financial request response) to the remote entity with the appropriate action code. The message is lost on the network. c. The timer expires and the remote entity performs stand-in authorization. The remote entity forwards a (new) reversal transaction by sending a 0420 (reversal) indicating a time-out condition and an actual amount of zero. The data identifying the original 0200 is sent in the original data field. d. Postilion received the reversal and matches it to the related 0200. It performs the necessary processing to negate the effect of the 0200 on the cardholder account before responding with a 0430 (reversal response). The following steps are only applicable if the stand-in authorization resulted in funds transfer. The transaction is sent once the connection to Postilion is re-established. e. The remote entity forwards a (new) financial transaction by sending a 0220 indicating the reason for the advice and the actual amount. f. Postilion captures the financial transaction for cardholder billing purposes and responds to the remote entity with a 0230 (financial advice response).
Message Flows
19
3.1.4.4
Not Completed
a. The remote entity sends a 0200 (financial request) to Postilion to request authorization for a financial transaction. b. Postilion captures the transaction and approves or declines the request by sending a 0210 (financial request response) to the remote entity with the appropriate action code. c. The transaction does not complete as authorized. The remote entity forwards a (new) reversal transaction by sending a 0420 (reversal advice) indicating the reason for the reversal and the actual amount. The data identifying the original 0200 is sent in the original data field. d. Postilion captures the reversal transaction and responds to the remote entity with a 0430 (reversal advice response).
3.1.4.5
Postilion Down
a. The remote entity attempts to send a 0200 (financial request) to Postilion to request authorization for a financial transaction, but the connection to Postilion is down. The remote entity performs standin authorization. This might result in a voice call to the card issuer requesting approval for the transaction. The following steps are only applicable if the stand-in authorization resulted in funds transfer. The remote entity sends the transaction to Postilion once the connection to Postilion is re-established.
Message Flows b. The remote entity forwards a (new) financial transaction by sending a 0220 (financial advice) indicating the reason for the advice and the actual amount. c. Postilion captures the financial transaction for cardholder billing purposes and responds to the remote entity with a 0230 (financial advice response).
20
3.1.4.6
Below Floor Limits
The transaction amount is below floor limits and the remote entity performs stand-in authorization. The following steps are only applicable if the stand-in authorization resulted in funds transfer. The remote entity sends the transaction to Postilion once the connection to Postilion is re-established. b. The remote entity forwards a (new) financial transaction by sending a 0220 (financial advice) indicating the reason for the advice and the actual amount. c. Postilion captures the financial transaction and responds to the remote entity with a 0230 (financial advice response).
3.1.5
3.1.5.1
Financial transactions dual message pair

Normal Condition
a. The remote entity sends a 0200 (financial request) to Postilion to request authorization for a financial transaction.
Message Flows b. Postilion captures the transaction and approves or declines the request by sending a 0210 (financial request response) to the remote entity with the appropriate action code. c. The remote entity sends a 0202 (financial completion request) to Postilion to complete the transaction
21
d. Postilion secures the 0202 and responds immediately with a 0212 (financial completion response) to the remote entity.
3.1.5.2
Lost Request
a. The remote entity sends a 0200 (financial request) to Postilion to request authorization for a financial transaction. b. The remote entity times out, and sends a 0202 (financial completion) to Postilion. The completion indicates the timeout condition for the transaction. c. Postilion responds immediately with a 0212 (financial completion response) without securing the transaction.
3.1.5.3
Lost Reply
Message Flows a. The remote entity sends a 0200 (financial request) to Postilion to request authorization for a financial transaction. b. Postilion obtains authorization (from the sink node or stand-in) and returns a 0210 (financial response) to the remote entity
22
c. The remote entity times out, and sends a 0202 (financial completion) to Postilion. The completion indicates the timeout condition for the transaction. d. Postilion responds immediately with a 0212 (financial completion response) without securing the transaction.
3.1.5.4
Lost Completion
a. The remote entity sends a 0200 (financial request) to Postilion to request authorization for a financial transaction. b. Postilion obtains authorization (from the sink node or stand-in) and returns a 0210 (financial response) to the remote entity c. The remote entity sends a 0202 (financial completion request) to Postilion to complete the transaction d. Postilion secures the 0202 and responds immediately with a 0212 (financial completion response) to the remote entity. e. The remote entity times out, and re-transmits the 0202 (financial completion) to Postilion. f. Postilion recognizes the duplicate and responds with a 0212 (financial completion response) to the remote entity
3.1.6
Reconciliation
Reconciliation transactions are used to assist in the reconciliation of the remote entity with Postilion. The remote entity should maintain a set of totals for a given reconciliation period (batch). During this period Postilion will maintain a set of totals for the remote entity (see note below). At any stage during the reconciliation period, the remote entity can query the totals maintained by Postilion with a query transaction. To advance to a new reconciliation period (i.e. perform batch cut-over), the remote entity can perform a batch cut-over transaction. To do this, the remote entity sends its totals for the period in a 0520 message. Postilion will match these totals to the totals it maintained. It will respond to the remote entity indicating the outcome of this comparison before advancing to a new batch. Alternatively,
Message Flows
23
Postilion can send a 0522 (card issuer reconciliation advice) message to the remote entity. The 0522 message contains the totals maintained by Postilion for a reconciliation period. The remote entity should cut-over its batch and respond with a 0532 (card issuer reconciliation advice response) message indicating the outcome of a comparison between the totals maintained locally and the totals provided in the 0522 message. Note: Postilion must be configured during the installation process to maintain batch totals for the reconciliation messages to contain meaningful data. If Postilion does not maintain totals, the reconciliation messages will contain totals depicting zero financial worth.
3.1.6.1
Acquirer Batch-cutover Normal Condition
a. The remote entity sends a 0520 (reconciliation advice) to Postilion to initiate batch cut-over. The totals that the remote entity maintained for this period (batch) are forwarded in the message. b. Postilion approves or declines the advice by sending a 0530 (reconciliation advice response) to the remote entity indicating whether or not the reconciliation was successful (i.e. in balance). The totals maintained by Postilion for the remote entity is returned in this message.
3.1.6.2
Acquirer Batch-cutover Lost Request
Message Flows
24
a. The remote entity sends a 0520 (reconciliation advice) to Postilion to initiate batch cut-over and starts a timer. The totals that the remote entity maintained for this period (batch) are forwarded in the message. The message is lost on the network. b. The timer expires. The remote entity re-transmits the remote entity reconciliation advice with a repeat indicator (the message type is 0521). c. Postilion approves or declines the advice by sending a 0530 (reconciliation advice response) to the remote entity indicating whether or not the reconciliation was successful (i.e. in balance). The totals that Postilion maintained for the remote entity are returned in this message.
3.1.6.3
Acquirer Batch-cutover Lost Reply
a. The remote entity sends a 0520 (reconciliation advice) to Postilion to initiate batch cut-over and starts a timer. The totals that the remote entity maintained for this period (batch) are forwarded in the message. b. Postilion approves or declines the advice by sending a 0530 (reconciliation advice response) to the remote entity indicating whether or not the reconciliation was successful (i.e. in balance). The totals maintained by Postilion for the remote entity is returned in this message. The message is lost on the network. c. The timer expires. The remote entity re-transmits the remote entity reconciliation advice with the repeat indicator (the message type is 0521). d. Postilion recognizes the 0520 as a duplicate and returns a 0530 indicating whether or not the reconciliation (previous) was successful (i.e. in balance). The totals that Postilion maintained for the remote entity are returned in this message.
3.1.6.4
Acquirer Batch-cutover Postilion Down

This is the situation where Postilion is not available, typically due to a break in communications.
Message Flows
25
a. The remote entity attempts to send a 0520 (reconciliation advice) to Postilion to initiate batch cutover, but the connection to Postilion is down. The remote entity waits for the connection to be reestablished, and does not allow any new transactions on the remote entity. b. The connection to Postilion is re-established. The remote entity sends a 0520 (reconciliation advice) to Postilion to initiate batch cut-over. The totals that the remote entity maintained for this period (batch) are forwarded in the message. c. Postilion approves or declines the advice by sending a 0530 (reconciliation advice response) to the remote entity indicating whether or not the reconciliation was successful (i.e. in balance). The totals maintained by Postilion maintained for the remote entity is returned in this message.
3.1.6.5
Issuer Batch-cutover Normal Condition
a. Postilion sends a 0522 (reconciliation advice) to the remote entity to initiate batch cut-over. The totals that Postilion maintained for this period (batch) are forwarded in the message. b. The remote entity approves or declines the advice by sending a 0532 (reconciliation advice response) to Postilion indicating whether or not the reconciliation was successful (i.e. in balance). The totals that the remote entity maintained are returned in this message.
Message Flows
26
3.1.6.6
Issuer Batch-cutover Lost Request
a. Postilion sends a 0522 (reconciliation advice) to the remote entity to initiate batch cut-over and starts a timer. The totals that Postilion maintained for this period (batch) are forwarded in the message. The message is lost on the network. b. The timer expires. Postilion re-transmits the issuer reconciliation advice with a repeat indicator (the message type is 0523). c. The remote entity approves or declines the advice by sending a 0532 (reconciliation advice response) to Postilion indicating whether or not the reconciliation was successful (i.e. in balance). The totals that the remote entity maintained are returned in this message.
3.1.6.7
Issuer Batch-cutover Lost Reply
a. Postilion sends a 0522 (reconciliation advice) to the remote entity to initiate batch cut-over and starts a timer. The totals that Postilion maintained for this period (batch) are forwarded in the message. b. The remote entity approves or declines the advice by sending a 0532 (reconciliation advice response) to Postilion indicating whether or not the reconciliation was successful (i.e. in balance). The totals that the remote entity maintained are returned in this message. The message is lost on the network.
Message Flows
27
c. The timer expires. Postilion re-transmits the issuer reconciliation advice with a repeat indicator (the message type is 0523). d. The remote entity recognizes the 0522 as a duplicate and returns a 0532 indicating whether or not the reconciliation (previous) was successful (i.e. in balance). The totals that the remote entity maintained are returned in this message.
3.1.6.8
Issuer Batch-cutover Acquirer Down

This is the situation where the remote entity is not available, typically due to a break in communication.
a. Postilion attempts to send a 0522 (reconciliation advice) to the remote entity to initiate batch cutover, but the connection to the remote entity is down. Postilion waits for the connection to be reestablished. b. The connection to the remote entity is re-established. Postilion sends a 0522 (reconciliation advice) to the remote entity to initiate batch cut-over. The totals that Postilion maintained for this period (batch) are forwarded in the message. c. The remote entity approves or declines the advice by sending a 0532 (reconciliation advice response) to Postilion indicating whether or not the reconciliation was successful (i.e. in balance). The totals that the remote entity maintained are returned in this message.
3.1.7
Administration
Administration transactions are used to request or inform the issuer of administrative functions that should be performed such as flagging a card as 'hot' or sending a message to the bank. Hot card notification (hold) transactions are initiated by ISO8583 0600/0620 messages sent to Postilion. The Postilion proprietary transaction type of 90 is defined for this transaction. The message reason code should specify the reason a hold was placed on the card. Message to bank transactions are also initiated by ISO8583 0600/0620 messages sent to Postilion. The Postilion proprietary transaction type of 91 is defined for this transaction. The message reason code should specify 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. Whenever a remote entity sends an administrative request (0600) to Postilion, it should start a timer. If the timer expires before the response to the message is received, the message can be retransmitted with a repeat indicator. If no response is received after a number of re transmissions, the remote entity should decline the transaction. Administration advice messages should be re-transmitted until acknowledged by Postilion.
Message Flows
28
3.1.7.1
Normal Condition
a. The remote entity sends a 0600 (administration request) to Postilion to request an administrative function. b. Postilion processes the administrative function (flags a card as 'hot' or logs a message to bank) and sends a 0610 (administration request response) to the remote entity with the appropriate action code.
3.1.7.2
Lost Request
a. The remote entity sends a 0600 (administration request) to Postilion to request an administrative function and starts a timer. The message is lost on the network. b. The timer expires. The remote entity optionally declines the transaction or re-transmits the administration request with a repeat indicator. c. Postilion processes the administrative function (flags a card as 'hot' or logs a message to bank) and sends a 0610 (administration request response) to the remote entity with the appropriate action code.
Message Flows
29
3.1.7.3
Lost Reply
a. The remote entity sends a 0600 (administration request) to Postilion to request an administrative function and starts a timer. b. Postilion processes the administrative function (flags a card as 'hot' or logs a message to bank) and sends a 0610 (administration request response) to the remote entity with the appropriate action code. The message is lost on the network. c. The timer expires and the remote entity optionally re-transmits the administration request (with repeat indicator) or declines the transaction.
3.1.7.4
Postilion Down
a. The remote entity attempts to send a 0600 (administration request) to Postilion to request an administrative function, but the connection to Postilion is down. The remote entity performs stand-in authorization, adding the administration request to the store and forward queue and waits for the connection to be re-established. b. The remote entity forwards the administrative function to Postilion by sending a 0620 (administration advice) indicating the reason for the advice.
Message Flows c. Postilion processes the administrative function (flags a card as 'hot' or logs a message to bank) and sends a 0630 (administration advice response) to the remote entity with the appropriate action code.
30
3.1.8
Sign On / Sign Off

Sign on messages are sent to the remote entity serve to notify the remote entity that you are ready to process transactions. The remote entity will respond back to the Sign on message acknowledging that it received your sign on request and indicating whether it is ready to initiate transaction processing as well. Once a sign on / sign on response has been successfully exchanged the system is ready to process transactions. Sign off messages are the inverse of this. A sign off message is sent to the remote to indicate that you cannot process transactions anymore. If the PostBridge Source Node interface is not signed on to the remote system it should not receive any transactions from that system. If it does received a transaction from the remote it will ignore it and log an error event. Responses to transactions will however still be processed correctly as this response might have originated from the remote system before sign off was initiated.
3.1.8.1
Sign On - Postilion Originated
a. Postilion sends a 0800 network management request to the remote with Network Management Information Code (field 70) set to Sign On (001). b. The remote entity responds to the network management request (0800) with a network management request response (0810).
Message Flows
31
3.1.8.2
Sign Off - Postilion Originated
a. Postilion sends a 0800 network management request to the remote with Network Management Information Code (field 70) set to Sign Off (002). b. The remote entity responds to the network management request (0800) with a network management request response (0810).
3.1.8.3
Sign On - Remote Originated
a. The remote entity sends a 0800 network management request to Postilion with Network Management Information Code (field 70) set to Sign On ('001'). b. Postilion responds to network management request (0800) with a network management request response (0810).
Message Flows
32
3.1.8.4
Sign Off - Remote Originated
a. The remote entity sends a 0800 network management request to Postilion with Network Management Information Code (field 70) set to Sign Off ('002'). b. Postilion responds to network management request (0800) with a network management request response (0810).
3.1.8.5
Sign On - Postilion Originated Lost Reply
a. Postilion sends a 0800 network management request to the remote with Network Management Information Code (field 70) set to Sign On (001). b. The remote entity responds to the network management request (0800) with a network management request response (0810). The response is lost on the network. c. Depending on the configuration of the system Postilion will either disconnect and reconnect after a short interval, or will send another sign on request (step a).
Message Flows
33
3.1.8.6
Sign Off - Postilion Originated Lost Reply
a. Postilion sends a 0800 network management request to the remote with Network Management Information Code (field 70) set to Sign Off (002) . b. The remote entity responds to the network management request (0800) with a network management request response (0810). The response is lost on the network. c. The Postilion System is already signed off and does nothing if it does not receive a response.
3.1.9
Key Management
Key management transactions are used to exchange the PIN encryption working (session) key and MAC working (session) keys 1 of the remote entity with Postilion. The master/session key management scheme is used. The basic principle involved in sharing session keys using a master key are that one of the two parties generates a new session key that is encrypted using the master key before sending it to the other party. The recipient can decrypt the session key because they share a master (or initial) key. The same master key must therefore be loaded statically on both the Postilion and remote host systems prior to key management transactions taking place. The remote entity should initiate a key management transaction at least once a day (typically after reconciliation). It should always perform a key management transaction on initialization or power up. To initiate a key management transaction, the remote entity sends a 0800 (network management request) message to Postilion, indicating that it requires a new key. On receipt of this message, Postilion generates a new session key, encrypts it under the master key and sends this encrypted value to the remote entity. Since the remote entity has the master key, it can decrypt the value and extract the session key.
3.1.9.1
PIN Working Key Exchange - Normal Condition

This message flow is only defined for Postilion PostBridge Interchanges that are configured to perform PIN processing.
While MACing makes use of 2 session keys only one session key will be exchanged at a time. This allows the master/session key management scheme to still be used. Refer to the MAC Key Management section for more information.
Message Flows
34
a. The remote entity sends a 0800 (network management request) to Postilion to request a new PIN working key. The Network Management Code (field 70) should contain a value of '101' to identify the message as a PIN Working Key Exchange. b. Postilion generates a new PIN working key and returns it encrypted under the master key in a 0810 (network management request response) to the remote entity with the appropriate action code.
3.1.9.2
PIN Working Key exchange - Lost Reply

a. The remote entity sends a 0800 (network management request) to Postilion to request a new PIN working key. The Network Management Code (field 70) should contain a value of '101' to identify the message as a PIN Working Key Exchange.
Message Flows
35
b. Postilion generates a new PIN working key and returns it encrypted under the master key in a 0810 (network management request response) to the remote entity with the appropriate action code. The message is lost on the network. c. The timer expires and the remote entity declines the transaction. The remote entity can not perform any transactions until the keys are synchronized.
3.1.9.3
MAC Working Key exchange - Normal Condition

This message flow is only defined for Postilion PostBridge Interchanges that are configured to support message MAC'ing and dynamic MAC key exchange. (This is configured in the Postilion PostBridge MAC Configuration Console.)
a. The remote entity sends a 0800 (network management request) to Postilion to request a new MAC working key. The Network Management Code (field 70) should contain a value of '160' to indicate that this is a MAC working key exchange message. The MAC Extended (field 128) will contain a key number indicating which key should be exchanged. b. Postilion generates a new MAC working key and returns it encrypted under the master key in a 0810 (network management request response) to the remote entity with the appropriate action code
3.1.9.4
MAC Working Key exchange - Lost Reply

Message Flows
36
a. The remote entity sends a 0800 (network management request) to Postilion to request a new MAC working key. The Network Management Code (field 70) of this message should contain a value of '160' to indicate that this is a MAC working key exchange message. The MAC Extended (field 128) will contain a key number indicating which key should be exchanged. b. Postilion generates a new MAC working key and returns it encrypted under the master key in a 0810 (network management request response) to the remote entity with the appropriate action code. The message is lost on the network. c. The remote entity times out. The remote entity resends the 0800 to request a new key.
3.1.10
3.1.10.1
Echo test
Postilion Originated
a. Postilion sends a 0800 (echo test request) to the remote entity with Network Management Information Code (field 70) set to Echo Test (301) b. The remote entity responds to the echo test network management request (0800) with a network management request response (0810).
Message Flows
37
3.1.10.2
Remotely Originated
a. The remote entity sends a 0800 (echo test request) to Postilion with Network Management Information Code (field 70) set to Echo Test (301) b. Postilion responds to the echo test network management request (0800) with a network management request response (0810).
3.1.11
MAC enabled transactions

When a message is sent from one system to another in an EFT network, it may be important to ensure that the message is not tampered with. This is achieved with message authentication. Message authentication operates by sharing an operational Message Authentication Key (KWA) between two systems. Depending upon the requirements of each system this key can be defined statically or exchanged dynamically under a Key Encrypting Key (KEK). If message authentication is required, each party uses the Message Authentication Key (KWA) and the message data to derive a four byte code called the Message Authentication Code (MAC). This MAC is then stored in the message before transmission. The receiving party takes the message and calculates the MAC using the same KWA. If the codes match, then the message is intact and the parties can be sure that only systems in the same security zone could have communicated the message. If the codes do not match, an error is logged. The MAC generation algorithm is based on the DES CBC mode and is specified in the ANSI X9.9 standard. Any message type on the Postilion system can be configured to use a MAC using the PostBridge MAC Configuration Console. If dynamic key exchange is enabled MACing will make use of two keys. The MAC Extended (field 128) will contain the number of the key (1 or 2) to indicate which key was used to generate the code and which key should be used to authenticate the code.
Message Flows
38
3.1.11.1
Normal Condition
a. The remote entity sends a request to Postilion containing a MAC Code. b. The PostBridge Interface successfully validates the MAC value before passing on the message to the Transaction Manager. c. The Transaction Manager processes the request and sends a response to the remote entity. d. The PostBridge Interface generates a MAC code for the message and places it in MAC Extended (field 128) before passing the message to the remote entity. e. The remote entity successfully validates the MAC value and processes the response as normal.
3.1.11.2
Invalid MAC in Request
a. The remote entity sends a request to Postilion which does not contain a MAC Code. b. While processing the request the PostBridge Interface finds a MAC error. (This can be any one of the exception conditions listed in the MAC Support Section.) The interface does not pass the message to Transaction Manager. c. The PostBridge Interface responds to the remote entity with a Format Error Response message. The Format Error Response message is a normal response message containing minimal data and a Response Code of '30' (Format Error). If configured, this message can also contain a MAC Code.
Message Flows d. The remote entity receives the Format Error Response message and initiates whatever exception processing is required.
39
3.1.11.3
Invalid MAC in Response
a. The remote entity sends a request to Postilion containing a MAC Code. b. The PostBridge Interface successfully validates the MAC value before passing on the message to the Transaction Manager. c. The Transaction Manager processes the request and sends a response to the remote entity. d. The PostBridge Interface generates a MAC code for the message and places it in Mac Extended (field 128) before passing the message to the remote entity. e. The remote entity finds that the MAC code in the response message is invalid and initiates whatever MAC exception processing is required on its own system. f. The remote entity initiates a reversal of the original request message. Please refer to the 'Lost Reply' section of each message type for more information on the reversal process.
3.2
Sink node interface

This section describes message flows between the Postilion and a remote entity using the PostBridge sink node interface. It explains which message types are used and how messages are exchanged. The processing of transactions under normal conditions is described for requests, reversals and (stand-in) advices. In addition, the following exception conditions are covered: lost request lost response lost completion remote entity down transaction not completed as authorized
Whenever Postilion sends a message to the remote entity, it starts a timer. If the timer expires before the response to the message is received, the message is optionally retransmitted with the message type indicator showing that it is a repeat transmission. If the message is a request and no response is received after a number of transmissions, Postilion (optionally) performs stand-in authorization. Advice messages are retransmitted until acknowledged by the remote entity.
Message Flows
40
3.2.1
0100/0101

Authorization request (repeat) Sent when the transaction can not complete at the point of service until the response message is received indicating the action to be taken. The use of this message does not imply that the cardholder is present (e.g. mail order).
0120/0121
Authorization advice (repeat) Sent to inform the card issuer of an authorization transaction (e.g. stand-in authorization) that has completed at the point of service.
0200/0201
Financial request (repeat) Sent when the transaction can not complete at the point of service until the response message is received indicating the action to be taken. The use of this message does not imply that the cardholder is present (e.g. mail order).
0202/0203
Financial completion request (repeat) Sent to complete inquiry, debit, credit, payment and transfer transactions (if dual message on-line draft capture is used). A completion will always be preceded by a 0200 (or 0201).
0220/0221
Financial Transaction Advice (repeat) Sent to advise the remote entity of a Financial Transaction that has taken place. This can be for a transaction which was authorized by the remote entity, for a Transaction authorized by Postilion, or for a transaction that was authorized by a preceding 0100 message.
0320/0321
Acquirer File Update Advice (repeat) Sent to advise an Acquirer file update function. Can be received from a Source Node Interface. Sent to a Sink Node Interface.
0332 0400/0401
Issuer File Update Advice Response Sent in response to a prior 0322 or 0323. Reversal request (repeat) Sent to fully or partially reverse a previous authorization or funds transfer. Can be received from a Source Node Interface. Sent to a Sink Node Interface.
0420/0421 0512 0532
Reversal advice (repeat) Sent to inform the issuer of a complete or partial reversal of a previous authorization or financial transaction. Card issuer reconciliation request response Sent in response to a card issuer reconciliation request. It contains the totals maintained by Postilion for the issuer. Card issuer reconciliation advice response Sent in response to a card issuer reconciliation advice. It indicates whether or not the totals accumulated by Postilion match the totals received from the host.
0520/0521
Acquirer reconciliation advice (repeat) Sent to initiate batch cut-over and to request the confirmation of totals (number and value). The totals contained in the message are those maintained by Postilion.
0600/0601 0620/0621
Administration request (repeat) Sent to request an administrative function such as flagging a card as 'hot' or sending a message to the bank. Administration advice (repeat) Sent to advise the issuer of administrative functions that must be performed such as flagging a card as 'hot' or sending a message to the bank.
0800/0801 9120/9121 9220/9221 9320/9321 9420/9421 9620/9621
Network Management request (repeat) Sent to synchronize cryptographic keys between Postilion and the third party. Authorization notification (repeat) Sent by Postilion to notify a third party, called a Control Node, of an authorization that took place. Transaction notification (repeat) Sent by Postilion to notify a third party, called a Control Node, of a transaction that took place. Acquirer File Update Notification (repeat) Sent by Postilion to notify a third party, called a Control Node, of an acquirer file update that took place. Reversal notification (repeat) Sent by Postilion to notify a third party, called a Control Node, of a reversal that took place. Administration notification (repeat) Sent by Postilion to notify a third party, called a Control Node, of an administration transaction that took place.
Message Flows
41
3.2.2
0110
Authorization request response Sent in response to an authorization request. It can indicate a full approval, partial approval or the declined action to be taken.
0130
Authorization advice response Sent in response to an authorization advice. It indicates if the card issuer accepts or rejects the transfer of financial liability.
0210 0212 0230 0322/0323 0330 0410 0430 0502/0503
Financial request response Sent in response to a financial request. It can indicate a full approval, partial approval or the declined action to be taken. Financial completion response Sent in response to a 0202 (financial completion request). Applicable when the dual message-pair protocol is used. Financial Transaction advice response Sent in response to a Financial Transaction advice. Issuer file update advice (repeat) Sent to request an Issuer file update function. Acquirer File Update Advice Response Used to respond to a prior 0320 or 0321. Reversal request response Sent in response to a prior 0400 or 0401. Reversal advice response Sent in response to a reversal advice. Note that the card issuer must always accept the reversal. Card issuer reconciliation request (repeat) Sent to request the confirmation of totals (number and value). The message can be repeated a number of times. If no response is received within a certain time, the issuer should decline the transaction.
0522/0523
Card issuer reconciliation advice (repeat) Sent to initiate batch cut-over and to request the confirmation of totals (number and value). The totals contained in the message are those maintained by the issuer.
0530
Acquirer reconciliation advice response Sent in response to an acquirer reconciliation advice. It indicates whether or not the totals accumulated by the host (if any) match the totals received from Postilion.
0610
Administration response Sent in response to an administration request. It indicates whether or not the administrative function was performed successfully or not.
0630
Administration advice response Sent in response to an administration advice. It indicates whether or not the administrative function was performed successfully or not.
0810 9130 9230 9430 9630 9330
Network Management request response Sent in response to a network management request. Authorization notification response Sent in response to an authorization notification. Transaction notification response Sent in response to a transaction notification. Reversal notification response Sent in response to a reversal notification. Administration notification response Sent in response to an administration notification. Acquirer File Update Notification Response Used to respond to a prior 9320.
Message Flows
42
3.2.3
3.2.3.1
Authorization transactions
Normal Condition
This is the normal pre-authorization scenario where an authorization requesting reservation of funds is followed by the corresponding financial advice indicating the actual amount.
a. Postilion sends a 0100 (authorization request) to the remote entity to request reservation of funds. b. If the amount can be authorized, the remote entity adapts the cardholders available balance. The remote entity approves or declines the request by sending a 0110 (authorization request response) to Postilion with the appropriate action code. c. The transaction completes for the same or different amount. Postilion forwards a (new) financial transaction by sending a 0220 (financial advice) indicating that the advice was previously authorized, the amount for which authorization was obtained and the actual amount. The data identifying the original 0100 is sent in the original data field. d. The remote entity captures the financial transaction for cardholder billing purposes and responds to Postilion with a 0230 (financial advice response).
3.2.3.2
Lost Request
a. Postilion sends a 0100 (authorization request) to the remote entity to request reservation of funds and starts a timer. The message is lost on the network.
Message Flows
43
b. The timer expires and Postilion performs stand-in authorization. This might result in a voice call to the remote entity requesting approval for the transaction. Postilion forwards a (new) reversal transaction by sending a 0420 (reversal) indicating a time-out condition and an actual amount of zero. The data identifying the original 0100 is sent in the original data field. c. The remote entity received the reversal but can not match it to any 0100. It therefore assumes that it never processed the 0100 and therefore no additional processing is required. The remote entity responds with a 0430 (reversal response). The following steps are only applicable if the stand-in authorization resulted in funds transfer. The transaction is moved to the store and forward queue for the remote entity and will be forwarded to the remote entity once a connection to the remote entity is re-established. d. Postilion forwards a (new) financial transaction by sending a 0220 (financial advice) indicating the reason for the advice. e. The remote entity captures the financial transaction for cardholder billing purposes and responds to Postilion with a 0230 (financial advice response).
3.2.3.3
Lost Reply
a. Postilion sends a 0100 (authorization request) to the remote entity to request reservation of funds and starts a timer. b. If the amount can be authorized, the remote entity adapts the cardholders available balance. The remote entity approves or declines the request by sending a 0110 to Postilion with the appropriate action code. The message is lost on the network. c. The timer expires and Postilion performs stand-in authorization. This might result in a voice call to the remote entity requesting approval for the transaction. Postilion forwards a (new) reversal transaction by sending a 0420 indicating a time-out condition and an actual amount of zero. The data identifying the original 0100 is sent in the original data field. d. The remote entity received the reversal and matches it to the related 0100. It adapts the cardholders available balance to negate the effect of the 0100 before responding with a 0430 (reversal response). The following steps are only applicable if the stand-in authorization resulted in funds transfer. The transaction is moved to the store and forward queue for the remote entity and will be forwarded to the remote entity once a connection to the remote entity is re-established. e. Postilion forwards a (new) financial transaction by sending a 0220 (financial advice) indicating the reason for the advice. f. The remote entity captures the financial transaction for cardholder billing purposes and responds to Postilion with a 0230 (financial advice response).
Message Flows
44
3.2.3.4
Not Completed
This happens when an authorization requesting reservation of funds does not result in a cardholder transaction, because the cardholder decided not to go ahead with the transaction.
a. Postilion sends a 0100 (authorization request) to the remote entity to request reservation of funds. b. If the amount can be authorized, the remote entity adapts the cardholders available balance. The remote entity approves or declines the request by sending a 0110 (authorization request response) to Postilion with the appropriate action code. c. The actual transaction does not take place (e.g. is cancelled by the cardholder). Postilion forwards a (new) reversal transaction by sending a 0420 (reversal advice) indicating the reason for the reversal and the actual amount. The data identifying the original 0100 is sent in the original data field. d. The remote entity received the reversal and matches it to the related 0100. It performs the necessary processing to negate the effect of the 0100 on the cardholders available balance before responding with a 0430 (reversal response).
3.2.3.5
Remote Entity Down
a. Postilion attempts to send a 0100 (authorization request) to the remote entity to request reservation of funds, but the connection to the remote entity is down. Postilion performs stand-in authorization. This might result in a voice call to the remote entity requesting approval for the transaction.
Message Flows
45
The following steps are only applicable if the stand-in authorization resulted in funds transfer. The transaction is moved to the store and forward queue for the remote entity and will be forwarded to the remote entity once a connection to the remote entity is re-established. b. Postilion forwards a (new) financial transaction by sending a 0220 (financial advice) indicating the reason for the advice and the actual amount. c. The remote entity captures the financial transaction for cardholder billing purposes and responds to Postilion with a 0230 (financial advice response).
3.2.4
3.2.4.1
Financial transactions single message pair

Normal Condition
a. Postilion sends a 0200 (financial request) to the remote entity to request authorization for a financial transaction. b. The remote entity captures the transaction for cardholder billing purposes and approves or declines the request by sending a 0210 (financial request response) to Postilion with the appropriate action code.
3.2.4.2
Lost Request
a. Postilion sends a 0200 (financial request) to the remote entity to request authorization for a financial transaction and starts a timer. The message is lost on the network.
Message Flows
46
b. The timer expires and Postilion performs stand-in authorization. Postilion forwards a (new) reversal transaction by sending a 0420 (reversal) indicating a time-out condition and an actual amount of zero. The data identifying the original 0200 is sent in the original data field. c. The remote entity received the reversal but can not match it to any 0200. It therefore assumes that it never processed the 0200 and therefore no additional processing is required. The remote entity responds with a 0430 (reversal response). The following steps are only applicable if the stand-in authorization resulted in funds transfer. The transaction is moved to the store and forward queue for the remote entity and will be forwarded to the remote entity once a connection to the remote entity is re-established. d. Postilion forwards a (new) financial transaction by sending a 0220 (financial advice) indicating the reason for the advice. e. The remote entity captures the financial transaction for cardholder billing purposes and responds to Postilion with a 0230 (financial advice response).
3.2.4.3
Lost Reply
a. Postilion sends a 0200 (financial request) to the remote entity to request authorization for a financial transaction and starts a timer. b. The remote entity captures the financial transaction for cardholder billing purposes and approves or declines the request by sending a 0210 (financial request response) to Postilion with the appropriate action code. The message is lost on the network. c. The timer expires and Postilion performs stand-in authorization. Postilion forwards a (new) reversal transaction by sending a 0420 (reversal) indicating a time-out condition and a zero final amount. The data identifying the original 0200 is sent in the original data field. d. The remote entity received the reversal and matches it to the related 0200. It performs the necessary processing to negate the effect of the 0200 on the cardholder account before responding with a 0430 (reversal response). The following steps are only applicable if the stand-in authorization resulted in funds transfer. The transaction is moved to the store and forward queue for the remote entity and will be forwarded to the remote entity once a connection to the remote entity is re-established. e. Postilion forwards a (new) financial transaction by sending a 0220 (financial advice) indicating the reason for the advice. f. The remote entity captures the financial transaction for cardholder billing purposes and responds to Postilion with a 0230 (financial advice response).
Message Flows
47
3.2.4.4
Not Completed
a. Postilion sends a 0200 (financial request) to the remote entity to request authorization for a financial transaction. b. The remote entity captures the financial transaction for cardholder billing purposes and approves or declines the request by sending a 0210 (financial request response) to Postilion with the appropriate action code. c. The transaction does not complete as authorized. The Postilion forwards a (new) reversal transaction by sending a 0420 (reversal advice) indicating the reason for the reversal and the actual amount. The data identifying the original 0200 is sent in the original data field. d. The remote entity captures the reversal transaction for cardholder billing purposes and responds to Postilion with a 0430 (reversal advice response).
3.2.4.5
Below Floor Limits
a. The transaction amount is below the local authorization limits and Postilion performs stand-in authorization. The following steps are only applicable if the stand-in authorization resulted in funds transfer. The transaction is moved to the store and forward queue for the remote entity and will be forwarded to the remote entity once a connection to the remote entity is re-established. b. Postilion forwards a (new) financial transaction by sending a 0220 (financial advice) indicating the reason for the advice.
Message Flows
48
c. The remote entity captures the financial transaction for cardholder billing purposes and responds to Postilion with a 0230 (financial advice response).
3.2.4.6
Remote Entity Down
a. Postilion attempts to send a 0200 (financial request) to the remote entity to request authorization for a financial transaction, but the connection to the remote entity is down. Postilion performs stand-in authorization. This might result in a voice call to the remote entity requesting approval for the transaction. The following steps are only applicable if the stand-in authorization resulted in funds transfer. The transaction is moved to the store and forward queue for the remote entity and will be forwarded to the remote entity once a connection to the remote entity is re-established. b. Postilion forwards a (new) financial transaction by sending a 0220 (financial advice) indicating the reason for the advice and the actual amount. c. The remote entity captures the financial transaction for cardholder billing purposes and responds to Postilion with a 0230 (financial advice response).
3.2.5
3.2.5.1
Financial transactions dual message pair

Normal Condition
Message Flows a. Postilion sends a 0200 (financial request) to the remote entity to request authorization for a financial transaction.
49
b. The remote entity captures the transaction and approves or declines the request by sending a 0210 (financial request response) to Postilion with the appropriate action code. c. Postilion sends a 0202 (financial completion request) to the remote entity to complete the transaction, irrespective of whether or not the transaction completed as authorized. d. The remote entity responds to the 0202 (financial completion request) with a 0212 (financial completion response) to Postilion.
3.2.5.2
Lost Request
a. Postilion sends a 0200 (financial request) to the remote entity to request authorization for a financial transaction. b. Postilion times out, and sends a 0202 (financial completion) to the remote entity. The completion indicates the timeout condition for the transaction (therefore reversing the transaction) c. The remote entity responds to the 0202 (financial completion) with a 0212 (financial completion response) to Postilion.
3.2.5.3
Lost Reply
a. Postilion sends a 0200 (financial request) to the remote entity to request authorization for a financial transaction.
Message Flows b. The remote entity authorizes the transaction and returns a 0210 (financial response) to Postilion, but the response message is lost on the network. c. Postilion times out, and sends a 0202 (financial completion) to the remote entity. The completion indicates the timeout condition for the transaction (therefore reversing the transaction) d. The remote entity responds to the 0202 (financial completion) with a 0212 (financial completion response) to Postilion.
50
3.2.5.4
Lost Completion
a. Postilion sends a 0200 (financial request) to the remote entity to request authorization for a financial transaction. b. The remote entity authorizes the transaction and returns a 0210 (financial response) to Postilion. c. Postilion sends a 0202 (financial completion request) to the remote entity to complete the transaction. d. The remote entity responds to the 0202 (financial completion request) with a 0212 (financial completion response) to Postilion. e. Postilion times out, and re-transmits the 0202 (financial completion) to the remote entity. f. The remote entity recognizes the duplicate and responds with a 0212 (financial completion response) to Postilion.
3.2.6
Reconciliation
Reconciliation transactions are used to assist in the reconciliation of the remote entity with Postilion. The remote entity may maintain a set of totals for a given reconciliation period (batch). During this period Postilion will maintain a set of totals for the remote entity (see note below). At a given (configurable) time of day, Postilion will advance to a new reconciliation period (i.e. perform batch cutover). Postilion can be configured to send a reconciliation message, containing the totals it maintained, to the remote entity when this happens. If this is the case, the remote entity could match these totals to the totals it maintains. Alternatively, the remote entity can send a 0522 (card issuer reconciliation advice) message to Postilion. The 0522 message contains the totals maintained by the remote entity for a reconciliation period. Postilion will cut-over its batch and respond with a 0532 (card issuer reconciliation advice response) message indicating the outcome of a comparison between the totals maintained locally and the totals provided in the 0522 message. Note: Postilion must be configured during the installation process to maintain batch totals for the reconciliation messages to contain meaningful data. If Postilion does not maintain totals, the reconciliation messages will contain totals depicting zero financial worth.
Message Flows
51
3.2.6.1
Acquirer Batch Cut-over - Normal Condition
a. Postilion sends a 0520 (reconciliation advice) to the remote entity to initiate batch cut-over. The totals that Postilion maintained for this period (batch) are forwarded in the message. b. The remote entity approves or declines the advice by sending a 0530 (reconciliation advice response) to Postilion indicating whether or not the reconciliation was successful (i.e. in balance). The totals that the remote entity maintained for the terminal are returned in this message.
3.2.6.2
Acquirer Batch Cut-over - Lost Request
a. Postilion sends a 0520 (reconciliation advice) to the remote entity to initiate batch cut-over and starts a timer. The totals maintained by Postilion for this period (batch) are forwarded in the message. The message is lost on the network. b. The timer expires. Postilion re-transmits the acquirer reconciliation advice with the repeat indicator (the message type is 0521). c. The remote entity approves or declines the advice by sending a 0530 (reconciliation advice response) to Postilion indicating whether or not the reconciliation was successful (i.e. in balance). The totals that the remote entity maintained for the terminal are returned in this message.
Message Flows
52
3.2.6.3
Acquirer Batch Cut-over - Lost Reply
a. Postilion sends a 0520 (reconciliation advice) to the remote entity to initiate batch cut-over. The totals that Postilion maintained for this period (batch) are forwarded in the message. b. The remote entity approves or declines the advice by sending a 0530 (reconciliation advice response) to Postilion indicating whether or not the reconciliation was successful (i.e. in balance). The totals that the remote entity maintained for the terminal are returned in this message. The message is lost on the network. c. The timer expires. Postilion re-transmits the acquirer reconciliation advice with the repeat indicator (the message type is 0520). d. The remote entity recognizes the 0520 as a duplicate and returns a 0530 indicating whether or not the reconciliation (previous) was successful (i.e. in balance). The totals that the remote entity maintained for the terminal are returned in this message.
3.2.6.4
Acquirer Batch Cut-over - Remote Entity Down

This is the situation where the remote entity is not available, typically due to a break in communications.
a. Postilion attempts to send a 0520 (reconciliation advice) to the remote entity to initiate batch cutover, but the connection to the remote entity is down.
Message Flows b. The connection to the remote entity is re-established. Postilion sends a 0520 (reconciliation advice) to the remote entity to initiate batch cut-over. The totals that Postilion maintained for this period (batch) are forwarded in the message. c. The remote entity approves or declines the advice by sending a 0530 (reconciliation advice response) to Postilion indicating whether or not the reconciliation was successful (i.e. in balance). The totals that the remote entity maintained for the terminal are returned in this message.
53
3.2.6.5
Issuer Batch Cut-over - Normal Condition
a. The remote entity sends a 0522 (reconciliation advice) to Postilion to initiate batch cut-over. The totals that the remote entity maintained for this period (batch) are forwarded in the message. b. Postilion approves or declines the advice by sending a 0532 (reconciliation advice response) to the remote entity indicating whether or not the reconciliation was successful (i.e. in balance). The totals that Postilion maintained for the terminal are returned in this message.
3.2.6.6
Issuer batch cut-over - lost request
a. The remote entity sends a 0522 (reconciliation advice) to Postilion to initiate batch cut-over and starts a timer. The totals that the remote entity maintained for this period (batch) are forwarded in the message. The message is lost on the network. b. The timer expires. The remote entity re-transmits the issuer reconciliation advice with the repeat indicator (the message type is 0523).
Message Flows
54
c. Postilion approves or declines the advice by sending a 0532 (reconciliation advice response) to the remote entity indicating whether or not the reconciliation was successful (i.e. in balance). The totals that Postilion maintained for the terminal are returned in this message.
3.2.6.7
Issuer Batch Cut-over - Lost Reply
a. The remote entity sends a 0522 (reconciliation advice) to Postilion to initiate batch cut-over. The totals that the remote entity maintained for this period (batch) are forwarded in the message. b. Postilion approves or declines the advice by sending a 0532 (reconciliation advice response) to the remote entity indicating whether or not the reconciliation was successful (i.e. in balance). The totals that Postilion maintained for the terminal are returned in this message. The message is lost on the network. c. The timer expires. The remote entity re-transmits the issuer reconciliation advice with the repeat indicator (the message type is 0523). d. Postilion recognizes the 0523 as a duplicate and returns a 0532 indicating whether or not the reconciliation (previous) was successful (i.e. in balance). The totals that Postilion maintained for the terminal are returned in this message.
3.2.6.8
Issuer Batch Cut-over - Postilion Down

This is the situation where Postilion is not available, typically due to a break in communications.
Message Flows
55
a. The remote entity attempts to send a 0522 (reconciliation advice) to Postilion to initiate batch cutover, but the connection to Postilion is down. b. The connection to Postilion is re-established. The remote entity sends a 0522 (reconciliation advice) to Postilion to initiate batch cut-over. The totals that the remote entity maintained for this period (batch) are forwarded in the message. c. Postilion approves or declines the advice by sending a 0532 (reconciliation advice response) to the remote entity indicating whether or not the reconciliation was successful (i.e. in balance). The totals that Postilion maintained for the terminal are returned in this message.
3.2.7
Administration
Administration transactions are used to request or inform the issuer of administrative functions that should be performed such as flagging a card as 'hot' or sending a message to the bank. Hot card notification (hold) transactions are initiated by ISO8583 0600/0620 messages sent by Postilion. The Postilion proprietary transaction type of 90 is defined for this transaction. The message reason code should specify the reason a hold was placed on the card. Message to bank transactions are also initiated by ISO8583 0600/0620 messages sent by Postilion. The Postilion proprietary transaction type of 91 is defined for this transaction. The message reason code should specify 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. Whenever Postilion sends an administrative request (0600) to the remote entity, it starts a timer. If the timer expires before the response to the message is received, the message is optionally re transmitted with a repeat indicator. If the message is a request and no response is received after a number of transmissions, Postilion (optionally) performs stand-in authorization. Non-interactive messages are re transmitted until acknowledged by the remote entity.
3.2.7.1
Normal Condition
a. Postilion sends a 0600 (administration request) to the remote entity to request an administrative function. b. The remote entity processes the administrative function and sends a 0610 (administration request response) to Postilion with the appropriate action code.
Message Flows
56
3.2.7.2
Lost Request
a. Postilion sends a 0600 (administration request) to the remote entity to request an administrative function and starts a timer. The message is lost on the network. b. The timer expires and Postilion performs stand-in authorization. Postilion forwards the administrative function to the remote entity by sending a 0620 (administration advice) indicating the reason for the advice. c. The remote entity processes the administrative function and sends a 0630 (administration advice response) to Postilion with the appropriate action code.
3.2.7.3
Lost Reply
a. Postilion sends a 0600 (administration request) to the remote entity to request an administrative function and starts a timer. b. The remote entity processes the administrative function and sends a 0610 (administration response) to Postilion with the appropriate action code. The message is lost on the network. c. The timer expires and Postilion performs stand-in authorization. Postilion forwards the administrative function to the remote entity by sending a 0620 (administration advice) indicating the reason for the advice. d. The remote entity matches the 0620 (administrative advice) to the previous 0600 (administrative request), determines whether the administrative function has been performed and responds with a 0630 (administration advice response).
Message Flows
57
3.2.7.4
Remote Entity Down
a. Postilion attempts to send a 0600 (administration request) to the remote entity to request an administrative function, but the connection to the remote entity is down. Postilion performs stand-in authorization. The administrative function is added to the store and forward queue and Postilion waits until the connection is re-established. b. Postilion forwards the administrative function to the remote entity by sending a 0620 (administration advice) indicating the reason for the advice. c. The remote entity processes the administrative function and sends a 0630 (administration advice response) to Postilion with the appropriate action code.
3.2.8
Sign On / Sign Off

Sign on messages are sent to the remote entity serve to notify the remote entity that you are ready to process transactions. The remote entity will respond back to the Sign on message acknowledging that it received your sign on request and indicating whether it is ready to initiate transaction processing as well. Once a sign on / sign on response has been successfully exchanged the system is ready to process transactions. Sign off messages are the inverse of this. A sign off message is sent to the remote to indicate that you cannot process transactions anymore. If the PostBridge Sink Node interface is not signed on to the remote system it should not receive any transactions from that system. If it does received a transaction from the remote it will ignore it and log an error event. Responses to transactions will however still be processed correctly as this response might have originated from the remote system before sign off was initiated
Message Flows
58
3.2.8.1
Sign On - Postilion Originated
a. Postilion sends a 0800 network management request to the remote with Network Management Information Code (field 70) set to Sign On (001). b. The remote responds to the network management request (0800) with a network management request response (0810).
3.2.8.2
Sign Off - Postilion Originated
a. Postilion sends a 0800 network management request to the remote with Network Management Information Code (field 70) set to Sign Off (002). b. The remote responds to the network management request (0800) with a network management request response (0810).
Message Flows
59
3.2.8.3
Sign On - Remote Originated
a. The remote entity sends a 0800 network management request to Postilion with Network Management Information Code (field 70) set to Sign On (001) . b. Postilion responds to the network management request (0800) with a network management request response (0810).
3.2.8.4
Sign Off - Remote Originated
a. The remote entity sends a 0800 network management request to Postilion with Network Management Information Code (field 70) set to Sign Off (002). b. Postilion responds to the network management request (0800) with a network management request response (0810).
Message Flows
60
3.2.8.5
Sign On - Postilion Originated Lost Reply
a. Postilion sends a 0800 network management request to the remote with Network Management Information Code (field 70) set to Sign On (001). b. The remote responds to the network management request (0800) with a network management request response (0810). The message is lost on the network. c. Depending on the configuration of the system Postilion will either disconnect and reconnect after a short interval, or will send another sign on request (step a).
3.2.8.6
Sign Off - Postilion Originated Lost Reply
a. Postilion sends a 0800 network management request to the remote with Network Management Information Code (field 70) set to Sign Off (002). b. The remote responds to the network management request (0800) with a network management request response (0810). The message is lost on the network. c. The Postilion System is already signed off and does nothing if it does not receive a response.
Message Flows
61
3.2.9
Key management
Key management transactions are used to exchange the PIN encryption working (session) key and MAC working (session) keys 2 of the issuer with Postilion. The master/session key management scheme is used. The basic principle involved in sharing session keys using a master key are that one of the two parties generates a new session key that is encrypted using the master key before sending it to the other party. The recipient can decrypt the session key because they share a master (or initial) key. The same master key must therefore be loaded statically on both the Postilion and remote entity systems prior to key management transactions taking place. To initiate a key management transaction, Postilion sends a 0800 (network management request) message to the issuer, indicating that it requires a new session key. On receipt of this message, the issuer should generate a new session key, encrypt it under the master key and return this encrypted value to Postilion. Since Postilion has the master key, it can decrypt the value and extract the session key.
3.2.9.1
PIN Working Key Exchange - Normal Condition

a. Postilion sends a 0800 (network management request) to the issuer to request a new PIN working key. The Network Management Code (field 70) should contain a value of '101' to identify the message as a PIN Working Key Exchange. This message will be initiated upon start-up of the node or by a timer which will expire 24 hours after each successful PIN working key exchange or 60 seconds after each failed PIN working key exchange. b. The issuer generates a new PIN working key and returns it encrypted under the master key in a 0810 (network management request response) to Postilion with the appropriate action code.
While MACing makes use of 2 session keys only one session key will be exchanged at a time. This allows the master/session key management scheme to still be used. Refer to the MAC Key Management section for more information.
Message Flows
62
3.2.9.2
PIN Working Key Exchange - Lost Reply

a. Postilion sends a 0800 (network management request) to the issuer to request a new PIN working key. The Network Management Code (field 70) should contain a value of '101' to identify the message as a PIN Working Key Exchange. This message will be initiated upon start-up of the node or by a timer which will expire 24 hours after each successful PIN working key exchange or 60 seconds after each failed PIN working key exchange. b. The issuer generates a new PIN working key and returns it encrypted under the master key in a 0810 (network management request response) to Postilion with the appropriate action code. The message is lost on the network. c. When Postilion does not receive the response within a certain amount of time a timer expires and Postilion declines the transaction. Another timer is started which will initiated the key exchange process again after 60 seconds (step a). This process will continue until the PIN working key has been successfully synchronized. Postilion will not perform any transactions until the keys are synchronized.
3.2.9.3
MAC Working Key Exchange - Normal Condition

Message Flows
63
a. Postilion sends a 0800 (network management request) to the issuer to request a new MAC working key. The Network Management Code (field 70) will contain a value of '160' to indicate that the message is a MAC working key exchange. The MAC Extended (field 128) will contain a key number indicating which key should be exchanged. This message will be initiated upon start-up of the node or by a timer which will expire 24 hours after each successful MAC working key exchange or 60 seconds after each failed MAC working key exchange. b. The issuer generates a new MAC working key and returns it encrypted under the master key in a 0810 (network management request response) to Postilion with the appropriate action code.
3.2.9.4
MAC Working Key Exchange - Lost Reply

a. Postilion sends a 0800 (network management request) to the issuer to request a new MAC working key. The Network Management Code (field 70) will contain a value of '160' to indicate that the message is a MAC working key exchange. The MAC Extended (field 128) will contain a key number indicating which key should be exchanged. This message will be initiated upon start-up of the node or by a timer which will expire 24 hours after each successful MAC working key exchange or 60 seconds after each failed MAC working key exchange. b. The issuer generates a new MAC working key and returns it encrypted under the master key in a 0810 (network management request response) to Postilion with the appropriate action code. The message is lost on the network. c. Postilion does not receive the response within a certain time interval. A timer is started in order to initiate the key exchange process again after 60 seconds (step a). This process will continue for five cycles. During this time Postilion will not perform any transactions. If Postilion does not receive a response to the fifth key exchange request it will disconnect from the remote. Postilion can be reconnected by issuing an 'OPEN' command from the Postilion Monitor, after which Postilion will connect the remote entity and initiate the key exchange process again. (step a).
Message Flows
64
3.2.10
3.2.10.1
Echo test
Postilion Originated
a. Postilion sends a 0800 (echo test request) to the issuer with Network Management Information Code (field 70) set to Echo Test (301). b. The issuer responds to the echo test network management request (0800) with a network management request response (0810).
3.2.10.2
Remotely Originated
a. The issuer sends a 0800 (echo test request) to Postilion with Network Management Information Code (field 70) set to Echo Test (301). b. Postilion responds to the echo test network management request (0800) with a network management request response (0810).
Message Flows
65
3.2.11
Notification
When a transaction is switched from a Source Node to a Sink Node it is often useful for a third Node (a Control Node) to be notified of these transactions. This requirement is identified by a configurable parameter in the Postilion configuration consoles. When such a transaction completes (irrespective of its approval or denial), Postilion forwards a notification advice transaction to the applicable Control Node. The notification advice can take the form of an authorization, transaction or reversal notification. These messages are non-interactive and are re transmitted until acknowledged by the remote entity.
3.2.11.1
Normal Condition
a. Postilion sends a 9x20 (notification advice) to the remote entity to inform the issuer of a switched transaction that took place between a source and sink node. b. The issuer processes the 9x20 (notification advice) and responds with a 9x30 (notification advice response).
3.2.11.2
Remote Entity Down
a. Postilion attempts to send a 9x20 (notification advice) to the remote entity to advise the issuer of a switched transaction that took place between a source and sink node, but the connection to the remote entity is down. The notification advice is added to the store and forward queue and Postilion waits until the connection is re-established.
Message Flows b. Postilion forwards the notification advice to the remote entity by sending a 9x20 (notification advice). c. The issuer processes the 9x20 (notification advice) and responds with a 9x30 (notification advice response).
66
3.2.12
MAC enabled transactions

When a message is sent from one system to another in an EFT network, it may be important to ensure that the message is not tampered with. This is achieved with message authentication. Message authentication operates by sharing an operational Message Authentication Key (KWA) between two systems. Depending upon the requirements of each system this key can be defined statically or exchanged dynamically under a Key Encrypting Key (KEK). If message authentication is required, each party uses the Message Authentication Key (KWA) and the message data to derive a four byte code called the Message Authentication Code (MAC). This MAC is then stored in the message before transmission. The receiving party takes the message and calculates the MAC using the same KWA. If the codes match, then the message is intact and the parties can be sure that only systems in the same security zone could have communicated the message. If the codes do not match, an error is logged. The MAC generation algorithm is based on the DES CBC mode and is specified in the ANSI X9.9 standard. Any message type on the Postilion system can be configured to use a MAC using the PostBridge MAC Configuration Console. If dynamic key exchange is enabled MACing will make use of two keys. The MAC Extended (field 128) will contain the number of the key (1 or 2) to indicate which key was used to generate the code and which key should be used to authenticate the code.
3.2.12.1
Normal Condition
a. The Transaction Manager sends a request to the remote entity. b. The PostBridge Interface generates a MAC Code for the message and places it in MAC Extended (field 128) before passing the message to the remote entity. c. The remote entity receives the request and successfully validates the MAC code. d. The remote entity generates a response message and generates a MAC Code which is placed into MAC Extended (field 128). e. The PostBridge Interface receives the response and successfully validates the MAC Code before passing the message to the Transaction Manager where it will be processed as normal.
Message Flows
67
3.2.12.2
Invalid MAC in request
a. The Transaction Manager sends a request to the remote entity. b. The PostBridge Interface generates a MAC Code for the message and places it in MAC Extended (field 128) before passing the message to the remote entity. c. The remote entity receives the request but finds that the MAC code is invalid. (This can be any one of the exception conditions listed in the MAC Support Section.) The remote entity initiates whatever MAC exception processing is required on its own system. d. The remote entity responds back to Postilion with a Format Error Response message. If configured, this message can contain a MAC Code. e. The PostBridge interface validates the MAC value and passes the message to Transaction Manager where it will be processed as normal.
3.2.12.3
Invalid MAC in response
a. The Transaction Manager sends a request to the remote entity. b. The PostBridge Interface generates a MAC Code for the message and places it in MAC Extended (field 128) before passing the message to the remote entity. c. The remote entity receives the request and successfully validates the MAC code.
Message Flows
68
d. The remote entity generates a response message and generates a MAC Code which is placed into MAC Extended (field 128). e. The PostBridge Interface receives the response and finds that the MAC Code is invalid. (This can be any one of the exception conditions listed in the MAC Support Section.) The interface aborts processing of the message and logs an error event in the NT event log. f. When the Transaction Manager does not receive a response within a certain interval it will initiate a reversal for the original request. Please refer to the 'Lost Reply' section of each message type for more information on the reversal process.
Message Content
69
4.
4.1
4.1.1
Field 2
Message Content
Receive - Authorization Request (Repeat) (0100/0101)
Description Primary account number Condition Conditional Notes Should be present for a card initiated transaction (or a check verification transaction using the plastic card format) if Track 2 data is not present (i.e. manual PAN entry or mail order).
3 4 5
Processing code Amount, transaction Amount, settlement
Mandatory Mandatory Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency.
7 9
Transmission date and time Conversion rate, settlement
Mandatory Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency.
11 12 13 14
System trace audit number Time, local transaction Date, local transaction Date, expiration
Mandatory Mandatory Mandatory Conditional Should be present for a card initiated transaction if track 2 data is not present (i.e. manual PAN entry or mail order), and expiry date checking is being performed by the Transaction Manager. If this field is not present, the Transaction Manager will extract the expiry date from the track 2 data if it is present. If both this field and the expiry date subfield of track 2 are present, the Transaction Manager will enforce that they have the same value. Should be present if the node to which the message is being sent is configured to use the external business date functionality. If this is the case the field should contain the settlement date of the batch to which this messages totals will be applied. If this field is not present or the node is not configured to make use of the external business date functionality then the transaction totals are applied to the batch for the current business day. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if a merchant was involved in the transaction.
15
Date, settlement
Conditional
16
Date, conversion
Conditional
18 22 23
Merchants type POS entry mode Card sequence number
Conditional Mandatory Conditional
Should be present for a card initiated transaction if Track 2 data is not present (i.e. manual PAN entry or mail order) and a card sequence number (issue number) was entered at the POS.
25 26 27 28 29
POS condition code POS PIN capture code Authorization ID response length Amount, transaction fee Amount, settlement fee
Mandatory Conditional Conditional Optional Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from, field 28 is present and the transaction (i.e. local) currency differs from the settlement currency. Should be present if a PIN was entered. Should be present if the authorization identification response (authorization code) in the response should be less than 6 characters.
30 31
Amount, transaction processing fee Amount, settle processing fee
Optional Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from, field 30 is present and the transaction currency differs from the settlement currency. Should be present if the node from which the message was received has a settlement granularity of acquirer.
32
Acquiring institution ID code
Conditional
Message Content
70
Field 33 35 37 40 41 42 43 45 49 50
Description Forwarding institution ID code Track 2 data Retrieval reference number Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Track 1 data Currency code, transaction Currency code, settlement
Condition Optional Conditional Optional Optional Mandatory Mandatory Mandatory Optional Mandatory Conditional
Notes
Should be included if available.
Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if a PIN was entered. Should be present if a PIN was entered and the DUKPT PIN encryption scheme is used. Should contain the cash amount requested, if the transaction is a purchase with cash back transaction. Must be in the transaction currency.
52 53 54 56 57 59 67 90 98 100
PIN data Security related control information Additional amounts Message reason code Authorization life cycle Echo data Extended payment code Original data elements Payee Receiving institution ID code
Conditional Conditional Conditional Optional Optional Optional Conditional Conditional Conditional Conditional
Should be present for budget transactions. Should be present for a debit or credit adjustment transaction that was preceded by a request. Should be present for all payment transactions made to an institution defined payee. Should be present if no card data is available (e.g. check verification using the MICR format). If this field is present in any initial message, it will be used to route the transaction. Should be included if available. Should be included if available.
102 103 123 127.1 127.4 127.5 127.7 127.8 127.9
Account identification 1 Account identification 2 POS data code Bitmap POS data Service station data Check data Retention data Additional node data
Conditional Conditional Mandatory Conditional Optional Optional Conditional Optional Optional Optional Conditional Conditional Conditional Conditional Optional Conditional Optional Optional Conditional
Must be present if any Postilion private data sub-field is set.
Should be present for a check guarantee or a check verification transaction.
127.10 CVV2 127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.15 Address verification data 127.18 Validation data 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.23 Payee name and address
Should be included if available. Should be included if available. Should be included if available. Should be present if address verification is required with a transaction (e.g. a mail order or airline transaction).
Should be present for third-party payments (inter-bank transfers).
Should be present in payment transactions to Customer defined payees, where the payees address details have been defined.
Message Content
71
Field
Description
Condition Optional Conditional
Notes
127.24 Payer account 127.25 ICC data
Should be present it the PAN entry mode subfield of the POS Entry Mode field (field 22) is set to Integrated circuit card (ICC). CVV can be checked (05) or Integrated circuit card (ICC). CVV may not be checked (95). Otherwise optional. Should be present if this is a linked transaction and the original message may have come from another source node.
127.26 Original node 127.27 Card verification result 127.28 American express card identifier (CID) 127.29 3D secure data 127.32 UCAF data 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
Conditional Optional Optional Optional Optional Optional Optional Optional Conditional
Must be present if MACing is enabled for the current message type.
4.1.2
Field 3 4 5
Receive - Authorization Request Response (0110)

Description Processing code Amount, transaction Amount, settlement Condition Optional Optional Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the node to which the message is being sent is configured to use the external business date functionality. If this is the case the field should contain the settlement date of the batch to which this messages totals will be applied. If this field is not present or the node is not configured to make use of the external business date functionality then the transaction totals are applied to the batch for the current business day. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be included if this fee amount has been removed/calculated/changed by the Host. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from, field 28 is present and the transaction (i.e. local) currency differs from the settlement currency. Should be included if this fee amount has been removed/calculated/changed by the Host Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from, field 30 is present and the transaction currency differs from the settlement currency. Should be included if available. Notes
Conversion rate, settlement
Conditional
15
Date, settlement
Conditional
16
Date, conversion
Conditional
28 29
Amount, transaction fee Amount, settlement fee
Conditional Conditional
30 31
38 39 44 48 50
Authorization ID response Response code Additional response data Additional data Currency code, settlement
Conditional Mandatory Optional Conditional Conditional
Should be present for approved linked account inquiries. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency.
Message Content
72
Field 54
Description Additional amounts
Condition Conditional
Notes If a goods and services with cash back transaction, should contain amount cash approved. The amount available is determined from available balance, available credit and credit limit (in that order) and the ledger balance from ledger balance. These balances are retained after being converted to the transaction currency. Should be present when the institution that processed an authorization or financial transaction is not the same institution identified by the primary account number.
58
Authorizing agent ID code
Conditional
59 102 103 127.1 127.6 127.8 127.9
Echo data Account identification 1 Account identification 2 Bitmap Authorization profile Retention data Additional node data
Mandatory Optional Optional Conditional Optional Optional Optional Conditional Optional Optional Optional Optional Optional Optional Optional Optional Optional Conditional Must be present if MACing is enabled for the current message type. Should be present when address verification is required with a transaction (e.g. a mail-order or airline transaction). Must be present if any Postilion private data sub-field is set.
127.16 Address verification result 127.17 Cardholder information 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.25 ICC data 127.27 Card verification result 127.30 3D secure result 127.31 Issuer network ID 127.32 UCAF data 127.33 Extended transaction type 128 MAC extended
4.1.3
Field 2 3 4 5
Receive Authorization Advice (Repeat) (0120/0121)

Description Primary account number Processing code Amount, transaction Amount, settlement Condition Conditional Mandatory Mandatory Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Notes Should be present for a card initiated transaction if Track 2 data is not present (i.e. manual PAN entry or mail order).
7 9
11 12 13 14
Mandatory Mandatory Mandatory Conditional Should be present for a card initiated transaction if track 2 data is not present (i.e. manual PAN entry or mail order), and expiry date checking is being performed by the Transaction Manager. If this field is not present, the Transaction Manager will extract the expiry date from the track 2 data if it is present. If both this field and the expiry date subfield of track 2 are present, the Transaction Manager will enforce that they have the same value.
Message Content
73
Field 15
Description Date, settlement
Notes Should be present if the node to which the message is being sent is configured to use the external business date functionality. If this is the case the field should contain the settlement date of the batch to which this messages totals will be applied. If this field is not present or the node is not configured to make use of the external business date functionality then the transaction totals are applied to the batch for the current business day. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if a merchant was involved in the transaction.
16
Date, conversion
Conditional
18 22 23
25 28 29
POS condition code Amount, transaction fee Amount, settlement fee
Mandatory Optional Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from, field 28 is present and the transaction (i.e. local) currency differs from the settlement currency.
30 31
32 33 35 37 38 39
Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Response code
Conditional Optional Conditional Optional Conditional Optional
Should be included if available. If this field is present, it will be forwarded in the advice message to the Sink Node. If this field is not present, a Response Code of '00' will be sent to the Sink Node.
40 41 42 43 45 49 50
Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Track 1 data Currency code, transaction Currency code, settlement
Optional Mandatory Mandatory Mandatory Optional Mandatory Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should contain amount cash final if purchase with cash back transaction. Must be in the transaction currency. Should contain amount, cash if purchase with cash back transaction.
54
Additional amounts
Conditional
56 58
Message reason code Authorizing agent ID code
Optional Conditional Should be present when the institution that processed an authorization or financial transaction is not the same institution identified by the primary account number.
59 67 90 95
Echo data Extended payment code Original data elements Replacement amounts
Optional Conditional Conditional Conditional Should be present for budget transactions. Should be present if this message was preceded by a request. Should be present if the transaction did not complete as authorized.
Message Content
74
Field 98 100
Description Payee Receiving institution ID code
Condition Conditional Conditional
Notes Should be present for all payment transactions made to an institution defined payee. Should be present if no card data is available (e.g. check verification using the MICR format). If this field is present in any initial message, it will be used to route the transaction. Should be included if available. Should be included if available.
102 103 123 127.1 127.4 127.5 127.6 127.7 127.8 127.9
Account identification 1 Account identification 2 POS data code Bitmap POS data Service station data Authorization profile Check data Retention data Additional node data
Conditional Conditional Mandatory Conditional Optional Optional Optional Conditional Optional Optional Conditional Conditional Conditional Conditional Optional Optional Conditional Optional Conditional
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.23 Payee name and address 127.24 Payer account 127.25 ICC data
Should be included if available. Should be included if available. Should be included if available. Should be present for third-party payments (inter-bank transfers).
127.26 Original node 127.27 Card verification result 127.32 UCAF data 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
Conditional Optional Optional Optional Optional Optional Conditional
4.1.4
Field 5
Receive - Authorization Advice Response (0130)

Description Amount, settlement Condition Conditional Notes Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the node to which the message is being sent is configured to use the external business date functionality. If this is the case the field should contain the settlement date of the batch to which this messages totals will be applied. If this field is not present or the node is not configured to make use of the external business date functionality then the transaction totals are applied to the batch for the current business day.
Conditional
15
Date, settlement
Conditional
Message Content
75
Field 16
Description Date, conversion
Notes Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency.
29 31 39 50
Amount, settlement fee Amount, settle processing fee Response code Currency code, settlement
Optional Optional Mandatory Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should contain amount, cash for a purchase with cash back transaction if all the following conditions are met: the Transaction Manager does not perform currency conversion for the Node the message was received from; the transaction (i.e. local) currency differs from the settlement currency; and the transaction did not complete as authorized.
54
Additional amounts
Conditional
59 95
Echo data Replacement amounts
Mandatory Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. This field is ignored by Transaction Manager if it performs currency conversion. If Transaction Manager does not perform currency conversion, it extracts the amount settlement final from this field. If this field is not present, the amount settlement final is assumed to be equal to the corresponding amount in the transaction currency. Must be present if any Postilion private data sub-field is set.
127.1
Bitmap
Conditional Optional Conditional
127.20 Originator/Authorizer settlement date 128 MAX extended
4.1.5
Field 2 3 4 5
Receive - Transaction Request (Repeat) (0200/0201)

Description Primary account number Processing code Amount, transaction Amount, settlement Condition Conditional Mandatory Mandatory Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Notes Should be present for a card initiated transaction if Track 2 data is not present (i.e. manual PAN entry).
7 9
11 12 13 14
Message Content
76
Field 15
16
Date, conversion
Conditional
18 22 23
25 26 27 28 29
POS condition code POS PIN capture code Authorization ID response length Amount, transaction fee Amount, settlement fee
Mandatory Conditional Conditional Optional Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from, field 28 is present and the transaction (i.e. local) currency differs from the settlement currency. Should be present if a PIN was entered. Should be present if the authorization identification response (authorization code) in the response should be less than 6 characters.
30 31
32 33 35 37 40 41 42 43 45 49 50
Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Track 1 data Currency code, transaction Currency code, settlement
Conditional Optional Conditional Optional Optional Mandatory Mandatory Mandatory Optional Mandatory Conditional
Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if a PIN was entered. Should be present if a PIN was entered and the DUKPT PIN encryption scheme is used. Should contain the cash amount requested, if the transaction is a purchase with cash back transaction. Must be in the transaction currency.
52 53 54 56 57 59 67 90 98
PIN data Security related control information Additional amounts Message reason code Authorization life cycle Echo data Extended payment code Original data elements Payee
Conditional Conditional Conditional Optional Optional Optional Conditional Conditional Conditional
Should be present for budget transactions. Should be present for a debit or credit adjustment transaction that was preceded by a request. Should be present for all payment transactions made to an institution defined payee.
Message Content
77
Field 100
Description Receiving institution ID code
Notes Should be present if no card data is available (e.g. check verification using the MICR format). If this field is present in any initial message, it will be used to route the transaction. Should be included if available. Should be included if available.
102 103 123 127.1 127.4 127.5 127.7 127.8 127.9
Account identification 1 Account identification 2 POS data code Bitmap POS data Service station data Check data Retention data Additional node data
Conditional Conditional Mandatory Conditional Optional Optional Conditional Optional Optional Optional Conditional Conditional Conditional Conditional Optional Conditional Optional Optional Conditional Optional Conditional
127.10 CVV2 127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.15 Address verification data 127.18 Validation data 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.23 Payee name and address 127.24 Payer account 127.25 ICC data
Should be present for third-party payments (inter-bank transfers).
127.26 Original node 127.27 Card verification result 127.28 American express card identifier (CID) 127.29 3D secure data 127.32 UCAF data 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
Conditional Optional Optional Optional Optional Optional Optional Optional Conditional
Message Content
78
4.1.6
Field 4
Receive Transaction Completion (Repeat) (0202/0203)

Description Amount, transaction Condition Mandatory Notes 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 amount (i.e. the actual transaction amount). 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). Ignored if the Transaction Manager performs currency conversion. If the Transaction Manager does not perform currency conversion and the field is not present, this field is assumed to be equal to and in the same currency as the transaction amount. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency.
Amount, settlement
Conditional
Conditional
16
Date, conversion
Conditional
28 29
Optional Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from, field 28 is present and the transaction (i.e. local) currency differs from the settlement currency.
30 31
Optional Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from, field 30 is present and the transaction currency differs from the settlement currency.
39 54 56 59 95 127.1
Response code Additional amounts Message reason code Echo data Replacement amounts Bitmap
Mandatory Conditional Optional Optional Optional Conditional Optional Optional Conditional Must be present if MACing is enabled for the current message type. If this field is not present, the final transaction amounts are obtained from field 4 and 5. Must be present if any Postilion private data sub-field is set. If goods and services with cash back transaction, should contain amount cash final. Must be in the transaction currency.
127.20 Originator/Authorizer settlement date 127.22 Structured data 128 MAX extended
4.1.7
Field 3 4 5
Receive - Transaction Request Response (0210)

Description Processing code Amount, transaction Amount, settlement Condition Optional Optional Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the node to which the message is being sent is configured to use the external business date functionality. If this is the case the field should contain the settlement date of the batch to which this messages totals will be applied. If this field is not present or the node is not configured to make use of the external business date functionality then the transaction totals are applied to the batch for the current business day. Notes
Conditional
15
Date, settlement
Conditional
Message Content
79
Field 16
Notes Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be included if this fee amount has been removed/calculated/changed by the Host. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from, field 28 is present and the transaction (i.e. local) currency differs from the settlement currency. Should be included if this fee amount has been removed/calculated/changed by the Host Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from, field 30 is present and the transaction currency differs from the settlement currency. Should be included if available.
28 29
30 31
38 39 44 48 50
Conditional Mandatory Optional Conditional Conditional
Should be present for approved linked account inquiries. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. If a goods and services with cash back transaction, should contain amount cash approved. The amount available is determined from available balance, available credit and credit limit (in that order) and the ledger balance from ledger balance. These balances are retained after being converted to the transaction currency. Should be present when the institution that processed an authorization or financial transaction is not the same institution identified by the primary account number.
54
Additional amounts
Conditional
58
Conditional
59 102 103 127.1 127.6 127.8 127.9
Echo data Account identification 1 Account identification 2 Bitmap Authorization profile Retention data Additional node data
Mandatory Optional Optional Conditional Optional Optional Optional Conditional Optional Optional Optional Optional Optional Optional Optional Optional Optional Conditional Must be present if MACing is enabled for the current message type. Should be present when address verification is required with a transaction (e.g. a mail-order or airline transaction). Must be present if any Postilion private data sub-field is set.
127.16 Address verification result 127.17 Cardholder information 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.25 ICC data 127.27 Card verification result 127.30 3D secure result 127.31 Issuer network ID 127.32 UCAF data 127.33 Extended transaction type 128 MAC extended
Message Content
80
4.1.8
Field 5
Receive Transaction Completion Response (0212)

Description Amount, settlement Condition Conditional Notes Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency.
Conditional
16
Date, conversion
Conditional
29 31 39 50
54
Additional amounts
Conditional
59 127.1 127.6
Echo data Bitmap Authorization profile
Mandatory Conditional Optional Optional Optional Conditional Must be present if MACing is enabled for the current message type. Must be present if any Postilion private data sub-field is set.
127.20 Originator/Authorizer settlement date 127.22 Structured data 128 MAX extended
4.1.9
Field 2 3 4 5
Receive Transaction Advice (Repeat) (0220/0221)

Description Primary account number Processing code Amount, transaction Amount, settlement Condition Conditional Mandatory Mandatory Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Notes Should be present for a card initiated transaction if Track 2 data is not present (i.e. manual PAN entry or mail order).
7 9
11 12 13 14
Message Content
81
Field 15
16
Date, conversion
Conditional
18 22 23
25 28 29
30 31
32 33 35 37 38 39
40 41 42 43 45 49 50
54
Additional amounts
Conditional
56 58
Message reason code Authorizing agent ID code
Optional Conditional Should be present when the institution that processed an authorization or financial transaction is not the same institution identified by the primary account number.
59 67 90 95
Echo data Extended payment code Original data elements Replacement amounts
Optional Conditional Conditional Conditional Should be present for budget transactions. Should be present if this message was preceded by a request. Should be present if the transaction did not complete as authorized.
Message Content
82
Field 98 100
Description Payee Receiving institution ID code
Notes Should be present for all payment transactions made to an institution defined payee. Should be present if no card data is available (e.g. check verification using the MICR format). If this field is present in any initial message, it will be used to route the transaction. Should be included if available. Should be included if available.
102 103 123 127.1 127.4 127.5 127.6 127.7 127.8 127.9
Account identification 1 Account identification 2 POS data code Bitmap POS data Service station data Authorization profile Check data Retention data Additional node data
Conditional Conditional Mandatory Conditional Optional Optional Optional Conditional Optional Optional Conditional Conditional Conditional Conditional Optional Optional Conditional Optional Conditional
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.23 Payee name and address 127.24 Payer account 127.25 ICC data
Should be included if available. Should be included if available. Should be included if available. Should be present for third-party payments (inter-bank transfers).
127.26 Original node 127.27 Card verification result 127.32 UCAF data 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
4.1.10
Field 5
Receive - Transaction Advice Response (0230)

Condition Conditional Notes Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the node to which the message is being sent is configured to use the external business date functionality. If this is the case the field should contain the settlement date of the batch to which this messages totals will be applied. If this field is not present or the node is not configured to make use of the external business date functionality then the transaction totals are applied to the batch for the current business day.
Description Amount, settlement
Conditional
15
Date, settlement
Conditional
Message Content
83
Field 16
Notes Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency.
29 31 39 50
54
Additional amounts
Conditional
59 95
127.1
Bitmap
4.1.11
Field 2
Receive Acquirer File Update Advice (Repeat) (0320/0321)

Condition Conditional Notes This field must be present if field 100 (Receiving Institution ID code) is not present. It is used to route the 0320 to an appropriate sink node by combining with a default account type. If both fields 2 and 100 are present, then field 100 takes precedence in the routing decision. If routing based on field 100 fails then routing will be attempted based on field 2. NOTE: If the 0320 is a HOTCARDS file update the field 2 is mandatory.
Description Primary account number
7 11 12 13 14 23 32 33 37 39 41 42 43 56 59 91
Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, expiration Card sequence number Acquiring institution ID code Forwarding institution ID code Retrieval reference number Response code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Message reason code Echo data File update code
Mandatory Mandatory Mandatory Mandatory Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Mandatory
Message Content
84
Field 100
Description Receiving institution ID code
Notes This field must be present if field 2 (Primary Account Number) is not present. It is used to route the 0320 to an appropriate sink node. If both fields 2 and 100 are present, then field 100 takes precedence in the routing decision. NOTE: If routing based on field 100 fails then routing will be attempted based on field 2.
101 127.1 127.8 127.9
File name Bitmap Retention data Additional node data
Mandatory Conditional Optional Optional Optional Conditional Must be present if MACing is enabled for the current message type. Must be present if any Postilion private data sub-field is set.
127.22 Structured data 128 MAX extended
4.1.12
Field 2 7 11 12 13 14 23 32 33 37 39 41 42 43 56 59 91 100 101 127.1 127.8 127.9
Receive Issuer File Update Advice (Repeat) (0322/0323)

Condition Conditional Mandatory Mandatory Mandatory Mandatory Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Mandatory Conditional Mandatory Conditional Optional Optional Optional Conditional Must be present if MACing is enabled for the current message type. Must be present if any Postilion private data sub-field is set. If the Route to Source checkbox in the sink node setup is switched on, this field will be used to route the transaction to the source. Notes This field must always be present unless field 127.22 (Structured Data) contains the applicable PAN(s).
Description Primary account number Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, expiration Card sequence number Acquiring institution ID code Forwarding institution ID code Retrieval reference number Response code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Message reason code Echo data File update code Receiving institution ID code File name Bitmap Retention data Additional node data
Message Content
85
4.1.13
Field 39 59 127.1
Receive Acquirer File Update Advice Response (0330)

Condition Mandatory Mandatory Conditional Optional Conditional Must be present if MACing is enabled for the current message type. Must be present if any Postilion private data sub-field is set. Notes
Description Response code Echo data Bitmap
4.1.14
Field 39 59 127.1
Receive Issuer File Update Advice Response (0332)

4.1.15
Field 2 3 4 5 7 9 11 12 13 14 15
Receive - Reversal Request (Repeat) (0400/0401)

Condition Conditional Mandatory Optional Optional Optional Optional Optional Optional Optional Optional Conditional Should be present if the node to which the message is being sent is configured to use the external business date functionality. If this is the case the field should contain the settlement date of the batch to which this messages totals will be applied. If this field is not present or the node is not configured to make use of the external business date functionality then the transaction totals are applied to the batch for the current business day. Notes Should be present for a card initiated transaction if Track 2 data is not present (i.e. manual PAN entry).
Description Primary account number Processing code Amount, transaction Amount, settlement Transmission date and time Conversion rate, settlement System trace audit number Time, local transaction Date, local transaction Date, expiration Date, settlement
16 18 22 23 25 26 27 28 29
Date, conversion Merchants type POS entry mode Card sequence number POS condition code POS PIN capture code Authorization ID response length Amount, transaction fee Amount, settlement fee
Optional Optional Optional Optional Optional Optional Conditional Optional Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from, field 28 is present and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the authorization identification response (authorization code) in the response should be less than 6 characters.
30
Amount, transaction processing fee
Optional
Message Content
86
Field 31
Description Amount, settle processing fee
Notes Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from, field 30 is present and the transaction currency differs from the settlement currency.
32 33 35 37 38 40 41 42 43 45 49 50
Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Track 1 data Currency code, transaction Currency code, settlement
Optional Optional Conditional Optional Optional Optional Mandatory Mandatory Optional Optional Optional Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be included if available.
52 53 54 56 59 67 90 95 98 100
PIN data Security related control information Additional amounts Message reason code Echo data Extended payment code Original data elements Replacement amounts Payee Receiving institution ID code
Optional Optional Conditional Optional Optional Optional Optional Conditional Conditional Conditional Should be present if the transaction did not complete as authorized. Should be present for all payment transactions made to an institution defined payee. Should be present if no card data is available (e.g. check verification using the MICR format). If this field is present in any initial message, it will be used to route the transaction. If goods and services with cash back transaction, should contain amount cash final. Must be in the transaction currency.
102 103 123 127.1 127.4 127.5 127.6 127.7 127.8 127.9
Account identification 1 Account identification 2 POS data code Bitmap POS data Service station data Authorization Profile Check data Retention data Additional node data
Optional Optional Optional Conditional Optional Optional Conditional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Should be present and set to "11" if the Transaction Manager should not perform online or offline limits-based stand-in. Must be present if any Postilion private data sub-field is set.
127.10 CVV2 127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.15 Address verification data 127.18 Validation data 127.19 Bank details
Message Content
87
Field
Description
Condition Optional Optional Optional Optional Conditional
Notes
127.20 Originator/Authorizer settlement date 127.22 Structured data 127.23 Payee name and address 127.24 Payer account 127.25 ICC data
127.26 Original node 127.27 Card verification result 127.28 American express card identifier (CID) 127.29 3D secure data 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
Conditional Optional Optional Optional Optional Optional Optional Conditional
4.1.16
Field 3 5
Receive - Reversal Request Response (0410)

Condition Optional Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the node to which the message is being sent is configured to use the external business date functionality. If this is the case the field should contain the settlement date of the batch to which this messages totals will be applied. If this field is not present or the node is not configured to make use of the external business date functionality then the transaction totals are applied to the batch for the current business day. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Notes
Description Processing code Amount, settlement
Conditional
15
Date, settlement
Conditional
16
Date, conversion
Conditional
29 30
Amount, settlement fee Amount, transaction processing fee
Optional Conditional Should be included if this fee amount has been removed/calculated/changed by the Host. This applies irrespective of whether the transaction was approved or declined. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from, field 30 is present and the transaction currency differs from the settlement currency. Should be included if available.
31
Amount, settle processing fee
Conditional
38 39 44 48 50
Conditional Mandatory Optional Optional Conditional
Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency.
Message Content
88
Field 54
Description Additional amounts
Notes Should contain amount, cash for a purchase with cash back transaction if all the following conditions are met: the Transaction Manager does not perform currency conversion for the Node the message was received from; the transaction (i.e. local) currency differs from the settlement currency; and the transaction did not complete as authorized.
58
Conditional
Should be present when the institution that processed an authorization or financial transaction is not the same institution identified by the primary account number.
59 95
Mandatory Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. This field is ignored by Transaction Manager if it performs currency conversion. If Transaction Manager does not perform currency conversion, it extracts the amount settlement final and the amount settlement fee final from this field. If this field is not present, the amount settlement final and amount settlement fee final is assumed to be equal to the corresponding amounts in the transaction currency.
102 103 127.1 127.6 127.8 127.9
Account identification 1 Account identification 2 Bitmap Authorization profile Retention data Additional node data
Optional Optional Conditional Optional Optional Optional Conditional Optional Optional Optional Optional Optional Optional Optional Optional Conditional Must be present if MACing is enabled for the current message type. Should be present when address verification is required with a transaction (e.g. a mail-order or airline transaction). Must be present if any Postilion private data sub-field is set.
127.16 Address verification result 127.17 Cardholder information 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.25 ICC data 127.27 Card verification result 127.30 3D secure result 127.31 Issuer network ID 127.33 Extended transaction type 128 MAC extended
4.1.17
Field 2 3 4 5
Receive Reversal Advice (Repeat) (0420/0421)

Condition Conditional Mandatory Mandatory Conditional Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Notes Should be present for a card initiated transaction if Track 2 data is not present (i.e. manual PAN entry or mail order).
Description Primary account number Processing code Amount, transaction Amount, settlement
7 9
11 12
System trace audit number Time, local transaction
Mandatory Mandatory
Message Content
89
Field 13 14
Description Date, local transaction Date, expiration
Condition Mandatory Conditional
Notes
Should be present for a card initiated transaction if track 2 data is not present (i.e. manual PAN entry or mail order), and expiry date checking is being performed by the Transaction Manager. If this field is not present, the Transaction Manager will extract the expiry date from the track 2 data if it is present. If both this field and the expiry date subfield of track 2 are present, the Transaction Manager will enforce that they have the same value. Should be present if the node to which the message is being sent is configured to use the external business date functionality. If this is the case the field should contain the settlement date of the batch to which this messages totals will be applied. If this field is not present or the node is not configured to make use of the external business date functionality then the transaction totals are applied to the batch for the current business day. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if a merchant was involved in the transaction.
15
Date, settlement
Conditional
16
Date, conversion
Conditional
18 22 23
25 28 29
30 31
32 33 35 37 38 39
40 41 42 43 45 49 50
54
Additional amounts
Conditional
56
Message reason code
Optional
Message Content
90
Field 58
Description Authorizing agent ID code
Notes Should be present when the institution that processed an authorization or financial transaction is not the same institution identified by the primary account number.
59 67 90 95 98 100 102 103 123 127.1 127.4 127.5 127.7 127.8 127.9
Echo data Extended payment code Original data elements Replacement amounts Payee Receiving institution ID code Account identification 1 Account identification 2 POS data code Bitmap POS data Service station data Check data Retention data Additional node data
Optional Conditional Mandatory Conditional Conditional Optional Optional Optional Mandatory Conditional Optional Optional Conditional Optional Optional Conditional Conditional Conditional Conditional Optional Optional Conditional Optional Optional Conditional Optional Optional Optional Optional Conditional Must be present if MACing is enabled for the current message type. Should be present if this is a linked transaction and the original message may have come from another source node. Should be present in payment transactions to Customer defined payees, where the payees address details have been defined. Should be included if available. Should be included if available. Should be included if available. Should be present for third-party payments (inter-bank transfers). Should be present for a check guarantee or a check verification transaction. Must be present if any Postilion private data sub-field is set. Should be included if available. Should be included if available. Should be present if the transaction did not complete as authorized. Should be present for all payment transactions made to an institution defined payee. Should be present for budget transactions.
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.23 Payee name and address 127.24 Payer account 127.25 ICC data 127.26 Original node 127.27 Card verification result 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
Message Content
91
4.1.18
Field 5
Receive - Reversal Advice Response (0430)

Condition Conditional Notes Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency. Should be present if the node to which the message is being sent is configured to use the external business date functionality. If this is the case the field should contain the settlement date of the batch to which this messages totals will be applied. If this field is not present or the node is not configured to make use of the external business date functionality then the transaction totals are applied to the batch for the current business day. Should be present if the Transaction Manager does not perform currency conversion for the Node the message was received from and the transaction (i.e. local) currency differs from the settlement currency.
Description Amount, settlement
Conditional
15
Date, settlement
Conditional
16
Date, conversion
Conditional
29 31 39 50
54
Additional amounts
Conditional
59 95
127.1
Bitmap
4.1.19
Field 7 11 12 13 15
Receive Acquirer Reconciliation Request (Repeat) (0500/0501)

Condition Mandatory Mandatory Mandatory Mandatory Conditional Contains the settlement date of the batch to which this message is applicable. If this field is not present, the totals for the current business day are returned. Should be present if the node from which the message was received has a settlement granularity of acquirer. Should be present if the node from which the message was received has a settlement granularity of terminal. Notes
Description Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, settlement
32 41
Acquiring institution ID code Card acceptor terminal ID
Message Content
92
Field 42 50 59 128
Description Card acceptor ID code Currency code, settlement Echo data MAX extended
Condition Conditional Optional Optional Conditional
Notes Should be present if the node from which the message was received has a settlement granularity of terminal or card acceptor.
4.1.20
Field 7 11 12 13 15
Receive Card Issuer Reconciliation Request (Repeat) (0502/0503)

Condition Mandatory Mandatory Mandatory Mandatory Conditional Contains the settlement date of the batch to which this message is applicable. If this field is not present, the totals for the current business day are returned. Should be present if the node from which the message was received has a settlement granularity of acquirer. Should be present if the node from which the message was received has a settlement granularity of terminal. Should be present if the node from which the message was received has a settlement granularity of terminal or card acceptor. Notes
Description Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, settlement
32 41 42 50 59 128
Acquiring institution ID code Card acceptor terminal ID Card acceptor ID code Currency code, settlement Echo data MAX extended
Conditional Conditional Conditional Optional Optional Conditional
4.1.21
Field 7 11 12 13 32 41 42 50 59 74 75 76 77 78 79 80 81 82 83
Receive Acquirer Reconciliation Advice (Repeat) (0520/0521)

Condition Mandatory Mandatory Mandatory Mandatory Conditional Conditional Conditional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Should be present if the node from which the message was received has a settlement granularity of acquirer. Should be present if the node from which the message was received has a settlement granularity of terminal. Should be present if the node from which the message was received has a settlement granularity of terminal or card acceptor. Notes
Description Transmission date and time System trace audit number Time, local transaction Date, local transaction Acquiring institution ID code Card acceptor terminal ID Card acceptor ID code Currency code, settlement Echo data Credits, number Credits, reversal number Debits, number Debits, reversal number Transfers, number Transfers, reversal number Inquiries, number Authorizations, number Credits, processing fee amount Credits, transaction fee amount
Message Content
93
Field 84 85 86 87 88 89 97 118 119 127.1
Description Debits, processing fee amount Debits, transaction fee amount Credits, amount Credits, reversal amount Debits, amount Debits, reversal amount Amount, net settlement Payments, number Payments, reversal number Bitmap
Condition Optional Optional Optional Optional Optional Optional Optional Optional Optional Conditional Optional Conditional
Notes
4.1.22
Field 7 11 12 13 32 41 42 50 59 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 97 118 119 127.1
Receive Card Issuer Reconciliation Advice (Repeat) (0522/0523)

Condition Mandatory Mandatory Mandatory Mandatory Conditional Conditional Conditional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Conditional Must be present if any Postilion private data sub-field is set. Should be present if the node from which the message was received has a settlement granularity of acquirer. Should be present if the node from which the message was received has a settlement granularity of terminal. Should be present if the node from which the message was received has a settlement granularity of terminal or card acceptor. Notes
Description Transmission date and time System trace audit number Time, local transaction Date, local transaction Acquiring institution ID code Card acceptor terminal ID Card acceptor ID code Currency code, settlement Echo data Credits, number Credits, reversal number Debits, number Debits, reversal number Transfers, number Transfers, reversal number Inquiries, number Authorizations, number Credits, processing fee amount Credits, transaction fee amount Debits, processing fee amount Debits, transaction fee amount Credits, amount Credits, reversal amount Debits, amount Debits, reversal amount Amount, net settlement Payments, number Payments, reversal number Bitmap
Message Content
94
Field
Description
Condition Optional Conditional
Notes
4.1.23
Field 39 59 66 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 97 118 119 127.1
Receive Acquirer Reconciliation Advice Response (0530)

Condition Mandatory Mandatory Mandatory Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Conditional Optional Conditional Must be present if MACing is enabled for the current message type. Must be present if any Postilion private data sub-field is set. Notes
Description Response code Echo data Settlement Code Credits, number Credits, reversal number Debits, number Debits, reversal number Transfers, number Transfers, reversal number Inquiries, number Authorizations, number Credits, processing fee amount Credits, transaction fee amount Debits, processing fee amount Debits, transaction fee amount Credits, amount Credits, reversal amount Debits, amount Debits, reversal amount Amount, net settlement Payments, number Payments, reversal number Bitmap
4.1.24
Field 39 66 74 75 76 77 78 79 80 81 82 83 84
Receive Card Issuer Reconciliation Advice Response (0532)

Condition Mandatory Mandatory Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Notes
Description Response code Settlement Code Credits, number Credits, reversal number Debits, number Debits, reversal number Transfers, number Transfers, reversal number Inquiries, number Authorizations, number Credits, processing fee amount Credits, transaction fee amount Debits, processing fee amount
Message Content
95
Field 85 86 87 88 89 97 118 119 127.1
Description Debits, transaction fee amount Credits, amount Credits, reversal amount Debits, amount Debits, reversal amount Amount, net settlement Payments, number Payments, reversal number Bitmap
Condition Optional Optional Optional Optional Optional Optional Optional Optional Conditional Optional Conditional
Notes
4.1.25
Field 2
Receive - Administration Request (Repeat) (0600/0601)

Condition Conditional Notes Should be present for a card initiated transaction (or a check verification transaction using the plastic card format) if Track 2 data is not present (i.e. manual PAN entry or mail order).
3 4 7 11 12 13 14
Processing code Amount, transaction Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, expiration
Mandatory Optional Mandatory Mandatory Mandatory Mandatory Conditional Should be present for a card initiated transaction if track 2 data is not present (i.e. manual PAN entry or mail order), and expiry date checking is being performed by the Transaction Manager. If this field is not present, the Transaction Manager will extract the expiry date from the track 2 data if it is present. If both this field and the expiry date subfield of track 2 are present, the Transaction Manager will enforce that they have the same value. Should be present if the node to which the message is being sent is configured to use the external business date functionality. If this is the case the field should contain the settlement date of the batch to which this messages totals will be applied. If this field is not present or the node is not configured to make use of the external business date functionality then the transaction totals are applied to the batch for the current business day. Should be present if a merchant was involved in the transaction.
15
Date, settlement
Conditional
18 22 23
25 26 28 32 33 35 37 40 41
POS condition code POS PIN capture code Amount, transaction fee Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Service restriction code Card acceptor terminal ID
Mandatory Conditional Optional Conditional Optional Conditional Optional Optional Mandatory Should be included if available. Should be present if the node from which the message was received has a settlement granularity of acquirer. Should be present if a PIN was entered.
Message Content
96
Field 42 43 45 49 52 53
Description Card acceptor ID code Card acceptor name location Track 1 data Currency code, transaction PIN data Security related control information
Condition Mandatory Mandatory Optional Optional Conditional Conditional
Notes
Should be present if a PIN was entered. In the case of a PIN change transaction, the Transaction Manager will attempt to change the PIN if it is configured to perform PIN verification for the Sink Node. Should be present in messages for place hold on card transactions where positions 1 and 2 of the Processing Code are 90. Otherwise optional.
56 59 90 100
Message reason code Echo data Original data elements Receiving institution ID code
Conditional Optional Conditional Conditional
Should be present for a debit or credit adjustment transaction that was preceded by a request. Should be present if no card data is available (e.g. check verification using the MICR format). If this field is present in any initial message, it will be used to route the transaction. Should be included if available.
102 123 127.1 127.4 127.8 127.9
Account identification 1 POS data code Bitmap POS data Retention data Additional node data
Conditional Mandatory Conditional Optional Optional Optional Optional Conditional Conditional Conditional Conditional Optional Optional Conditional
127.10 CVV2 127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.15 Address verification data 127.18 Validation data 127.22 Structured data 127.25 ICC data
127.26 Original node 127.27 Card verification result 127.28 American express card identifier (CID) 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
Message Content
97
4.1.26
Field 3 15
Receive - Administration Request Response (0610)

Condition Optional Conditional Should be present if the node to which the message is being sent is configured to use the external business date functionality. If this is the case the field should contain the settlement date of the batch to which this messages totals will be applied. If this field is not present or the node is not configured to make use of the external business date functionality then the transaction totals are applied to the batch for the current business day. Notes
Description Processing code Date, settlement
39 44 53 59 127.1 127.8 127.9
Response code Additional response data Security related control information Echo data Bitmap Retention data Additional node data
Mandatory Optional Optional Mandatory Conditional Optional Optional Conditional Optional Optional Optional Optional Optional Optional Conditional Must be present if MACing is enabled for the current message type. Should be present when address verification is required with a transaction (e.g. a mail-order or airline transaction). Must be present if any Postilion private data sub-field is set.
127.16 Address verification result 127.17 Cardholder information 127.22 Structured data 127.25 ICC data 127.27 Card verification result 127.31 Issuer network ID 127.33 Extended transaction type 128 MAC extended
4.1.27
Field 2
Receive - Administration Advice (Repeat) (0620/0621)

Condition Conditional Notes Should be present for a card initiated transaction (or a check verification transaction using the plastic card format) if Track 2 data is not present (i.e. manual PAN entry or mail order).
3 4 7 11 12 13 14
Mandatory Optional Mandatory Mandatory Mandatory Mandatory Conditional Should be present for a card initiated transaction if track 2 data is not present (i.e. manual PAN entry or mail order), and expiry date checking is being performed by the Transaction Manager. If this field is not present, the Transaction Manager will extract the expiry date from the track 2 data if it is present. If both this field and the expiry date subfield of track 2 are present, the Transaction Manager will enforce that they have the same value. Should be present if the node to which the message is being sent is configured to use the external business date functionality. If this is the case the field should contain the settlement date of the batch to which this messages totals will be applied. If this field is not present or the node is not configured to make use of the external business date functionality then the transaction totals are applied to the batch for the current business day. Should be present if a merchant was involved in the transaction.
15
Date, settlement
Conditional
18 22
Merchants type POS entry mode
Conditional Mandatory
Message Content
98
Field 23
Description Card sequence number
Notes Should be present for a card initiated transaction if Track 2 data is not present (i.e. manual PAN entry or mail order) and a card sequence number (issue number) was entered at the POS.
25 28 32 33 35 37 39 40 41 42 43 45 49 53
POS condition code Amount, transaction fee Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Response Code Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Track 1 data Currency code, transaction Security related control information
Mandatory Optional Optional Optional Conditional Optional Optional Optional Mandatory Mandatory Mandatory Optional Optional Conditional In the case of a PIN change transaction, the Transaction Manager will attempt to change the PIN if it is configured to perform PIN verification for the Sink Node. Should be present in messages for place hold on card transactions where positions 1 and 2 of the Processing Code are 90. Otherwise optional. Should be included if available.
56 59 90 100
Message reason code Echo data Original data elements Receiving institution ID code
Conditional Optional Conditional Conditional
Should be present for a debit or credit adjustment transaction that was preceded by a request. Should be present if no card data is available (e.g. check verification using the MICR format). If this field is present in any initial message, it will be used to route the transaction. Should be included if available.
102 123 127.1 127.4 127.8 127.9
Account identification 1 POS data code Bitmap POS data Retention data Additional node data
Conditional Mandatory Conditional Optional Optional Optional Conditional Conditional Conditional Optional Conditional
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.22 Structured data 127.25 ICC data
Should be included if available. Should be included if available. Should be included if available.
127.26 Original node 127.27 Card verification result 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
Conditional Optional Optional Optional Optional Conditional
Message Content
99
4.1.28
Field 15
Receive Administration Advice Response (0630)

Condition Conditional Notes Should be present if the node to which the message is being sent is configured to use the external business date functionality. If this is the case the field should contain the settlement date of the batch to which this messages totals will be applied. If this field is not present or the node is not configured to make use of the external business date functionality then the transaction totals are applied to the batch for the current business day.
39 59 128
Response code Echo data MAX extended
Mandatory Mandatory Conditional Must be present if MACing is enabled for the current message type.
4.1.29
Field 7 11 12 13 70 128
Receive Network Management Request (Repeat) (0800/0801)

Condition Mandatory Mandatory Mandatory Mandatory Mandatory Conditional Must be present if MACing is enabled for the current message type. Notes
Description Transmission date and time System trace audit number Time, local transaction Date, local transaction Network management information code MAX extended
4.1.30
Field 39 53
Receive Network Management Response (0810)

Condition Mandatory Conditional Must be present in an approved key management transaction if the "Crypto Field 125" user parameter for the interchange is set to "0". Contains the encrypted value and check digits of the PIN key used for encryption of PIN blocks from the Acquirer. Notes
Description Response code Security related control information
70 125
Network management information code Network management information
Mandatory Conditional Must be present in an approved key management transaction if the "Crypto Field 125" user parameter for the interchange is set to "1". Contains the encrypted value and check digits of the PIN key used for encryption of PIN blocks from the Acquirer. Must be present if MACing is enabled for the current message type.
128
MAX extended
Conditional
4.1.31
Field 39 59 128
Receive Authorization Notification Advice Response (9130)

Condition Mandatory Mandatory Conditional Must be present if MACing is enabled for the current message type. Notes
Description Response code Echo data MAX extended
4.1.32
Field 39 59 128
Receive Transaction Notification Advice Response (9230)

Message Content
100
4.1.33
Field 39 59 127.1
Receive Acquirer File Update Notification Response (9330)

4.1.34
Field 39 59 128
Receive Reversal Notification Advice Response (9430)

4.1.35
Field 39 59 128
Receive Administration Notification Advice Response (9630)

4.1.36
Receive Format Error Response (0xx0)
The message type of the format error message will always be a response to the original message. E.g. if the original message was an Authorization Request (0100) the format error message will be an Authorization Request Response (0110). If the original message was an Administrative Advice (0620) then the format error message will be an Administrative Advice Response (0630).
Field 39 59 128 Description Response code Echo data MAX extended Condition Mandatory Mandatory Conditional Must be present if MACing is enabled for the current message type. Notes
4.2
4.2.1
Field 2

Send - Authorization Request (Repeat) (0100/0101)
Description Primary account number Condition Conditional Notes If this information was provided in the message received by the Source Node (in this field or as part of track 2 data), then this field will be present. Present for all card initiated transactions (including check guarantee or check verification transactions that use the plastic card account format).
3 4 5
Always sent Always sent Conditional The amount requested in the currency of the Sink Node. Only sent if the Transaction Manager performs currency conversion for the Source Node and the transaction (i.e. local) currency differs from the settlement currency. If the Transaction Manager does not perform currency conversion for the Source Node, the Source Node returns the settlement amounts, currencies, etc. in the subsequent response.
7 9
Always sent Conditional Present if the Transaction Manager performs currency conversion for the Node the message is sent to and the transaction (i.e. local) currency differs from the settlement currency.
Message Content
101
Field 11 12 13 14
Description System trace audit number Time, local transaction Date, local transaction Date, expiration
Condition Always sent Always sent Always sent Conditional
Notes
If this information was provided in the message received by the Source Node (in this field or as part of track 2 data), then this field will be present. Present for all card initiated transactions (including check guarantee or check verification transactions that use the plastic card account format).
15 16
Date, settlement Date, conversion
Always sent Conditional Present if the Transaction Manager performs currency conversion for the Node the message is sent to and the transaction (i.e. local) currency differs from the settlement currency. Included if present in the initial message from the Source Node.
18 22 23 25 26 27 28 29
Merchants type POS entry mode Card sequence number POS condition code POS PIN capture code Authorization ID response length Amount, transaction fee Amount, settlement fee
Conditional Always sent Conditional Always sent Conditional Conditional Always sent Conditional
Included if present in the initial message from the Source Node or if it could be retrieved from Track 2 data.
Present if a PIN was entered at the Point of Service. Included if present in the initial message from the Source Node.
Present if the Transaction Manager performs currency conversion for the Node the message is sent to and the transaction (i.e. local) currency differs from the settlement currency.
30 31
Always sent Conditional Present if the Transaction Manager performs currency conversion for the Node the message is sent to and the transaction (i.e. local) currency differs from the settlement currency. Included if present in the initial message from the Source Node or if configured in the node configuration for the Sink Node. Included if present in the initial message from the Source Node or if configured in the node configuration for the Sink Node. Present if Track 2 was entered at the Point of Service.
32 33 35 37 40 41 42 43 45 49 50
Conditional Conditional Conditional Always sent Conditional Always sent Always sent Always sent Conditional Always sent Conditional
Included if present in the initial message from the Source Node.
Present if the Transaction Manager performs currency conversion for the Node the message is sent to and the transaction (i.e. local) currency differs from the settlement currency. Present if a PIN was entered at the Point of Service. Present if a PIN was entered at the Point of Service and the DUKPT PIN encryption scheme is used. Contains amount cash if the transaction is a goods and services with cash back transaction.
52 53 54 56 57 59 67 98
PIN data Security related control information Additional amounts Message reason code Authorization life cycle Echo data Extended payment code Payee
Conditional Conditional Conditional Always sent Conditional Always sent Conditional Conditional
Included if the transaction is a budget transaction. Present for Third-party payments (inter-bank transfers) and linked bill
Message Content
102
Field 100 102
Description Receiving institution ID code Account identification 1
Notes payments. Included if present in the initial message from the Source Node. Included if present in the response message from the Source Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer. Included if present in the response message from the Source Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer.
103
Account identification 2
Conditional
123 127.1 127.2 127.3 127.4 127.5 127.7 127.9
POS data code Bitmap Switch key Routing information POS data Service station data Check data Additional node data
Always sent Always sent Always sent Always sent Conditional Conditional Conditional Conditional Conditional Conditional Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if a check guarantee or a check verification transaction. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. If the corresponding message from the Source Node contained field 127.11, then Transaction Manager will locate the Sink Node equivalent value and send it in field 127.11. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present for third-party payments (inter-bank transfers).
127.10 CVV2 127.11 Original key
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.15 Address verification data 127.16 Address verification result 127.18 Validation data 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.23 Payee name and address 127.24 Payer account 127.25 ICC data 127.26 Original node 127.27 Card verification result
Conditional Conditional Conditional Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional
Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if an original transaction could be found. This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type.
127.28 American express card identifier (CID) 127.29 3D secure data 127.32 UCAF data 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
Conditional Conditional Conditional Conditional Conditional Conditional Conditional
4.2.2
Field 2
Send - Authorization Request Response (0110)

Message Content
103
Field 3 4 5 7 9 11 12 13 14 15 16 18 22 23 25 28 29 30 31 32 33 35 37 38 39 40 41 42 43 44 45 48 49 50 54 58 59 67 98 100
Description Processing code Amount, transaction Amount, settlement Transmission date and time Conversion rate, settlement System trace audit number Time, local transaction Date, local transaction Date, expiration Date, settlement Date, conversion Merchants type POS entry mode Card sequence number POS condition code Amount, transaction fee Amount, settlement fee Amount, transaction processing fee Amount, settle processing fee Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Response code Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Additional response data Track 1 data Additional response data Currency code, transaction Currency code, settlement Additional amounts Authorizing agent ID code Echo data Extended payment code Payee Receiving institution ID code
Condition Always sent Always sent Conditional Always sent Conditional Always sent Always sent Always sent Always sent Always sent Conditional Conditional Always sent Conditional Always sent Always sent Conditional Always sent Conditional Conditional Conditional Conditional Always sent Conditional Always sent Conditional Always sent Always sent Always sent Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional
Notes
Present if the transaction (i.e. local) currency differs from the settlement currency.
Present if the transaction (i.e. local) currency differs from the settlement currency. Echoed from original request.
Present if the transaction (i.e. local) currency differs from the settlement currency. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if Track 2 was entered at the Point of Service.
From authorizer (or from stand-in authorization).
From authorizer (or from stand-in authorization). Included if present in the initial message from the Source Node. Present for approved linked account inquiries.
Present if the transaction (i.e. local) currency differs from the settlement currency. Contains the approved amount. If the transaction is a goods and services with cash back transaction amount cash will also be present. Included if the authorizer and the card issuer differs. Echoed from original request. Echoed from original request. Present for Third-party payments (inter-bank transfers) and linked bill payments. Included if present in the initial message from the Source Node.
Message Content
104
Field 102
Description Account identification 1
Notes Included if present in the response message from the Sink Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer. Included if present in the response message from the Sink Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer.
103
Conditional
123 127.1 127.3 127.4 127.5 127.6 127.7 127.9
POS data code Bitmap Routing information POS data Service station data Authorization profile Check data Additional node data
Always sent Always sent Always sent Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Included if present in the response message received from the Sink Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the response message received from the Sink Node the Sink Node is configured to do EMV authentication Included if a check guarantee or a check verification transaction. From authorizer (Sink Node). Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. From authorizer (Sink Node). From authorizer (or from stand-in authorization). Included if present in the initial message from the Source Node. Echoed from original request. Echoed from original request.
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.15 Address verification data 127.16 Address verification result 127.17 Cardholder information 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.23 Payee name and address 127.24 Payer account 127.25 ICC data
If the Sink Node is configured to do EMV authentication then this field will contain the IccResponse Issuer Authentication Data subfield. 127.27 Card verification result Conditional This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. From authorizer (Sink Node). From authorizer (Sink Node). Included if present in the initial message from the Source Node or if received in the response message from the Sink Node. Included if a duplicate transaction was received, and Transaction Manager is configured to respond to duplicate transactions. Present if MACing is enabled for the current message type.
127.30 3D secure result 127.32 UCAF data 127.33 Extended transaction type 127.39 Original response code 128 MAX extended
Conditional Conditional Conditional Conditional Conditional
Message Content
105
4.2.3
Field 2
Send - Authorization Advice (Repeat) (0120/0121)

3 4 5
7 9
11 12 13 14 15 16
System trace audit number Time, local transaction Date, local transaction Date, expiration Date, settlement Date, conversion
Always sent Always sent Always sent Always sent Always sent Conditional Present if the Transaction Manager performs currency conversion for the Node the message is sent to and the transaction (i.e. local) currency differs from the settlement currency. Included if present in the initial message from the Source Node.
18 22 23 25 28 29
Merchants type POS entry mode Card sequence number POS condition code Amount, transaction fee Amount, settlement fee
Conditional Always sent Conditional Always sent Always sent Conditional
30 31
32 33 35 37 38 39 40 41 42 43 44 45
Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Response Code Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Additional response data Track 1 data
Conditional Conditional Conditional Always sent Conditional Always sent Conditional Always sent Always sent Always sent Conditional Conditional
From authorizer (or from stand-in authorization). Included if present in the initial message from the Source Node.
Message Content
106
Field 49 50
Description Currency code, transaction Currency code, settlement
Condition Always sent Conditional
Notes
Present if the Transaction Manager performs currency conversion for the Node the message is sent to and the transaction (i.e. local) currency differs from the settlement currency. Contains amount cash if the transaction is a goods and services with cash back transaction.
54 56 58 59 67 90
Additional amounts Message reason code Authorizing agent ID code Echo data Extended payment code Original data elements
Conditional Always sent Conditional Always sent Conditional Conditional
Included if the authorizer and the card issuer differs.
Included if the transaction is a budget transaction. Present if supplied in the message from the source or constructed by Transaction Manager from the contents of the original message, if it could be retrieved.
95 98 100 102
Replacement Amounts Payee Receiving institution ID code Account identification 1
Always sent Conditional Conditional Conditional Present for Third-party payments (inter-bank transfers) and linked bill payments. Included if present in the initial message from the Source Node. Included if present in the response message from the Source Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer. Included if present in the response message from the Source Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer.
103
Conditional
123 127.1 127.2 127.3 127.4 127.5 127.6 127.7 127.9
POS data code Bitmap Switch key Routing information POS data Service station data Authorization profile Check data Additional node data
Always sent Always sent Always sent Always sent Conditional Conditional Always sent Conditional Conditional Conditional Included if a check guarantee or a check verification transaction. Included if present in any prior message, associated with the transaction, from Source Node. If the corresponding message from the Source Node contained field 127.11, then Transaction Manager will locate the Sink Node equivalent value and send it in field 127.11. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present for third-party payments (inter-bank transfers). Echoed from original request. Echoed from original request.
127.11 Original key
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.23 Payee name and address 127.24 Payer account 127.25 ICC data 127.26 Original node 127.27 Card verification result
Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional
Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if an original transaction could be found. This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node.
127.32 UCAF data 127.33 Extended transaction type 127.34 Account type qualifier
Conditional Conditional Conditional
Message Content
107
Field
Description
Notes Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type.
127.35 Acquirer network ID 128 MAX extended
4.2.4
Field 2
Send - Authorization Advice Response (0130)

3 4 5 7 9 11 12 13 14 15 16 18 22 23 25 28 29 30 31 32 33 35 37 38 39 40 41 42 43 44 45 49 50
Processing code Amount, transaction Amount, settlement Transmission date and time Conversion rate, settlement System trace audit number Time, local transaction Date, local transaction Date, expiration Date, settlement Date, conversion Merchants type POS entry mode Card sequence number POS condition code Amount, transaction fee Amount, settlement fee Amount, transaction processing fee Amount, settle processing fee Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Response code Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Additional response data Track 1 data Currency code, transaction Currency code, settlement
Always sent Always sent Conditional Always sent Conditional Always sent Always sent Always sent Always sent Always sent Conditional Conditional Always sent Conditional Always sent Always sent Conditional Always sent Conditional Conditional Conditional Conditional Always sent Conditional Always sent Conditional Always sent Always sent Always sent Conditional Conditional Always sent Conditional Present if the transaction (i.e. local) currency differs from the settlement currency. From authorizer (or from stand-in authorization). Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. From authorizer (or from stand-in authorization). Present if the transaction (i.e. local) currency differs from the settlement currency. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if Track 2 was entered at the Point of Service. Present if the transaction (i.e. local) currency differs from the settlement currency. Included if present in the initial message from the Source Node or if it could be retrieved from Track 2 data. Present if the transaction (i.e. local) currency differs from the settlement currency. Echoed from original advice. Present if the transaction (i.e. local) currency differs from the settlement currency. Present if the transaction (i.e. local) currency differs from the settlement currency.
Message Content
108
Field 54 58 59 67 90
Description Additional amounts Authorizing agent ID code Echo data Extended payment code Original data elements
Condition Conditional Conditional Conditional Conditional Conditional
Notes Contains the approved amount. If the transaction is a goods and services with cash back transaction amount cash will also be present. Included if the authorizer and the card issuer differs. Echoed from original advice. Echoed from original advice. Present if supplied in the message from the source or constructed by Transaction Manager from the contents of the original message, if it could be retrieved.
95 98 100 102
Replacement amounts Payee Receiving institution ID code Account identification 1
Always sent Conditional Conditional Conditional Present for Third-party payments (inter-bank transfers) and linked bill payments. Included if present in the initial message from the Source Node. Included if present in the response message from the Sink Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer. Included if present in the response message from the Sink Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer.
103
Conditional
123 127.1 127.3 127.4 127.5 127.6 127.7
POS data code Bitmap Routing information POS data Service station data Authorization profile Check data
Always sent Always sent Always sent Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node or if received in the response message from the Sink Node. Included if a duplicate transaction was received, and Transaction Manager is configured to respond to duplicate transactions. Present if MACing is enabled for the current message type. Included if a check guarantee or a check verification transaction. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Echoed from original advice. Echoed from original advice.
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.23 Payee name and address 127.24 Payer account 127.33 Extended transaction type 127.39 Original response code 128 MAX extended
4.2.5
Field 2
Send - Transaction Request (Repeat) (0200/0201)

3 4 5
Message Content
109
Field 7 9
Description Transmission date and time Conversion rate, settlement
Condition Always sent Conditional
Notes
11 12 13 14 15 16
18 22 23 25 26 27 28 29
30 31
32 33 35 37 40 41 42 43 45 49 50
Conditional Conditional Conditional Always sent Conditional Always sent Always sent Always sent Conditional Always sent Conditional
52 53 54 56 59 67 98
PIN data Security related control information Additional amounts Message reason code Echo data Extended payment code Payee
Conditional Conditional Conditional Always sent Always sent Conditional Conditional
Included if the transaction is a budget transaction. Present for Third-party payments (inter-bank transfers) and linked bill payments.
Message Content
110
Field 100 102
Notes Included if present in the initial message from the Source Node. Included if present in the response message from the Source Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer. Included if present in the response message from the Source Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer.
103
Conditional
123 127.1 127.2 127.3 127.4 127.5 127.7 127.9
Always sent Always sent Always sent Always sent Conditional Conditional Conditional Conditional Conditional Conditional Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if a check guarantee or a check verification transaction. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. If the corresponding message from the Source Node contained field 127.11, then Transaction Manager will locate the Sink Node equivalent value and send it in field 127.11. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present for third-party payments (inter-bank transfers).
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.15 Address verification data 127.16 Address verification result 127.18 Validation data 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.23 Payee name and address 127.24 Payer account 127.25 ICC data 127.26 Original node 127.27 Card verification result
Conditional Conditional Conditional Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional
Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if an original transaction could be found. This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type.
127.28 American express card identifier (CID) 127.29 3D secure data 127.32 UCAF data 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
Message Content
111
4.2.6
Field 2
Send Transaction Completion (Repeat) (0202)

3 4 5
7 9
11 12 13 14 15 16
18 22 23 25 28 29
30 31
32 33 35 37 38 39 40 41 42 43 45 49
Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Response Code Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Track 1 data Currency code, transaction
Conditional Conditional Conditional Always sent Conditional Always sent Conditional Always sent Always sent Always sent Conditional Always sent
Message Content
112
Field 50
Description Currency code, settlement
Notes Present if the Transaction Manager performs currency conversion for the Node the message is sent to and the transaction (i.e. local) currency differs from the settlement currency. Contains the approved amount for the transaction. Note that the final amount can be different (and higher) than the approved amount. This is typically the case when, e.g. a tip is added in a restaurant.
54
Additional amounts
Conditional
56 58 59 67 95 100 102
Message reason code Authorizing agent ID code Echo data Extended payment code Replacement amounts Receiving institution ID code Account identification 1
Always sent Conditional Always sent Conditional Always sent Conditional Conditional Included if present in the initial message from the Source Node. Included if present in the response message from the Source Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer. Included if present in the response message from the Source Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer. Included if the transaction is a budget transaction. Included if the authorizer and the card issuer differs.
103
Conditional
123 127.1 127.2 127.3 127.4 127.5 127.6 127.7
POS data code Bitmap Switch key Routing information POS data Service station data Authorization profile Check data
Always sent Always sent Always sent Always sent Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type. Included if a check guarantee or a check verification transaction. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present for third-party payments (inter-bank transfers). Echoed from original request. Echoed from original request.
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.23 Payee name and address 127.24 Payer account 127.33 Extended transaction type 128 MAX extended
4.2.7
Field 2
Send - Transaction Request Response (0210)

3 4 5 7 9 11
Processing code Amount, transaction Amount, settlement Transmission date and time Conversion rate, settlement System trace audit number
Always sent Always sent Conditional Always sent Conditional Always sent Present if the transaction (i.e. local) currency differs from the settlement currency. Present if the transaction (i.e. local) currency differs from the settlement currency.
Message Content
113
Field 12 13 14 15 16 18 22 23 25 28 29 30 31 32 33 35 37 38 39 40 41 42 43 44 45 48 49 50 54 58 59 67 98 100 102
Description Time, local transaction Date, local transaction Date, expiration Date, settlement Date, conversion Merchants type POS entry mode Card sequence number POS condition code Amount, transaction fee Amount, settlement fee Amount, transaction processing fee Amount, settle processing fee Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Response code Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Additional response data Track 1 data Additional response data Currency code, transaction Currency code, settlement Additional amounts Authorizing agent ID code Echo data Extended payment code Payee Receiving institution ID code Account identification 1
Condition Always sent Always sent Always sent Always sent Conditional Conditional Always sent Conditional Always sent Always sent Conditional Always sent Conditional Conditional Conditional Conditional Always sent Conditional Always sent Conditional Always sent Always sent Always sent Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional
Notes
From authorizer (or from stand-in authorization). Included if present in the initial message from the Source Node. Present for approved linked account inquiries.
Present if the transaction (i.e. local) currency differs from the settlement currency. Contains the approved amount. If the transaction is a goods and services with cash back transaction amount cash will also be present. Included if the authorizer and the card issuer differs. Echoed from original request. Echoed from original request. Present for Third-party payments (inter-bank transfers) and linked bill payments. Included if present in the initial message from the Source Node. Included if present in the response message from the Sink Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer. Included if present in the response message from the Sink Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer.
103
Conditional
123 127.1 127.3
POS data code Bitmap Routing information
Always sent Always sent Always sent
Message Content
114
Field 127.4 127.5 127.6 127.7 127.9
Description POS data Service station data Authorization profile Check data Additional node data
Condition Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional
Notes Echoed from original request. Echoed from original request.
Included if a check guarantee or a check verification transaction. From authorizer (Sink Node). Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. From authorizer (Sink Node). From authorizer (or from stand-in authorization). Included if present in the initial message from the Source Node.
Included if present in the response message received from the Sink Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the response message received from the Sink Node the Sink Node is configured to do EMV authentication
If the Sink Node is configured to do EMV authentication then this field will contain the IccResponse Issuer Authentication Data subfield. 127.27 Card verification result Conditional This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. From authorizer (Sink Node). From authorizer (Sink Node). From authorizer (Sink Node). Included if present in the initial message from the Source Node or if received in the response message from the Sink Node. Included if a duplicate transaction was received, and Transaction Manager is configured to respond to duplicate transactions. Present if MACing is enabled for the current message type.
127.30 3D secure result 127.31 Issuer network ID 127.32 UCAF data 127.33 Extended transaction type 127.39 Original response code 128 MAX extended
Conditional Conditional Conditional Conditional Conditional Conditional
4.2.8
Field 2
Send Transaction Completion Response (0212)

3 4 5 7 9 11 12 13
Processing code Amount, transaction Amount, settlement Transmission date and time Conversion rate, settlement System trace audit number Time, local transaction Date, local transaction
Always sent Always sent Conditional Always sent Conditional Always sent Always sent Always sent Present if the transaction (i.e. local) currency differs from the settlement currency. Present if the transaction (i.e. local) currency differs from the settlement currency.
Message Content
115
Field 14 15 16 18 22 23 25 28 29 30 31 32 33 35 37 38 39 40 41 42 43 45 49 50 54 58 59 67 95 98 100 102
Description Date, expiration Date, settlement Date, conversion Merchants type POS entry mode Card sequence number POS condition code Amount, transaction fee Amount, settlement fee Amount, transaction processing fee Amount, settle processing fee Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Response code Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Track 1 data Currency code, transaction Currency code, settlement Additional amounts Authorizing agent ID code Echo data Extended payment code Replacement amounts Payee Receiving institution ID code Account identification 1
Condition Always sent Always sent Conditional Conditional Always sent Conditional Always sent Always sent Conditional Always sent Conditional Conditional Conditional Conditional Always sent Conditional Always sent Conditional Always sent Always sent Always sent Conditional Always sent Conditional Conditional Conditional Always sent Conditional Always sent Conditional Conditional Conditional
Notes
Present if the transaction (i.e. local) currency differs from the settlement currency. Echoed from original advice.
Present if the transaction (i.e. local) currency differs from the settlement currency. Contains amount cash if the transaction is a goods and services with cash back transaction. Included if the authorizer and the card issuer differs. Echoed from original advice. Echoed from original advice.
Present for Third-party payments (inter-bank transfers) and linked bill payments. Included if present in the initial message from the Source Node. Included if present in the response message from the Sink Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer. Included if present in the response message from the Sink Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer.
103
Conditional
123 127.1 127.3 127.4 127.5 127.6
POS data code Bitmap Routing information POS data Service station data Authorization profile
Always sent Always sent Always sent Conditional Conditional Always sent Echoed from original advice. Echoed from original advice.
Message Content
116
Field 127.7
Description Check data
Condition Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional
Notes Included if a check guarantee or a check verification transaction. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node.
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.23 Payee name and address 127.24 Payer account 127.33 Extended transaction type 128 MAX extended
Included if present in the response message received from the Sink Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node or if received in the response message from the Sink Node. Present if MACing is enabled for the current message type.
4.2.9
Field 2
Send - Transaction Advice (Repeat) (0220/0221)

3 4 5
7 9
11 12 13 14 15 16
18 22 23 25 28 29
30 31
Message Content
117
Field 32 33 35 37 38 39
Description Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Response Code
Condition Conditional Conditional Conditional Always sent Conditional Conditional
Notes Included if present in the initial message from the Source Node or if configured in the node configuration for the Sink Node. Included if present in the initial message from the Source Node or if configured in the node configuration for the Sink Node. Present if Track 2 was entered at the Point of Service.
From authorizer (or from stand-in authorization). Copied from the 0120/0220 message from the Source Node, or if field 39 is not present in the 0120/0220 message from the Source Node, a response code of 00 will be sent. If the Transaction Manager performs PIN verification, the PIN verification failed and the Sink Node is configured to receive an advice if a PIN failure occurs, this field indicates an incorrect PIN.
40 41 42 43 44 45 49 50
Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Additional response data Track 1 data Currency code, transaction Currency code, settlement
Conditional Always sent Always sent Always sent Conditional Conditional Always sent Conditional
Present if the Transaction Manager performs currency conversion for the Node the message is sent to and the transaction (i.e. local) currency differs from the settlement currency. Contains the approved amount for the transaction. Note that the final amount can be different (and higher) than the approved amount. This is typically the case when, e.g. a tip is added in a restaurant.
54
Additional amounts
Conditional
56 58 59 67 90
Message reason code Authorizing agent ID code Echo data Extended payment code Original data elements
Always sent Conditional Always sent Conditional Conditional Included if the transaction is a budget transaction. Present if supplied in the message from the source or constructed by Transaction Manager from the contents of the original message, if it could be retrieved. Included if the authorizer and the card issuer differs.
95 98 100 102
103
Conditional
123 127.1 127.2 127.3 127.4 127.5 127.6 127.7 127.9
Always sent Always sent Always sent Always sent Conditional Conditional Always sent Conditional Conditional Included if a check guarantee or a check verification transaction. Included if present in any prior message, associated with the transaction, from Source Node. Echoed from original request. Echoed from original request.
Message Content
118
Field
Description
Notes If the corresponding message from the Source Node contained field 127.11, then Transaction Manager will locate the Sink Node equivalent value and send it in field 127.11. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present for third-party payments (inter-bank transfers).
127.11 Original key
Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional
Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if an original transaction could be found. This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type.
127.32 UCAF data 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
4.2.10
Field 2
Send - Transaction Advice Response (0230)

Condition Conditional Notes If this information was provided in the message received by the Source Node (in this field or as part of track 2 data), then this field will be present. Present for all card initiated transactions (including check guarantee or check verification transactions that use the plastic card account format).
3 4 5 7 9 11 12 13 14 15 16 18 22 23 25 28 29
Processing code Amount, transaction Amount, settlement Transmission date and time Conversion rate, settlement System trace audit number Time, local transaction Date, local transaction Date, expiration Date, settlement Date, conversion Merchants type POS entry mode Card sequence number POS condition code Amount, transaction fee Amount, settlement fee
Always sent Always sent Conditional Always sent Conditional Always sent Always sent Always sent Always sent Always sent Conditional Conditional Always sent Conditional Always sent Always sent Conditional Present if the transaction (i.e. local) currency differs from the settlement currency. Included if present in the initial message from the Source Node or if it could be retrieved from Track 2 data. Present if the transaction (i.e. local) currency differs from the settlement currency. Echoed from original advice. Present if the transaction (i.e. local) currency differs from the settlement currency. Present if the transaction (i.e. local) currency differs from the settlement currency.
Message Content
119
Field 30 31 32 33 35 37 38 39 40 41 42 43 44 45 49 50 54 58 59 67 90
Description Amount, transaction processing fee Amount, settle processing fee Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Response code Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Additional response data Track 1 data Currency code, transaction Currency code, settlement Additional amounts Authorizing agent ID code Echo data Extended payment code Original data elements
Condition Always sent Conditional Conditional Conditional Conditional Always sent Conditional Always sent Conditional Always sent Always sent Always sent Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional
Notes
Present if the transaction (i.e. local) currency differs from the settlement currency. Contains the approved amount. If the transaction is a goods and services with cash back transaction amount cash will also be present. Included if the authorizer and the card issuer differs. Echoed from original advice. Echoed from original advice. Present if supplied in the message from the source or constructed by Transaction Manager from the contents of the original message, if it could be retrieved.
95 98 100 102
103
Conditional
123 127.1 127.3 127.4 127.5 127.6
POS data code Bitmap Routing information POS data Service station data Authorization profile
Always sent Always sent Always sent Conditional Conditional Always sent Conditional Conditional Conditional Conditional Always sent Conditional Conditional Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Echoed from original advice. Echoed from original advice.
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.23 Payee name and address 127.24 Payer account
Message Content
120
Field
Description
Condition Conditional Conditional Conditional
Notes Included if present in the initial message from the Source Node or if received in the response message from the Sink Node. Included if a duplicate transaction was received, and Transaction Manager is configured to respond to duplicate transactions. Present if MACing is enabled for the current message type.
127.33 Extended transaction type 127.39 Original response code 128 MAX extended
4.2.11
Field 2 7 11 12 13 14 15 23 32 33 37 39 41 42 43 56 91 100 101 127.1 127.3 127.9
Send Acquirer File Update Advice (Repeat) (0320/0321)

Condition Conditional Always sent Always sent Always sent Always sent Always sent Always sent Conditional Conditional Conditional Always sent Always sent Always sent Always sent Conditional Always sent Always sent Conditional Conditional Always sent Always sent Conditional Conditional Conditional Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node, or if it is returned as a result of a card lookup from PostCard records. Notes Included if present in the initial message from the Source Node.
Note that an Acquirer File Update Advice (0320) message is sent by PostBridge connected to a Sink Node.
Description Primary account number Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, expiration Date, settlement Card sequence number Acquiring institution ID code Forwarding institution ID code Retrieval reference number Response Code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Message reason code File update code Receiving institution ID code File name Bitmap Routing information Additional node data
4.2.12
Send Issuer File Update Advice (Repeat) (0322/0323)
Note that an Issuer File Update Advice (0322) message is sent by PostBridge connected to a Source Node if the route to source node option is ticked on the original sink node.
Field 2 7 11 12 13 14 15 Description Primary account number Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, expiration Date, settlement Condition Conditional Always sent Always sent Always sent Always sent Always sent Always sent Included if present in the initial message from the Sink Node, or if it is returned as a result of a card lookup from PostCard records. Notes Included if present in the initial message from the Sink Node.
Message Content
121
Field 23 32 33 37 39 41 42 43 56 91 100 101 127.1 127.3 127.9
Description Card sequence number Acquiring institution ID code Forwarding institution ID code Retrieval reference number Response Code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Message reason code File update code Receiving institution ID code File name Bitmap Routing information Additional node data
Condition Conditional Conditional Conditional Always sent Always sent Always sent Always sent Conditional Always sent Always sent Conditional Conditional Always sent Always sent Conditional Conditional Conditional
Notes Included if present in the initial message from the Sink Node. Included if present in the initial message from the Sink Node. Included if present in the initial message from the Sink Node.
Included if present in the initial message from the Sink Node.
Included if present in the initial message from the Sink Node. Included if present in the initial message from the Sink Node.
Included if present in the initial message from the Sink Node. Included if present in the initial message from the Sink Node. Present if MACing is enabled for the current message type.
4.2.13
Send Acquirer File Update Advice Response (0330)
Note that an Acquirer File Update Advice Response (0330) message is sent by PostBridge connected to a Source Node.
Field 2 7 11 14 15 23 32 33 37 39 41 42 43 56 59 91 100 101 127.1 127.3 Description Primary account number Transmission date and time System trace audit number Date, expiration Date, settlement Card sequence number Acquiring institution ID code Forwarding institution ID code Retrieval reference number Response Code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Message reason code Echo data File update code Receiving institution ID code File name Bitmap Routing information Condition Conditional Always sent Always sent Always sent Always sent Conditional Conditional Conditional Always sent Always sent Always sent Always sent Conditional Always sent Conditional Always sent Conditional Conditional Always sent Always sent Conditional Conditional Included if present in the initial message from the Source Node. Included if a duplicate transaction was received, and Transaction Manager is configured to respond to duplicate transactions. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Sink Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node, or if it is returned as a result of a card lookup from PostCard records. Notes Included if present in the initial message from the Source Node.
127.22 Structured data 127.39 Original response code
Message Content
122
Field 128
Description MAX extended
Notes Present if MACing is enabled for the current message type.
4.2.14
Send Issuer File Update Advice Response (0332/0323)
Note that an Issuer File Update Advice Response (0332) message is sent by PostBridge connected to a Sink Node.
Field 2 7 11 14 15 23 32 33 37 39 41 42 43 56 59 91 100 101 127.1 127.3 Description Primary account number Transmission date and time System trace audit number Date, expiration Date, settlement Card sequence number Acquiring institution ID code Forwarding institution ID code Retrieval reference number Response Code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Message reason code Echo data File update code Receiving institution ID code File name Bitmap Routing information Condition Conditional Always sent Always sent Always sent Always sent Conditional Conditional Conditional Always sent Always sent Always sent Always sent Conditional Always sent Conditional Always sent Conditional Conditional Always sent Always sent Conditional Conditional Included if present in the initial message from the Sink Node. Present if MACing is enabled for the current message type. Included if present in the initial message from the Sink Node. Included if present in the initial message from the Sink Node. Included if present in the initial message from the Sink Node. Included if present in the initial message from the Sink Node. Included if present in the initial message from the Sink Node. Included if present in the initial message from the Sink Node. Included if present in the initial message from the Sink Node. Included if present in the initial message from the Sink Node, or if it is returned as a result of a card lookup from PostCard records. Notes Included if present in the initial message from the Sink Node.
4.2.15
Field 2
Send - Reversal Request (Repeat) (0400/0401)

3 4 5
7 9
11
System trace audit number
Always sent
Message Content
123
Field 12 13 14 15 16
Description Time, local transaction Date, local transaction Date, expiration Date, settlement Date, conversion
Condition Always sent Always sent Conditional Always sent Conditional
Notes
If this information was provided in the message received by the Source Node (in this field or as part of track 2 data), then this field will be present.
Present if the Transaction Manager performs currency conversion for the Node the message is sent to and the transaction (i.e. local) currency differs from the settlement currency. Included if present in the initial message from the Source Node.
18 22 23 25 26 27 28 29
30 31
32 33 35 37 38 40 41 42 43 45 49 50
Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Track 1 data Currency code, transaction Currency code, settlement
Conditional Conditional Conditional Always sent Conditional Conditional Always sent Always sent Always sent Conditional Always sent Conditional
Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node.
52 53 54 56 59 67 90 95 98 100
PIN data Security related control information Additional amounts Message reason code Echo data Extended payment code Original data elements Replacement amounts Payee Receiving institution ID code
Conditional Conditional Conditional Always sent Always sent Conditional Always sent Always sent Conditional Conditional
Included if the transaction is a budget transaction.
Present for Third-party payments (inter-bank transfers) and linked bill payments. Included if present in the initial message from the Source Node.
Message Content
124
Field 102
Notes Included if present in the response message from the Source Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer. Included if present in the response message from the Source Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer.
103
Conditional
123 127.1 127.2 127.3 127.4 127.5 127.7 127.9
Always sent Always sent Always sent Always sent Conditional Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if an original transaction could be found. This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present for third-party payments (inter-bank transfers). Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if a check guarantee or a check verification transaction. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node.
127.10 CVV2 127.11 Original key 127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.15 Address verification data 127.16 Address verification result 127.18 Validation data 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.23 Payee name and address 127.24 Payer account 127.25 ICC data 127.26 Original node 127.27 Card verification result
127.28 American express card identifier (CID) 127.29 3D secure data 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
4.2.16
Field 2
Send - Reversal Request Response (0410)

3 4 5
Always sent Always sent Conditional Present if the transaction (i.e. local) currency differs from the settlement currency.
Message Content
125
Field 7 9 11 12 13 14 15 16 18 22 23 25 28 29 30 31 32 33 35 37 38 39 40 41 42 43 44 45 49 50 54 58 59 67 90 95 98 100 102
Description Transmission date and time Conversion rate, settlement System trace audit number Time, local transaction Date, local transaction Date, expiration Date, settlement Date, conversion Merchants type POS entry mode Card sequence number POS condition code Amount, transaction fee Amount, settlement fee Amount, transaction processing fee Amount, settle processing fee Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Response code Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Additional response data Track 1 data Currency code, transaction Currency code, settlement Additional amounts Authorizing agent ID code Echo data Extended payment code Original data elements Replacement amounts Payee Receiving institution ID code Account identification 1
Condition Always sent Conditional Always sent Always sent Always sent Always sent Always sent Conditional Conditional Always sent Conditional Always sent Always sent Conditional Always sent Conditional Conditional Conditional Conditional Always sent Conditional Always sent Conditional Always sent Always sent Always sent Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Always sent Always sent Conditional Conditional Conditional
Notes
If this information was provided in the message received by the Source Node (in this field or as part of track 2 data), then this field will be present
Present if the transaction (i.e. local) currency differs from the settlement currency. Contains the approved amount. If the transaction is a goods and services with cash back transaction amount cash will also be present. Included if the authorizer and the card issuer differs. Echoed from original request. Echoed from original request.
Present for Third-party payments (inter-bank transfers) and linked bill payments. Included if present in the initial message from the Source Node. Included if present in the response message from the Sink Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer.
Message Content
126
Field 103
Notes Included if present in the response message from the Sink Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer.
123 127.1 127.3 127.4 127.5 127.6 127.7 127.9
Always sent Always sent Always sent Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Included if present in the response message received from the Sink Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the response message received from the Sink Node the Sink Node is configured to do EMV authentication Included if a check guarantee or a check verification transaction. From authorizer (Sink Node). Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. From authorizer (Sink Node). From authorizer (or from stand-in authorization). Included if present in the initial message from the Source Node. Echoed from original request. Echoed from original request.
If the Sink Node is configured to do EMV authentication then this field will contain the IccResponse Issuer Authentication Data subfield. 127.27 Card verification result Conditional This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. From authorizer (Sink Node). From authorizer (Sink Node). Included if present in the initial message from the Source Node or if received in the response message from the Sink Node. Included if a duplicate transaction was received, and Transaction Manager is configured to respond to duplicate transactions. Present if MACing is enabled for the current message type.
127.30 3D secure result 127.31 Issuer network ID 127.33 Extended transaction type 127.39 Original response code 128 MAX extended
Message Content
127
4.2.17
Field 2
Send Reversal Advice (Repeat) (0420/0421)

3 4 5
7 9
11 12 13 14
Always sent Always sent Always sent Conditional If this information was provided in the message received by the Source Node (in this field or as part of track 2 data), then this field will be present. Present for all card initiated transactions (including check guarantee or check verification transactions that use the plastic card account format).
15 16
Date, settlement Date, conversion
Always sent Conditional Present if the Transaction Manager performs currency conversion for the Node the message is sent to and the transaction (i.e. local) currency differs from the settlement currency. Included if present in the initial message from the Source Node.
18 22 23 25 28 29
30 31
32 33 35 37 38 39
Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Response Code
Conditional Conditional Conditional Always sent Conditional Conditional
40
Service restriction code
Conditional
Message Content
128
Field 41 42 43 44 45 49 50
Description Card acceptor terminal ID Card acceptor ID code Card acceptor name location Additional response data Track 1 data Currency code, transaction Currency code, settlement
Condition Always sent Always sent Always sent Conditional Conditional Always sent Conditional
Notes
54
Additional amounts
Conditional
56 58 59 67 90
95 98 100 102
103
Conditional
123 127.1 127.2 127.3 127.4 127.5 127.6 127.7 127.9
Always sent Always sent Always sent Always sent Conditional Conditional Always sent Conditional Conditional Conditional Included if a check guarantee or a check verification transaction. Included if present in any prior message, associated with the transaction, from Source Node. If the reversal was generated due to a timeout, then this field will contain the value of field 127.2 of the original message that timed out. If the corresponding message from the Source Node contained field 127.11, then Transaction Manager will locate the Sink Node equivalent value and send it in field 127.11. Echoed from original request. Echoed from original request.
127.11 Original key
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.22 Structured data 127.23 Payee name and address 127.24 Payer account
Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional
Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present for third-party payments (inter-bank transfers).
Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node.
Message Content
129
Field
Description
Condition Conditional Conditional Conditional
Notes Included if present in the initial message from the Source Node. Present if an original transaction could be found. This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type.
127.25 ICC data 127.26 Original node 127.27 Card verification result
127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
Conditional Conditional Conditional Conditional
4.2.18
Field 2
Send Reversal Advice Response (0430)

3 4 5 7 9 11 12 13 14
Processing code Amount, transaction Amount, settlement Transmission date and time Conversion rate, settlement System trace audit number Time, local transaction Date, local transaction Date, expiration
Always sent Always sent Conditional Always sent Conditional Always sent Always sent Always sent Conditional If this information was provided in the message received by the Source Node (in this field or as part of track 2 data), then this field will be present. Present for all card initiated transactions (including check guarantee or check verification transactions that use the plastic card account format). Present if the transaction (i.e. local) currency differs from the settlement currency. Present if the transaction (i.e. local) currency differs from the settlement currency.
15 16 18 22 23 25 28 29 30 31 32 33 35 37 38 39 40
Date, settlement Date, conversion Merchants type POS entry mode Card sequence number POS condition code Amount, transaction fee Amount, settlement fee Amount, transaction processing fee Amount, settle processing fee Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Response code Service restriction code
Always sent Conditional Conditional Always sent Conditional Always sent Always sent Conditional Always sent Conditional Conditional Conditional Conditional Always sent Conditional Always sent Conditional Included if present in the initial message from the Source Node. From authorizer (or from stand-in authorization). Present if the transaction (i.e. local) currency differs from the settlement currency. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if Track 2 was entered at the Point of Service. Present if the transaction (i.e. local) currency differs from the settlement currency. Included if present in the initial message from the Source Node or if it could be retrieved from Track 2 data. Present if the transaction (i.e. local) currency differs from the settlement currency. Echoed from original advice.
Message Content
130
Field 41 42 43 45 49 50 54 58 59 67 90
Description Card acceptor terminal ID Card acceptor ID code Card acceptor name location Track 1 data Currency code, transaction Currency code, settlement Additional amounts Authorizing agent ID code Echo data Extended payment code Original data elements
Condition Always sent Always sent Always sent Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional
Notes
Present if the transaction (i.e. local) currency differs from the settlement currency. Contains the approved amount. If the transaction is a goods and services with cash back transaction amount cash will also be present. Included if the authorizer and the card issuer differs. Echoed from original advice. Echoed from original advice. Present if supplied in the message from the source or constructed by Transaction Manager from the contents of the original message, if it could be retrieved.
95 98 100 102
103
Conditional
123 127.1 127.3 127.4 127.5 127.6 127.7
POS data code Bitmap Routing information POS data Service station data Authorization profile Check data
Always sent Always sent Always sent Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node or if received in the response message from the Sink Node. Included if a duplicate transaction was received, and Transaction Manager is configured to respond to duplicate transactions. Present if MACing is enabled for the current message type. Included if a check guarantee or a check verification transaction. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Echoed from original advice. Echoed from original advice.
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.23 Payee name and address 127.24 Payer account 127.33 Extended transaction type 127.39 Original response code 128 MAX extended
Message Content
131
4.2.19
Field 7 11 12 13 15 32 39 41 42 50 59 66 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 97 118 119 128
Send Acquirer Reconciliation Request Response (0510)

Condition Always sent Always sent Always sent Always sent Always sent Conditional Always sent Conditional Conditional Always sent Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Present if MACing is enabled for the current message type. Echoed from original request. Present if the Node has a settlement granularity of terminal. Present if the Node has a settlement granularity of terminal or card acceptor. Present if the Node has a settlement granularity of acquirer. Notes
Description Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, settlement Acquiring institution ID code Response Code Card acceptor terminal ID Card acceptor ID code Currency code, settlement Echo data Settlement code Credits, number Credits, reversal number Debits, number Debits, reversal number Transfers, number Transfers, reversal number Inquiries, number Authorizations, number Credits, processing fee amount Credits, transaction fee amount Debits, processing fee amount Debits, transaction fee amount Credits, amount Credits, reversal amount Debits, amount Debits, reversal amount Amount, net settlement Payments, number Payments, reversal number MAX extended
Message Content
132
4.2.20
Field 7 11 12 13 15 32 39 41 42 50 59 66 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 97 118 119 128
Send Card Issuer Reconciliation Request Response (0512)

Condition Always sent Always sent Always sent Always sent Always sent Conditional Always sent Conditional Conditional Always sent Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Present if MACing is enabled for the current message type. Echoed from original request. Present if the Node has a settlement granularity of terminal. Present if the Node has a settlement granularity of terminal or card acceptor. Present if the Node has a settlement granularity of acquirer. Notes
Description Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, settlement Acquiring institution ID code Response Code Card acceptor terminal ID Card acceptor ID code Currency code, settlement Echo data Settlement code Credits, number Credits, reversal number Debits, number Debits, reversal number Transfers, number Transfers, reversal number Inquiries, number Authorizations, number Credits, processing fee amount Credits, transaction fee amount Debits, processing fee amount Debits, transaction fee amount Credits, amount Credits, reversal amount Debits, amount Debits, reversal amount Amount, net settlement Payments, number Payments, reversal number MAX extended
Message Content
133
4.2.21
Field 7 11 12 13 15 32 41 42 50 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 97 118 119 127.1
Send Acquirer Reconciliation Advice (Repeat) (0520/0521)

Condition Always sent Always sent Always sent Always sent Always sent Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Sent if Postilion private data is present. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type. Present if the Node has a settlement granularity of acquirer. Present if the Node has a settlement granularity of terminal. Present if the Node has a settlement granularity of terminal or card acceptor. Notes
Description Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, settlement Acquiring institution ID code Card acceptor terminal ID Card acceptor ID code Currency code, settlement Credits, number Credits, reversal number Debits, number Debits, reversal number Transfers, number Transfers, reversal number Inquiries, number Authorizations, number Credits, processing fee amount Credits, transaction fee amount Debits, processing fee amount Debits, transaction fee amount Credits, amount Credits, reversal amount Debits, amount Debits, reversal amount Amount, net settlement Payments, number Payments, reversal number Bitmap
Message Content
134
4.2.22
Field 7 11 12 13 15 32 41 42 50 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 97 118 119 127.1
Send Card Issuer Reconciliation Advice (Repeat) (0522/0523)

Condition Always sent Always sent Always sent Always sent Always sent Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Sent if Postilion private data is present. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type. Present if the Node has a settlement granularity of acquirer. Present if the Node has a settlement granularity of terminal. Present if the Node has a settlement granularity of terminal or card acceptor. Notes
Description Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, settlement Acquiring institution ID code Card acceptor terminal ID Card acceptor ID code Currency code, settlement Credits, number Credits, reversal number Debits, number Debits, reversal number Transfers, number Transfers, reversal number Inquiries, number Authorizations, number Credits, processing fee amount Credits, transaction fee amount Debits, processing fee amount Debits, transaction fee amount Credits, amount Credits, reversal amount Debits, amount Debits, reversal amount Amount, net settlement Payments, number Payments, reversal number Bitmap
Message Content
135
4.2.23
Field 7 11 12 13 15 32 39 41 42 50 59 66 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 97 118 119 127.1
Send Acquirer Reconciliation Advice Response (0530)

Condition Always sent Always sent Always sent Always sent Always sent Conditional Always sent Conditional Conditional Always sent Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Sent if Postilion private data is present. Echoed from original advice. Present if the Node has a settlement granularity of terminal. Present if the Node has a settlement granularity of terminal or card acceptor. Present if the Node has a settlement granularity of acquirer. Notes
Description Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, settlement Acquiring institution ID code Response Code Card acceptor terminal ID Card acceptor ID code Currency code, settlement Echo data Settlement code Credits, number Credits, reversal number Debits, number Debits, reversal number Transfers, number Transfers, reversal number Inquiries, number Authorizations, number Credits, processing fee amount Credits, transaction fee amount Debits, processing fee amount Debits, transaction fee amount Credits, amount Credits, reversal amount Debits, amount Debits, reversal amount Amount, net settlement Payments, number Payments, reversal number Bitmap
Message Content
136
Field
Description
Notes Included if a duplicate transaction was received, and Transaction Manager is configured to respond to duplicate transactions. Present if MACing is enabled for the current message type.
127.39 Original response code 128 MAX extended
4.2.24
Field 7 11 12 13 15 32 39 41 42 50 59 66 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 97
Send Card Issuer Reconciliation Advice Response (0532)

Condition Always sent Always sent Always sent Always sent Always sent Conditional Always sent Conditional Conditional Always sent Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Echoed from original advice. Present if the Node has a settlement granularity of terminal. Present if the Node has a settlement granularity of terminal or card acceptor. Present if the Node has a settlement granularity of acquirer. Notes
Description Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, settlement Acquiring institution ID code Response Code Card acceptor terminal ID Card acceptor ID code Currency code, settlement Echo data Settlement code Credits, number Credits, reversal number Debits, number Debits, reversal number Transfers, number Transfers, reversal number Inquiries, number Authorizations, number Credits, processing fee amount Credits, transaction fee amount Debits, processing fee amount Debits, transaction fee amount Credits, amount Credits, reversal amount Debits, amount Debits, reversal amount Amount, net settlement
Message Content
137
Field 118 119 127.1
Description Payments, number Payments, reversal number Bitmap
Notes Contains the totals maintained by the Transaction Manager for the applicable settlement period. Contains the totals maintained by the Transaction Manager for the applicable settlement period. Sent if Postilion private data is present. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type.
4.2.25
Field 2
Send - Administration Request (Repeat) (0600/0601)

3 4 7 11 12 13 14
Always sent Conditional Always sent Always sent Always sent Always sent Conditional If this information was provided in the message received by the Source Node (in this field or as part of track 2 data), then this field will be present. Present for all card initiated transactions (including check guarantee or check verification transactions that use the plastic card account format). Included if present in the initial message from the Source Node.
15 18 22 23 25 26 28 32 35 37 40 41 42 43 45 49 52 53 56
Date, settlement Merchants type POS entry mode Card sequence number POS condition code POS PIN capture code Amount, transaction fee Acquiring institution ID code Track 2 data Retrieval reference number Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Track 1 data Currency code, transaction PIN data Security related control information Message reason code
Always sent Conditional Always sent Conditional Always sent Conditional Conditional Conditional Conditional Always sent Conditional Always sent Always sent Always sent Conditional Conditional Conditional Conditional Conditional Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if a PIN was entered at the Point of Service. Present if a PIN was entered at the Point of Service and the DUKPT PIN encryption scheme is used. If the transaction type is 92 (PIN change) and the response code is 38 (PIN tries exceeded, pick up), 55 (Incorrect PIN) or 75 (PIN tries exceeded) a message reason code of 1376 is sent. Otherwise the message reason code is included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if a PIN was entered at the Point of Service. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node or if configured in the node configuration for the Sink Node. Present if Track 2 was entered at the Point of Service. Included if present in the initial message from the Source Node or if it could be retrieved from Track 2 data. Included if present in the initial message from the Source Node.
59
Echo data
Always sent
Message Content
138
Field 100 102
Notes Included if present in the initial message from the Source Node. Included if present in the response message from the Source Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer.
123 127.1 127.2 127.3 127.4 127.9
POS data code Bitmap Switch key Routing information POS data Additional node data
Always sent Always sent Always sent Always sent Conditional Conditional Conditional Conditional Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. If the corresponding message from the Source Node contained field 127.11, then Transaction Manager will locate the Sink Node equivalent value and send it in field 127.11. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if an original transaction could be found. This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type.
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.15 Address verification data 127.16 Address verification result 127.18 Validation data 127.22 Structured data 127.25 ICC data 127.26 Original node 127.27 Card verification result
Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional
127.28 American express card identifier (CID) 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
4.2.26
Field 2
Send - Administration Request Response (0610)

3 4 7 11 12 13 14 15 18 22
Processing code Amount, transaction Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, expiration Date, settlement Merchants type POS entry mode
Always sent Conditional Always sent Always sent Always sent Always sent Conditional Always sent Conditional Always sent Echoed from original request. Included if present in the initial message from the Source Node. Echoed from original request.
Message Content
139
Field 23 25 28 32 33 35 37 39 40 41 42 43 44 45 49 56
Description Card sequence number POS condition code Amount, transaction fee Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Response code Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Additional response data Track 1 data Currency code, transaction Message reason code
Condition Conditional Always sent Conditional Conditional Conditional Conditional Always sent Always sent Conditional Always sent Always sent Always sent Conditional Conditional Conditional Conditional
Notes Included if present in the initial message from the Source Node or if it could be retrieved from Track 2 data.
Echoed from original request. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if Track 2 was entered at the Point of Service.
From authorizer (or from stand-in authorization). Included if present in the initial message from the Source Node. Echoed from original request. If the transaction type is 92 (PIN change) and the response code is 38 (PIN tries exceeded, pick up), 55 (Incorrect PIN) or 75 (PIN tries exceeded) a message reason code of 1376 is sent. Otherwise the message reason code is included if present in the initial message from the Source Node. Echoed from original request. Included if present in the initial message from the Source Node. Included if present in the response message from the Sink Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer.
59 100 102
Echo data Receiving institution ID code Account identification 1
123 127.1 127.3 127.4 127.9
POS data code Bitmap Routing information POS data Additional node data
Always sent Always sent Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Echoed from original request. From authorizer (Sink Node). Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. From authorizer (Sink Node). From authorizer (or from stand-in authorization). Included if present in the response message received from the Sink Node. Included if present in the response message received from the Sink Node the Sink Node is configured to do EMV authentication
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.15 Address verification data 127.16 Address verification result 127.17 Cardholder information 127.22 Structured data 127.25 ICC data
If the Sink Node is configured to do EMV authentication then this field will contain the IccResponse Issuer Authentication Data subfield. 127.27 Card verification result Conditional This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. From authorizer (Sink Node). Included if present in the initial message from the Source Node or if received in the response message from the Sink Node.
127.31 Issuer network ID 127.33 Extended transaction type
Message Content
140
Field
Description
Notes Included if a duplicate transaction was received, and Transaction Manager is configured to respond to duplicate transactions. Present if MACing is enabled for the current message type.
127.39 Original response code 128 MAX extended
4.2.27
Field 2
Send - Administration Advice (Repeat) (0620/0621)

3 4 7 11 12 13 14
15 18 22 23 25 28 32 35 37 39 40 41 42 43 44 45 49 53 56
Date, settlement Merchants type POS entry mode Card sequence number POS condition code Amount, transaction fee Acquiring institution ID code Track 2 data Retrieval reference number Response Code Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Additional response data Track 1 data Currency code, transaction Security related control information Message reason code
Always sent Conditional Always sent Conditional Always sent Conditional Conditional Conditional Always sent Always sent Conditional Always sent Always sent Always sent Conditional Conditional Conditional Conditional Conditional From authorizer (or from stand-in authorization). Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. If the transaction type is 92 (PIN change) and the response code is 38 (PIN tries exceeded, pick up), 55 (Incorrect PIN) or 75 (PIN tries exceeded) a message reason code of 1376 is sent. Otherwise the message reason code is included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node or if configured in the node configuration for the Sink Node. Present if Track 2 was entered at the Point of Service. Included if present in the initial message from the Source Node or if it could be retrieved from Track 2 data. Included if present in the initial message from the Source Node.
59 90
Echo data Original data elements
Always sent Conditional Present if supplied in the message from the source or constructed by Transaction Manager from the contents of the original message, if it could be retrieved. Included if present in the initial message from the Source Node. Included if present in the response message from the Source Node or if Transaction Manager provides issuer services and the transaction is a
100 102
Receiving institution ID code Account identification 1
Message Content
141
Field 123 127.1 127.2 127.3 127.4 127.9
Description POS data code Bitmap Switch key Routing information POS data Additional node data
Condition Always sent Always sent Always sent Always sent Conditional Conditional Conditional
Notes debit, inquiry, payment or transfer.
Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. If the corresponding message from the Source Node contained field 127.11, then Transaction Manager will locate the Sink Node equivalent value and send it in field 127.11. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if an original transaction could be found. This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type.
127.11 Original key
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.22 Structured data 127.25 ICC data 127.26 Original node 127.27 Card verification result
127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
4.2.28
Field 2
Send - Administration Advice Response (0630)

3 4 7 11 12 13 14 15 18 22 23 25 28 32 33 35 37 39
Processing code Amount, transaction Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, expiration Date, settlement Merchants type POS entry mode Card sequence number POS condition code Amount, transaction fee Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Response code
Always sent Conditional Always sent Always sent Always sent Always sent Always sent Always sent Conditional Always sent Conditional Always sent Conditional Conditional Conditional Conditional Always sent Always sent Echoed from original advice. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if Track 2 was entered at the Point of Service. Included if present in the initial message from the Source Node or if it could be retrieved from Track 2 data. Echoed from original advice. Echoed from original advice.
Message Content
142
Field 40 41 42 43 45 49 56
Description Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Track 1 data Currency code, transaction Message reason code
Condition Conditional Always sent Always sent Always sent Conditional Conditional Conditional
Notes Included if present in the initial message from the Source Node.
Included if present in the initial message from the Source Node. Echoed from original advice. If the transaction type is 92 (PIN change) and the response code is 38 (PIN tries exceeded, pick up), 55 (Incorrect PIN) or 75 (PIN tries exceeded) a message reason code of 1376 is sent. Otherwise the message reason code is included if present in the initial message from the Source Node. Echoed from original advice. Included if present in the initial message from the Source Node. Included if present in the response message from the Sink Node or if Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer.
59 100 102
Echo data Receiving institution ID code Account identification 1
123 127.1 127.3 127.4
POS data code Bitmap Routing information POS data
Always sent Always sent Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional Echoed from original advice. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node or if received in the response message from the Sink Node. Included if a duplicate transaction was received, and Transaction Manager is configured to respond to duplicate transactions. Present if MACing is enabled for the current message type.
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.33 Extended transaction type 127.39 Original response code 128 MAX extended
4.2.29
Field 7 11 12 13 70 128
Send Network Management Request (Repeat) (0800/0801)

Condition Always sent Always sent Always sent Always sent Always sent Conditional Present if MACing is enabled for the current message type. Notes
Description Transmission date and time System trace audit number Time, local transaction Date, local transaction Network management information code MAX extended
4.2.30
Field 7 11 12 13 39 53
Send Network Management Response (0810)

Condition Always sent Always sent Always sent Always sent Always sent Conditional Present if an approved key management transaction and the "Crypto Field 125" user parameter for the interchange is set to '0'. Contains the encrypted value and check digits of the PIN key used for encryption of PIN blocks from the Acquirer. Notes
Description Transmission date and time System trace audit number Time, local transaction Date, local transaction Response code Security related control information
70
Network management information code
Always sent
Message Content
143
Field 125
Description Network management information
Notes Present if an approved key management transaction and the "Crypto Field 125" user parameter for the interchange is set to '1'. Contains the encrypted value and check digits of the PIN key used for encryption of PIN blocks from the Acquirer. Present if MACing is enabled for the current message type.
128
MAX extended
Conditional
4.2.31
Field 2
Send - Authorization Notification Advice (Repeat) (9120/9121)

3 4 5
7 9
11 12 13 14 15 16
18 22 23 25 28 29
30 31
32 33 35 37 38 39 40
Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Response Code Service restriction code
Conditional Conditional Conditional Always sent Conditional Always sent Conditional
Message Content
144
Field 41 42 43 44 45 49 50
Description Card acceptor terminal ID Card acceptor ID code Card acceptor name location Additional response data Track 1 data Currency code, transaction Currency code, settlement
Condition Always sent Always sent Always sent Conditional Conditional Always sent Conditional
Notes
Present if the Transaction Manager performs currency conversion for the Node the message is sent to and the transaction (i.e. local) currency differs from the settlement currency. Contains amount cash if the transaction is a goods and services with cash back transaction.
54 56 58 59 67 90
Additional amounts Message reason code Authorizing agent ID code Echo data Extended payment code Original data elements
Conditional Always sent Conditional Always sent Conditional Conditional
Included if the authorizer and the card issuer differs.
Included if the transaction is a budget transaction. Present if supplied in the message from the source or constructed by Transaction Manager from the contents of the original message, if it could be retrieved.
95 98 100 102
Replacement Amounts Payee Receiving institution ID code Account identification 1
103
Conditional
123 127.1 127.3 127.4 127.5 127.6 127.7 127.9
Always sent Always sent Always sent Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if an original transaction could be found. This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. From authorizer (sink node). Included if a check guarantee or a check verification transaction. Included if present in any prior message, associated with the transaction, from Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present for third-party payments (inter-bank transfers). Echoed from original request/advice. Echoed from original request/advice.
127.31 Issuer network ID
Conditional
Message Content
145
Field
Description
Notes Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type.
127.32 UCAF data 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
4.2.32
Field 2
Send - Transaction Notification Advice (Repeat) (9220/9221)

3 4 5
7 9
11 12 13 14 15 16
18 22 23 25 28 29
30 31
32 33 35 37 38
Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response
Conditional Conditional Conditional Always sent Conditional
Message Content
146
Field 39
Description Response Code
Notes Copied from the 0120/0220 message from the Source Node, or if field 39 is not present in the 0120/0220 message from the Source Node, a response code of 00 will be sent. If the Transaction Manager performs PIN verification, the PIN verification failed and the Sink Node is configured to receive an advice if a PIN failure occurs, this field indicates an incorrect PIN.
40 41 42 43 44 45 49 50
Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Additional response data Track 1 data Currency code, transaction Currency code, settlement
Conditional Always sent Always sent Always sent Conditional Conditional Always sent Conditional
54
Additional amounts
Conditional
56 58 59 67 90
95 98 100 102
103
Conditional
123 127.1 127.3 127.4 127.5 127.6 127.7 127.9
Always sent Always sent Always sent Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Always sent Conditional Included if present in the initial message from the Source Node. Included if a check guarantee or a check verification transaction. Included if present in any prior message, associated with the transaction, from Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present for third-party payments (inter-bank transfers). Echoed from original request/advice. Echoed from original request/advice.
127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.19 Bank details 127.20 Originator/Authorizer settlement date 127.22 Structured data
Message Content
147
Field
Description
Notes Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if an original transaction could be found. This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. From authorizer (sink node). Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type.
127.23 Payee name and address 127.24 Payer account 127.25 ICC data 127.26 Original node 127.27 Card verification result
127.31 Issuer network ID 127.32 UCAF data 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
4.2.33
Field 2 7 11 12 13 14 15 23 32 33 37 39 41 42 43 56 91 100 101 127.1 127.3 127.9
Send Acquirer File Update Notification (Repeat) (9320/9321)

Condition Conditional Always sent Always sent Always sent Always sent Always sent Always sent Conditional Conditional Conditional Always sent Always sent Always sent Always sent Conditional Always sent Always sent Conditional Conditional Always sent Always sent Conditional Conditional Conditional Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node, or if it is returned as a result of a card lookup from PostCard records. Notes Included if present in the initial message from the Source Node.
Note that an Acquirer File Update Notification (9320) message is sent by PostBridge connected to a Sink Node.
Description Primary account number Transmission date and time System trace audit number Time, local transaction Date, local transaction Date, expiration Date, settlement Card sequence number Acquiring institution ID code Forwarding institution ID code Retrieval reference number Response Code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Message reason code File update code Receiving institution ID code File name Bitmap Routing information Additional node data
4.2.34
Field 2
Send Reversal Notification Advice (Repeat) (9420/9421)

Condition Conditional Notes If this information was provided in the message received by the Source Node (in this field or as part of track 2 data), then this field will be present.
Message Content
148
Field
Description
Condition
Notes Present for all card initiated transactions (including check guarantee or check verification transactions that use the plastic card account format).
3 4 5
7 9
11 12 13 14 15 16
18 22 23 25 28 29
30 31
32 33 35 37 38 39
Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Authorization ID response Response Code
Conditional Conditional Conditional Always sent Conditional Conditional
40 41 42 43 44
Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Additional response data
Conditional Always sent Always sent Always sent Conditional
Message Content
149
Field 45 49 50
Description Track 1 data Currency code, transaction Currency code, settlement
Condition Conditional Always sent Conditional
Notes Included if present in the initial message from the Source Node.
54
Additional amounts
Conditional
56 58 59 67 90
95 98 100 102
103
Conditional
123 127.1 127.3 127.4 127.5 127.6 127.7 127.9
Always sent Always sent Always sent Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Always sent Conditional Conditional Conditional Conditional Conditional Conditional Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if an original transaction could be found. This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. From authorizer (sink node). Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if a check guarantee or a check verification transaction. Included if present in any prior message, associated with the transaction, from Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present for third-party payments (inter-bank transfers). Echoed from original request/advice. Echoed from original request/advice.
127.31 Issuer network ID 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID
Message Content
150
Field 128
Description MAX extended
Notes Present if MACing is enabled for the current message type.
4.2.35
Field 2
Send - Administration Notification Advice (Repeat) (9620/9621)

3 4 7 11 12 13 14
15 18 22 23 25 26 28 32 33 35 37 39 40 41 42 43 44 45 49 52 53 54 56 59 90
Date, settlement Merchants type POS entry mode Card sequence number POS condition code POS PIN capture code Amount, transaction fee Acquiring institution ID code Forwarding institution ID code Track 2 data Retrieval reference number Response code Service restriction code Card acceptor terminal ID Card acceptor ID code Card acceptor name location Additional response data Track 1 data Currency code, transaction PIN data Security related control information Additional amounts Message reason code Echo data Original data elements
Always sent Conditional Always sent Conditional Always sent Conditional Conditional Conditional Conditional Conditional Always sent Always sent Conditional Always sent Always sent Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional Always sent Conditional Present if supplied in the message from the source or constructed by Transaction Manager from the contents of the original message, if it could be retrieved. Included if present in the initial message from the Source Node. Included if present in the response message from the Source Node or if From authorizer (or from stand-in authorization). Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if a PIN was entered at the Point of Service. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node or if configured in the node configuration for the Sink Node. Included if present in the initial message from the Source Node or if configured in the node configuration for the Sink Node. Present if Track 2 was entered at the Point of Service. Included if present in the initial message from the Source Node or if it could be retrieved from Track 2 data. Included if present in the initial message from the Source Node.
100 102
Receiving institution ID code Account identification 1
Message Content
151
Field
Description
Condition
Notes Transaction Manager provides issuer services and the transaction is a debit, inquiry, payment or transfer.
123 127.1 127.3 127.4 127.6 127.9
POS data code Bitmap Routing information POS data Authorization profile Additional node data
Always sent Always sent Always sent Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Conditional Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if an original transaction could be found. This field is set up if card verification is performed. If card verification is not performed then this field is included if it was present in the received message. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Included if present in the initial message from the Source Node. Present if MACing is enabled for the current message type.
127.10 CVV2 127.12 Terminal owner 127.13 POS geographic data 127.14 Sponsor bank 127.15 Address verification data 127.16 Address verification result 127.18 Validation data 127.22 Structured data 127.25 ICC data 127.26 Original node 127.27 Card verification result
127.28 American express card identifier (CID) 127.33 Extended transaction type 127.34 Account type qualifier 127.35 Acquirer network ID 128 MAX extended
4.2.36
Send Format Error (0xx0)
The message type of the format error message will always be a response to the original message. E.g. if the original message was an Authorization Request (0100) the format error message will be an Authorization Request Response (0110). If the original message was an Administrative Advice (0620) then the format error message will be an Administrative Advice Response (0630).
Field 7 11 12 13 39 59 128 Description Transmission date and time System trace audit number Time, local transaction Date, local transaction Response code Echo data MAX extended Condition Always sent Always sent Always sent Always sent Always sent Conditional Conditional Will always be equal to 30 (Format Error) Echoed from original request/reversal/advice. Present if MACing is enabled for the current message type. Notes
Fields
152
5.
5.1
Symbol a n p s an as ns anp ans YY CCYY MM DD hh mm ss LL LLL LLLLL LLLLLL VAR 3 ..17 x b z
Fields
Format
Description Alphabetic characters, A through Z and a through z Numeric digits, 0 through 9 Pad character, space Special characters, i.e. other printable Alphabetic and numeric characters Alphabetic and special characters Numeric and special characters Alphabetic, numeric and pad characters Alphabetic, numeric and special characters Year, 00 through 99 Year, 0001 through 9999 Month, 01 through 12 Day, 01 through 31 Hour, 00 through 23 Minute, 00 through 59 Second, 00 through 59 Length of variable data element that follows, 01 through 99 Length of variable data element that follows, 001 through 999 Length of variable data element that follows, 00001 through 99999 Length of variable data element that follows, 000001 through 999999 Variable length data element Fixed length of 3 characters Variable length up to 17 characters, containing an additional 2 or 3 characters at the start of the data indicating the number of characters following to the end of the field C for credit, D for debit, always associated with a numeric amount field, i.e. x+n16 means a prefix of C or D followed by 16 numeric characters. Binary representation of data Track 2 as defined in ISO 7813
Fields
153
5.2
5.2.1
5.2.1.1 5.2.1.2
Definitions
Field 2 Primary Account Number
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.
5.2.2
5.2.2.1 5.2.2.2
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.
5.2.2.2.1
Transaction Type
This data element is present in positions 1-2.
Debits (00-19) 00 01 02 03 04 05 06 07 08 09 10 11 12 19 Goods and services Cash withdrawal Adjustment Check cash / guarantee Check verification Eurocheque Travellers check Letter of credit Giro (postal banking) Goods and services with cash back Non-cash financial instrument (e.g. wire transfer) Quasi-cash and scrip General debit (see field 127.33 Extended Transaction Type) Visa Cash load settlement reversal
Credits (20-29) 20 21 22 23 24 25 28 29 Returns (refund) Deposit Adjustment Check deposit guarantee Check deposit General credit (see field 127.33 Extended Transaction Type) Merchandise request Visa cash load settlement
Fields
154
Inquiry Services (30-39) 30 31 32 35 36 37 38 39 Available balance inquiry Balance inquiry General inquiry (see field 127.33 Extended Transaction Type) Full-statement inquiry Merchandise inquiry (e.g. wire transfer inquiry) Card verification inquiry Mini-statement inquiry Linked account inquiry
Transfer Services (40-49) 40 42 Cardholder accounts transfer General transfer (see field 127.33 Extended Transaction Type)
Payment Services (50-59) 50 51 52 53 54 Payment from account Payment by deposit General payment (see field 127.33 Extended Transaction Type) Payment to account Payment from account to account
Administration transactions (90-99) 90 91 92 93 Place hold on card General admin (see field 127.33 Extended Transaction Type) Change PIN Dead-end general admin (see field 127.33 Extended Transaction Type)
5.2.2.2.2
Account Type
The account type affected for debits and inquiries and the "from" account for transfers, is found in positions 3-4. The account type affected for credits and the "to" account for transfers, is found in positions 5-6.
Account Type 00 10 20 30 40 50 60 91 92 Default unspecified Savings account Check account Credit account Universal account Investment account Electronic purse account (default) Mortgage loan Instalment loan
Fields
155
5.2.3
5.2.3.1 5.2.3.2
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).
5.2.4
5.2.4.1 5.2.4.2
Field 5 Amount Settlement

Format
n12
Description
The funds to be transferred between the acquirer and card issuer equal to the amount, transaction as expressed in the settlement currency.
5.2.5
5.2.5.1 5.2.5.2
Field 7 Transmission Date and Time

Format
n10, MMDDhhmmss
Description
The date and time, expressed in Coordinated Universal Time (UTC), when this message is sent by the message initiator.
5.2.6
5.2.6.1 5.2.6.2
Field 9 Conversion rate, Settlement

Format
n8
Description
The factor used in the conversion from amount, transaction to amount, settlement. The amount, transaction is multiplied by this field to yield the amount, settlement. The leftmost digit denotes the number of positions the decimal separator shall be moved from the right. Positions 2 to 8 of the field represent the actual rate. For example, a conversion rate value of 91234567 would equate to 0,001234567.
5.2.7
5.2.7.1 5.2.7.2
Field 11 - Systems Trace Audit Number

Format
n6
Description
A number assigned by a transaction originator to assist in identifying a transaction uniquely. The systems trace audit number remains unchanged for all messages within a transaction.
Fields
156
5.2.8
5.2.8.1 5.2.8.2
Field 12 - Time, Local Transaction

Format
n6, hhmmss
Description
The local time at which the transaction takes place at the card acceptor location in authorization and financial messages. For all other transactions, this field indicates the local time set by the initiator of the first message of the transaction.
5.2.9
5.2.9.1 5.2.9.2
Field 13 - Date, Local Transaction

Format
n4, MMDD
Description
The local date at which the transaction takes place at the card acceptor location in authorization and financial messages. For all other transactions, this field indicates the local date set by the initiator of the first message of the transaction.
5.2.10
5.2.10.1 5.2.10.2
Field 14 - Date, Expiration

Format
n4, YYMM
Description
The year and month after which the card expires.
5.2.11
5.2.11.1 5.2.11.2
Field 15 - Date, Settlement

Format
n4, MMDD
Description
The month and day for which financial totals are reconciled between the acquirer and the issuer.
5.2.12
5.2.12.1 5.2.12.2
Field 16 - Date, Conversion

Format
n4, MMDD
Description
The month and day on which the currency for the transaction was converted.
Fields
157
5.2.13
5.2.13.1 5.2.13.2
Field 18 - Merchant Type

Format
n4
Description
The classification of the merchants type of business product or service. Codes to be developed within each country.
5.2.14
5.2.14.1 5.2.14.2
Field 22 - POS Entry Mode

Format
n3
Description
A series of codes that identify the actual method used to capture the account number and expiry 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.
PAN entry mode (positions 1 - 2) 00 01 02 03 04 05 07 90 91 95 99 Unknown Manual (i.e. via key pad) Magnetic stripe (possibly constructed manually). CVV may not be checked. Bar code OCR Integrated circuit card (ICC). CVV can be checked. Auto entry via contactless integrated circuit card (ICC) Magnetic stripe as read from track 2. CVV can be checked. Auto entry via contactless magnetic stripe Integrated circuit card (ICC). CVV may not be checked. Same as original transaction (Note: Only valid for a transaction linked to a previous transaction, where it is not financially related to the previous transaction.)
Note that the MasterCard PAN Entry Mode of 80 (Fallback) is not supported. Typically this will be mapped to 90.
PIN entry capability (position 3) 0 1 2 Unknown Terminal can accept PINs Terminal can not accept PINs
5.2.15
5.2.15.1 5.2.15.2
Field 23 Card Sequence Number

Format
n3
Description
A number distinguishing between separate cards with the same primary account number or primary account number extended.
Fields
158
5.2.16
5.2.16.1 5.2.16.2
Field 25 - POS Condition Code

Format
n2
Description
A code that describes the condition under which the transaction takes place at the Point-Of-Service.
POS condition code 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 41 Normal presentment Customer not present Unattended terminal - card can be retained Merchant suspicious Electronic Cash Register interface Customer present, card not present Pre-authorized request Telephone device required Mail/telephone order POS security alert Customer identity verified Suspected fraud Security reasons Representation of item Public utility terminal Customer's terminal Administrative terminal Returned item No check in envelope - return Deposit out of balance - return Payment out of balance - return Manual reversal Terminal error - counted Terminal error - not counted Deposit out of balance - apply Payment out of balance - apply Withdrawal error reversed Unattended terminal - card can not be retained Partial approval allowed
Additional codes can be defined for private use.
Fields
159
5.2.17
5.2.17.1 5.2.17.2
Field 26 - POS PIN Capture Code

Format
n2
Description
The maximum number of PIN characters that can be accepted by the Point-of-Service device. Valid values are "04" to "12" ("00" to "03" are reserved by ISO) and if the POS device does not accept PINs or it is unknown whether the device does, this value should be set to "12".
5.2.18
5.2.18.1 5.2.18.2
Field 27 - Authorization ID Response Length

Format
n1
Description
The maximum length of the authorization ID response which the acquirer can accommodate. The card issuer or agent shall limit the authorization ID response to this length.
5.2.19
5.2.19.1 5.2.19.2
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.
5.2.20
5.2.20.1 5.2.20.2
Field 29 - Amount, Settlement Fee

Format
x + n8
Description
A fee charged, by the acquirer to the issuer, for transaction activity, in the currency of the amount, settlement.
5.2.21
5.2.21.1 5.2.21.2
Field 30 - Amount, Transaction 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.
Fields
160
5.2.22
5.2.22.1 5.2.22.2
Field 31 - Amount, Settle Processing Fee

Format
x + n8
Description
A fee charged by the network for the handling and routing of messages, in the currency of amount, settlement. This field is usually inserted by the network into the applicable messages.
5.2.23
5.2.23.1 5.2.23.2
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 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.
5.2.23.3
Usage
If an acquiring institution identification code is defined for the Sink Node associated with the transaction, the Transaction Manager uses this value as the acquiring institution identification code for the transaction. If not, the Transaction Manager uses the value in the message that originated the transaction as the acquiring institution identification code for the transaction. The Transaction Manager 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.
5.2.24
5.2.24.1 5.2.24.2
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.
Fields
161
5.2.25
5.2.25.1 5.2.25.2
Field 35 - Track 2 Data

Format
z..37, LLVAR
Description
The information encoded on Track 2 of the magnetic stripe as defined in ISO 7813, 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 Primary account number Field separator Expiry date (YYMM) Service restriction code Discretionary data Length Up to 19 digits 1 digit 4 digits (or a field separator if not present) 3 digits (or a field separator if not present) 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 59 type cards, where the primary account number commences with the major industry identifier "5" followed by the digit "9", the layout of the field becomes:
Field Primary account number Field separator Country code Expiry date (YYMM) Service restriction code Discretionary data Length Up to 19 digits 1 digit 3 digits (as specified in ISO 3166). 4 digits (or a field separator if not present) 3 digits (or a field separator if not present) Balance of available digits
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 Visa Cash card number Field separator Expiry date (YYMM) Service restriction code Visa Cash balance Transaction number GMT offset Length 16 digits 1 digit (can be a "=" or a "D" character) 4 digits: Only the YYMM portion of the Visa Cash expiration date 3 digits (must be "101") 6 digits 5 digits 2 digits
5.2.26
5.2.26.1 5.2.26.2
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.
Fields
162
5.2.27
5.2.27.1 5.2.27.2
Field 38 - Authorization ID Response

Format
anp6
Description
A code assigned by the authorizing institution indicating approval.
5.2.28
5.2.28.1 5.2.28.2
Field 39 - Response Code

Format
an2
Description
A code that defines the disposition of a transaction.
Response code 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Approved or completed successfully Refer to card issuer Refer to card issuer, special condition Invalid merchant Pick-up card Do not honor Error Pick-up card, special condition Honor with identification Request in progress Approved, partial Approved, VIP Invalid transaction Invalid amount Invalid card number No such issuer Approved, update track 3 Customer cancellation Customer dispute Re-enter transaction Invalid response No action taken Suspected malfunction Unacceptable transaction fee File update not supported Unable to locate record Duplicate record File update field edit error File update file locked File update failed Format error
Fields
163
31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 to 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 to 74 75 76 77 78 79 to 89 90 91 92 93
Bank not supported Completed partially Expired card, pick-up Suspected fraud, pick-up Contact acquirer, pick-up Restricted card, pick-up Call acquirer security, pick-up PIN tries exceeded, pick-up No credit account Function not supported Lost card, pick-up No universal account Stolen card, pick-up No investment account Account closed Identification required Identification cross-check required Reserved for future Postilion use Not sufficient funds No check account No savings account Expired card Incorrect PIN No card record Transaction not permitted to cardholder Transaction not permitted on terminal Suspected fraud Contact acquirer Exceeds withdrawal limit Restricted card Security violation Original amount incorrect Exceeds withdrawal frequency Call acquirer security Hard capture Response received too late Advice received too late Reserved for future Postilion use PIN tries exceeded Reserved for future Postilion use Intervene, bank approval required Intervene, bank approval required for partial amount Reserved for client-specific use (declined) Cut-off in progress Issuer or switch inoperative Routing error Violation of law
Fields
164
94 95 96 97 98 99 Zero A to A Zero A1 A2 A3 A4 A5 A6 A7 A8 to BZ C Zero C1 C2 C3 to D Zero D1 D2 to E Zero E1 E2 to MZ N Zero to ZZ
Duplicate transaction Reconcile error System malfunction Reserved for future Postilion use Exceeds cash limit Reserved for future Postilion use Reserved for future Postilion use ATC not incremented ATC limit exceeded ATC configuration error CVR check failure CVR configuration error TVR check failure TVR configuration error Reserved for future Postilion use Unacceptable PIN PIN Change failed PIN Unblock failed Reserved for future Postilion use MAC Error Reserved for future Postilion use Prepay error Reserved for future Postilion use Reserved for client-specific use (declined)
5.2.29
5.2.29.1 5.2.29.2
Field 40 - Service Restriction Code

Format
n3
Description
An identification of geographic/service availability. Contains: The area of usage and whether the card has additional read facilities The authorization processing requirements for this card The range of services available and PIN requirements
Area of usage 1 2 5 6 9 International card International card - integrated circuit facilities National use only National use only - integrated circuit facilities Test card - online authorization mandatory
Fields
165
Authorization requirements 1 2 4 Normal authorization Online authorization mandatory Online authorization mandatory
Services available and PIN requirements 0 1 2 3 5 6 7 PIN required No restrictions - normal cardholder verification Goods and services only PIN required, ATM only PIN required, goods and services only at POS, cash at ATM PIN required if PIN pad present PIN required if PIN pad present, goods and services only at POS, cash at ATM
5.2.30
5.2.30.1 5.2.30.2
Field 41 - Card Acceptor Terminal ID

Format
ans8
Description
A unique code identifying a terminal at the card acceptor location.
5.2.31
5.2.31.1 5.2.31.2
Field 42 - Card Acceptor ID Code

Format
ans15
Description
A code identifying the card acceptor (typically a merchant).
5.2.32
5.2.32.1 5.2.32.2
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: The location information (positions 1 - 23), exclusive of city, state and country 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
For Visa Cash load transactions, this field contains the Visa Cash Service Identifier ("SV:") followed by the load request signature (S1), the load acquirer BIN and other location information. This is a fixed length field consisting of 5 data elements:
Fields The Visa cash service identifier (positions 1 - 3), a constant value of "SV:" The Visa load request signature (positions 4 - 19) The Visa load acquirer BIN (positions 20 - 25) The city (positions 26 - 38) in which the Point-of-Service is located The country (positions 39 - 40) in which the Point-of-Service is located.
166
5.2.33
5.2.33.1 5.2.33.2
Field 44 - Additional Response Data

Format
ans..25, LLVAR
Description
Used to provide other supplemental data (such as a telephone number for referrals) that may be required in response to an authorization or other type of transaction request. After a PIN Change request has been processed, this field contains the PIN offset (or PVV) in a 0610 message to the Source Node, as well as in a 0620 message to the Sink Node. If set in a 0610 message from the Sink Node, this field again indicates the PIN offset (or PVV). For Visa Cash load transactions, this field is used to carry signature information. In load responses, it contains the Visa Cash Service Identifier ("SV:") followed by the load response signature (S2). This is a fixed length field consisting of 2 data elements: The Visa cash service identifier (positions 1 - 3), a constant value of "SV:" The load authorization signature (positions 4 - 19) for this load operation
In load settlement advices, it contains the Visa Cash Service Identifier ("SV:") followed by the load completion signature (S3). This is a fixed length field consisting of 2 data elements: The Visa cash service identifier (positions 1 - 3), a constant value of "SV:" The load completion signature (positions 4 - 19) for this load operation
Fields
167
5.2.34
5.2.34.1 5.2.34.2
Field 45 - Track 1 Data

Format
ans..76, LLVAR
Description
The information encoded on Track 1 of the magnetic stripe as defined in ISO 7813, including field separators but excluding the begin sentinel, end sentinel and longitudinal redundancy check characters. Note that two structures are defined by ISO 7813, namely Structure A and Structure B. Structure A is reserved for proprietary use by card issuers, while Structure B is defined as follows:
Field Format code Primary account number Field separator Country code Name Field separator Expiry date (YYMM) Service restriction code Discretionary data Length B (ASCII 66) Up to 19 digits 1 characters (ASCII 61 or 94) 3 digits (or a field separator if not present) 2 to 26 characters (this field is further described below) 1 characters (ASCII 61 or 94) 4 digits (or a field separator if not present) 3 digits (or a field separator if not present) 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. The structure of the Name field is defined in the following table. Sub-fields are separated by means of a space character (ASCII 32). The minimum encoded data allowed is a single character followed by the surname separator.
Field Surname Surname separator First Name or Initial Space Middle Name or Initial Period Title When followed by Title; ASCII 46 When used When required ASCII 47 Length
The space character (ASCII 32) is required to separate the sub-fields of the Name field other than the surname. The separator terminating the surname should be encoded following the last sub-field of the Name field. If only the surname is encoded, it will follow the surname separator. Note: Transaction Manager currently performs no validation on track 1 data and in no way attempts to unpack the sub-fields. The contents of this field are simply saved in the transaction record and passed upstream unchanged.
Fields
168
5.2.35
5.2.35.1 5.2.35.2
Field 48 - Additional Data

Format
ans..999, LLLVAR
Description
Used to provide linked account or mini-statement information for a linked account inquiry or a ministatement inquiry.
5.2.35.3
Mini-statement Information
Postilion terminal driving applications, excluding those driving terminals which do not support ministatements, allow formatting of slips using a slip processing scripting language. This allows the owners of the system to determine slip formats according to their own requirements, and based on the constraints of the terminal printer (e.g. paper width). The format for field 48 when mini-statement data is to be sent downstream, is as follows: A mini-statement heading line, containing tags to identify the format of the mini-statement data lines that follows, e.g. DATE_TIME|SEQ_NR|TRAN_TYPE|TRAN_AMOUNT~ The different fields of the mini-statement heading line are separated by bar characters ("|") and the line is terminated by a tilde character ("~"). One or more mini-statement data lines, each similar to the identifying string above in structure, but containing the actual transaction data to be printed per line, e.g. 19971201123123|001234|01|000000005000~ Below is a list of tags that Postilion supports.
Field Sequence Number Date and time Terminal ID Transaction type From account To account Transaction amount Account ID 1 Account ID 2 Authorization ID Currency code Surcharge Tag Name SEQ_NR DATE_TIME TERM_ID TRAN_TYPE FROM_ACC TO_ACC TRAN_AMOUNT ACC_ID1 ACC_ID2 AUTH_ID CURR_CODE SURCHARGE Format N6 n14, CCYYMMDDhhmmss n8 n2 (Postilion transaction type, to cater for multilingualism) n2 (Postilion account type, to cater for multilingualism) n2 (Postilion account type, to cater for multilingualism) n12 ans28 ans28 ans6 n3 (Currency code of the Transaction Amount field) n8
Fields
169
5.2.35.4
Linked Account Inquiry

In the case of a linked account inquiry, this field contains information relating to the accounts linked to the card that initiated the transaction. The information for up to 20 accounts can be returned. Note that when "00" is specified as an account type in the original request, a list of all accounts linked to the card is retrieved, and not only the linked accounts of the default account type. The format of the information associated with each account is as follows:
Field Account ID Account type Currency code Ledger balance Length 28 2 3 13 Description The identifier uniquely identifying the account, left justified, space-filled. The ISO 8583 account type of the account. The ISO numeric currency code of the account. The ledger balance of the account. The first character contains the sign. A "D" indicates a debit (negative) balance and a "C" indicates a credit (positive) balance.
5.2.36
5.2.36.1 5.2.36.2
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: amount, transaction (field 4) amount, transaction fee (field 28) amount, transaction processing fee (field 30)
5.2.37
5.2.37.1 5.2.37.2
Field 50 - Currency Code, Settlement

Format
n3
Description
A code identifying the currency of settlement. If this field is not present for a transaction, it is assumed that this field is the same as the currency code, transaction field. This is the currency code used for the following amount fields: amount, settlement (field 5) amount, settlement fee (field 29) amount, settlement processing fee (field 31) amount, net settlement (field 97)
5.2.38
5.2.38.1 5.2.38.2
Field 52 - PIN Data

Format
b8 (Hex 16)
Description
The PIN data field contains the PIN (a number assigned to a cardholder intended to uniquely identify that cardholder) of the cardholder formatted into a 64-bit block and encrypted with a DES key.
Fields
170
5.2.39
5.2.39.1 5.2.39.2
Field 53 - Security Related Control Information

Format
b48 (Hex 96)
Description
Identifies security management information used in the current transaction or specifies security management information to be used in future transactions. If the DUKPT scheme is used, the first 8 bytes of this field in authorization and financial transaction request messages containing an encrypted PIN block, contain the DUKPT key sequence number. In PIN change transactions, the first byte indicates the PIN to change: binary 0 - insecure PIN (e.g. telephone PIN) binary 1 - secure PIN (e.g. ATM PIN)
The following 8 bytes of this field contains the new PIN formatted into a 64-bit block and encrypted with a DES key. It may be followed by the 8-byte DUKPT key sequence number if the DUKPT scheme is used. In key change transactions, this field contains the encrypted key in the first 8-24 bytes (8 for single, 16 for double, 24 for triple length), followed by a 3-byte or less key check value (i.e. the first 3 bytes of a clear value of all zeroes encrypted with the key).
5.2.40
5.2.40.1 5.2.40.2
Field 54 - Additional Amounts

Format
an..120, LLLVAR
Description
Information on up to 6 amounts and related account data for which specific data elements have not been defined. Each amount is a fixed length field consisting of 5 data elements:
00 10 20 30 40 50 60 91 92
Account type (positions 1 - 2) Amount type (positions 3 - 4) Currency code (positions 5 - 7) Amount sign (position 8) - "C" or "D" Amount (position 9 - 20)
Default unspecified Savings account Check account Credit account Universal account Investment account Electronic purse account (default) Mortgage loan Instalment loan
Account Type
Fields
171
Amount Type 01 02 20 40 53 90 91 Ledger balance Available balance Remaining this cycle Cash Approved Available credit Credit limit
When this field is sent by the entity that performed currency conversion this field should contain amounts in the transaction and settlement currencies if they differ. In a response message from the Transaction Manager, this field will always contain the approved amounts and cash amounts, if applicable. When configuring a Postilion Sink Node which is providing service to an Issuer, Postilion can provide Stand-in or Full Authorization service. These types of stand-in processing are also known as Positive Balances Authorization. When one of these types of stand-in has been performed successfully for a Debit, Credit, Inquiry or Payment transaction, excluding linked accounts inquiry and payment by deposit transactions, the Additional Amounts field will also contain the ledger balance followed by the available balance of the specific account. The account ID of the specific account is returned in field 102, Account Identification 1. When one of these types of stand-in has been performed successfully for a Transfer transaction, the Additional Amounts field will contain the ledger balance followed by the available balance of the 'from account' as located in the Positive Balances environment. These amounts are followed by the ledger balance and the available balance of the 'to account' as located in the Positive Balances environment. The account ID of the specific 'from account' is returned in field 102, Account Identification 1, and the account ID of the specific 'to account' is returned in field 103, Account Identification 2. If a Goods and Services with cash back transaction or a Cash transaction has been partially approved, field 54 of the 0110 / 0210 response message must contain the reduced cash portion, with Amount type '40' (Cash). Field 4 must contain the approved amount. The approved amount sent in field 54 to a PostBridge sink node will not be used for anything. It is informational only.
5.2.41
5.2.41.1 5.2.41.2
Field 56 - Message Reason Code

Format
n4, LLLVAR
Description
A code that provides the receiver of a request, advice or notification message with the reason, or purpose of that message. For original authorizations 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.
Fields
172
Message reason code 1000 1003 1006 1376 1377 1378 1510 1800 4000 4001 4004 4013 4017 4020 4021 4351 4352 Stand-in processing at the card issuer's option Card issuer unavailable Under floor limit PIN related failure Change dispensed IOU receipt printed Over floor limit Negative card Customer cancellation Unspecified, no action taken Completed partially Unable to deliver message to point-of-service Suspected malfunction / No cash dispensed Invalid response, no action taken. Timeout waiting for response Invalid CVV2 Invalid address
For place hold on card transactions, in Issuer File Update Advice (0322) or Administration (0600/0620) messages, it states why a card should be put on the hotcard list:
Message reason code 3000 3001 3002 3003 3700 Lost card Stolen card Undelivered card Counterfeit card Lost PIN
If a hold response code has not been specified in these transactions, the message reason code field will be used to determine which hold response code to use for the transaction. A message reason code of "3001-Stolen card" will result in a hold response code of "43-Stolen card", otherwise "41-Lost card" will be used. In the case of a message to bank transaction, 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. Message reason codes are defined in the ISO 8583 (1993) specification, and this specification has been used as basis for the codes defined here. The use of the following message reason codes have been deprecated:
Message reason code 1801 1802 Card lost Card stolen
Fields
173
5.2.42
5.2.42.1 5.2.42.2
Field 57 - Authorization Life-cycle Code

Format
n3, LLLVAR
Description
A value in calendar days, hours or minutes which defines the time period for which the acquirer is requesting guarantee of funds, or that the card issuer shall guarantee funds for a financial transaction which may follow. It consists of 2 fields: Time code (position 1)
Time code 0 1 2 3 4-5 6-7 8-9 Reserved for ISO use Calendar days Hours Minutes Reserved for ISO use Reserved for national use Reserved for private use
Time interval (positions 2 - 3): A value of 01 through 99 indicating the number of reiterations indicated in position 1.
5.2.43
5.2.43.1 5.2.43.2
Field 58 - Authorizing Agent Id Code

Format
n..11, LLLVAR
Description
A code identifying the authorizing agent institution.
5.2.44
5.2.44.1 5.2.44.2
Field 59 - Echo Data

Format
ans..255, LLLVAR
Description
This is a Postilion specific addition to the ISO 8583 standard. Contains data from the originator of the message that shall be returned unaltered in the response message.
5.2.45
5.2.45.1 5.2.45.2
Field 66 - Settlement Code

Format
n1
Description
A code indicating the result of a reconciliation.
Fields
174
Settlement code 0 1 2 3 Unknown In balance Out of balance Error
The result is 0 (Unknown) if the Amount, Net Settlement field (field 97) is not present in the reconciliation advice. The result is 1 (In balance) if all optional fields provided are in balance. If one or more of the optional fields in the reconciliation advice is out of balance with the local batch totals, the result is 2 (Out of balance).
5.2.46
5.2.46.1 5.2.46.2
Field 67 - Extended Payment Code

Format
n2
Description
The number of months that the cardholder prefers to pay for this item if permitted by the card issuer.
5.2.47
5.2.47.1 5.2.47.2
Field 70 - Network Management Information Code

Format
n3
Description
The code that defines the type of network management needed.
Settlement code 001 002 101 160 301 999 Sign On request Sign Off request Pin Working Key Change MAC Working Key Change Echo test Text
5.2.48
5.2.48.1 5.2.48.2
Field 73 - Date, Action

Format
n6, YYMMDD
Description
A date specifying when a future action should occur.
Fields
175
5.2.49
5.2.49.1 5.2.49.2
Field 74 - Credits, Number

Format
n10
Description
The total number of credit transactions, other than reversals, processed since the last settlement cutover (i.e. the sum number of all financial transactions where positions 1 - 2 of the processing code in the financial transaction indicated a credit (20-29)).
5.2.50
5.2.50.1 5.2.50.2
Field 75 - Credits, Reversal Number

Format
n10
Description
The total number of reversal credit transactions, having a credit effect on the cardholders account, processed since the last settlement cutover (i.e. the sum number of all reversal transactions where positions 1 - 2 of the processing code in the reversal transaction indicated a debit (00-19) and where the original message type identifier indicated a financial transaction (02xx)).
5.2.51
5.2.51.1 5.2.51.2
Field 76 - Debits, Number

Format
n10
Description
The total number of debit transactions with financial impact processed since the last settlement cutover, excluding reversals. A transaction with financial impact is one for which the final amount in the batch totals is non-zero. Therefore, this field is the total number of financial transactions where positions 1 - 2 of the processing code in the financial transaction indicated a debit (00-19).
5.2.52
5.2.52.1 5.2.52.2
Field 77 - Debits, Reversal Number

Format
n10
Description
The total number of reversal debit transactions, having a debit effect on the cardholders account, processed since the last settlement cutover (i.e. the sum number of all reversal transactions where positions 1 - 2 of the processing code in the reversal transaction indicated a credit (20-29) and where the original message type identifier indicated a financial transaction (02xx)).
Fields
176
5.2.53
5.2.53.1 5.2.53.2
Field 78 - Transfer, Number

Format
n10
Description
The total number of all transfer transactions, other than reversals, processed since the last settlement cutover (i.e. the sum number of all financial transactions where positions 1 - 2 of the processing code in the financial transaction indicated a transfer (40-49)).
5.2.54
5.2.54.1 5.2.54.2
Field 79 - Transfer, Reversal Number

Format
n10
Description
The total number of transfer transactions reversed since the last settlement cutover (i.e. the sum number of all reversal transactions where positions 1 - 2 of the processing code in the reversal transaction indicated a transfer (40-49) and where the original message type identifier indicates a financial transaction (02xx)).
5.2.55
5.2.55.1 5.2.55.2
Field 80 - Inquiries, Number

Format
n10
Description
The total number of inquiries processed since the last settlement cutover (i.e. the sum number of all authorization transactions where positions 1 - 2 of the processing code in the financial transaction indicated an inquiry (30-39)).
5.2.56
5.2.56.1 5.2.56.2
Field 81 - Authorizations, Number

Format
n10
Description
The total number of authorization transactions processed since the last settlement cutover.
5.2.57
5.2.57.1 5.2.57.2
Field 82 - Credits, Processing Fee Amount

Format
n12
Description
The total amount of all credit processing fees.
Fields
177
5.2.58
5.2.58.1 5.2.58.2
Field 83 - Credits, Transaction Fee Amount

Format
n12
Description
The total amount of all credit transaction fees.
5.2.59
5.2.59.1 5.2.59.2
Field 84 - Debits, Processing Fee Amount

Format
n12
Description
The total amount of all debit processing fees.
5.2.60
5.2.60.1 5.2.60.2
Field 85 - Debits, Transaction Fee Amount

Format
n12
Description
The total amount of all debit transaction fees.
5.2.61
5.2.61.1 5.2.61.2
Field 86 - Credits, Amount

Format
n16
Description
The total amount of all credit transactions, other than reversals, processed since the last settlement cutover (i.e. the sum amount of amount, settlement in all financial transactions, exclusive of any fees, where positions 1 - 2 of the processing code in the financial transaction indicated a credit (20-29)).
5.2.62
5.2.62.1 5.2.62.2
Field 87 - Credits, Reversal Amount

Format
n16
Description
The total amount of all reversal credit transactions, having a credit effect on the cardholders account, processed since the last settlement cutover (i.e. the sum amount of amount, settlement of all reversal transactions, exclusive of any fees, where positions 1 - 2 of the processing code in the financial transaction indicated a debit (00-19) and where the original message type identifier indicated a financial transaction (02xx)).
Fields
178
5.2.63
5.2.63.1 5.2.63.2
Field 88 - Debits, Amount

Format
n16
Description
The total amount for all debit transactions with financial impact processed since the last settlement cutover, excluding reversals. A transaction with financial impact is one for which the final amount in the batch totals is non-zero. Therefore, this field is the sum of amount, settlement in all financial transactions where positions 1 - 2 of the processing code in the financial transaction indicated a debit (00-19).
5.2.64
5.2.64.1 5.2.64.2
Field 89 - Debits, Reversal Amount

Format
n16
Description
The total amount of all reversal debit transactions, having a debit effect on the cardholders account, processed since the last settlement cutover (i.e. the sum amount of amount, settlement of all reversal transactions, exclusive of any fees, where positions 1 - 2 of the processing code in the financial transaction indicated a credit (20-29) and where the original message type identifier indicated a financial transaction (02xx)).
5.2.65
5.2.65.1 5.2.65.2
Field 90 - Original Data Elements

Format
n42
Description
The data elements contained in the original message intended for transaction matching (e.g. to identify a transaction for correction or reversal). It is a fixed length field consisting of 5 data elements: Original message type (positions 1 - 4) - the message type identifier of the original message of the transaction being reversed. Original systems trace audit number (positions 5 - 10) - the systems trace audit number (field 11) of the original message. Original transmission date and time (positions 11 - 20) - the transmission date and time (field 7) of the original message Original acquirer institution ID code (position 21 - 31) - the acquirer institution ID code (field 32) of the original message (right justified with leading zeroes). Original forwarding institution ID code (position 32 - 42) - the forwarding institution ID code (field 33) of the original message (right justified with leading zeroes).
Fields
179
5.2.66
5.2.66.1 5.2.66.2
Field 91 - File Update Code

Format
an1
Description
An indication to the system maintaining the file about which procedure to follow.
File update code 0 1 2 3 4 5 6 7 8 9 Unassigned Add record Change record Delete record Bulk replacement Inquiry Delete record, system purge Add file Delete file Unassigned
5.2.67
5.2.67.1 5.2.67.2
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: Actual amount, transaction (positions 1 - 12) - the corrected, actual amount of the customers transaction, in the currency of the transaction (field 49). Actual amount, settlement (positions 13 - 24) - the corrected, actual amount of the customers transaction, in the settlement currency (field 50). 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. 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.
5.2.68
5.2.68.1 5.2.68.2
Field 97 - Amount, Net Settlement

Format
x + n16
Description
The net of all gross debit and gross credit amounts for a settlement period for a specific settlement entity. Specified in the settlement currency (field 50).
Fields
180
5.2.69
5.2.69.1 5.2.69.2
Field 98 - Payee
Format
ans25
Description
A code or ID identifying the payee (recipient) of a payment transaction. This field is used in a payment transaction when the payee is an Institution defined payee. Customer defined payees do not have a payee ID. When using this field with the Postilion Payments Engine, however, it contains the ID of the payee as maintained in the payee list for a cardholder. Because the Payments Engine assigns an ID to both institution defined and customer defined payees, this field can be used to refer to either type of payee.
5.2.70
5.2.70.1 5.2.70.2
Field 100 - Receiving Institution ID Code

Format
n..11, LLVAR
Description
A code identifying the financial institution that should receive a request or advice. This identification code is used when it is not possible to route a message using the account number field in the message, e.g. in a check verification message. When this field is included in a request or advice, it takes precedence over all account number fields for routing.
5.2.71
5.2.71.1 5.2.71.2
Field 101 - File Name

Format
ans..17, LLVAR
Description
The actual or abbreviated name of the file being accessed. The following file names are used to update the database of the Payments Engine using 0300 messages: RTE_USER_PAYEES RTE_STD_PAYEES RTE_USER_XFER RTE_USER_PAYMENTS The following file name is used to update the Postilion issuer card records with respect to card status, card hold response code and PIN codes (typically this only applies to systems with a card management system installed): CARD_MANAGEMENT The following file names are used to update the hotcard file of Postilion using 0322 messages: HOTCARDS
Fields
181 The following file update codes (field 91) can be used to update the hotcard file of Postilion using 0322 messages:
File update code 1 2 3 Add record Change record Delete record
5.2.72
5.2.72.1 5.2.72.2
Field 102 - Account Identification 1

Format
ans..28, LLVAR
Description
A series of digits and/or characters used to identify a specific account held by the cardholder at the card issuer and if present, shall remain unchanged for the life of the transaction. This field usually contains the description of the "from" account.
5.2.73
5.2.73.1 5.2.73.2
Field 103 - Account Identification 2

Format
ans..28, LLVAR
Description
A series of digits and/or characters used to identify a specific account held by the cardholder at the card issuer and if present, shall remain unchanged for the life of the transaction. This field usually contains the description of the "to" account. When used in payment transactions, this field specifies the bank account number of the payee.
5.2.74
5.2.74.1 5.2.74.2
Field 118 - Payments, Number

Format
n10, LLLVAR
Description
The total number of payments processed since the last settlement cutover (i.e. the sum number of all authorization transactions where positions 1 - 2 of the processing code in the financial transaction indicated a payment (50-59)).
5.2.75
5.2.75.1 5.2.75.2
Field 119 - Payments, Reversal Number

Format
n10, LLLVAR
Description
The total number of payment transactions reversed since the last settlement cutover (i.e. the sum number of all reversal transactions where positions 1 - 2 of the processing code in the reversal transaction indicated a payment (50-59) and where the original message type identifier indicates a financial transaction (02xx)).
Fields
182
5.2.76
5.2.76.1 5.2.76.2
Field 123 - POS Data Code

Format
an15, LLLVAR
Description
A Postilion specific addition to the ISO 8583 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 subfields:
Card data input capability (position 1) 0 1 2 3 4 5 6 7 8 9 A B Unknown Manual, no terminal Magnetic stripe Bar code OCR Magnetic stripe, key entry and integrated circuit card (ICC) Key entry Magnetic stripe and key entry Magnetic stripe and integrated circuit card (ICC) Integrated circuit card (ICC) Contactless integrated circuit card (ICC) Contactless magnetic stripe
Cardholder authentication capability (position 2) 0 1 2 3 4 5 6 No electronic authentication PIN Electronic signature analysis Biometrics Biographic Electronic authentication inoperative Other
Card capture capability (position 3) 0 1 None Card Capture
Operating environment (position 4) 0 1 2 3 4 5 No terminal used On premises of card acceptor, attended On premises of card acceptor, unattended Off premises of card acceptor, attended Off premises of card acceptor, unattended On premises of cardholder, unattended
Fields
183
Cardholder is present (position 5) 0 1 2 3 4 5 Cardholder present Cardholder not present, unspecified Cardholder not present, mail order Cardholder not present, telephone Cardholder not present, standing authorization/recurring transaction Cardholder not present, electronic order
Card is present (position 6) 0 1 Card not present Card present
Card data input mode (position 7) 0 1 2 3 4 5 6 7 8 Unknown Manual, no terminal Magnetic stripe Bar code OCR Integrated circuit card (ICC) Key entered Contactless integrated circuit card (ICC) Contactless magnetic stripe
Cardholder authentication method (position 8) 0 1 2 3 4 5 6 No electronic authentication PIN Electronic signature analysis Biometrics Biographic Manual Other
Cardholder authentication entity (position 9) 0 1 2 3 4 5 Not authenticated Integrated circuit card (ICC) Terminal Authorizing agent Merchant Other
Fields
184
Card data output capability (position 10) 0 1 2 3 Unknown None Magnetic stripe write Integrated circuit card (ICC)
Terminal output capability (position 11) 0 1 2 3 4 Unknown None Printing Display Printing and display
PIN capture capability (position 12) 0 1 4 5 6 7 8 9 A B C No PIN capture capability Device PIN capture capability unknown Four characters Five characters Six characters Seven characters Eight characters Nine characters Ten characters Eleven characters Twelve characters
Terminal operator (position 13) 0 1 2 Customer operated Card acceptor operated Administrative
Fields
185
Terminal type (position 14-15) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 90 91 92 93 94 95 96 Administrative terminal POS terminal ATM Home terminal Electronic Cash Register (ECR) Dial terminal Travellers check machine Fuel machine Scrip machine Coupon machine Ticket machine Point-of-Banking terminal Teller Franchise teller Personal banking Public utility Vending Self-service Authorization Payment VRU Smart phone Interactive television Personal digital assistant Screen phone E-commerce - No encryption; no authentication E-commerce - SET encryption; cardholder certificate not used (non-authenticated) E-commerce - SET encryption; cardholder certificate used (authenticated) E-commerce - SET encryption, chip cryptogram used; cardholder certificate not used E-commerce - SET encryption, chip cryptogram used; cardholder certificate used E-commerce - Channel encryption (SSL); cardholder certificate not used (non-authenticated) E-commerce - Channel encryption (SSL); cardholder certificate not used (non-authenticated)
Fields
186
5.2.77
5.2.77.1 5.2.77.2
Field 125 - Network management information

Format
ans..40, LLLVAR
Description
In key change transactions, this field contains the encrypted key in the first 16-32 positions of this field (16 for Single Length, 32 for Double Length), followed by 6 or less positions for the key check value. The encrypted key and key check value are encoded as hexadecimal characters in this field. (When using this field for key exchange messages Triple Length keys cannot be used)
5.2.77.3
Usage
Postilion will load the encrypted key and verify the key check value.
5.2.78
5.2.78.1 5.2.78.2
Field 127.1 - Bitmap

Format
b8
Description
This is a Postilion specific addition to the ISO 8583 standard. The bitmap signifies the presence (1) or absence (0) of data sub-elements contained within field 127.
5.2.78.3
Usage
The Postilion private data bit map (bits 1-64) is always present when field 127 is present in the message. The Postilion private data bitmap is used to indicate the presence (1) or absence (0) of data sub-elements and is thus used to decode the Postilion private data (field 127).
Postilion private data sub-elements are indexed from these bit positions i.e. the fifth bit in the bitmap will index Service Station Data (field 127.5).
5.2.79
5.2.79.1 5.2.79.2
Field 127.2 - Switch Key

Format
ans..32, LLVAR
Description
This is a Postilion specific addition to the ISO 8583 standard. The switch key field uniquely identifies a transaction.
Fields
187
5.2.80
5.2.80.1 5.2.80.2
Field 127.3 - Routing Information

Format
ans48
Description
This is a Postilion specific addition to the ISO 8583 standard. The totals group, Source Node, Sink Node and systems trace audit numbers associated with a customer transaction. Although passed in a variable length field, this is a fixed length field of 48 characters consisting of 5 data elements: The source node (positions 1 - 12), left justified, space-filled. The sink node (positions 13 - 24), left justified, space-filled. The source node systems trace audit number (positions 25 - 30). The sink node systems trace audit number (positions 31 - 36). The totals group (positions 37 - 48), left justified, space-filled.
5.2.81
5.2.81.1 5.2.81.2
Field 127.4 - POS Data

Format
ans22
Description
This is a Postilion specific addition to the ISO 8583 standard. Contains data passed from the Point-ofService (POS) system, e.g. a cash register. Although passed in a variable length field, this is a fixed length field of 22 characters consisting of 3 data elements: The POS terminal ID (positions 1 - 8) identifying the POS terminal, e.g. a cash register, on which the transaction was performed. The POS sequence number (positions 9 - 14) specifying the POS terminal sequence number. The POS operator ID (positions 15 - 22) specifying the cashier that performed the transaction.
5.2.82
5.2.82.1 5.2.82.2
Field 127.5 - Service Station Data

Format
ans73
Description
This is a Postilion specific addition to the ISO 8583 standard. Contains data passed from a service station, i.e. forecourt system, for forwarding to the card issuer. This data is typically used for fleet management. This data element consists of 2 mandatory fields and up to 3 repetitions of a group of 3 fields. Note that this is a fixed format data element. All unused fields should contain spaces. The vehicle usage (position 1) indicates whether the product(s) was purchased for business or private use (0 - private, 1 - business). The odometer reading (positions 2 - 7) of the vehicle.
The following group of fields represents a fuel product and can be repeated up to 3 times (i.e. 3 different products are supported): The product ID (positions 1 - 2) specifying the fuel product purchased. The literage (positions 3 - 10) specifying the literage of the product purchased. The amount (positions 11 - 22) of the product purchased.
Fields
188
5.2.83
5.2.83.1 5.2.83.2
Field 127.6 - Authorization Profile

Format
n2
Description
This is a Postilion specific addition to the ISO 8583 standard. Provides additional information on the conditions under which authorization should be or was performed:
Authorization type (position 1) 0 1 2 3 4 5 9 A B Unknown The transaction was authorized by the card issuer. Online stand-in. The transaction amount was below the local limits. Timeout stand-in. The Sink Node did not respond to a request. Offline stand-in. The Sink Node was not available. The use of this authorization type has been deprecated. The transaction was authorized by Visa. Declined by the Sink Node, not sent to the remote entity. This is not forwarded to the Source Node. Declined by the Sink Node after an approved response was received from the remote entity. This is not forwarded to the Source Node.
Authorization limits (position 2) 0 1 2 3 4 5 Unknown Transaction authorized against cardholder record at card issuer. Transaction authorized using card issuer limits. Transaction authorized using card acceptor (merchant) limits. Transaction authorized using card issuer balances. Authorized using card issuer velocity limits.
If the Authorization Type field is set to 9 (Authorized by Visa), the values of Authorization Limits are defined in the following Visa manual: V.I.P. System Technical Reference Vol. 2, Field and Code Descriptions, Additional Response Data (Field 44), Response Source/Reason Code (Field 44.1).
Fields
189
5.2.84
5.2.84.1 5.2.84.2
Field 127.7 - Check Data

Format
ans..50, LLVAR
Description
This is a Postilion specific addition to the ISO 8583 standard. Contains check guarantee or check verification data. This field can be in a number of different formats. The first 2 digits indicate the format. This field may be extended to new formats in the future. Currently supported formats are:
Driver License Check Verification Data Length Description 2 6 2 6 24 Format 00 Check number State code (space-filled if not available) Date of birth - MMDDYY Drivers license number (left justified, space-filled)
Formatted MICR Check Verification Data Length Description 2 6 2 8 16 9 Format 01 Check number State code (space-filled if not available) Institution code MICR account number ZIP code
Plastic Card Account Check Verification Data Length Description 2 6 2 Format 02 Check number State code (space-filled if not available)
Unformatted MICR Check Verification Data Length Description 2 65 Format 03 MICR data
Note: The use of the CheckData DTD (for field 127.22) is preferred over the use of field 127.7.
The plastic card account number is carried in the primary account number or track 2 data fields.
Fields
190
5.2.85
5.2.85.1 5.2.85.2
Field 127.8 - Retention Data

Format
ans..999, LLLVAR
Description
This is a Postilion specific addition to the ISO 8583 standard. Transparent data passed from a Source or Sink Node to the Transaction Manager for retention in the transaction table.
5.2.86
5.2.86.1 5.2.86.2
Field 127.9 - Additional Node Data

Format
ans..255(999), LLLVAR
Description
This is a Postilion specific addition to the ISO 8583 standard. Transparent data passed from a Source Node to a Sink Node, or from a Sink Node to a Source Node.
5.2.87
5.2.87.1 5.2.87.2
Field 127.10 - CVV2

Format
n3
Description
This is a Postilion specific addition to the ISO 8583 standard. The embossed Visa CVV2 value that was manually entered when the magnetic stripe could not be read.
5.2.88
5.2.88.1 5.2.88.2
Field 127.11 - Original Key

Format
ans..32, LLVAR
Description
This is a Postilion specific addition to the ISO 8583 standard. The switch key of the original message, intended for transaction matching (e.g. to identify a transaction for correction or reversal).
5.2.89
5.2.89.1 5.2.89.2
Field 127.12 - Terminal Owner

Format
ans..25, LLVAR
Description
This is a Postilion specific addition to the ISO 8583 standard. Contains the name of the financial institution that owns the ATM, or the name of the merchant where the POS terminal is located.
Fields
191
5.2.90
5.2.90.1 5.2.90.2
Field 127.13 - POS Geographic Data

Format
ans17
Description
This is a Postilion specific addition to the ISO 8583 standard. Contains a series of codes to identify the state, county, postal service code and country code where the POS device is physically located. This data element is defined in ANSI X9.2 (1988). The layout is as follows: The numeric state code (positions 1 - 2). The numeric county code (positions 3 - 5). The alphanumeric postal service code (positions 6 - 14). The numeric country code (positions 15 - 17).
If any of the sub-fields are not used, it should be set to spaces.
5.2.91
5.2.91.1 5.2.91.2
Field 127.14 - Sponsor Bank

Format
ans8
Description
This is a Postilion specific addition to the ISO 8583 standard. Identifies the institution sponsoring the card acceptor POS terminal.
5.2.92
5.2.92.1 5.2.92.2
Field 127.15 - Address Verification Data

Format
ans..29, LLVAR
Description
This is a Postilion specific addition to the ISO 8583 standard. This field can contain cardholder address information for a mail order or airline transaction. The layout is as follows: The alphanumeric postal/ZIP code (positions 1 - 9). The alphanumeric cardholder address (positions 10 - 29).
Fields
192
5.2.93
5.2.93.1 5.2.93.2
Field 127.16 - Address Verification Result

Format
ans1
Description
This is a Postilion specific addition to the ISO 8583 standard. Contains the result of a transaction involving address verification.
Address verification result A E N R U Y Z Address matches, postal/ZIP code does not Error Neither address nor postal/ZIP code matches Retry Unavailable Address and postal/ZIP code matches postal/ZIP code matches, address does not
5.2.94
5.2.94.1 5.2.94.2
Field 127.17 - Cardholder Information

Format
ans..50, LLVAR
Description
This is a Postilion specific addition to the ISO 8583 standard. Contains cardholder related response information. This information is typically returned by the authorizer of the transaction.
5.2.95
5.2.95.1 5.2.95.2
Field 127.18 - Validation data

Format
ans..50, LLVAR
Description
This is a Postilion specific addition to the ISO 8583 standard. Contains cardholder related validation information. This information is typically supplied by the originator of the transaction as an additional security mechanism. This data can be used by the authorizer when authorizing a transaction. For example, this field could contain the identification number of the cardholder. If this value differs from the value carried in the cardholder database of the authorizer, the transaction may be declined.
Fields
193
5.2.96
5.2.96.1 5.2.96.2
Field 127.19 - Bank details

Format
ans31
Description
This is a Postilion specific addition to the ISO 8583 standard. Contains bank and branch details. This field is used to specify the bank details of the payee (recipient) of a payment transaction. Payments made to Customer defined payees require either bank details or address details to be specified in the transaction message.
Field Bank ID Length 9 Format ANS Description The financial institution where the bank account of the recipient is kept. Typically, the field will be space filled to the right when less than 9 characters are available. The interpretation of this field varies by country. The branch where the bank account is kept. Typically, the field will be space filled to the right when less than 22 characters are available. The interpretation of this field varies by country.
Branch ID
22
ANS
5.2.97
5.2.97.1 5.2.97.2
Field 127.20 - Originator / Authorizer date settlement

Format
n8, CCYYMMDD
Description
This is a Postilion specific addition to the ISO 8583 standard. This field contains the settlement date of the authorizer.
5.2.98
5.2.98.1 5.2.98.2
Field 127.21 - Record identification

Format
ans..12, LLVAR
Description
This is a Postilion specific addition to the ISO 8583 standard. Contains the record ID for any file update transaction.
Fields
194
5.2.99
5.2.99.1 5.2.99.2
Field 127.22 - Structured Data

Format
ans..99999, LLLLLVAR
Description
This is a Postilion specific addition to the ISO 8583 standard. As of Postilion 4.0 Service Pack 5, this field is stored in the Postilion Transaction Table. This field uses a key/value pair structure to represent data. The idea behind the field is to provide a flexible mechanism with which to transport data through Postilion. There is therefore no limitation to what either the key or value may contain, provided of course that the format of the field is adhered to. The physical layout of the field is as follows: 1 byte length indicator of the key length indicator Length indicator of the key Key 1 byte length indicator of the value length indicator Length indicator of the value Value
The above describes the physical layout of a single key/value pair. It is therefore repeated for each key/value pair in the field. There is no limitation to the number of key value pairs that may be used, besides the overall field length.
5.2.99.3
XML content
Postilion defines DTDs for the following: StatementData CardManagementUpdateData CardManagementUpdateLoad PrepaidMerchandise PurchasingCardData FleetCardData CheckData AirlineItineraryData VehicleRentalData LodgingData
For more details, please refer to XML schemas.
Fields
195
5.2.100
Field 127.23 - Payee name and address

ans253
5.2.100.1 Format 5.2.100.2 Description

This is a Postilion specific addition to the ISO 8583 standard. Contains identification and billing information for a payee. All fields are left-justified, space filled to the right. This field is used when making a payment to a Customer defined payee, where the payee is defined by its address details. A bank, for example, would use these details to post a check to the payee on the customers behalf.
Field Name Address line 1 Address line 2 Address line 3 City Region Postal code Country code Phone Length 35 35 35 35 35 20 20 3 35 Format ANS ANS ANS ANS ANS ANS ANS A ANS Description Name of the payee. First address line. Second address line. Third address line. City payee is located in. Region / State the City is located in. Postal code of the City. A 3 letter ISO country code. Phone number of payee.
5.2.101
Field 127.24 - Payer account

ans..28, LLVAR

This is a Postilion specific addition to the ISO 8583 standard. Defines the payer account ID at the payee.
Fields
196
5.2.102
Field 127.25 - Integrated circuit card (ICC) Data

ans..8000, LLLLVAR

This is a Postilion specific addition to the ISO 8583 standard. The field contains data for use with integrated circuit cards that implement the EMV specification. This field can contain ICC Data in two different formats but only one format can be used per message. PostBridge will automatically detect which format is used in messages to PostBridge. A user parameter will configure how ICC Data is formatted in messages from PostBridge. The two formats, ICC Data in XML and ICC Data in Bitmap Field, are described in the following sections.
5.2.102.3 ICC Data in XML

IccData (field 127.25) is formatted as an XML document, as per a DTD. This XML document has an outer tag (IccData), and 2 primary inner tags (IccRequest and IccResponse). The IccRequest tag is used in request messages, and the IccResponse tag is used in response messages. A request message would have the following structure for example
<?xml version="1.0"?> <IccData> <IccRequest> ... ... </IccRequest> </IccData>
A response message would have the following structure for example:

<?xml version="1.0"?> <IccData> <IccResponse> ... ... </IccResponse> </IccData>
For more details, please refer to XML schemas.
5.2.102.4 ICC Data in Bitmap Field

ICC Data is formatted as a Bitmap field. Each of the ICC Data elements is defined as a sub-field within the Bitmap field. The bitmap signifies the presence (1) or absence (0) of data sub-elements contained within field 127.25 (ICC Data). The bitmap is a binary field, but is formatted as a hexadecimal. This means the 8 binary characters representing the bitmap must be converted to hexadecimal before being placed in this field.
ICC Data sub-elements are indexed from these bit positions. For example, the fifth bit in the bitmap will index Application Interchange Profile (field 127.25.5).
Fields
197 To illustrate assume that fields 3, 5, 7 and 11 are present. This would give the following bitmap: (The "|" character is not part of the bitmap and is only used for clarity, to indicate the bytes of the bitmap)
"00101010|00100000|00000000|00000000|00000000|00000000|00000000|00000000"
Which would translate to the following binary bitmap: (Assume that "*" represents the NULL character)
".2******"
Before this value can be placed into Field 127.25.1 it has to be formatted as a hexadecimal, which would give the following value:
"2E32000000000000"
The fields present in the bitmap will differ between request/advice messages and response messages.
Request/Advice messages Field 127.25.1 Name Bitmap Description The bitmap signifies the presence (1) or absence (0) of data sub-elements contained within field 127.25 (ICC Data). The bitmap is a binary field, but is formatted as a hexadecimal. This means the 8 binary characters representing the bitmap must be converted to hexadecimal before being placed in this field. The amount of the transaction Format b8 (Hex 16) Condition Mandatory
127.25.2
Amount Authorized
n12
Must be present in a 0100, 0120, 0200 or 0220 message for an ICC chip transaction. Otherwise optional. In a cash back transaction, must be present in a 0100, 0120, 0200 or 0220 message for an ICC chip transaction. Otherwise optional. Optional
127.25.3
Amount Other
Secondary amount associated with the n12 transaction, representing a cash back amount. Identifies the application on the ICC as ans..32, LLVAR described in ISO/IEC 7816-5. (Field value: translate 16 byte binary EMV value to 32 byte hex string.)
127.25.4
Application Identifier
127.25.5
Application Interchange Profile
Indicates the capabilities of the ICC to support specific functions in the application. (Field value: translate 2 byte binary EMV value to 4 byte hex string.)
ans4
Must be present in a 0100, 0120, 0200 or 0220 message for an ICC chip transaction. Otherwise optional. Must be present in a 0100, 0120, 0200 or 0220 message for an ICC chip transaction. Otherwise optional. Optional
127.25.6
Application Transaction Counter
Counter maintained by the application in the ICC. (Incrementing the ATC is managed by the ICC). (Field value: translate 2 byte binary EMV value to 4 byte hex string.)
ans4
127.25.7
Application Usage Control
Indicates the issuer's specified restrictions on the geographic usage and services allowed for the application. (Field value: translate 2 byte binary EMV value to 4 byte hex string.)
ans4
127.25.8
Authorization Response Code
Code returned by the issuer or generated by the terminal if it did not receive an online response from the issuer. May be set and sent by the acquirer when the acquirer or issuer is inactive for card authentication. An issuer-supplied code indicating card authentication results.
an2
Optional
127.25.9
Card Authentication Reliability Indicator Card Authentication Results Code
n1
Optional
127.25.10
ans1
Optional
Fields
198
127.25.11
Chip Condition Code Indicates the status of last chip attempt at the terminal. 0 Magnetic stripe read, service code does not begin with 2 or 6 1 Magnetic stripe read, service code begins with 2 or 6, last transaction was a successful IC read or not an IC transaction 2 Magnetic stripe read, service code begins with 2 or 6, last transaction was an unsuccessful IC read
n1
May be present in an ICC chip transaction or a non-chip transaction such as an ICC fallback to magnetic stripe.
127.25.12
Cryptogram
The cryptogram generated by the ICC. ans16 Consists of one of the following: Authorization Request Cryptogram (ARQC) for an authorization request, Application Authentication Cryptogram (AAC) for a declined transaction, or Transaction Certificate (TC) for an approved transaction. (Field value: translate 8 byte binary EMV value to 16 byte hex string.)
Must be present in a 0100, 0120, 0200 or 0220 message for an ICC chip transaction. Otherwise optional.
127.25.13
Cryptogram Information Data
Indicates the type of cryptogram returned by the ICC (ARQC, AAC or TC) and the actions to be performed by the terminal. (Field value: translate 1 byte binary EMV value to 2 byte hex string.)
ans2
Will be present if available from the terminal, and must be set if available. May be used in validating the cryptogram.
127.25.14
Cvm List
Identifies the cardholder verification methods (CVMs) supported by the application. (Field value: translate 252 byte binary EMV value to 504 byte hex string.)
ans..504, LLLVAR
Optional
127.25.15
Cvm Results
Cardholder verification method (CVM) results indicating the results of the last CVM performed. (Field value: translate 3 byte binary EMV value to 6 byte hex string.)
ans6
Optional
127.25.16
Interface Device Serial Number
A unique and permanent serial number assigned to the interface device (IFD) by the terminal manufacturer. Card parameters that instruct the terminal about actions to take under various conditions. The first byte of the field indicates the type of Action Code: 0 = Default, specifies the issuer's conditions that cause a transaction to be rejected if it might have been approved online, but the terminal is unable to process the transaction online. 1 = Denial, specifies the issuer's conditions that cause the denial of a transaction without attempt to go online. 2 = Online, specifies the issuer's conditions that cause a transaction to be transmitted online. The remainder of the field consists of the 5 byte binary EMV value translated to a 10 byte hex string.
an8
Should be set if available.
127.25.17
Issuer Action Code
ans11
Optional
Fields
199
127.25.18
Issuer Application Data
ans..64, Proprietary application data for LLVAR transmission from the ICC to the issuer. May contain the following subfields: Scheme Discretionary Data, Issuer Discretionary Data, Derivation Key Index, Cryptogram Version Number, Card Verification Results, DAC. The layout of this field is specific to the issuer. (Field value: translate 32 byte binary EMV value to 64 byte hex string.)
Will be present if available from the terminal, and must be set if available. May be used in validating the cryptogram.
127.25.19
Issuer Script Results Indicates the result of the terminal script processing. (Field value: translate binary EMV value to hex string.)
ans..507, LLLLVAR
May be returned by the ICC to indicate the results of a script processed in a previous transaction. Typically sent in an advice message (0120/0220/0420). Optional Optional
127.25.20 127.25.21
Terminal Application Version Number
Version number assigned by the payment system for the application.
ans4 ans6
Terminal Capabilities Indicates the card data input, CVM, and security capabilities of the terminal. (Field value: translate 3 byte binary EMV value to 6 byte hex string.)
127.25.22
Terminal Country Code
Indicates the country of the terminal, represented according to ISO 3166.
n3
Must be present in a 0100, 0120, 0200 or 0220 message for an ICC chip transaction. Otherwise optional. Optional
127.25.23
Terminal Type
Indicates the environment of the terminal, its communications capability, and its operational control. Status of the different functions as seen from the terminal. (Field value: translate 5 byte binary EMV value to 10 byte hex string.)
n2
127.25.24
Terminal Verification Result
ans10
Must be present in a 0100, 0120, 0200 or 0220 message for an ICC chip transaction. Otherwise optional.
127.25.25
Transaction Category Code Transaction Currency Code
Defines the type of transaction for which authorization is being requested. Used in risk management. Indicates the currency code of the transaction according to ISO 4217.
ans1
Optional
127.25.26
n3
Must be present in a 0100, 0120, 0200 or 0220 message for an ICC chip transaction. Otherwise optional. Must be present in a 0100, 0120, 0200 or 0220 message for an ICC chip transaction. Otherwise optional.
127.25.27
Transaction Date
The local date (in YYMMDD format) on which the transaction was authorized. Counter maintained by the terminal and incremented by one for each transaction. Indicates the type of the transaction, represented by the first two digits of the ISO 8583:1997 Processing Code. Value to provide uniqueness to the generation of the cryptogram. (Field value: translate 4 byte binary EMV value to 8 byte hex string.)
n6
127.25.28
Transaction Sequence Counter Transaction Type
n..8, LVAR Optional
127.25.29
n2
Must be present in a 0100, 0120, 0200 or 0220 message for an ICC chip transaction. Otherwise optional. Must be present in a 0100, 0120, 0200 or 0220 message for an ICC chip transaction. Otherwise optional.
127.25.30
Unpredictable Number
ans8
Fields
200
Response messages Field 127.25.1 Name Bitmap Description The bitmap signifies the presence (1) or absence (0) of data sub-elements contained within field 127.25 (ICC Data). The bitmap is a binary field, but is formatted as a hexadecimal. This means the 8 binary characters representing the bitmap must be converted to hexadecimal before being placed in this field. Counter maintained by the application in the ICC. (Incrementing the ATC is managed by the ICC). (Field value: translate 2 byte binary EMV value to 4 byte hex string.) 127.25.10 127.25.31 Card Authentication Results Code An issuer-supplied code indicating card authentication results. ans..32, LLVAR Optional Optional Format b8 (Hex 16) Condition Mandatory
127.25.6
Application Transaction Counter
ans4
Should be set if available in the message from the issuer.
Issuer Authentication Data sent to the ICC for online issuer Data authentication. May contain the following subfields: Authorization Response Cryptogram (ARPC), Authorization Response Code. The layout of this field is specific to the issuer. (Field value: translate binary EMV value to hex string.)
127.25.32
Issuer Script Template 1
A command from the issuer for transmission to the ICC. This script is processed by the terminal before sending the second GENERATE AC command to the ICC. (Field value: translate binary EMV value to hex string.)
ans..3354, Optional LLLLVAR
127.25.33
Issuer Script Template 2
A command from the issuer for transmission to the ICC. This script is processed by the terminal after sending the second GENERATE AC command to the ICC. (Field value: translate binary EMV value to hex string.)
ans..3354, Optional LLLLVAR
5.2.103
Field 127.26 - Original Node

ans..12, LLVAR

This is a Postilion specific addition to the ISO 8583 standard. Contains the name of the original source node for this transaction. This field is used for linking transactions across source nodes, to handle cases where (for example) the authorization request arrives from one source node, while the matching transaction request or reversal is sent from another.
Fields
201
5.2.104
Field 127.27 - Card Verification Result

ans1

This is a Postilion specific addition to the ISO 8583 standard. Contains the result of a transaction involving card verification.
Card verification result M N P U Y CVV2 valid (match), CVV valid or not available CVV2 invalid (non-match), CVV valid or not available Unable to process CVV2, CVV valid or not available Issuer unregistered to process CVV2, CVV valid or not available CVV invalid
5.2.105
Field 127.28 - American Express Card Identifier (CID)

n4

This is a Postilion specific addition to the ISO 8583 standard. The American Express Card Identifier (CID) is similar to Visa's CVV2 and MasterCard's CVC2. It is used for additional validation in card-notpresent transactions. Note that if the Transaction Manager is configured to perform stand-in, it will not validate the American Express Card Identifier (CID) while performing stand-in. Hence if the Transaction Manager performs stand-in for a transaction where this field is present, it does not imply that the data in this field is valid and correct. The American Express Card Identifier (CID) is passed through the Transaction Manager unaltered and not saved in the database.
5.2.106
Field 127.29 - 3D Secure Data

b40

This is a Postilion specific addition to the ISO 8583 standard. 3D-Secure Data is made up of the following two subfields (both with format b20): The Transaction Identifier (XID) (positions 1 to 20). The Cardholder Authentication Verification Value (CAVV) (positions 21 to 40).
3D-Secure data is passed through the Transaction Manager unaltered and not saved in the database. The Transaction Manager is not allowed to perform stand-in authorization for 3D-Secure transactions.
Fields
202
5.2.107
Field 127.30 - 3D Secure Result

ans1

This is a Postilion specific addition to the ISO 8583 standard. Contains the Cardholder Authentication Verification Value (CAVV) results code.
3D Secure result blank (a space) 0 1 2 3 4 CAVV not validated CAVV not validated due to erroneous data submitted CAVV failed validation CAVV passed validation CAVV validation could not be performed. Issuer attempt incomplete. CAVV validation could not be performed. Issuer system error.
3D-Secure Result is passed through Postilion unaltered and saved in the database.
5.2.108
Field 127.31 - Issuer Network ID

ans..11, LLVAR

This is a Postilion specific addition to the ISO 8583 standard. Contains the ID of the network that the issuer belongs to, that either switched the transaction to the issuer, or authorized the transaction on behalf of the Issuer.
5.2.109
Field 127.32 - UCAF data

b..33, LLVAR

This is a Postilion specific addition to the ISO 8583 standard. Contains the MasterCard UCAF (Universal Cardholder Authentication Field) field for electronic commerce transactions. This field consists of two subfields: UCAF collection indicator, with a format of n1
UCAF collection indicator 0 1 2 UCAF data collection is not supported at the merchant's web site. UCAF data collection is supported by the merchant, but UCAF data was not populated. UCAF data collection is supported by the merchant and the UCAF data was populated.
UCAF authentication data, with a format of b..32. If the UCAF collection indicator subfield is set to 0 or 1, this subfield will not be present.
Fields
203
5.2.110
Field 127.33 - Extended Transaction Type

n4

This is a Postilion specific addition to the ISO 8583 standard. The extended transaction type is a code that distinguishes between transaction types with the same code in the transaction type subfield of field 3 (Processing code). The extended transaction type field can be used in conjunction with any of the current transaction types.
Administration transaction types (1000 - 5999): 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1160 1161 1162 1170 1171 1172 1180 1181 1182 2000 2001 2002 2003 2004 2005 2006 2007 2008 3000 3001 3002 3010 3011 3030 3100 Membership sign-up Bills retracted IOU dispense Cash accepted Rounding Fee reversal Change dispense from cash acceptor Change dispense from canister Deposit envelope dispense Deposit with unknown amount Remote key delivery - Public key request Signature Remote key delivery - Master key request Signature Remote key delivery - Master key verification Signature Remote key delivery - Public key request Certificate Remote key delivery - Master key request Certificate Remote key delivery - Master key verification Certificate Remote key delivery - Master key exchange Remote key delivery - Public key exchange Remote key delivery - Master key update Cash replenishment Depositor cleanout Cash replenishment & depositor cleanout Suspect transaction - Bank saved Suspect transaction - Bank not saved Media totals printed Media totals cleared Suspect transaction - No action taken Declined transaction - Terminal problem Unblock PIN PIN change failure PIN unblock failure EMV cryptogram validation EMV transaction result Signature capture Card activation
Fields
204
Administration transaction types (1000 - 5999): 3101 3200 3201 3202 3300 3301 3302 4000 4001 4100 4101 4102 4103 4101 4105 4106 4107 Card deactivation Statement order Check/cheque book order Stop check/cheque Customer update Account update Card update Fraud alert Suspect transaction Transaction documentation retrieval request Chargeback Chargeback reversal Representment Arbitration chargeback Fee collection Funds disbursement Administration text message
5000- Reserved for client-specific use 5999
Financial transaction types (6000 - 6999): 6000 6001 6002 6003 6010 6011 6012 6100 6101 6102 6103 6110 6200 6201 6202 6203 6204 6300 6301 6400 6401 6402 6403 6404 6500 Money order Money transfer Money transfer inquiry Check/cheque cash inquiry Debit order Debit order inquiry Future debit orders inquiry Check/cheque deposit with OCR entry Check/cheque deposit with manual entry Check/cheque deposit with OCR entry - Cash back to follow Check/cheque deposit with manual entry - Cash back to follow Cash deposit with bunch note acceptor Offline funds load Offline funds unload Offline funds account synchronization Non-usage fee Funding account credit Loan activation Loan cancellation Prepay Prepay - Anonymous voucher Prepay - Consumer-specific voucher Prepay - Electronic topup Prepay - Anonymous voucher reprint Card activation with deposit verified by operator
Fields
205
Financial transaction types (6000 - 6999): 6501 6502 6600 6601 6700 7000 7001 7002 7003 7004 7005 7006 7007 Deposit verified by operator Card deactivation with cash back Check/cheque guarantee for goods and services with cash back Check/cheque verification for goods and services with cash back Currency conversion lookup inquiry Customer verification inquiry Customer linked account inquiry Customer linked card inquiry Customer inquiry Card linked account inquiry Card inquiry Account linked customer inquiry Account inquiry
9000- Reserved for client-specific use 9999
The Extended transaction type field should be used as follows:

Message Type 06xx Transaction Type 90 / 92 Extended Transaction Manager / PostCard stand-in Transaction Type Administratio Defined per transaction type in field 3 for 0600 messages. n transaction types(10005999) Administratio n transaction types(10005999) Defined per extended transaction type in field 127.33 for 0600 messages (PostCard stand-in only supported for extended transaction type 3000 if it is an EMV transaction and PostCard is configured to do PIN verification and to send issuer scripts). If field 127.33 is not present, no stand-in will be done, except in the following cases: 1. PostCard can do stand-in for an EMV PIN unblock transaction (message reason code 6800) if it is configured to do PIN verification and to send issuer scripts. 2. Transaction Manager can do stand-in for a Positive Balances sink node. 3. Transaction Manager can do stand-in for an acquirer sink node when the sink node is not available. This is necessary to maintain backwards compatibility. 01xx / 02xx / 04xx / 9xxx 01xx / 02xx / 04xx / 9xxx Non-general transaction types in the range 00-59 12 / 25 / 32 / 42 / 52 Financial transaction types (60009999) Financial transaction types (60009999) Defined per transaction type in field 3 for 0100 and 0200 messages.
06xx
91
Stand-in is not performed for these transaction types.
Fields
206
5.2.111
Field 127.34 - Account Type Qualifiers

n2

This is a Postilion specific addition to the ISO 8583 standard. This field contains the 'From' and 'To' account type qualifiers for the account types specified in the processing code (field 30. An account type qualifier is an indication of whether the primary, secondary or tertiary account of a specific type should be used. This field consists of two subfields:
0 1 2 3
Account Type Qualifier which qualifies the "From" Account Type (position 1) Account Type Qualifier which qualifies the "To" Account Type (position 2)
Unspecified Primary account Secondary account Tertiary account
Account type qualifier
5.2.112
Field 127.35 - Acquirer Network ID

ans..11, LLVAR

This is a Postilion specific addition to the ISO 8583 standard. Contains the ID of the network that the acquirer belongs to, that switched the transaction from the acquirer.
5.2.113
Field 127.39 - Original Response Code

an2

This is a Postilion specific addition to the ISO 8583 standard. Contains the response code of the original response message. Used when responding to duplicate transactions.
5.2.114
Field 128 - MAC Extended

b8 (Hex 16)

The purpose of the MAC value is to verify that sensitive information in a message has not been modified between leaving the source and arriving at the destination. The MAC value is based upon the values of the sensitive fields of the message and a Cryptographic Key called a MAC Working key or MWK. The Postilion PostBridge MAC Configuration Console can be used to configure which fields should be included in the MAC. The console can also be used to configure which MWK(s) should be used to
Fields
207 calculate the MAC. (Please note: This console will only be used to configure which existing MWK(s) will be used. The actual MWK itself must already be configured on the Postilion system using the Hardware Security Module Configuration Console.)
5.2.114.2.1 Static Key

If the current system uses static MAC Working Keys (MWK) this field will contain the MAC value for the message formatted as a 4 digit binary value, space filled to the right. E.g. if the MAC value is '0000' the field will contain: 0000
5.2.114.2.2 Dynamic Keys

If the current system uses dynamically exchanges MWK's this will contain the MAC value for the message formatted as a 4 digit binary value, follow by the key number used to generate the MAC value, spaced filled to the right. Valid values for the key number are '1' and '2' for MWK 1 and 2 respectively. For a MAC value of '0000', which was calculated using MWK 2 the field will contain: 0002 MACing is not allowed on Network Management Requests / Responses (0800/0810) but a MAC Key Exchange Network Management Request will contain the key number of the key which should be exchanged in position 5 of this field. The rest of the field will be space filled. If MWK 2 is to be exchanged the 0800 and 0810 will contain: 2 Refer to the MAC Key Management section for more information on this topic.
Fields
208
5.3
5.3.1
XML schemas
Iso8583PostXml
The PostBridge interface supports the processing of ISO 8583 messages in XML format. Messages sent to the interface in XML format should be formatted according to the below DTD/XSD.
5.3.1.1
Iso8583PostXml DTD
<?xml version="1.0"?> <!ELEMENT Iso8583PostXml (MsgType, Fields)> <!ELEMENT MsgType (#PCDATA)> <!ELEMENT Fields ( Field_002?, Field_003?, Field_004?, Field_005?, Field_007?, Field_009?, Field_011?, Field_012?, Field_013?, Field_014?, Field_015?, Field_016?, Field_018?, Field_022?, Field_023?, Field_025?, Field_026?, Field_027?, Field_028?, Field_029?, Field_030?, Field_031?, Field_032?, Field_033?, Field_035?, Field_037?, Field_038?, Field_039?, Field_040?, Field_041?, Field_042?, Field_043?, Field_044?, Field_045?, Field_048?, Field_049?, Field_050?, Field_052?, Field_053?, Field_054?, Field_056?, Field_057?, Field_058?, Field_059?, Field_066?, Field_067?, Field_070?, Field_073?, Field_074?, Field_075?, Field_076?, Field_077?, Field_078?, Field_079?, Field_080?, Field_081?, Field_082?, Field_083?, Field_084?, Field_085?, Field_086?, Field_087?,
Fields
Field_088?, Field_089?, Field_090?, Field_091?, Field_095?, Field_097?, Field_098?, Field_100?, Field_101?, Field_102?, Field_103?, Field_118?, Field_119?, Field_123?, Field_125?, Field_127_002?, Field_127_003?, Field_127_004?, Field_127_005?, Field_127_006?, Field_127_007?, Field_127_008?, Field_127_009?, Field_127_010?, Field_127_011?, Field_127_012?, Field_127_013?, Field_127_014?, Field_127_015?, Field_127_016?, Field_127_017?, Field_127_018?, Field_127_019?, Field_127_020?, Field_127_021?, Field_127_022?, Field_127_023?, Field_127_024?, Field_127_025?, Field_127_026?, Field_127_027?, Field_127_028?, Field_127_029?, Field_127_030?, Field_127_031?, Field_127_032?, Field_127_033?, Field_127_034?, Field_127_035?, Field_127_039? )> <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT Field_002 (#PCDATA)> Field_003 (#PCDATA)> Field_004 (#PCDATA)> Field_005 (#PCDATA)> Field_007 (#PCDATA)> Field_009 (#PCDATA)> Field_011 (#PCDATA)> Field_012 (#PCDATA)> Field_013 (#PCDATA)> Field_014 (#PCDATA)> Field_015 (#PCDATA)> Field_016 (#PCDATA)> Field_018 (#PCDATA)> Field_022 (#PCDATA)> Field_023 (#PCDATA)> Field_025 (#PCDATA)> Field_026 (#PCDATA)> Field_027 (#PCDATA)> Field_028 (#PCDATA)> Field_029 (#PCDATA)> Field_030 (#PCDATA)> Field_031 (#PCDATA)> Field_032 (#PCDATA)> Field_033 (#PCDATA)> Field_035 (#PCDATA)> Field_037 (#PCDATA)>
209
Fields
<!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT Field_038 (#PCDATA)> Field_039 (#PCDATA)> Field_040 (#PCDATA)> Field_041 (#PCDATA)> Field_042 (#PCDATA)> Field_043 (#PCDATA)> Field_044 (#PCDATA)> Field_045 (#PCDATA)> Field_048 (#PCDATA)> Field_049 (#PCDATA)> Field_050 (#PCDATA)> Field_052 (#PCDATA)> Field_053 (#PCDATA)> Field_054 (#PCDATA)> Field_056 (#PCDATA)> Field_057 (#PCDATA)> Field_058 (#PCDATA)> Field_059 (#PCDATA)> Field_066 (#PCDATA)> Field_067 (#PCDATA)> Field_070 (#PCDATA)> Field_073 (#PCDATA)> Field_074 (#PCDATA)> Field_075 (#PCDATA)> Field_076 (#PCDATA)> Field_077 (#PCDATA)> Field_078 (#PCDATA)> Field_079 (#PCDATA)> Field_080 (#PCDATA)> Field_081 (#PCDATA)> Field_082 (#PCDATA)> Field_083 (#PCDATA)> Field_084 (#PCDATA)> Field_085 (#PCDATA)> Field_086 (#PCDATA)> Field_087 (#PCDATA)> Field_088 (#PCDATA)> Field_089 (#PCDATA)> Field_090 (#PCDATA)> Field_091 (#PCDATA)> Field_095 (#PCDATA)> Field_097 (#PCDATA)> Field_098 (#PCDATA)> Field_100 (#PCDATA)> Field_101 (#PCDATA)> Field_102 (#PCDATA)> Field_103 (#PCDATA)> Field_118 (#PCDATA)> Field_119 (#PCDATA)> Field_123 (#PCDATA)> Field_125 (#PCDATA)> Field_127_002 (#PCDATA)> Field_127_003 (#PCDATA)> Field_127_004 (#PCDATA)> Field_127_005 (#PCDATA)> Field_127_006 (#PCDATA)> Field_127_007 (#PCDATA)> Field_127_008 (#PCDATA)> Field_127_009 (#PCDATA)> Field_127_010 (#PCDATA)> Field_127_011 (#PCDATA)> Field_127_012 (#PCDATA)> Field_127_013 (#PCDATA)> Field_127_014 (#PCDATA)> Field_127_015 (#PCDATA)> Field_127_016 (#PCDATA)> Field_127_017 (#PCDATA)> Field_127_018 (#PCDATA)> Field_127_019 (#PCDATA)> Field_127_020 (#PCDATA)> Field_127_021 (#PCDATA)> Field_127_022 (#PCDATA)> Field_127_023 (#PCDATA)> Field_127_024 (#PCDATA)> Field_127_025 (#PCDATA)> Field_127_026 (#PCDATA)> Field_127_027 (#PCDATA)>
210
Fields
<!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT Field_127_028 Field_127_029 Field_127_030 Field_127_031 Field_127_032 Field_127_033 Field_127_034 Field_127_035 Field_127_039 (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)>
211
5.3.1.2
Iso8583PostXml XSD
<?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="Iso8583PostXml"> <xsd:complexType> <xsd:sequence> <xsd:element ref="MsgType"/> <xsd:element ref="Fields"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="MsgType" type="xsd:string"/> <xsd:element name="Fields"> <xsd:complexType> <xsd:sequence> <xsd:element ref="Field_002" <xsd:element ref="Field_003" <xsd:element ref="Field_004" <xsd:element ref="Field_005" <xsd:element ref="Field_007" <xsd:element ref="Field_009" <xsd:element ref="Field_011" <xsd:element ref="Field_012" <xsd:element ref="Field_013" <xsd:element ref="Field_014" <xsd:element ref="Field_015" <xsd:element ref="Field_016" <xsd:element ref="Field_018" <xsd:element ref="Field_022" <xsd:element ref="Field_023" <xsd:element ref="Field_025" <xsd:element ref="Field_026" <xsd:element ref="Field_027" <xsd:element ref="Field_028" <xsd:element ref="Field_029" <xsd:element ref="Field_030" <xsd:element ref="Field_031" <xsd:element ref="Field_032" <xsd:element ref="Field_033" <xsd:element ref="Field_035" <xsd:element ref="Field_037" <xsd:element ref="Field_038" <xsd:element ref="Field_039" <xsd:element ref="Field_040" <xsd:element ref="Field_041" <xsd:element ref="Field_042" <xsd:element ref="Field_043" <xsd:element ref="Field_044" <xsd:element ref="Field_045" <xsd:element ref="Field_048" <xsd:element ref="Field_049" <xsd:element ref="Field_050" <xsd:element ref="Field_052" <xsd:element ref="Field_053" <xsd:element ref="Field_054" <xsd:element ref="Field_056" <xsd:element ref="Field_057" <xsd:element ref="Field_058" <xsd:element ref="Field_059" <xsd:element ref="Field_066" <xsd:element ref="Field_067" <xsd:element ref="Field_070" <xsd:element ref="Field_073" <xsd:element ref="Field_074" <xsd:element ref="Field_075"
minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0" minOccurs="0"
maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/> maxOccurs="1"/>
Fields
<xsd:element ref="Field_076" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_077" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_078" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_079" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_080" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_081" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_082" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_083" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_084" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_085" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_086" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_087" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_088" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_089" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_090" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_091" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_095" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_097" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_098" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_100" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_101" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_102" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_103" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_118" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_119" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_123" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_125" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_002" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_003" minOccurs="0" axOccurs="1"/> <xsd:element ref="Field_127_004" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_005" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_006" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_007" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_008" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_009" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_010" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_011" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_012" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_013" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_014" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_015" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_016" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_017" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_018" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_019" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_020" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_021" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_022" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_023" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_024" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_025" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_026" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_027" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_028" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_029" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_030" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_031" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_032" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_033" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_034" minOccurs="0" maxOccurs="1"/> <xsd:element ref="Field_127_035" minOccurs="0" maxOccurs="1"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Field_002" type="xsd:string"/> <xsd:element name="Field_003" type="xsd:string"/> <xsd:element name="Field_004" type="xsd:string"/> <xsd:element name="Field_005" type="xsd:string"/> <xsd:element name="Field_007" type="xsd:string"/> <xsd:element name="Field_009" type="xsd:string"/> <xsd:element name="Field_011" type="xsd:string"/> <xsd:element name="Field_012" type="xsd:string"/> <xsd:element name="Field_013" type="xsd:string"/> <xsd:element name="Field_014" type="xsd:string"/> <xsd:element name="Field_015" type="xsd:string"/> <xsd:element name="Field_016" type="xsd:string"/> <xsd:element name="Field_018" type="xsd:string"/>
212
Fields
<xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element name="Field_022" type="xsd:string"/> name="Field_023" type="xsd:string"/> name="Field_025" type="xsd:string"/> name="Field_026" type="xsd:string"/> name="Field_027" type="xsd:string"/> name="Field_028" type="xsd:string"/> name="Field_029" type="xsd:string"/> name="Field_030" type="xsd:string"/> name="Field_031" type="xsd:string"/> name="Field_032" type="xsd:string"/> name="Field_033" type="xsd:string"/> name="Field_035" type="xsd:string"/> name="Field_037" type="xsd:string"/> name="Field_038" type="xsd:string"/> name="Field_039" type="xsd:string"/> name="Field_040" type="xsd:string"/> name="Field_041" type="xsd:string"/> name="Field_042" type="xsd:string"/> name="Field_043" type="xsd:string"/> name="Field_044" type="xsd:string"/> name="Field_045" type="xsd:string"/> name="Field_048" type="xsd:string"/> name="Field_049" type="xsd:string"/> name="Field_050" type="xsd:string"/> name="Field_052" type="xsd:string"/> name="Field_053" type="xsd:string"/> name="Field_054" type="xsd:string"/> name="Field_056" type="xsd:string"/> name="Field_057" type="xsd:string"/> name="Field_058" type="xsd:string"/> name="Field_059" type="xsd:string"/> name="Field_066" type="xsd:string"/> name="Field_067" type="xsd:string"/> name="Field_070" type="xsd:string"/> name="Field_073" type="xsd:string"/> name="Field_074" type="xsd:string"/> name="Field_075" type="xsd:string"/> name="Field_076" type="xsd:string"/> name="Field_077" type="xsd:string"/> name="Field_078" type="xsd:string"/> name="Field_079" type="xsd:string"/> name="Field_080" type="xsd:string"/> name="Field_081" type="xsd:string"/> name="Field_082" type="xsd:string"/> name="Field_083" type="xsd:string"/> name="Field_084" type="xsd:string"/> name="Field_085" type="xsd:string"/> name="Field_086" type="xsd:string"/> name="Field_087" type="xsd:string"/> name="Field_088" type="xsd:string"/> name="Field_089" type="xsd:string"/> name="Field_090" type="xsd:string"/> name="Field_091" type="xsd:string"/> name="Field_095" type="xsd:string"/> name="Field_097" type="xsd:string"/> name="Field_098" type="xsd:string"/> name="Field_100" type="xsd:string"/> name="Field_101" type="xsd:string"/> name="Field_102" type="xsd:string"/> name="Field_103" type="xsd:string"/> name="Field_118" type="xsd:string"/> name="Field_119" type="xsd:string"/> name="Field_123" type="xsd:string"/> name="Field_125" type="xsd:string"/> name="Field_127_002" type="xsd:string"/> name="Field_127_003" type="xsd:string"/> name="Field_127_004" type="xsd:string"/> name="Field_127_005" type="xsd:string"/> name="Field_127_006" type="xsd:string"/> name="Field_127_007" type="xsd:string"/> name="Field_127_008" type="xsd:string"/> name="Field_127_009" type="xsd:string"/> name="Field_127_010" type="xsd:string"/> name="Field_127_011" type="xsd:string"/> name="Field_127_012" type="xsd:string"/> name="Field_127_013" type="xsd:string"/> name="Field_127_014" type="xsd:string"/>
213
Fields
<xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element </xsd:schema> name="Field_127_015" name="Field_127_016" name="Field_127_017" name="Field_127_018" name="Field_127_019" name="Field_127_020" name="Field_127_021" name="Field_127_022" name="Field_127_023" name="Field_127_024" name="Field_127_025" name="Field_127_026" name="Field_127_027" name="Field_127_028" name="Field_127_029" name="Field_127_030" name="Field_127_031" name="Field_127_032" name="Field_127_033" name="Field_127_034" name="Field_127_035" type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/>
214
5.3.2
ICC Data
IccData (field 127.25) is formatted as an XML document, as per a DTD. This XML document has an outer tag (IccData), and 2 primary inner tags (IccRequest and IccResponse). The IccRequest tag is used in request messages, and the IccResponse tag is used in response messages.
5.3.2.1
ICC Request
Field Format Condition Description
AmountAuthorized AmountOther
n12 n12
The amount of the transaction. Secondary amount associated with the transaction, representing a cash back amount. Identifies the application on the ICC as described in ISO/IEC 7816-5. (Field value: translate 16 byte binary EMV value to 32 byte hex string.)
ApplicationIdentifier
ans..32
Optional
ApplicationInterchangeProfile
ans4
Conditional
Indicates the capabilities of the ICC to support specific functions in the application. (Field value: translate 2 byte binary EMV value to 4 byte hex string.)
ApplicationTransactionCounter
ans4
Conditional
ApplicationUsageControl
ans4
Optional
Indicates the issuer's specified restrictions on the geographic usage and services allowed for the application. (Field value: translate 2 byte binary EMV value to 4 byte hex string.)
AuthorizationResponseCode
an2
Optional
Code returned by the issuer or generated by the terminal if it did not receive an online response from the issuer. May be set and sent by the acquirer when the acquirer or issuer is inactive for card
CardAuthenticationReliabilityIndicator
n1
Optional
Fields
215
Field
Format
Condition
Description
authentication. CardAuthenticationResultsCode ans1 Optional An issuer-supplied code indicating card authentication results. Indicates the status of last chip attempt at the terminal. 0 Magnetic stripe read, service code does not begin with 2 or 6 1 Magnetic stripe read, service code begins with 2 or 6, last transaction was a successful IC read or not an IC transaction 2 Magnetic stripe read, service code begins with 2 or 6, last transaction was an unsuccessful IC read Cryptogram ans16 Conditional The cryptogram generated by the ICC. Consists of one of the following: Authorization Request Cryptogram (ARQC) for an authorization request, Application Authentication Cryptogram (AAC) for a declined transaction, or Transaction Certificate (TC) for an approved transaction. (Field value: translate 8 byte binary EMV value to 16 byte hex string.) CryptogramInformationData ans2 Conditional Indicates the type of cryptogram returned by the ICC (ARQC, AAC or TC) and the actions to be performed by the terminal. (Field value: translate 1 byte binary EMV value to 2 byte hex string.) CvmList ans..504 Optional Identifies the cardholder verification methods (CVMs) supported by the application. (Field value: translate 252 byte binary EMV value to 504 byte hex string.) CvmResults ans6 Optional Cardholder verification method (CVM) results indicating the results of the last CVM performed. (Field value: translate 3 byte binary EMV value to 6 byte hex string.) InterfaceDeviceSerialNumber an8 Conditional A unique and permanent serial number assigned to the interface device (IFD) by the terminal manufacturer Card parameters that instruct the terminal about actions to take under various conditions. Specifies the issuer's conditions that cause a transaction to be rejected if it might have been approved online, but the terminal is unable to process the transaction online. (Field value: translate 5 byte binary EMV value to 10 byte hex string.)
ChipConditionCode
n1
Optional
IssuerActionCode
Optional
Default
ans10
Conditional
Fields
216
Field
Format
Condition
Description
Denial
ans10
Conditional
Specifies the issuer's conditions that cause the denial of a transaction without attempt to go online. (Field value: translate 5 byte binary EMV value to 10 byte hex string.)
Online
ans10
Conditional
Specifies the issuer's conditions that cause a transaction to be transmitted online. (Field value: translate 5 byte binary EMV value to 10 byte hex string.)
IssuerApplicationData
ans..64
Conditional
Proprietary application data for transmission from the ICC to the issuer. May contain the following subfields: Scheme Discretionary Data, Issuer Discretionary Data, Derivation Key Index, Cryptogram Version Number, Card Verification Results, DAC. The layout of this field is specific to the issuer. (Field value: translate 32 byte binary EMV value to 64 byte hex string.)
IssuerScriptResults
ans..
Optional
Indicates the result of the terminal script processing. (Field value: translate binary EMV value to hex string.)
TerminalApplicationVersionNumber
ans4
Optional
Version number assigned by the payment system for the application. Indicates the card data input, CVM, and security capabilities of the terminal. (Field value: translate 3 byte binary EMV value to 6 byte hex string.)
TerminalCapabilities
ans6
Optional
TerminalCountryCode
n3
Conditional
Indicates the country of the terminal, represented according to ISO 3166. Indicates the environment of the terminal, its communications capability, and its operational control. Status of the different functions as seen from the terminal. (Field value: translate 5 byte binary EMV value to 10 byte hex string.)
TerminalType
n2
Optional
TerminalVerificationResult
ans10
Conditional
TransactionCategoryCode
ans1
Optional
Defines the type of transaction for which authorization is being requested. Used in risk management. Indicates the currency code of the transaction according to ISO 4217. The local date (in YYMMDD format) on which the transaction was authorized. Counter maintained by the terminal and incremented by one for each transaction.
TransactionCurrencyCode
n3
Conditional
TransactionDate
n6
Conditional
TransactionSequenceCounter
n..8
Optional
Fields
217
Field
Format
Condition
Description
TransactionType
n2
Conditional
Indicates the type of the transaction, represented by the first two digits of the ISO 8583:1997 Processing Code. Value to provide uniqueness to the generation of the cryptogram. (Field value: translate 4 byte binary EMV value to 8 byte hex string.)
UnpredictableNumber
ans8
Conditional
5.3.2.2
ICC Response
Field Format Condition Description
ApplicationTransactionCounter
ans4
Conditional
CardAuthenticationResultsCode
ans1
Optional
An issuer-supplied code indicating card authentication results. Data sent to the ICC for online issuer authentication. May contain the following subfields: Authorization Response Cryptogram (ARPC), Authorization Response Code. The layout of this field is specific to the issuer. (Field value: translate binary EMV value to hex string.)
IssuerAuthenticationData
ans32
Optional
IssuerScriptTemplate1
ans..
Optional
A command from the issuer for transmission to the ICC. This script is processed by the terminal before sending the second GENERATE AC command to the ICC. (Field value: translate 16 byte binary EMV value to 32 byte hex string.)
IssuerScriptTemplate2
ans..
Optional
A command from the issuer for transmission to the ICC. This script is processed by the terminal after sending the second GENERATE AC command to the ICC. (Field value: translate 16 byte binary EMV value to 32 byte hex string.)
5.3.2.3
ICCData DTD
<?xml version="1.0"?> <!ELEMENT IccData ( IccRequest?, IccResponse?) > <!ELEMENT IccRequest ( AmountAuthorized?, AmountOther?, ApplicationIdentifier?, ApplicationInterchangeProfile?, ApplicationTransactionCounter?, ApplicationUsageControl?, AuthorizationResponseCode?, CardAuthenticationReliabilityIndicator?,
Fields
CardAuthenticationResultsCode?, ChipConditionCode?, Cryptogram?, CryptogramInformationData?, CvmList?, CvmResults?, InterfaceDeviceSerialNumber?, IssuerActionCode?, IssuerApplicationData?, IssuerScriptResults?, TerminalApplicationVersionNumber?, TerminalCapabilities?, TerminalCountryCode?, TerminalType?, TerminalVerificationResult?, TransactionCategoryCode?, TransactionCurrencyCode?, TransactionDate?, TransactionSequenceCounter?, TransactionType?, UnpredictableNumber?) > <!ELEMENT IccResponse ( ApplicationTransactionCounter?, CardAuthenticationResultsCode?, IssuerAuthenticationData?, IssuerScriptTemplate1?, IssuerScriptTemplate2?) > <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT AmountAuthorized (#PCDATA)> AmountOther (#PCDATA)> ApplicationAuthenticationCryptogram (#PCDATA)> ApplicationIdentifier (#PCDATA)> ApplicationInterchangeProfile (#PCDATA)> ApplicationTransactionCounter (#PCDATA)> ApplicationUsageControl (#PCDATA)> AuthorizationRequestCryptogram (#PCDATA)> AuthorizationResponseCode (#PCDATA)> CardAuthenticationReliabilityIndicator (#PCDATA)> CardAuthenticationResultsCode (#PCDATA)> CryptogramInformationData (#PCDATA)> CvmList (#PCDATA)> CvmResults (#PCDATA)> InterfaceDeviceSerialNumber (#PCDATA)> IssuerActionCode ( Default?, Denial?, Online?) <!ELEMENT Default (#PCDATA)> <!ELEMENT Denial (#PCDATA)> <!ELEMENT Online (#PCDATA)> IssuerApplicationData (#PCDATA)> IssuerAuthenticationData (#PCDATA)> IssuerScriptResults (#PCDATA)> IssuerScriptTemplate1 (#PCDATA)> IssuerScriptTemplate2 (#PCDATA)> TerminalApplicationVersionNumber (#PCDATA)> TerminalCapabilities (#PCDATA)> TerminalCountryCode (#PCDATA)> TerminalType (#PCDATA)> TerminalVerificationResult (#PCDATA)> TransactionCategoryCode (#PCDATA)> TransactionCertificate (#PCDATA)> TransactionCurrencyCode (#PCDATA)> TransactionDate (#PCDATA)> TransactionSequenceCounter (#PCDATA)> TransactionType (#PCDATA)> UnpredictableNumber (#PCDATA)>
218
>
<!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT
Fields
219
5.3.3
StatementData
The fields described below are used to send StatementData information. The key value of this structure is "StatementData", and the top level element is "StatementData".
Field
Type (element or attribute)
Condition
Format
Description
Request
Element
Optional
This aggregate wraps the information required to request a statement from the host. The RequestRange aggregate wraps information that delimits the transactions to be returned in the <TransactionList/> aggregate. n8 Transactions occurring prior to this date should not be included in the statement transaction list. Transactions occurring after this date should not be included in the statement transaction list. The maximum number of transactions to be included in the transaction list.
RequestRange
Element
Optional
StartDate
Attribute
Optional
EndDate
Attribute
Optional
n8
TransactionCount
Attribute
Optional
n4
LastBlockReference
Attribute
Optional
ans..16 This token is returned in the <TransactionList/> aggregate if all the transactions that fall within the specified range could not be sent in a single message (i.e. the value for <isComplete/> is set to Y). To receive the remaining transactions in the range, the client should include the token in another request that otherwise has the same range as the initial request. ans..16 Back if the block before the block identified by the LastBlockReference field is requested or Forward if the block after the block identified by the LastBlockReference field is requested. Present for 0110/0210. The ResponseRange aggregate wraps information that delimits the transactions to be returned in the <TransactionList/> aggregate. n8 The posting date of the first transaction included in the statement. The format should be CCYYMMDD. The posting date of the last transaction included in the statement. The format should be CCYYMMDD. The actual number of transactions included in the response.
NextBlock
Attribute
Optional
Response ResponseRange
Element Attribute
Optional Mandatory
StartDate
Attribute
Optional
EndDate
Attribute
Optional
n8
TransactionCount
Attribute
Mandatory n4
BlockReference
Attribute
Optional
ans..16 This token is returned in the <TransactionList/> aggregate if all the transaction that fall within the specified range could not be sent in a single message (i.e. the value for <isComplete/> is set to Y). To receive the remaining transactions in the range, the client should include the token in another request that otherwise has the same range as the initial request.
Fields
220
Field
Condition
Format
Description
CurrencyCode
Element
Optional
Postilion numeric currency code - to cater for multiple languages. This is the currency of the account for which the statement is returned.
TransactionList Transaction
Element Element
Optional One or more Optional Optional Postilion numeric transaction type. Postilion numeric account type. This is the type of the account from which funds were transferred to this account. The ID of the account from which funds were transferred to this account. Postilion numeric account type. This is the type of the account to which funds were transferred from this account. The ID of the account to which funds were transferred from this account. The date at which the transaction was performed originally. The format should be CCYYMMDD. The time can optionally be appended to the date in the format hhmmss. The date at which the transaction was posted against the account. The format should be CCYYMMDD. The time can optionally be appended to the date in the format hhmmss.
TransactionType
Attribute
FromAccountType Attribute
FromAccountID
Attribute
Optional
ToAccountType
Attribute
Optional
ToAccountID
Attribute
Optional
TransactionDate
Attribute
Optional
PostDate
Attribute
Mandatory
TransactionAmount Element Amount Sign Currency Code Attribute Attribute Attribute
Mandatory Mandatory Mandatory Mandatory C for credit, D for debit. Postilion numeric currency code. This is the currency in which the transaction was done originally. The transaction amount in currency of the account.
PostAmount Amount Sign Surcharge
Element Attribute Attribute Element
Mandatory Mandatory Mandatory Optional
C for credit, D for debit. The transaction surcharge amount. The currency is the original transaction currency.
Amount Sign
Attribute Attribute
Mandatory Mandatory C for credit, D for debit.
Fields
221
Field
Condition
Format
Description
Fee
Element
One or more Optional Mandatory Mandatory Optional Optional Optional
A transaction fee charged by the issuer. The currency is the currency of the account.
FeeDescription Amount Sign Description ReferenceNumber Balance
Attribute Attribute Attribute Attribute Attribute Element
C for credit, D for debit.
This aggregate wraps information pertaining to a balance of the account. Postilion numeric amount type. The value of this tag must contain the type of balance that is being reported (e.g. LedgerBalance).
BalanceType
Attribute
Mandatory
Amount Sign IsComplete
Attribute Attribute Attribute
Mandatory Mandatory Optional C for credit, D for debit. Y if there are no more transactions that fall within the range specified in the statement request message, N otherwise. Wraps information about the account's opening balances. This aggregate wraps information pertaining to a balance of the account. The value of this tag must contain a description of the type of balance that is being reported (e.g. LedgerBalance). The numerical value of the transaction (i.e. the quantity of funds). C for credit, D for debit. This aggregate wraps one or more types of closing balances for the account. This aggregate wraps information pertaining to a balance of the account. The value of this tag must contain a description of the type of balance that is being reported (e.g. LedgerBalance). The numerical value of the transaction (i.e. the quantity of funds). C for credit, D for debit.
OpeningBalance
Element
Optional
Balance
Element
One or more Optional
Balance Type
Attribute
Amount
Attribute
Mandatory
Sign OpeningBalance
Attribute Element
Mandatory Optional
Balance
Element
One or more Mandatory
Balance Type
Attribute
Amount
Attribute
Mandatory
Sign
Attribute
Mandatory
Fields
222
5.3.3.1
StatementData DTD
<!ELEMENT StatementData (Request | Response)> <!ELEMENT Request (RequestRange?)> <!ELEMENT RequestRange ( StartDate?, EndDate?, TransactionCount?, LastBlockReference?, NextBlock?)> <!ELEMENT Response ( ResponseRange, CurrencyCode?, TransactionList?, OpeningBalance?, ClosingBalance? )> <!ELEMENT ResponseRange ( StartDate?, EndDate?, TransactionCount, BlockReference? )> <!ELEMENT TransactionList (Transaction+, IsComplete)> <!ELEMENT Transaction ( TransactionType?, FromAccountType?, FromAccountID?, ToAccountType?, ToAccountID?, TransactionDate?, PostDate?, TransactionAmount?, PostAmount, Surcharge?, Fee*, Description?, ReferenceNumber?, Balance? )> <!ELEMENT OpeningBalance (Balance*)> <!ELEMENT ClosingBalance (Balance*)> <!ELEMENT TransactionAmount (Amount, Sign, CurrencyCode)> <!ELEMENT PostAmount (Amount, Sign)> <!ELEMENT Surcharge (Amount, Sign)> <!ELEMENT Fee (FeeDescription?, Amount, Sign)> <!ELEMENT Balance (BalanceType, Amount, Sign)> <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT StartDate EndDate TransactionCount LastBlockReference NextBlockReference LastBlockReference NextBlock BlockReference CurrencyCode TransactionType FromAccountType FromAccountID ToAccountType ToAccountID TransactionDate PostDate Amount Sign FeeDescription Description ReferenceNumber BalanceType IsComplete (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)>
Fields
223
5.3.4
CardManagementUpdateData
The fields described below are used to send CardManagementUpdateData information. The key value of this structure is "CardManagementUpdateData", and the top level element is "CardManagementUpdateData".
Field Type (element or attribute) Condition Description
Request
Element
Optional
The Request aggregate wraps the information required to request a card management update from the host. This record must be present for a request message
Card
Element
Mandatory The Card aggregate wraps the information about the card involved in the request. Mandatory The PAN of the card involved. If this field is present, field 2 need not be present, but if field 2 is present, the values must be the same.
PAN
Attribute
SequenceNumber
Attribute
Optional
The sequence number of the card involved. If this field is present, field 23 need not be present, but if field 23 is present, the values must be the same. If this field is not present, field 23 may not be present.
ExpiryDate CardActive HoldResponseCode
Optional Optional Optional
The expiry date of the card involved. Is this card currently marked as active? Y for Yes, N for No. The hold response code to use. If this field is present, but empty, the hold response code will be cleared.
PINCodeSecure PINCodeInsecure
Attribute Attribute
Optional Optional
PIN offset/PVV for the secure PIN. The insecure PIN block.
5.3.4.1
CardManagementUpdateData DTD
<!ELEMENT CardManagementUpdateData (Request)> <!ELEMENT Request (Card?)> <!ELEMENT Card ( PAN, SequenceNumber, ExpiryDate?, CardActive?, HoldResponseCode?, PINCodeSecure?, PINCodeInsecure?)> <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT PAN SequenceNumber ExpiryDate CardActive HoldResponseCode PINCodeSecure PINCodeInsecure (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)> (#PCDATA)>
Fields
224
5.3.5
CardManagementUpdateLoad
The fields described below are used to send CardManagementUpdateLoad information. The key value of this structure is "CardManagementUpdateLoad", and the top level element is "CardManagementUpdateLoad".
Field Type (element or attribute) Condition Description
Request
Element
Optional
The Request aggregate wraps the information required to request a card management update from the host. This record must be present for a request message
FileFormat
Attribute
Mandatory display_name in pc_custom_classes where category is PostCard_UpdateLoad. Only the standard PostCard file formats are allowed: Standard, Standard 2, etc. Mandatory This aggregate wraps one or more file items One or more Mandatory CARDS, CARDOVERRIDELIMITS, ACCOUNTS, ACCOUNTOVERRIDELIMITS, CARDACCOUNTS, ACCOUNTBALANCES, or STATEMENTS Optional One or more This aggregate wraps one or more file row items The fields in a row are separated by commas. Database table columns with a type of datetime correspond to fields in a row with the following formatting: YYYY-MM-DD hh:mm:ss (exactly 19 characters). Database table columns with a type of int or numeric correspond to fields in a row that can contain negative numbers, which are indicated by a minus sign ('-') in front of the number. A row must be preceded by either U (update) or D (delete), followed by a comma. U applies to rows to be inserted as well as to rows to be updated. For rows which are to be deleted, only the key information needs to be provided (such as the PAN, sequence number and expiry date for cards, or the account ID and account type for accounts). Note that cascading deletes are not supported. In order to maintain database integrity, all applicable rows must be deleted explicitly. Rows which are to be updated or inserted may contain fields where the current value of the field should be deleted (set to null). To indicate this, the field should be empty, i.e. the length should be zero. Rows which are to be updated may contain fields where the current value of the field should be retained. To indicate this, the field should contain an asterisk ('*').
FileList File
Element Element
FileName
Attribute
FileRowList FileRow
Element Attribute
Response
Element
Optional
This record will be present for a response message if the response code is 27 or 29.
FileFormat FileList File
Attribute Element Element
Mandatory Echoed from Request. Mandatory This aggregate wraps one or more file items One or more The file rows that caused the error will be echoed from Request.
Fields
225
Field
Condition
Description
FileName FileRowList FileRow
Attribute Element Attribute
Mandatory Echoed from Request. Mandatory This aggregate wraps one or more file row items One or more The file rows that caused the error will be echoed from Request.
5.3.5.1
CardManagementUpdateLoad DTD
<!ELEMENT CardManagementUpdateLoad ( Request?, Response?)> <!ELEMENT Request ( FileFormat, FileList)> <!ELEMENT Response ( FileFormat, FileList)> <!ELEMENT FileList (File+)> <!ELEMENT File ( FileName, FileRowList)> <!ELEMENT FileRowList (FileRow+)> <!ELEMENT FileRow (#PCDATA)> <!ELEMENT FileName (#PCDATA)> <!ELEMENT FileFormat (#PCDATA)>
5.3.6
PrepaidMerchandise
The fields described below are used to send PrepaidMerchandise information. The key value of this structure is "PrepaidMerchandise", and the top level element is "PrepaidMerchandise". This DTD caters for telephone prepay and electricity prepay. There are three modes of prepay: Anonymous voucher: A product and tender is sent up and a PIN (activation code) is sent back, which is keyed in on the device by the consumer. Reversals are generally not supported here. Electronic top-up: The consumer/device information is sent up along with the product and the tender and the top-up is done by the service provider. Consumer-specific voucher: The consumer/device information is sent up along with the product and the tender and a PIN (that typically incorporates consumer/device information) is sent back, which is keyed in on the device by the consumer.
The DTD is to be used in the non-financial leg of a prepay transaction with message type 0100/0200/0220/0400/0420 and transaction type 28 (Merchandise dispatch/top-up), or message type 0200 and transaction type 02 (Debit adjustment). The extended transaction type should be 6401 (Prepay Anonymous voucher), 6402 (Prepay Consumer-specific voucher) or 6403 (Prepay Electronic top-up).
Field Type (element or attribute) Condition Format Description
Request Product NetworkID
Element Element Attribute
Optional Optional Optional ans..12
Present for 0100/0200.
The network that must authorize.
Fields
226
Field
Condition
Format
Description
ProductID Type
Attribute Attribute
Optional Optional
ans..50 ans..30
The code of the merchandise. Valid values: TELEPHONE PREPAY CALLING PLAN ELECTRICITY OTHER
UserID
Attribute
Optional
ans..40
For telephone prepay, this contains the telephone number (MSISDN). The track 2 of the merchandise card issued by the service provider.
Track2
Attribute
Optional
ans..37
Tender Amount
Element Attribute
Optional Optional n..12 The requested amount (in the minor denomination). Valid values: 00 None 10 Cash 20 Check/Cheque 30 Credit card 40 Debit card 50 Voucher 60 Auto cash 99 Other
Type
Attribute
Optional
n2
SerialNumber
Attribute
Optional
ans..40
If the merchandise is purchased using a voucher, this field can be used to store the vouchers serial number. Present for 0110/0210. Assigned by the merchandise host. Valid values: A0 Prepay transaction failed A1 Prepay transaction rejected A2 Invalid telephone number A3 Prepay account limit reached A4 Prepay system unavailable N0 to ZZ Reserved for client-specific use All other values are reserved for future Postilion use.
Response TransactionSeqNo ResponseCode
Element Attribute Attribute
Optional Mandatory n..8 Optional ans..12
ResponseMessage
Attribute
Optional
ans..200
An explanation of the response code.
Fields
227
Field
Condition
Format
Description
Product NetworkID ProductID Type UserID Track2 Tender Amount Type SerialNumber MerchandiseItem PIN
Element Attribute Attribute Attribute Attribute Attribute Element Attribute Attribute Attribute Element Attribute
Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional ans..255 The activation code to be keyed in on the device by the consumer. This field may contain multiple values separated by commas. The serial number of the merchandise, for example a voucher serial number. n..12 n2 ans..40 Copied from request. Copied from request. Copied from request. ans..12 ans..50 ans..30 ans..40 ans..37 Copied from request. Copied from request. Copied from request. Copied from request. Copied from request.
ItemSerialNumber
Attribute
Optional
ans..20
ExpiryDate
Attribute
Optional
YYYYMM The expiry date of the merchandise. DD n..12 The approved amount (in the minor denomination). The tax amount (in the minor denomination). The network that authorized. The name of the merchandise. A message associated with the merchandise, for example instructions on how to load the PIN. Line breaks are denoted by '|'. A description of the merchandise. The code for the tariff that was applied. A list of additional values supplied to the customer. For example, this can be used to supply: - A new key - A new key revision number - The electricity supply group code
Amount
Attribute
Optional
TaxAmount NetworkName ProductName ItemMessage
Attribute Attribute Attribute Attribute
Optional Optional Optional Optional
n..12 ans..50 ans..50 ans..250
DescriptiveValue TariffIndex Token
Attribute Attribute Element
Optional Optional Zero or more
ans..80 ans..12
Fields
228
Field
Condition
Format
Description
Description Value MerchandiseIssuer
Attribute Attribute Element
Mandatory ans..25 Mandatory ans..25 Optional The network or service provider is typically the same as the merchandise issuer (compare the NetworkName field with the MerchandiseIssuer.Name field and the NetworkID field with the MerchandiseIssuer.Id field), but these fields have been defined separately for legacy reasons. ans..50 ans..12 ans..25 ans..20 Can be used for printing on the receipt. Can be used for printing on the receipt. Can be used for printing on the receipt. For example the VAT registration number. Can be used for printing on the receipt. Used to return balance information, for example the available number of minutes of airtime and talktime. ans..12 ans..20 ans..255 ans..50 The code of the balance type. The name of the balance type. The balance. A description of the balance.
Name Id ContactNumber RegistrationNumber
Attribute Attribute Attribute Attribute
Optional Optional Optional Optional
QuantityItem
Element
Zero or more
ProductCode ProductName Quantity QuantityDescription ExpiryDate
Attribute Attribute Attribute Attribute Attribute
Optional Optional Optional Optional Optional
YYYYMM The expiry date of the balance. DD
Consumer Id Name Address AdviceRequest TransactionSeqNo ReversalRequest
Element Attribute Attribute Attribute Element Attribute Element
Optional Optional Optional Optional Optional Mandatory n..8 Optional ans..40 ans..40 ans..40 Present for 0220. Copied from response. Present for 0400/0420 and 0200 with transaction type 02. Copied from response. Present for 0410 and 0210 with transaction type 02. Copied from reversal request. For example a meter serial number.
TransactionSeqNo ReversalResponse
Attribute Element
Mandatory n..8 Optional
TransactionSeqNo
Attribute
Mandatory n..8
Fields
229
Field
Condition
Format
Description
ResponseCode
Attribute
Optional
ans..12
Valid values: A2 Invalid telephone number A4 Prepay system unavailable B0 Reversal processing failed B1 Original transaction not found B2 Reversal received too late B3 Reversal not allowed N0 to ZZ Reserved for client-specific use All other values are reserved for future Postilion use.
ResponseMessage
Attribute
Optional
ans..200
An explanation of the response code.
5.3.6.1
PrepaidMerchandise DTD
<!ELEMENT PrepaidMerchandise ( Request?, Response?, AdviceRequest?, ReversalRequest?, ReversalResponse? )> <!ELEMENT Request (Product?, Tender?)> <!ELEMENT Product ANY> <!ATTLIST Product NetworkID CDATA #IMPLIED> <!ATTLIST Product ProductID CDATA #IMPLIED> <!ATTLIST Product Type CDATA #IMPLIED> <!ATTLIST Product UserID CDATA #IMPLIED> <!ATTLIST Product Track2 CDATA #IMPLIED> <!ELEMENT <!ATTLIST <!ATTLIST <!ATTLIST Tender ANY> Tender Amount CDATA #IMPLIED> Tender Type CDATA #IMPLIED> Tender SerialNumber CDATA #IMPLIED>
<!ELEMENT Response ( Product?, Tender?, MerchandiseItem?, MerchandiseIssuer?, QuantityItem* )> <!ATTLIST Response TransactionSeqNo CDATA #IMPLIED> <!ATTLIST Response ResponseCode CDATA #IMPLIED> <!ATTLIST Response ResponseMessage CDATA #IMPLIED> <!ELEMENT <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST MerchandiseItem MerchandiseItem MerchandiseItem MerchandiseItem MerchandiseItem MerchandiseItem MerchandiseItem MerchandiseItem MerchandiseItem MerchandiseItem MerchandiseItem (Token*, MerchandiseIssuer?)> PIN CDATA #IMPLIED> ItemSerialNumber CDATA #IMPLIED> ExpiryDate CDATA #IMPLIED> Amount CDATA #IMPLIED> TaxAmount CDATA #IMPLIED> NetworkName CDATA #IMPLIED> ProductName CDATA #IMPLIED> ItemMessage CDATA #IMPLIED> DescriptiveValue CDATA #IMPLIED> TariffIndex CDATA #IMPLIED>
<!ELEMENT Token ANY> <!ATTLIST Token Description CDATA #IMPLIED> <!ATTLIST Token Value CDATA #IMPLIED>
Fields
230
<!ELEMENT <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ELEMENT <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST
MerchandiseIssuer MerchandiseIssuer MerchandiseIssuer MerchandiseIssuer MerchandiseIssuer QuantityItem QuantityItem QuantityItem QuantityItem QuantityItem QuantityItem
ANY> Name CDATA #IMPLIED> Id CDATA #IMPLIED> ContactNumber CDATA #IMPLIED> RegistrationNumber CDATA #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> CDATA #IMPLIED> #IMPLIED> CDATA #IMPLIED> CDATA #IMPLIED> CDATA #IMPLIED> CDATA #IMPLIED> CDATA #IMPLIED>
ANY> ProductCode CDATA ProductName CDATA Quantity CDATA QuantityDescription ExpiryDate CDATA
<!ELEMENT AdviceRequest ANY> <!ATTLIST AdviceRequest TransactionSeqNo <!ELEMENT ReversalRequest ANY> <!ATTLIST ReversalRequest TransactionSeqNo <!ELEMENT <!ATTLIST <!ATTLIST <!ATTLIST ReversalResponse ANY> ReversalResponse TransactionSeqNo ReversalResponse ResponseCode ReversalResponse ResponseMessage
5.3.7
PurchasingCardData
The fields described below are used to send PurchasingCardData information. The key value of this structure is "PurchasingCardData", and the top level element is "PurchasingCardData". This DTD contains invoice data, including line item detail. Invoice data relating to the transaction as a whole is known as level 2 data and line item detail is known as level 3 data. This is required for purchases made with purchasing cards, which are typically issued to company employees for the purpose of covering business-related expenditure. However, invoice data can be useful for any purchase transaction. This DTD is to be used in 0100/0120/0200/0220/0400/0420 messages with transaction type 00 (Goods and services) or 09 (Goods and services with cash back).
CustomerCode
Attribute
Optional
ans..20
A code identifying the customer, supplied by the cardholder to the card acceptor. The merchants national tax number. The card acceptors VAT number, used to identify the card acceptor when reporting taxes. A reference number supplied by the card acceptor to facilitate communication and record keeping. The merchants VAT number. The customers VAT number, used to identify the customer when reporting taxes. The merchants purchase order number. A unique invoice number associated with this transaction, supplied by the card acceptor.
CardAcceptorTaxId CardAcceptorVatNr
Attribute Attribute
Optional Optional
ans..20 ans..20
CardAcceptorRefNr
Attribute
Optional
ans..20
CorporationVatNr CustomerVatNr
Attribute Attribute
Optional Optional
ans..20 ans..20
MerchantOrderNumber InvoiceNumber
Attribute Attribute
Optional Optional
ans..25 ans..20
Fields
231
Field
Condition
Format
Description
OrderDate PurchaseDate CustomerBillingCode PurchaseOrderNumber TaxExempt
Attribute Attribute Attribute Attribute Attribute
Optional Optional Optional Optional Optional
YYYYMMDD YYYYMMDD ans..20 ans..22 a..5
The date when the order was placed. The date of the purchase/invoice. A customer code supplied by the merchant. The customers purchase order number. Indicates whether the purchaser is tax exempt. Valid values: Y Yes N No TRUE FALSE
CommodityCode
Attribute
Optional
ans..20
A code assigned by the card acceptor, which best categorizes the goods/services purchased. A description of this purchase transaction. The discount amount (in the minor denomination) of the total purchase. The freight/shipping/delivery amount (in the minor denomination) to be paid on the total purchase. The duty amount (in the minor denomination) to be paid on the total purchase. Indicates whether tax was collected. Valid values: Y Yes N No TRUE FALSE
Description DiscountAmount
Attribute Attribute
Optional Optional
ans..40 n12
ShippingAmount
Attribute
Optional
n12
DutyAmount
Attribute
Optional
n12
TaxCollected
Attribute
Optional
a..5
TotalAmount
Attribute
Optional
n12
The total amount (in the minor denomination) of this purchase transaction. A comment/note regarding this purchase transaction. Any data proprietary to the system for this purchase. A list of the items purchased.
Comment
Attribute
Optional
ans..40
PrivateData
Attribute
Optional
ans..999
LineItem
Element
Zero or more Optional n3
ItemNumber
Attribute
The line number of this item on the invoice.
Fields
232
Field
Condition
Format
Description
ProductCode
Attribute
Optional
ans..20
The universal product code (UPC) of this item. A customer-supplied code relating to this item. A merchant-supplied code or stock keeping unit (SKU) relating to this item. The reference number used to identify the VAT invoice or tax receipt. A description of this item. The quantity of this item. Indicates the number of places the decimal point shall be moved to the left, starting from the rightmost numeric digit of the Quantity value. If this field is not present, zero is assumed. The unit of measure pertaining to the Quantity field, as defined by the card acceptor. The price (in the minor denomination) of one unit of the product. Indicates whether a discount is given for this item. Valid values: Y Yes N No TRUE FALSE
CustomerCode
Attribute
Optional
ans..20
CommodityCode
Attribute
Optional
ans..20
VatReferenceNr
Attribute
Optional
ans..20
Description Quantity QuantityExponent
ans..40 n..12 n1
UnitOfMeasure
Attribute
Optional
ans..12
UnitPrice
Attribute
Optional
n..12
Discount
Attribute
Optional
a..5
DiscountRate
Attribute
Optional
ans5
The discount rate applied to this item. Three decimal places are implied. The discount amount (in the minor denomination) applied to this item. The total amount (in the minor denomination) for this item. Indicates whether tax is included in or excluded from the TotalAmount field. Valid values: NET Tax amount excluded GROSS Tax amount included
DiscountAmount
Attribute
Optional
n12
TotalAmount
Attribute
Optional
n12
TotalAmountType
Attribute
Optional
ans5
Fields
233
Field
Condition
Format
Description
SupplyType
Attribute
Optional
n2
Valid values: 00 Goods 01 Services
Sign
Attribute
Optional
a1
This sign applies to the TotalAmount field of this item and to all the TaxAmount fields of this item. If this field is not present, D is assumed. Valid values: C Credit D Debit
PrivateData
Attribute
Optional
ans..999
Any data proprietary to the system for this item. A list of the tax amounts applied to this item.
TaxAmount
Element
Zero or more Optional ans..6
Type
Attribute
Valid values for the first two characters: 00 Unknown 01 Federal/National sales tax 02 State sales tax 03 City sales tax 04 Local sales tax 05 Municipal tax 06 Other tax 10 Value added tax (VAT) 11 Goods and services tax (GST) 12 Provincial sales tax (PST) 20 Room tax 21 Occupancy tax 22 Energy tax The last 4 digits are optional and can be used to further clarify the type of tax.
Description Included
Attribute Attribute
Optional Optional
ans..20 a..5
A description of the type of tax, e.g. Freight. Indicates whether this tax amount is included in the TotalAmount field of this item. Valid values: Y Yes N No TRUE FALSE
Amount
Attribute
Optional
n12
A tax amount (in the minor denomination)
Fields
234
Field
Condition
Format
Description
applied to this item. Rate Attribute Optional n5 The rate of tax to be applied to calculate this tax amount. The number of decimal places in the Rate field. If this field is not present, zero is assumed. An ID number used by the card acceptor with the tax authority, in connection with this type of tax. A list of the tax amounts applied to this transaction. ans..6 Valid values for the first two characters: 00 Unknown 01 Federal/National sales tax 02 State sales tax 03 City sales tax 04 Local sales tax 05 Municipal sales tax 06 Other tax 10 Value added tax (VAT) 11 Goods and services tax (GST) 12 Provincial sales tax (PST) 20 Room tax 21 Occupancy tax 22 Energy tax The last 4 digits are optional and can be used to further clarify the type of tax. Description Included Attribute Attribute Optional Optional ans..20 a..5 A description of the type of tax, e.g. Freight. Indicates whether this tax amount is included in the TotalAmount field of this purchase. Valid values: Y Yes N No TRUE FALSE Amount Attribute Optional n12 A tax amount (in the minor denomination) applied to this purchase. The rate of tax to be applied to calculate this tax amount.
RateExponent
Attribute
Optional
n1
CardAcceptorTaxId
Attribute
Optional
ans..20
TaxAmount
Element
Zero or more Optional
Type
Attribute
Rate
Attribute
Optional
n5
Fields
235
Field
Condition
Format
Description
RateExponent
Attribute
Optional
n1
The number of decimal places in the Rate field. If this field is not present, zero is assumed. An ID number used by the card acceptor with the tax authority, in connection with this type of tax. Contains details about an authorized person to be contacted for shipping or billing purposes. Valid values: BILL_FROM BILL_TO SHIP_FROM SHIP_TO
CardAcceptorTaxId
Attribute
Optional
ans..20
Contact
Element
Zero or more
Type
Attribute
Mandatory ans..10
PostalCode
Attribute
Optional
ans..10
The postal/ZIP code of the company or authorized person to contact. The name of the company or authorized person to contact. The telephone number of the company or authorized person to contact. The address of the company or authorized person to contact. The city of the company or authorized person to contact. The region/state code of the company or authorized person to contact. The ISO country code of the company or authorized person to contact.
Name
Attribute
Optional
ans..50
Telephone
Attribute
Optional
ans..20
Address
Attribute
Optional
ans..50
City
Attribute
Optional
ans..20
State
Attribute
Optional
ans..20
Country
Attribute
Optional
an3
5.3.7.1.1
<!ELEMENT <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST
PurchasingCardData DTD
PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData (LineItem*, TaxAmount*, Contact*)> CustomerCode CDATA #IMPLIED> CardAcceptorTaxId CDATA #IMPLIED> CardAcceptorVatNr CDATA #IMPLIED> CardAcceptorRefNr CDATA #IMPLIED> CorporationVatNr CDATA #IMPLIED> CustomerVatNr CDATA #IMPLIED> MerchantOrderNumber CDATA #IMPLIED> InvoiceNumber CDATA #IMPLIED> OrderDate CDATA #IMPLIED> PurchaseDate CDATA #IMPLIED> CustomerBillingCode CDATA #IMPLIED> PurchaseOrderNumber CDATA #IMPLIED> TaxExempt CDATA #IMPLIED> CommodityCode CDATA #IMPLIED> Description CDATA #IMPLIED> DiscountAmount CDATA #IMPLIED>
Fields
<!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ELEMENT <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ELEMENT <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ELEMENT <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData PurchasingCardData LineItem LineItem LineItem LineItem LineItem LineItem LineItem LineItem LineItem LineItem LineItem LineItem LineItem LineItem LineItem LineItem LineItem LineItem LineItem ShippingAmount CDATA #IMPLIED> DutyAmount CDATA #IMPLIED> TaxCollected CDATA #IMPLIED> TotalAmount CDATA #IMPLIED> Comment CDATA #IMPLIED> PrivateData CDATA #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED>
236
(TaxAmount*)> ItemNumber CDATA ProductCode CDATA CustomerCode CDATA CommodityCode CDATA VatReferenceNr CDATA Description CDATA Quantity CDATA #IMPLIED> QuantityExponent CDATA UnitOfMeasure CDATA UnitPrice CDATA #IMPLIED> Discount CDATA #IMPLIED> DiscountRate CDATA DiscountAmount CDATA TotalAmount CDATA TotalAmountType CDATA SupplyType CDATA Sign CDATA #IMPLIED> PrivateData CDATA
TaxAmount ANY> TaxAmount Type CDATA #IMPLIED> TaxAmount Description CDATA #IMPLIED> TaxAmount Included CDATA #IMPLIED> TaxAmount Amount CDATA #IMPLIED> TaxAmount Rate CDATA #IMPLIED> TaxAmount RateExponent CDATA #IMPLIED> TaxAmount CardAcceptorTaxId CDATA #IMPLIED> Contact Contact Contact Contact Contact Contact Contact Contact Contact ANY> Type PostalCode Name Telephone Address City State Country CDATA CDATA CDATA CDATA CDATA CDATA CDATA CDATA #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED>
5.3.8
FleetCardData
The fields described below are used to send FleeatCardData information. The key value of this structure is "FleetCardData", and the top level element is "FleetCardData". This DTD is based on the ISO 8583:2003 specification and can be used to report information regarding motor fuel and related purchases involving company-owned fleets of vehicles. It supersedes field 127.5 (Service station data). Field 127.5 can still be used, but using the FleetCardData DTD instead will be encouraged. Transaction Manager will not map values between these structures. Note that the VehicleUsage field will be added to the existing DTD, since this subfield is present in field 127.5. This DTD is to be used in 0100/0120/0200/0220/0400/0420 messages with transaction type 00 (Goods and services) or 09 (Goods and services with cash back).
LineItem
Element
Zero or more Optional n4 The acquirers abbreviation for the brand name of the card acceptors oil company.
OilBrandName
Attribute
Fields
237
Field
Condition
Format
Description
ServiceType
Attribute
Optional
ans1
The type of service received at the card acceptor location. Valid values: 0 Reserved for future Postilion use 1 Self-service 2 Full service 3 Only non-fuel products purchased 4-7 Reserved for future Postilion use 8-9 Reserved for client-specific use
ProductCode
Attribute
Optional
an..15
A code which identifies a specific product as supplied by the card acceptor. The price per unit (in the minor denomination) net of tax. The price per unit (in the minor denomination) inclusive of tax. The unit of measure of the quantity purchased as defined by the card acceptor. The quantity of goods purchased. Indicates the number of places the decimal point shall be moved to the left, starting from the rightmost numeric digit of the Quantity value. Total line amount (in the minor denomination) excluding tax. Total line amount (in the minor denomination) including tax. Valid values: P Private B Business
UnitPriceExTax
Attribute
Optional
n12
UnitPriceIncTax
Attribute
Optional
n12
UnitOfMeasure
Attribute
Optional
ans..12
Quantity QtyMinorUnit
Attribute Attribute
Optional Optional
n..12 n1
ItemValueExTax
Attribute
Optional
n12
ItemValueIncTax
Attribute
Optional
n12
VehicleUsage
Attribute
Optional
a1
Odometer
Attribute
Optional
n8
The reading of the total distance traveled by the vehicle. The registration number of the rented or fleet vehicle. The number assigned to the driver by the employer for purposes of tracking fuel purchases. Contains a code read from a card that indicates terminal prompts that occur at the point-of-service. Valid values: 0 Reserved for future Postilion use 1 Prompts for identification number and odometer
VehicleReg
Attribute
Optional
an17
DriverId
Attribute
Optional
n..17
PromptCode
Attribute
Optional
n1
Fields
238
Field
Condition
Format
Description
reading 2 Prompts for vehicle number and odometer reading 3 Prompts for driver number and odometer reading 4 Prompts for odometer reading only 5 No prompts issued 6-8 Reserved for future Postilion use 9 Reserved for client-specifc use DiscountAmount Attribute Optional n12 The discount amount (in the minor denomination) on the total purchase. The total amount (in the minor denomination) of tax on the transaction. Any data proprietary to the system for this item.
TaxAmount
Attribute
Optional
n12
PrivateData
Attribute
Optional
ans..999
5.3.8.1
<!ELEMENT <!ELEMENT <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST <!ATTLIST
FleetCardData DTD
FleetCardData (LineItem*)> LineItem ANY> LineItem OilBrandName CDATA LineItem ServiceType CDATA LineItem ProductCode CDATA LineItem UnitPriceExTax CDATA LineItem UnitPriceIncTax CDATA LineItem UnitOfMeasure CDATA LineItem Quantity CDATA #IMPLIED> LineItem QtyMinorUnit CDATA LineItem ItemValueExTax CDATA LineItem ItemValueIncTax CDATA LineItem VehicleUsage CDATA LineItem Odometer CDATA #IMPLIED> LineItem VehicleReg CDATA LineItem DriverId CDATA #IMPLIED> LineItem PromptCode CDATA LineItem DiscountAmount CDATA LineItem TaxAmount CDATA #IMPLIED> LineItem PrivateData CDATA #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED> #IMPLIED>
5.3.9
CheckData
The fields described below are used to send CheckData information. The key value of this structure is "CheckCardData", and the top level element is "CheckData". Our current field 127.7 (Check data) format is identical to the format specified by the STAR network in the US . The eFunds and NYCE networks have similar formats. The current format has the following shortcomings: It has no field for the check type. It has no fields for the generic ID and ID type. It has no field to indicate that the ID was cross-checked with a second ID. When MICR information is present, customer identification information cannot be present as well.
Fields
239 Therefore a new CheckData DTD to be used with field 127.22 (Structured data) has been defined. Field 127.7 can still be used, but using the CheckData DTD instead will be encouraged. Transaction Manager will not map values between these structures. PostCheck is a new Postilion product. It performs the role of a sink node authorizer for Transaction Manager and is therefore similar to PostCard in that sense. See the PostCheck Requirements and Functional Specifications for more information about PostCheck. This DTD contains all the information needed by PostCheck, but it is not PostCheck-specific. It can be used to pass check data through Transaction Manager even if PostCheck is not involved. Note that the DateOfBirth field will be added to the existing DTD, since this subfield is present in field 127.7. This DTD is to be used in 0100/0120/0200/0220/0400/0420 messages with transaction type 03 (Check cash/guarantee) or 04 (Check verification).
CheckType
Element
Optional
a1
The check type (typically entered manually). Valid values: P Personal L Payroll B Business G Government K Bank
CheckIDCard
Element
Optional
a1
Indicates whether the info in fields 2, 14, 23, 40 and 35 pertain to a check ID card or not. Valid values: Y Yes N No T True F False If not present, N is assumed.
IDCrossChecked
Element
Optional
a1
Indicates whether the original ID produced by the customer was cross checked with a second ID. Valid values: Y Yes N No T True F False If not present, N is assumed.
SupervisorID FormattedMICR CheckNr
Element Element Element
Optional Optional
ans..24
The ID of the supervisor.
Mandatory n..6
The check number (from the MICR data).
Fields
240
Field
Condition
Format
Description
TransitNr
Element
Mandatory n..8
The code of the institution that issued the check (from the MICR data). In the US this is the ABA number, also called the routingand-transit number. The check digit of the institution code (from the MICR data). The account number (from the MICR data). The MICR data as present on the check, including the separator characters.
TransitNrCheckDigit
Element
Optional
n1
AccountNr UnformattedMICR
Element Element
Mandatory n..28 Optional ans..65
DriversLicense DriversLicenseNr StateCode
Optional Mandatory ans..24 Optional ans2 The driver's license number. Driver's license numbers are unique per region code. In the US , driver's licenses are issued by states, so this will be the state code. The date of birth of the driver.
DateOfBirth GenericID IDNr IDType
Element Element Element Element
Optional Optional
YYYYMMDD
Mandatory ans..24 Mandatory ans2
The ID number of the customer. The ID type. Valid values: PP Passport ID Identity document SS Social security number NI National insurance number
5.3.9.1
CheckData DTD
CheckData - DTD <!ELEMENT CheckData ( CheckType?, CheckIDCard?, IDCrossChecked?, SupervisorID?, FormattedMICR?, UnformattedMICR?, DriversLicense?, GenericID? )> <!ELEMENT CheckType (#PCDATA)> <!ELEMENT CheckIDCard (#PCDATA)> <!ELEMENT IDCrossChecked (#PCDATA)> <!ELEMENT SupervisorID (#PCDATA)> <!ELEMENT FormattedMICR (CheckNr, TransitNr, TransitNrCheckDigit?, AccountNr)> <!ELEMENT CheckNr (#PCDATA)> <!ELEMENT TransitNr (#PCDATA)> <!ELEMENT TransitNrCheckDigit (#PCDATA)> <!ELEMENT AccountNr (#PCDATA)> <!ELEMENT UnformattedMICR (#PCDATA)>
Fields
<!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT DriversLicense (DriversLicenseNr, StateCode?, DateOfBirth?)> DriversLicenseNr (#PCDATA)> StateCode (#PCDATA)> DateOfBirth (#PCDATA)> GenericID (IDNr, IDType)> IDNr (#PCDATA)> IDType (#PCDATA)>
241
5.3.10
AirlineItineraryData
The fields described below are used to send AirlineItineraryData information. The key value of this structure is "AirlineItineraryData", and the top level element is "AirlineItineraryData". This DTD is based on the ISO 8583:2003 specification and can be used when card issuers need to provide travel reporting services to cardholders and their employers. This DTD is to be used in 0100/0120/0200/0220/0400/0420 messages with transaction type 00 (Goods and services) or 09 (Goods and services with cash back).
CarrierName
Element
Optional
an..19
The name of the airline carrier as defined by ATPCO (Airline Tariff Publishing Company). The ticket number as supplied by the airline. The plan number as supplied by the airline. The invoice number as supplied by the airline. The name of the airline passenger. A cardholder supplied reference number. The code of the travel agency which sold the airline ticket as defined by ATPCO. The name of the ticket agency which sold the airline ticket. The address at which the airline ticket was issued. The date on which the airline ticket was issued. The total airline ticket amount (in the minor denomination). The total fees (in the minor denomination) associated with an airline ticket. The total taxes (in the minor denomination) associated with an airline ticket.
TicketNr
Element
Optional
an..15
PlanNr
Element
Optional
an2
InvoiceNr
Element
Optional
an6
PassengerName CustomerRef
Element Element
Optional Optional
ans..29 ans.. 20
TravelAgencyCode
Element
Optional
an8
TicketAgencyName
Element
Optional
an..25
TicketIssueAddress
Element
Optional
ans..16
DateTicketIssue
Element
Optional
YYYYMMDD
AmountTotalFare
Element
Optional
n12
AmountTotalFees
Element
Optional
n12
AmountTotalTaxes
Element
Optional
n12
Fields
242
Field
Condition
Format
Description
AmountOriginalInvoice
Element
Optional
n12
The amount (in the minor denomination) of the original invoice. Used to identify the original amount on a refund transaction. The currency code of the original transaction. Used to identify the original currency in a refund transaction.
OriginalCurrencyCode
Element
Optional
n3
Leg
Element
Zero or more Mandatory n2 The number of this leg of the airline journey of a multi-flight booking. The code of the airline carrier as defined by ATPCO. The number assigned to this trip leg by the operating or marketing air carrier. The airport from which this trip leg departs as defined by ATPCO. The code of the stop-over airport during an airline journey as defined by ATPCO. The code of the destination airport as defined by ATPCO. The date of departure of the trip leg. The time of departure for this trip leg. Indicates whether the departure time is in the morning or the afternoon/evening. Valid values: A a.m. P p.m.
Nr
Element
CarrierCode
Element
Optional
an2
FlightNr
Element
Optional
ans5
DepartureAirport
Element
Optional
an5
StopOverCode
Element
Optional
an1
DestinationCode
Element
Optional
an5
DateOfTravel DepartureTime DepartureTimeSegmentCode
YYYYMMDD HHMM as1
ArrivalTime ArrivalTimeSegmentCode
Element Element
Optional Optional
HHMM as1
The time of arrival for this trip leg. Indicates whether the arrival time is in the morning or the afternoon/evening. Valid values: A a.m. P p.m.
ClassOfTravel
Element
Optional
an2
The class of the airline journey as defined by ATPCO.
Fields
243
Field
Condition
Format
Description
CouponNr
Element
Optional
ans1
Identifies the coupon associated with this trip leg. The ticket that contains additional coupons on an itinerary that is more than four trip legs. A conjunction ticket is a ticket where all destinations are included on a single ticket.
ConjunctionTicketNr
Element
Optional
an..15
ExchangeTicketNr
Element
Optional
an..15
The original airline ticket number replaced by a new ticket number. The basis for the calculation of the airline fare as defined by ATPCO. The trip leg airline ticket amount (in the minor denomination). The fees (in the minor denomination) associated with this trip leg. The total tax amount (in the minor denomination) associated with this trip leg. The tax amount (in the minor denomination) payable by the airline passenger on departure. Any agency-added or government required notations, or restrictions such as non-refundable, that are applicable to this trip leg.
FareBasisCode
Element
Optional
an..15
AmountFare
Element
Optional
n12
AmountFees
Element
Optional
n12
AmountTaxes
Element
Optional
n12
AmountDepartureTax
Element
Optional
n12
EndorsementsOrRestrictions
Element
Optional
ans..20
5.3.10.1
AirlineItenararyData DTD
<!ELEMENT AirlineItineraryData ( CarrierName?, TicketNr?, PlanNr?, InvoiceNr?, PassengerName?, CustomerRef?, TravelAgencyCode?, TicketAgencyName?, TicketIssueAddress?, DateTicketIssue?, AmountTotalFare?, AmountTotalFees?, AmountTotalTaxes?, AmountOriginalInvoice?, OriginalCurrencyCode?, Leg* )> <!ELEMENT CarrierName (#PCDATA)> <!ELEMENT TicketNr (#PCDATA)> <!ELEMENT PlanNr (#PCDATA)> <!ELEMENT InvoiceNr (#PCDATA)> <!ELEMENT PassengerName (#PCDATA)> <!ELEMENT CustomerRef (#PCDATA)>
Fields
<!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT TravelAgencyCode (#PCDATA)> TicketAgencyName (#PCDATA)> TicketIssueAddress (#PCDATA)> DateTicketIssue (#PCDATA)> AmountTotalFare (#PCDATA)> AmountTotalFees (#PCDATA)> AmountTotalTaxes (#PCDATA)> AmountOriginalInvoice (#PCDATA)> OriginalCurrencyCode (#PCDATA)> Leg ( Nr, CarrierCode?, FlightNr?, DepartureAirport?, StopOverCode?, DestinationCode?, DateOfTravel?, DepartureTime?, DepartureTimeSegmentCode?, ArrivalTime?, ArrivalTimeSegmentCode?, ClassOfTravel?, CouponNr?, ConjunctionTicketNr?, ExchangeTicketNr?, FareBasisCode?, AmountFare?, AmountFees?, AmountTaxes?, AmountDepartureTax?, EndorsementsOrRestrictions? Nr (#PCDATA)> CarrierCode (#PCDATA)> FlightNr (#PCDATA)> DepartureAirport (#PCDATA)> StopOverCode (#PCDATA)> DestinationCode (#PCDATA)> DateOfTravel (#PCDATA)> DepartureTime (#PCDATA)> DepartureTimeSegmentCode (#PCDATA)> ArrivalTime (#PCDATA)> ArrivalTimeSegmentCode (#PCDATA)> ClassOfTravel (#PCDATA)> CouponNr (#PCDATA)> ConjunctionTicketNr (#PCDATA)> ExchangeTicketNr (#PCDATA)> FareBasisCode (#PCDATA)> AmountFare (#PCDATA)> AmountFees (#PCDATA)> AmountTaxes (#PCDATA)> AmountDepartureTax (#PCDATA)> EndorsementsOrRestrictions (#PCDATA)>
244
)> <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT
5.3.11
VehicleRentalData
The fields described below are used to send VehicleRentalData information. The key value of this structure is "VehicleRentalData", and the top level element is "VehicleRentalData". This DTD is based on the ISO 8583:2003 specification and can be used to provide vehicle rental reporting services to cardholders and their employers. This DTD is to be used in 0100/0120/0200/0220/0400/0420 messages with transaction type 00 (Goods and services) or 09 (Goods and services with cash back).
Fields
245
Field
Condition
Format
Description
RentalAgreementRef
Element
Optional
ans..25
The reference number on the vehicle rental agreement form. The name of the person making the vehicle rental agreement. The agency code, phone number or other abbreviation used to identify the location from which the vehicle was rented. The address from where the vehicle was rented. The city in which the vehicle was rented. The state or province within the country in which the vehicle was rented. The country in which the vehicle was rented. The date from which the vehicle rental starts. The time from which the vehicle rental starts. The classification defined by the acquirer of the vehicle rented, e.g. midsize, luxury. The rental rate (in the minor denomination) charged for the vehicle. Indicates the time period to which the RentalRate value applies. Valid values: D Daily W Weekly M Monthly
RenterName
Element
Optional
ans..29
RentalLocationID
Element
Optional
ans10
RentalAddress
Element
Optional
ans..26
RentalCity
Element
Optional
ans..18
RentalStateOrRegion
Element
Optional
ans3
RentalCountry
Element
Optional
ans3
RentalDate
Element
Optional
YYYYMMDD
RentalTime
Element
Optional
HHMM
RentalClassIdentifier
Element
Optional
ans4
RentalRate
Element
Optional
n12
RentalRateTimePeriod
Element
Optional
as1
MaximumFreeMilesOrKms
Element
Optional
n4
The number of free miles or kilometers allowed to a customer for the duration of the vehicle rental agreement. Indicates whether the customer purchased vehicle insurance as part of the vehicle rental agreement. Valid values: Y Yes
VehicleInsuranceIndicator
Element
Optional
as1
Fields
246
Field
Condition
Format
Description
N No AmountVehicleInsurance Element Optional n12 The amount (in the minor denomination) of vehicle insurance purchased as part of the vehicle rental agreement. The registration number of the rented or fleet vehicle. The reading of the total distance traveled by the vehicle. The agency code, phone number or other abbreviation used to identify the location to which the vehicle was/will be returned. The address to which the vehicle was/will be returned. The city to which the vehicle was/will be returned. The state or province within the country to which the vehicle was/will be returned. The country to which the vehicle was/will be returned. The date on which the vehicle was/will be returned. The time by which the vehicle was/will be returned. The distance traveled during the rental period. The unit of measure of distance traveled. Valid values: K Kilometers M Miles AmountAdjusted Element Optional n12 The amount (in the minor denomination) of miscellaneous charges incurred after the vehicle was rented, e.g. extra hours. Indicates the type of charges provided in AmountAdjusted. Valid values: A Drop-off charges B Delivery charges
VehicleRegistrationNr
Element
Optional
an17
OdometerReading
Element
Optional
n8
ReturnLocationID
Element
Optional
ans10
ReturnAddress
Element
Optional
ans..26
ReturnCity
Element
Optional
ans..18
ReturnStateOrRegion
Element
Optional
ans3
ReturnCountry
Element
Optional
ans3
ReturnDate
Element
Optional
YYYYMMDD
ReturnTime
Element
Optional
HHMM
RentalDistance
Element
Optional
n5
DistanceUnitOfMeasure
Element
Optional
a1
AmountAdjustedIndicatorCode
Element
Optional
as1
Fields
247
Field
Condition
Format
Description
C Parking expenses D Extra hours E Violations F-W Reserved for future Postilion use X Multiple charges of the above types Y-Z Reserved for client-specific use ProgramCode Element Optional ans2 A code allocated by the acquirer that identifies special circumstances, e.g. frequent customer or no show.
CustomerServicePhoneNr
Element
Optional
ans16
The customer service number that the cardholder may call to resolve questions or disputes.
5.3.11.1
VechicleRentalData DTD
<!ELEMENT VehicleRentalData ( RentalAgreementRef?, RenterName?, RentalLocationID?, RentalAddress?, RentalCity?, RentalStateOrRegion?, RentalCountry?, RentalDate?, RentalTime?, RentalClassIdentifier?, RentalRate?, RentalRateTimePeriod?, MaximumFreeMilesOrKms?, VehicleInsuranceIndicator?, AmountVehicleInsurance?, VehicleRegistrationNr?, OdometerReading?, ReturnLocationID?, ReturnAddress?, ReturnCity?, ReturnStateOrRegion?, ReturnCountry?, ReturnDate?, ReturnTime?, RentalDistance?, DistanceUnitOfMeasure?, AmountAdjusted?, AmountAdjustedIndicatorCode?, ProgramCode?, CustomerServicePhoneNr? )> <!ELEMENT RentalAgreementRef (#PCDATA)> <!ELEMENT RenterName (#PCDATA)> <!ELEMENT RentalLocationID (#PCDATA)> <!ELEMENT RentalAddress (#PCDATA)> <!ELEMENT RentalCity (#PCDATA)> <!ELEMENT RentalStateOrRegion (#PCDATA)> <!ELEMENT RentalCountry (#PCDATA)> <!ELEMENT RentalDate (#PCDATA)>
Fields
<!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT RentalTime (#PCDATA)> RentalClassIdentifier (#PCDATA)> RentalRate (#PCDATA)> RentalRateTimePeriod (#PCDATA)> MaximumFreeMilesOrKms (#PCDATA)> VehicleInsuranceIndicator (#PCDATA)> AmountVehicleInsurance (#PCDATA)> VehicleRegistrationNr (#PCDATA)> OdometerReading (#PCDATA)> ReturnLocationID (#PCDATA)> ReturnAddress (#PCDATA)> ReturnCity (#PCDATA)> ReturnStateOrRegion (#PCDATA)> ReturnCountry (#PCDATA)> ReturnDate (#PCDATA)> ReturnTime (#PCDATA)> RentalDistance (#PCDATA)> DistanceUnitOfMeasure (#PCDATA)> AmountAdjusted (#PCDATA)> AmountAdjustedIndicatorCode (#PCDATA)> ProgramCode (#PCDATA)> CustomerServicePhoneNr (#PCDATA)>
248
5.3.12
LodgingData
The fields described below are used to send LodgingData information. The key value of this structure is "LodgingData", and the top level element is "LodgingData". This DTD is based on the ISO 8583:2003 specification and can be used to report information regarding lodging (hotel, motel, etc.) transactions. This DTD is to be used in 0100/0120/0200/0220/0400/0420 messages with transaction type 00 (Goods and services) or 09 (Goods and services with cash back).
FolioNr
Element
Optional
ans10
The lodging facilitys internal invoice or billing identification reference number. The local phone number of the lodging facility at which the cardholder stayed. The date on which the cardholder checked into the lodging facility. The date on which the cardholder checked out of the lodging facility. The daily room charges (in the minor denomination), exclusive of taxes and fees. The daily room tax amount (in the minor denomination). The total amount (in the minor denomination) of phone calls charged to the room. The total amount (in the minor denomination) of restaurant and/or room service food charged to the room.
FacilityPhoneNr
Element
Optional
ans16
DateArrival
Element
Optional
YYYYMMDD
DateDeparture
Element
Optional
YYYYMMDD
AmountRoomRate
Element
Optional
n12
AmountRoomTax
Element
Optional
n12
AmountPhoneCharges
Element
Optional
n12
AmountRestaurantAndRoomService Element
Optional
n12
Fields
249
Field
Condition Format
Description
AmountBarAndMinibar
Element
Optional
n12
The total amount (in the minor denomination) of bar and in-room mini-bar items charged to the room. The total amount (in the minor denomination) of laundry and dry cleaning items charged to the room. The total amount (in the minor denomination) of gift shop and speciality shop items charged to the room. The total amount (in the minor denomination) of miscellaneous items/services charged to the room, not specified elsewhere. Indicates the type of charges provided in AmountOtherServices. Values are provided by the acquirer. The amount (in the minor denomination) of any additional charges incurred after the cardholders departure from the lodging facility. A code allocated by the acquirer that identifies special circumstances, e.g. frequent customer or no show. The customer service number that the cardholder may call to resolve questions or disputes.
AmountLaundryAndDryCleaning
Element
Optional
n12
AmountGiftShop
Element
Optional
n12
AmountOtherServices
Element
Optional
n12
AmountOtherServicesIndicator
Element
Optional
ans3
AmountBillingAdjustment
Element
Optional
n12
ProgramCode
Element
Optional
ans2
CustomerServicePhoneNr
Element
Optional
ans16
5.3.12.1
LodgingData DTD
<!ELEMENT LodgingData ( FolioNr?, FacilityPhoneNr?, DateArrival?, DateDeparture?, AmountRoomRate?, AmountRoomTax?, AmountPhoneCharges?, AmountRestaurantAndRoomService?, AmountBarAndMinibar?, AmountLaundryAndDryCleaning?, AmountGiftShop?, AmountOtherServices?, AmountOtherServicesIndicator?, AmountBillingAdjustment?, ProgramCode?, CustomerServicePhoneNr? )> <!ELEMENT FolioNr (#PCDATA)> <!ELEMENT FacilityPhoneNr (#PCDATA)> <!ELEMENT DateArrival (#PCDATA)> <!ELEMENT DateDeparture (#PCDATA)> <!ELEMENT AmountRoomRate (#PCDATA)>
Fields
<!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT AmountRoomTax (#PCDATA)> AmountPhoneCharges (#PCDATA)> AmountRestaurantAndRoomService (#PCDATA)> AmountBarAndMinibar (#PCDATA)> AmountLaundryAndDryCleaning (#PCDATA)> AmountGiftShop (#PCDATA)> AmountOtherServices (#PCDATA)> AmountOtherServicesIndicator (#PCDATA)> AmountBillingAdjustment (#PCDATA)> ProgramCode (#PCDATA)> CustomerServicePhoneNr (#PCDATA)>
250

If Postbridge

Uploaded by

Copyright:

Available Formats

If Postbridge

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

If Postbridge

Uploaded by

Copyright:

Available Formats

PostBridge Interface Specification Version 8

Document status: Copyright:

Final Postilion International Limited

PostBridge Interface Specification Version 8

MAC KEY MANAGEMENT .........................................................................................................3

Message Flows...........................................................................................................................11 3.1

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

Dynamic Key Exchange

PostBridge Interface Specification Version 8

MAC Key Management

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

Bitmap Message Format

Message type identifier

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

Compose Message to PostBridge

Unpack a Message from PostBridge

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

XML Message Format

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

Message Type ID Description

0320/0321 0332 0400/0401

PostBridge Interface Specification Version 8

Messages from PostBridge

Message Type ID Description

Network Management request response Sent in response to a network management request.

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

Financial transactions singe message pair

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

Below Floor Limits

Financial transactions dual message pair

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

PostBridge Interface Specification Version 8

Acquirer Batch-cutover Normal Condition

Acquirer Batch-cutover Lost Request

PostBridge Interface Specification Version 8

Acquirer Batch-cutover Lost Reply

Acquirer Batch-cutover Postilion Down

PostBridge Interface Specification Version 8

Issuer Batch-cutover Normal Condition

PostBridge Interface Specification Version 8

Issuer Batch-cutover Lost Request

Issuer Batch-cutover Lost Reply

PostBridge Interface Specification Version 8

Issuer Batch-cutover Acquirer Down