Cardpaymentsmessageusageguide 8.0

1 CAPE
2 Card Payments Acquirer

3 Message Usage Guide
4 Version 8.0
5 Novembre 2019
1 © 2018 nexo-standards AISBL All rights reserved.

This information is protected by international intellectual property laws and its use is governed by the applicable End-User
license
Card Payment Message Usage Guide Version 8.0
6 TABLE OF CONTENTS
7 1 Introduction.............................................................................................................12
8 1.1 Purpose and Use of this Guide...................................................................................12
9 1.2 Intended Audience.....................................................................................................12
10 1.3 Scope of the Document..............................................................................................12
11 1.4 Messages Covered in this Guide................................................................................12
12 1.5 How this Guide was created.......................................................................................14
13 1.6 nexo and ISO 20022..................................................................................................14
14 1.7 ISO 20022 Intellectual Property Rights Policy............................................................15
15 1.8 Message Transport....................................................................................................15
16 1.9 Security...................................................................................................................... 15
17 1.10 Coding...................................................................................................................... 15
18 1.11 Related Documents and Guides...............................................................................15
19 1.12 Conventions.............................................................................................................16
20 1.13 What’s new in the edition 8.......................................................................................16
21 2 Message Exchange and Processes......................................................................17
22 2.1 Card Payment............................................................................................................ 17
23 2.1.1 Authorisation...................................................................................................................... 17
24 2.1.2 Completion........................................................................................................................ 17
25 2.1.3 Financial capture............................................................................................................... 18
26 2.1.4 Batch................................................................................................................................. 18
27 2.1.5 Dynamic Currency Conversion..........................................................................................18
28 2.2 Scope of Card Payments............................................................................................20
29 2.3 Types of environments...............................................................................................21
30 2.3.1 Online only......................................................................................................................... 21
31 2.3.1.1 Financial capture made during the authorisation exchange.......................................................21
32 2.3.1.2 Financial capture made during the completion exchange..........................................................23
33 2.3.2 Semi-online authorisations................................................................................................25
34 2.3.2.1 Capture of offline and online transactions during completion.....................................................25
35 2.3.2.2 Capture during authorisation for online transactions and during completion for offline
36 authorisations......................................................................................................................................... 26
37 2.3.3 Offline only......................................................................................................................... 27
38 2.3.4 Capture by Batch............................................................................................................... 28
39 2.3.4.1 Authorisation through an authorisation exchange without completion with capture in batch......28
40 2.3.4.2 Authorisation through authorisation and completion exchanges with capture in batch..............29
41 2.3.4.3 Offline authorisation with capture in batch..................................................................................30
42 2.3.4.4 Capture of unsuccessful transactions in batch...........................................................................31
43 2.3.5 Batch of Authorisations...................................................................................................... 32
44 2.4 Cancellation...............................................................................................................33
45 2.4.1 Cancellation through cancellation advice or batch.............................................................34
46 2.4.2 Cancellation through cancellation request and advice exchanges....................................38
47 2.4.3 Cancellation declined by the Acquirer................................................................................40
48 2.4.4 Error in Cancellation Message Exchanges........................................................................41
49 2.4.4.1 Cancellation declined after timeout of a cancellation request.....................................................41
50 2.4.4.2 Cancellation successful after timeout of a completion advice...................................................42
51 2.4.4.3 Cancellation declined after timeout of a completion advice........................................................44
-2-
52 2.4.4.4 Cancellation declined after timeout.............................................................................................46

53 2.4.4.5 Cancellation successful after completion errors.........................................................................48
54 2.4.4.6 Cancellation in batch mode.......................................................................................................49
55 2.4.4.7 Declined cancellation in batch mode..........................................................................................51
56 2.4.4.8 Declined cancellation after timeout in batch mode and cancellation request.............................53
57 2.4.4.9 Declined cancellation in batch mode after timeout in cancellation request................................55
58 2.4.4.10 Cancellation in batch mode of a transaction captured but not yet cleared...............................57
59 2.5 Batch.......................................................................................................................... 59
60 2.5.1 Introduction........................................................................................................................ 59
61 2.5.2 Data Organisation.............................................................................................................. 60
62 2.5.2.1 AcceptorBatchTransfer...............................................................................................................60
63 2.5.2.2 AcceptorBatchTransferResponse...............................................................................................60
64 2.5.2.3 Data Factorisation....................................................................................................................... 61
65 2.5.2.4 Multiplicity................................................................................................................................... 62
66 2.5.3 Types of Batch Transfer.................................................................................................... 62
67 2.5.3.1 Batch containing Completion and Cancellation Transactions.....................................................62
68 2.5.3.2 Batch containing Authorisation Transactions..............................................................................63
69 2.5.4 Configuration..................................................................................................................... 65
70 2.6 Reconciliation Process...............................................................................................66
71 2.6.1 Introduction........................................................................................................................ 66
72 2.6.2 Reconciliation Period Identification....................................................................................67
73 2.6.3 Transaction Totals............................................................................................................ 69
74 2.6.4 Reconciliation Exchange................................................................................................... 71
75 2.6.5 Configuration..................................................................................................................... 72
76 2.7 Diagnostic Messages.................................................................................................73
77 2.8 Reject Message..........................................................................................................75
78 3 Message Functionalities........................................................................................78
79 3.1 Message Organisation................................................................................................78
80 3.1.1 Management of the message............................................................................................ 78
81 3.1.1.1 Management information............................................................................................................79
82 3.1.1.2 Parties involved in the message.................................................................................................80
83 3.1.1.3 Traceability information...............................................................................................................81
84 3.1.2 ApplicationData................................................................................................................. 82
85 3.1.2.1 Environment................................................................................................................................ 83
86 3.1.2.2 Context....................................................................................................................................... 84
87 3.1.2.3 Transaction................................................................................................................................. 84
88 3.1.3 SecurityTrailer................................................................................................................... 85
89 3.2 Traceability.................................................................................................................86
90 3.2.1 Security level..................................................................................................................... 86
91 3.2.2 Usage Condition................................................................................................................ 86
92 3.2.3 Traceability in an exchange...............................................................................................86
93 3.3 Message Retransmission...........................................................................................88
94 3.3.1 Acceptor Behaviour........................................................................................................... 88
95 3.3.1.1 Late Responses to an Advice message.....................................................................................89
96 3.3.1.2 Unordered Responses to Retransmitted Advice messages.......................................................90
97 3.3.2 Acquirer Behaviour............................................................................................................ 91
98 3.4 Error Handling............................................................................................................ 92
99 3.4.1 Error Cases....................................................................................................................... 92
100 3.4.1.1 Acceptor is Unable to Send a Message......................................................................................92
101 3.4.1.2 Acquirer Receives an Unacceptable Message...........................................................................93
-3-
102 3.4.1.3 Acquirer is Unable to Process the Message...............................................................................94

103 3.4.1.4 Acquirer is Unable to Send a Message......................................................................................94
104 3.4.1.5 Acceptor has not Received a Response Message.....................................................................95
105 3.4.1.6 Acceptor Receives an Unacceptable Message..........................................................................95
106 3.4.1.7 Acceptor is Unable to Process the Response Message.............................................................96
107 3.4.1.8 Acquirer or Acceptor has received a Duplicate Message...........................................................96
108 3.4.2 Acceptor Error Handling.................................................................................................... 97
109 3.4.2.1 Reverse the Transaction.............................................................................................................98
110 3.4.2.2 Retransmission of the Advice.....................................................................................................98
111 3.4.2.3 Terminate the Exchange in Progress.........................................................................................99
112 3.4.2.4 Ignore the Error........................................................................................................................... 99
113 3.4.3 Acquirer Error Handling................................................................................................... 100
114 3.4.3.1 Message Rejection................................................................................................................... 100
115 3.4.3.2 Retransmission of the Response..............................................................................................101
116 3.4.3.3 Ignore the Error......................................................................................................................... 101
117 4 Messages and Usage..........................................................................................102
118 4.1 Configuration Parameters/ Condition of Presence....................................................102
119 4.2 Authorisation Messages...........................................................................................103
120 4.2.1 AcceptorAuthorisationRequest (caaa.001.001.08)..........................................................103
121 4.2.1.1 Constraints................................................................................................................................ 119
122 4.2.2 AcceptorAuthorisationResponse (caaa.002.001.08).......................................................122
123 4.2.2.1 Constraints................................................................................................................................ 130
124 4.3 Completion Messages..............................................................................................131
125 4.3.1 AcceptorCompletionAdvice (caaa.003.001.08)................................................................131
126 4.3.1.1 Constraints................................................................................................................................ 143
127 4.3.2 AcceptorCompletionAdviceResponse (caaa.004.001.07)................................................145
128 4.3.2.1 Constraints................................................................................................................................ 147
129 4.4 Cancellation Messages............................................................................................149
130 4.4.1 AcceptorCancellationRequest (caaa.005.001.08)...........................................................149
131 4.4.1.1 Constraints................................................................................................................................ 156
132 4.4.2 AcceptorCancellationResponse (caaa.006.001.07).........................................................157
133 4.4.2.1 Constraints................................................................................................................................ 160
134 4.4.3 AcceptorCancellationAdvice (caaa.007.001.08)..............................................................161
135 4.4.3.1 Constraints................................................................................................................................ 168
136 4.4.4 AcceptorCancellationAdviceResponse (caaa.008.001.07)..............................................169
137 4.5 Reconciliation Messages..........................................................................................172
138 4.5.1 AcceptorReconciliationRequest (caaa.009.001.07).........................................................172
139 4.5.1.1 Constraints................................................................................................................................ 175
140 4.5.2 AcceptorReconciliationResponse (caaa.010.001.06)......................................................176
141 4.5.2.1 Constraints................................................................................................................................ 178
142 4.6 Batch........................................................................................................................ 179
143 4.6.1 AcceptorBatchTransfer (caaa.011.001.08).....................................................................179
144 4.6.1.1 Constraints................................................................................................................................ 185
145 4.6.2 AcceptorBatchTransferResponse (caaa.012.001.07)......................................................186
146 4.6.2.1 Constraints................................................................................................................................ 189
147 4.7 Diagnostic Messages...............................................................................................190
148 4.7.1 AcceptorDiagnosticRequest (caaa.013.001.07)..............................................................190
149 4.7.1.1 Constraints................................................................................................................................ 191
150 4.7.2 AcceptorDiagnosticResponse (caaa.014.001.06)............................................................192
151 4.8 Reject Message........................................................................................................194
-4-
152 4.8.1 AcceptorRejection (caaa.015.001.05)..............................................................................194

153 4.9 Dynamic Currency Conversion Messages................................................................195
154 4.9.1 AcceptorCurrencyConversionRequest (caaa.016.001.06)...............................................195
155 4.9.2 AcceptorCurrencyConversionResponse (caaa.017.001.06)............................................202
156 4.9.3 AcceptorCurrencyConversionAdvice (caaa.018.001.03).................................................207
157 4.9.4 AcceptorCurrencyConversionAdviceResponse (caaa.019.001.02).................................212
158 4.10 Common nexo Acquirer message principles..........................................................214
159 4.10.1 CardPaymentToken....................................................................................................... 214
160 4.10.2 TransactionIdentifier...................................................................................................... 215
161 4.10.3 NetworkParameters....................................................................................................... 215
162 4.10.4 PointOfInteractionComponent.......................................................................................216
163 4.10.5 CommunicationAddress.................................................................................................217
164 4.10.6 PostalAddress22........................................................................................................... 217
165 4.10.7 PostalAddress2............................................................................................................. 218
166 4.10.8 PostalAddress1............................................................................................................. 218
167 5 Dynamic of the Payment Exchanges.................................................................219
168 5.1 Introduction............................................................................................................... 219
169 5.2 Determination of Payment Cases.............................................................................219
170 5.2.1 Elements Impacting the Message Flow...........................................................................219
171 5.2.1.1 Authorisation Type.................................................................................................................... 219
172 5.2.1.2 Authorisation Result.................................................................................................................. 220
173 5.2.1.3 Incident after Authorisation.......................................................................................................220
174 5.2.1.4 Merchant Forced Acceptance...................................................................................................221
175 5.2.1.5 Capture Type............................................................................................................................ 221
176 5.2.1.6 Completion Exchange...............................................................................................................222
177 5.2.2 List of Payment Cases..................................................................................................... 223
178 5.3 Table of Payment Cases..........................................................................................227
179 5.4 Cancellation Exchange.............................................................................................233
180 5.4.1 List of Cancellation Cases...............................................................................................234
181 5.4.2 Table of Cancellation Cases............................................................................................ 236
182 6 Additional Payment Services..............................................................................241
183 6.1 Voice Authorisation..................................................................................................241
184 6.2 Deferred Payments..................................................................................................245
185 6.2.1 Introduction...................................................................................................................... 245
186 6.2.2 Constraints on the Protocol.............................................................................................246
187 6.3 Cashback................................................................................................................. 249
188 6.4 Cash Advance..........................................................................................................250
189 6.5 Gratuity..................................................................................................................... 251
190 6.6 Reservation.............................................................................................................. 251
191 6.6.1 Introduction...................................................................................................................... 251
192 6.6.2 Reservation steps............................................................................................................ 252
193 6.6.2.1 Initial Reservation..................................................................................................................... 252
194 6.6.2.2 Update Reservation.................................................................................................................. 252
195 6.6.2.3 Cancellation of the Reservation (before payment)...................................................................252
196 6.6.2.4 Payment for the Reservation....................................................................................................252
197 6.6.2.5 No-Show Payment for the Reservation....................................................................................252
198 6.6.2.6 Additional Payment (after Payment for the Reservation)..........................................................252
199 6.6.2.7 No-show payment without performing a prior reservation service............................................252
-5-
200 6.6.3 Message flows................................................................................................................. 252

201 6.6.4 Description of the steps................................................................................................... 253
202 6.6.4.1 Initial reservation....................................................................................................................... 253
203 6.6.4.2 Update reservation................................................................................................................... 253
204 6.6.4.3 Cancellation of the reservation (before payment).....................................................................254
205 6.6.4.4 Payment after reservation.........................................................................................................254
206 6.6.5 Reservation transaction data........................................................................................... 254
207 6.6.5.1 Initial reservation....................................................................................................................... 254
208 6.6.5.2 Update reservation................................................................................................................... 257
209 6.6.5.3 Cancellation of a Reservation before payment.........................................................................259
210 6.6.5.4 Payment after reservation.........................................................................................................260
211 6.6.5.5 Additional payment................................................................................................................... 262
212 6.6.5.6 No-show payment without prior reservation.............................................................................265
213 6.6.5.7 Batch......................................................................................................................................... 267
214 6.6.5.8 Reconciliation........................................................................................................................... 268
215 6.7 Dynamic Currency Conversion (DCC)......................................................................269
216 6.7.1 Introduction...................................................................................................................... 269
217 6.7.2 Currency conversion during the authorisation.................................................................269
218 6.7.2.1 Transaction eligible for DCC and DCC accepted by the Cardholder........................................271
219 6.7.2.2 Transaction eligible for DCC and partially approved by the Issuer...........................................273
220 6.7.2.3 Transaction not eligible for DCC by the DCC service provider.................................................275
221 6.7.2.4 Transaction not eligible for DCC by the Agent..........................................................................276
222 6.7.2.5 Transaction eligible for DCC but DCC refused by the Cardholder...........................................277
223 6.7.2.6 Transaction eligible for DCC but interrupted due to an incident...............................................279
224 6.7.3 Currency conversion prior to the authorisation................................................................282
225 6.7.3.1 Transaction eligible for DCC and DCC accepted by the Cardholder........................................284
226 6.7.3.2 Transaction eligible for DCC and partially approved by the Issuer...........................................287
227 6.7.3.3 Transaction not eligible for DCC by DCC service provider.......................................................289
228 6.7.3.4 Transaction not eligible for DCC by the Agent..........................................................................291
229 6.7.3.5 Transaction eligible for DCC but DCC refused by the Cardholder...........................................293
230 6.7.3.6 Transaction eligible for DCC but interrupted due to an incident...............................................295
231 6.7.4 Reconciliation Totals........................................................................................................ 299
232 6.8 Aggregation.............................................................................................................. 299
233 6.9 Externally defined Data............................................................................................300
234 6.9.1 Scope.............................................................................................................................. 300
235 6.9.2 Guidance on how to use ExternallyDefinedData.............................................................300
236 6.9.2.1 Private Data.............................................................................................................................. 300
237 6.9.2.2 CardPaymentInvoice................................................................................................................ 300
238 7 Messages Examples............................................................................................302
239 8 Transport Protocols and Services......................................................................303
240 8.1 Protocols Organisation.............................................................................................303
241 8.2 TCP Protocol............................................................................................................ 304
242 8.2.1 Typical Use...................................................................................................................... 304
243 8.2.2 Message Delimitation...................................................................................................... 304
244 8.2.3 Addressing....................................................................................................................... 305
245 8.3 Transport Services...................................................................................................305
246 8.3.1 Message Delimitation...................................................................................................... 305
247 8.3.1.1 Definition................................................................................................................................... 305
248 8.3.1.2 Specifications............................................................................................................................ 305
249 8.3.1.3 Typical Example of Implementation..........................................................................................305
-6-
250 8.3.1.4 Notes........................................................................................................................................ 306

251 8.3.2 Connection and Data Transfer Management...................................................................306
252 8.3.2.1 Connection Services................................................................................................................. 306
253 8.3.2.2 Data Transfer............................................................................................................................ 307
254 8.3.3 Single Message Pair Exchange.......................................................................................308
255 8.3.3.1 Definition................................................................................................................................... 308
256 8.3.3.2 Specifications............................................................................................................................ 308
257 8.3.3.3 Notes........................................................................................................................................ 309
258 8.3.4 Multiple Message Pair Exchange....................................................................................310
259 8.3.4.1 Definition................................................................................................................................... 310
260 8.3.4.2 Specifications............................................................................................................................ 310
261 8.3.4.3 Notes........................................................................................................................................ 311
262 8.3.5 Addressing....................................................................................................................... 312
263 8.3.5.1 Definition................................................................................................................................... 312
264 8.3.5.2 Specifications............................................................................................................................ 312
265 8.3.6 Flow Control.................................................................................................................... 312
266 8.3.6.1 Definition................................................................................................................................... 312
267 8.3.6.2 Specifications............................................................................................................................ 312
268 8.3.7 Error Cases..................................................................................................................... 313
269 8.3.7.1 Unable to Establish a Transport Connection (ERTR01)...........................................................313
270 8.3.7.2 Transport Connection Broken (ERTR02)..................................................................................313
271 8.3.7.3 Unable to Send a Message (ERTR03).....................................................................................314
272 8.3.7.4 Message Too Big (ERTR04).....................................................................................................314
273 8.3.7.5 Late Arrival (ERTR05)..............................................................................................................315
274 8.3.7.6 Max Number of Connections (ERTR06)...................................................................................315
275 8.3.7.7 Incomplete Application Message (ERTR07).............................................................................316
276 8.3.7.8 Other Errors.............................................................................................................................. 316
277 8.3.8 Transport Service Parameters......................................................................................... 317
278 8.3.9 Connection and Data Management State Diagrams.......................................................318
279 8.3.9.1 Recipient Party Diagram...........................................................................................................318
280 8.3.9.2 Initiating Party Diagram............................................................................................................319
-7-
281 Figures
Figure 1: Authorisation with capture (successful transaction)...............................................................23

Figure 2: Authorisation with capture (failed transaction).......................................................................24
Figure 3: Completion with capture (successful transaction)..................................................................25
Figure 4: Completion with capture (failed transaction)..........................................................................26
Figure 5: Capture of offline and online transactions during completion................................................27
Figure 6: Capture during authorisation for online transactions.............................................................28
Figure 7: Capture through completion of previously offline-authorised transactions.............................29
Figure 8: Authorisation through an authorisation exchange without completion with capture in batch. 30
Figure 9: Authorisation through authorisation and completion exchanges with capture in batch..........31
Figure 10: Off-line authorisation with capture in batch..........................................................................32
Figure 11: Capture of unsuccessful transactions in batch....................................................................33
Figure 12: Batch of Authorisations........................................................................................................ 35
Figure 13: Cancellation through cancellation advice or batch...............................................................38
Figure 14: Cancellation through cancellation advice and batch exchanges..........................................40
Figure 15: Cancellation through cancellation request and advice exchanges......................................42
Figure 16: Declined cancellation of a captured transaction..................................................................43
Figure 17: Cancellation declined after timeout of a cancellation request..............................................44
Figure 18: Cancellation successful after timeout of a completion advice..............................................46
Figure 19: Cancellation declined after timeout of a completion advice.................................................48
Figure 20: Cancellation declined after timeout......................................................................................50
Figure 21: Cancellation successful after completion errors..................................................................51
Figure 22: Cancellation in batch mode................................................................................................. 53
Figure 23: Declined cancellation in batch mode...................................................................................55
Figure 24: Declined cancellation after timeout in batch mode and cancellation request.......................57
Figure 25: Declined cancellation in batch mode after timeout cancellation request..............................59
Figure 26: Cancellation in batch mode of a transaction captured but not yet cleared...........................61
Figure 27: BatchTransfer structure....................................................................................................... 63
Figure 28: BatchTransferResponse structure.......................................................................................64
Figure 29: Batch containing Financial Authorisations...........................................................................68
Figure 30: Batch containing Authorisations.......................................................................................... 69
Figure 31: Reconciliation Exchange..................................................................................................... 71
Figure 32: Reconciliation Period Assigned by the Acceptor.................................................................72
Figure 33: Reconciliation Period Assigned by the Acquirer..................................................................73
Figure 34: Reconciliation between the Authorisation and the Completion............................................73
Figure 35: Overlapping of Reconciliation Periods.................................................................................74
Figure 36: Diagnostic Exchange........................................................................................................... 79
Figure 37: Diagnostic Reject................................................................................................................. 80
Figure 38: Diagnostic Request from an Acceptor to an Agent..............................................................80
Figure 39: Diagnostic Request from an Intermediary Agent.................................................................82
Figure 40: Rejection of an Authorisation............................................................................................... 83
-8-
Figure 41: Rejection of an Authorisation to an Agent............................................................................84

Figure 42: Rejection of an Completion to an Agent..............................................................................85
Figure 43: Example of Traceability with an Intermediary Agent............................................................95
Figure 44: Retransmission of an Advice by the Acceptor.....................................................................96
Figure 45: Late Responses to an Advice message...............................................................................97
Figure 46: Unordered Responses to Retransmitted Advice messages.................................................98
Figure 47: Retransmission of an AdviceResponse by the Acquirer......................................................99
Figure 48: Non-Receipt of an Advice by the Acquirer...........................................................................99
Figure 49: Error Cases in Message Exchange...................................................................................101
Figure 50: Acceptor Error Handling in a Message Exchange.............................................................106
Figure 51: Acquirer Error Handling in a Message Exchange..............................................................109
Figure 52: Payment Cases Tree List.................................................................................................. 235
Figure 53: Payment Cases Tree List (Con't).......................................................................................236
Figure 54 Cancellation Cases Tree List.............................................................................................. 248
Figure 55: Successful Voice Authorisation captured with Completion................................................255
Figure 56: Unsuccessful Voice Authorisation captured with Completion............................................255
Figure 57: Successful Voice Authorisation Interleaved with another transaction................................256
Figure 58: Successful Voice Authorisation Captured with Batch without Completion.........................257
Figure 59: Deferred Payment............................................................................................................. 258
Figure 60: Interleaved Deferred Payment Transactions.....................................................................258
Figure 61: Approved Deferred Payment without Delivery...................................................................260
Figure 62: Declined Deferred Payment............................................................................................... 260
Figure 63: Deferred Payment Captured by Completion......................................................................261
Figure 64: Deferred Payment Captured by Batch...............................................................................261
Figure 65: Approved Deferred Payment without Delivery...................................................................262
Figure 66: Currency conversion during the authorisation...................................................................284
Figure 67: Transaction eligible for DCC and DCC accepted by the Cardholder.................................286
Figure 68: Transaction eligible for DCC and partially approved by the Issuer....................................288
Figure 69: Transaction not eligible for DCC by DCC service provider................................................289
Figure 70: Transaction not eligible for DCC by Agent.........................................................................290
Figure 71: Transaction eligible for DCC but DCC refused by cardholder............................................292
Figure 72: : Incident at Agent level..................................................................................................... 293
Figure 73: Incident at DCC service provider level...............................................................................295
Figure 74: Currency conversion before authorisation.........................................................................297
Figure 75: Transaction eligible for DCC and DCC accepted by the Cardholder.................................300
Figure 76: Transaction eligible for DCC and partially approved by the Issuer....................................302
Figure 77: Transaction not eligible for DCC by DCC service..............................................................304
Figure 78: Transaction not eligible for DCC by the Agent...................................................................306
Figure 79: Transaction eligible for DCC but DCC refused by the Cardholder.....................................308
Figure 80: Incident at the Agent level................................................................................................. 310
Figure 81: Incident at DCC service provider level...............................................................................312
Figure 82: Protocols Organisation...................................................................................................... 317
Figure 83: Transport Adaptation Layer............................................................................................... 317
-9-
Figure 84: Peer-to-peer TCP Transport Protocol................................................................................319

Figure 85: Gateway TCP Transport Protocol......................................................................................319
Figure 86: Header Length................................................................................................................... 320
Figure 87: Connection Services.......................................................................................................... 322
Figure 88: Transport Connection Management Service Primitives.....................................................323
Figure 89: Application Protocol Message Flow...................................................................................323
Figure 90: Single Message Pair Exchange Sequence Flow...............................................................324
Figure 91: Single Message Pair Exchange Transport Primitives Sequence Flow..............................325
Figure 92: Multiple Message Pair Exchange Sequence Flow.............................................................326
Figure 93: Multiple Message Pair Exchange Transport Primitives Sequence Flow............................327
Figure 94: Transport Address............................................................................................................. 329
Figure 95: Late Arrival Error Example.................................................................................................333
Figure 96: Recipient Party Connection Management State Diagram..................................................337
Figure 97: Initiating Party Connection Management State Diagram...................................................338
- 10 -
282 Tables
283 Table 1: Message type and version...................................................................................................... 14
284 Table 2: MessageFunction Values..................................................................................................... 231
285 Table 3: List of Payment Cases.......................................................................................................... 240
286 Table 4: Cancellation MessageFunction Values.................................................................................242
287 Table 5: List of Cancellation Cases.................................................................................................... 248
- 11 -
288 1 Introduction
289 1.1 Purpose and Use of this Guide
290 This guide outlines how to use the CAPE Card Payments messages in the context of the acceptor-to-
291 acquirer transactions (caaa) ISO 20022 Business Area1. It provides a comprehensive view on how
292 these messages fit within a card payment business process and the activities of the involved parties.
293 Also included are detailed explanations and examples of the use of the message components to
294 convey specific information related to these processes and activities. This guide acts as a
295 complement to the ISO 20022 CAPE Message Definition Report and the XML Schema for those
296 exchanges. It complies with ISO 20022 rules and specifications.
297 The guide provides information regarding the application of the included messages in a general
298 context. Additional documents, published by individual user communities, may be available that
299 discuss the application of this standard in a more specific context.
300 1.2 Intended Audience

301 The present guide is intended for both business people and message developers. It is also targeted
302 for manufacturers, software providers, banks and card payment services providers offering these
303 messages to their clients, technology firms seeking to embed support for these messaging standards
304 into their applications, and standards organisations that wish to use the payment kernel as part of the
305 messages they offer.
306 1.3 Scope of the Document

307 The present guide covers basic payments with a limited number of optional features such as cash-
308 back, gratuity, DCC, loyalty. It includes cancellation, refund and reconciliation associated with these
309 payments.
310 1.4 Messages Covered in this Guide

311 The present guide covers card payments in the acceptor-to-acquirer domain only and complies with
312 ISO 20022 message specifications published by ISO 20022 in "Message Definition Report Card
313 Payments Exchanges – Acceptor to Acquirer" on February 2016.
314 It addresses the following categories of exchanges of messages:
315  Authorisation messages2, cover the messages exchanged between an Acceptor and an
316 Acquirer to initiate and, in some implementations, to finalise the card-based payment
317 transactions initiated at a Point-of-Interaction.
318
319  Completion messages3, cover the messages exchanged between an Acceptor and an
320 Acquirer to finalise the card-based payment transactions initiated at a Point-of-Interaction.
2 1 http://www.iso20022.org/documents/general/ISO20022_BusinessAreas.pdf
3 2 AcceptorAuthorisationRequest (caaa.001.001.08) and AcceptorAuthorisationResponse (caaa.002.001.08)
4 3 AcceptorCompletionAdvice (caaa.003.001.08) and AcceptorCompletionAdviceResponse (caaa.004.001.07)
1 Introduction - 12 - 1.4 Messages Covered in this Guide

321  Cancellation messages4, cover the messages exchanged between an Acceptor and an
322 Acquirer to cancel successfully completed payment transactions or other types of transactions
323 (e.g. reservations) which have not yet been cleared. A cancellation is sometimes called a
324 manual reversal.
325  Reconciliation messages5, cover the messages exchanged between an Acceptor and an
326 Acquirer to perform checks and balances between the card acceptor and the acquirer for a
327 reconciliation period.
328  Batch transfer messages6 cover the messages exchanged in batch between an Acceptor and
329 and Acquirer process a set of card-based payment transactions initiated at a Point-of-
330 Interaction.
331  Diagnostic messages7 cover the messages exchanged between an InitiatingParty and a
332 RecipientParty to prove that messages can be exchanged correctly between the parties.
333  Rejection message8 cover the message send by a RecipientParty to an InitiatingParty to

334 indicate that the RecipientParty could not process the received message.
335  Dynamic Currency conversion message9 cover the messages exchanged between and
336 Acceptor or an acquirer and a DCC service provider (Agent or Acquirer).
337 All messages exchanged according to the rules defines in this Message User Guide must specify
338 ProtocolVersion 8.0 in the message header.
Message Message type and version

AcceptorAuthorisationRequest caaa.001.001.08
AcceptorAuthorisationResponse caaa.002.001.08
AcceptorCompletionAdvice caaa.003.001.08
AcceptorCompletionAdviceResponse caaa.004.001.07
AcceptorCancellationRequest caaa.005.001.08
AcceptorCancellationResponse caaa.006.001.07
AcceptorCancellationAdvice caaa.007.001.08
AcceptorCancellationAdviceResponse caaa.008.001.07
AcceptorReconciliationRequest caaa.009.001.07
AcceptorReconciliationResponse caaa.010.001.06
5 4 AcceptorCancellationRequest (caaa.005.001.08), AcceptorCancellationResponse (caaa.006.001.07),

6 AcceptorCancellationAdvice (caaa.007.001.08) and AcceptorCancellationAdviceResponse
7 (caaa.008.001.07)
8 5 AcceptorReconciliationRequest (caaa.009.001.07) and AcceptorReconciliationResponse (caaa.010.001.06)
9 6 AcceptorBatchTransfer (caaa.011.001.08) and AcceptorBatchTransferResponse (caaa.012.001.07)
10 7 AcceptorDiagnosticRequest (caaa.013.001.07) and AcceptorDiagnosticResponse (caaa.014.001.06)
11 8 AcceptorRejection (caaa.015.001.05)
12 9 AcceptorCurrencyConversionRequest (caaa.016.001.06), AcceptorCurrencyConversionResponse
13 (caaa.017.001.06), AcceptorCurrencyConversionAdvice (caaa.018.001.03) and
14 AcceptorCurrencyConversionAdviceResponse (caaa.019.001.02)
1 Introduction - 13 - 1.4 Messages Covered in this Guide

Message Message type and version

AcceptorBatchTransfer caaa.011.001.08
AcceptorBatchTransferResponse caaa.012.001.07
AcceptorDiagnosticRequest caaa.013.001.07
AcceptorDiagnosticResponse caaa.014.001.06
AcceptorRejection caaa.015.001.05
AcceptorCurrencyConversionRequest caaa.016.001.05
AcceptorCurrencyConversionResponse caaa.017.001.05
AcceptorCurrencyConversionAdvice caaa.018.001.03
AcceptorCurrencyConversionAdviceResponse caaa.019.001.02
339 Table 1: Message type and version
340 1.5 How this Guide was created

341 This guide was created through the combined efforts of the nexo Acquirer Protocol Working Group
342 involving representatives belonging to various industries (banks, card payments service providers,
343 manufacturers, software service providers, retailers, etc.). It follows ISO 20022 rules for the design of
344 Message Usage Guides.
345 1.6 nexo and ISO 20022

346 nexo10 is a major standardisation initiative in card-based payment transactions involving card-payment
347 experts belonging to various industries. Nexo has been created by merging various standardisation
348 initiative like EPAS Org, CIR and Oscar. Since its inception, EPASOrg has been following the ISO
349 20022 methodology in developing standards with the ultimate objective to become a full-fledged ISO
350 20022 standard. ISO 20022 is part of the International Organization for Standardization (ISO) under
351 Technical Committee 68 (TC68), which is the Financial Services Technical Committee of the
352 International Organization for Standardization. ISO 20022 message standards are submitted through
353 the ISO 20022 Registration Management Group (RMG) via a Business Justification. When this
354 Business Justification is approved, the RMG assigns the proposed message standards to a Standards
355 Evaluation Group (SEG).
356 The Cards and Related Retail Financial Services SEG mandated by the RMG to address the card
357 payments business domain officially endorsed the nexo CAPE (Card Payment Exchanges) series of
358 messages in June 2010.
359 Complete information on the membership of the ISO 20022 SEGs, the ISO 20022 Financial
360 Repository, and the message maintenance and registration process can be found on www.iso20022.org.
361 For more information on ISO itself, please see www.iso.org.
362 For more information on nexo, the body in charge of the nexo and CAPE messages, please visit
363 www.nexo-standards.org.
15 10 http://www.nexo-standards.org
1 Introduction - 14 - 1.6 nexo and ISO 20022

364 1.7 ISO 20022 Intellectual Property Rights Policy

365 EPASOrg acknowledges and abides by the ISO 20022 IPR policy outlined as follows: “Organizations
366 that contribute information to be incorporated into the ISO 20022 Repository shall keep any
367 Intellectual Property Rights (IPR) they have on this information. A contributing organization warrants
368 that it has sufficient rights on the contributed information to have it published in the ISO 20022
369 Repository through the ISO 20022 Registration Authority in accordance with the rules set in ISO
370 20022. To ascertain a widespread, public and uniform use of the ISO 20022 Repository information,
371 the contributing organization grants third parties a non-exclusive, royalty-free license to use the
372 published information”.
373 The EPAS End-User License Agreement11 can be downloaded from the ISO 20022 Web site.
374 1.8 Message Transport

375 CAPE messages are designed to be transport protocol independent. The CAPE standard does,
376 however, provide message transport conventions of its own (including header and trailer).
377 1.9 Security

378 CAPE messages embed their own security data components and structures to ensure an adequate
379 security in the transmission of the information.
380 1.10 Coding

381 CAPE messages are proposed in ISO 20022 XML derived from ISO 20022 Message Definitions.
382 1.11 Related Documents and Guides

383 The complete catalog of official ISO 20022 CAPE messages, including the Message Definition
384 Reports and XML Schemas, is available on the ISO 20022 official Web site ( www.iso20022.org) All other
385 CAPE or nexo related information can be found by visiting the nexo Web site ( www.nexo-standards.org).
386 Useful information about XML is available from the following sources:
387  XML recommendations of W3C can be found at:
388 http://www.w3c.org/TR/2000/REC-xml-20081126
389 http://www.w3.org/TR/2006/REC-xml11-20060816/
390  XML Schema recommendations of W3C can be found at:
391 http://www.w3c.org/TR/xmlschema-0/
394 The security elements of these messages are described in the nexo document named Card Payment
395 Protocols Security.
16 11 http://www.iso20022.org/documents/general/EPASOrg_EPAS_End-user_License_Final.pdf
1 Introduction - 15 - 1.11 Related Documents and Guides

396 1.12 Conventions

397 The words MUST, SHOULD and MAY will be used throughout this document with the meaning defined
398 by [RFC2119].
399 Items represented in grey in the table are not covered by the present MUG. Within the terms of the
400 protocol they may be used as agreed between the sender and receiver.
401 1.13 What’s new in the edition 8
402 This edition brings the following improvements:

403  Support of ReservedAmount in response from Acquirer or Agent in Reservation use case
404  ISO20022 model update: Move to new BIC's standardCard Initiated Direct Debit
1 Introduction - 16 - 1.13 What’s new in the edition 8

405 2 Message Exchange and Processes
406 2.1 Card Payment
407 2.1.1 Authorisation

408 An authorisation is used in a card payment to request the approval of the transaction. It can be done
409 either remotely (on-line to the Acquirer through an authorisation exchange) or locally (off-line
410 authorisation) depending on the business context.
411 The possible outcomes of an authorisation are:

412  a successful authorisation
413  a declined authorisation
414  a technical problem (eg. timeout, unable to go online, etc.)
415  a voice referral, which in turn may result in a successful authorisation or a decline.
416 An online authorisation exchange is made up an AcceptorAuthorisationRequest message used to

417 request the authorisation of the related transaction and an AcceptorAuthorisationResponse message
418 used to provide the outcome of the authorisation.
419 2.1.2 Completion

420 Completion is the process of finalising the interaction between the cardholder and the merchant at the
421 POI.
422 The outcome of a completion is the acceptance or decline of the transaction by the Acceptor.
423 A completion exchange may also be required by an Acquirer to finalise the transaction:
424  when the Acceptor is configured to support completion,
425  in the authorisation response (if required by the Acquirer),
426  when an online approved authorisation did not complete successfully.
427 A completion exchange is made up an AcceptorCompletionAdvice message sent by an Acceptor to

428 notify the Acquirer of the outcome of the transaction and an AcceptorCompletionAdviceResponse
429 message used by the Acquirer to acknowledge this notification.
430 A completion exchange can be performed in realtime at the end of the transaction or in a store-and-
431 forward mode of operation.
432 An AcceptorCompletionAdvice is used for three main purposes:

433  to reverse an authorisation (also called a “reversal”)
434  to inform the Acquirer of the outcome of a service
435  to transfer the transaction data to the Acquirer for a further clearing and settlement (financial
436 capture).
2 Message Exchange and Processes - 17 - 2.1 Card Payment

437 The Acquirer must accept an AcceptorCompletionAdvice message. In case of an error, the message is
438 resent to the Acquirer (see section 3.3 Message Retransmission).
439 2.1.3 Financial capture

440 The ultimate financial settlement of a card payment transaction requires a prior financial capture of the
441 elements of this transaction by the Acquirer or by an agent acting on his behalf. The responsibility of
442 keeping the financial information is then transferred from the Acceptor to the Acquirer for a further
443 clearing and settlement of the transaction.
444 A financial capture can take place in realtime, after a short delay or at a later time as part of a batch
445 transfer.
446 A financial capture process can be done:

447  within an authorisation exchange;
448  within a completion exchange;
449  through a batch transfer.
450 2.1.4 Batch

451 A batch is a collection of transactions sent to the Acquirer for a further processing.
452 A batch transfer is processed through an AcceptorBatchTransfer and an
453 AcceptorBatchTransferResponse which is used to acknowledge or to reject some or all transactions
454 contained in a batch.
455 In case of batch of authorisation requests, the Acquirer will sent the authorisation result to the
456 POISystem through an AcceptorBatchTransfer. The POISystem will acknowledge or reject some or all
457 of the response through an AcceptorBatchTransferResponse.
458 2.1.5 Dynamic Currency Conversion

459 When the currency of the transaction is not the same as the currency of the card, it may be difficult for
460 a cardholder to estimate the actual amount he will have to pay in his own currency at the moment of
461 the payment.
462 Dynamic Currency Conversion (DCC) is a service offered by a merchant to allow the cardholder to
463 make the payment in the currency of his card instead of the currency of the merchant when different.
464 The cardholder can choose whether to accept the DCC service or not. When DCC is allowed by the
465 merchant, the currency conversion is managed through a DCC service provider proposing to the
466 cardholder the converted amount to be ultimately debited on his card.
467 If the DCC service is refused by the cardholder, the transaction then proceeds as a normal card
468 payment transaction in the currency of the merchant.

469 The DCC service may rely on an agent acting between the merchant and the DCC service provider.
470 The following use cases involve agents in the process, but direct exchanges between a merchant and
471 a DCC service provider or between a merchant and an acquirer follow the same logic.
472 The role of the DCC service provider can be played by any party (Agent, Acquirer, etc.).
473 DCC is supported by two types of exchanges:
474  Authorisation exchanges where a pair of AcceptorAuthorisationRequest and

475 AcceptorAuthorisationResponse messages are used
476  Dynamic Currency Conversion exchanges where a pair of
477 AcceptorCurrencyConversionRequest and AcceptorCurrencyConversionResponse messages
478 are used to fulfil the same purpose.
479 An Advice may be sent to DCC provider for the final outcome of the DCC service with messages
480 AcceptorCurrencyConversionAdvice and AcceptorCurrencyConversionAdviceResponse .
481 Use cases outlining some typical DCC scenarios are described in Chapter 6.7 Dynamic Currency
482 Conversion (DCC) .

483 2.2 Scope of Card Payments

484 Card payment exchanges can be domestic, cross-border and/or cross currency. They may be used by
485 an Acceptor to request to an Acquirer to initiate and/or complete a card transaction.
486 An Acceptor can directly exchange with an Acquirer a series of card payment messages. The
487 proposed messages may also go through the intermediation of one or more Intermediary Agents to
488 request similar services. The Intermediary Agent is then acting as an agent of the Acquirer, the
489 Acceptor or both.
490 In a normal card payment process, the Acquirer further forwards to the Issuer (e.g. a payment
491 institution or a similar entity issuing the payment card to the cardholder) the related authorisation
492 request to get an ultimate response from the entity entitled to issue the authorisation of payment for a
493 purchase which was initiated with the card issued by them. The protocol needs to transport all relevant
494 information to enable the Issuer to take the appropriate decision i.e. either to authorise or to decline
495 the card payment transaction submitted by the Acquirer.
496 In an alternative process and based on the information submitted by an Acceptor, the Acquirer may
497 take the responsibility to authorise or decline the transaction (below a certain amount, for instance) on
498 behalf of the Issuer. He may also decide to forward to the Issuer the information required by the Issuer
499 to take the ultimate authorisation decision. In this case, the information is exchanged through an
500 Acquirer-to-Issuer protocol. This exchange is out of scope of the present specification.
501 In some specific environments (e.g. petrol), some purchasing information, such as a list of products,
502 may accompany the authorisation since the final payment can occur if and only if the list of products
503 was approved by the issuer of the payment card.
504 In that case, either the Acceptor submits with an authorisation request the list of products for approval
505 to the Acquirer which further forwards this list to the Issuer for approval or, based on the information
506 contained in the authorisation request, the Issuer submits in the authorisation response the restricted
507 list of products (e.g. fuel dispensing products) authorised for the Cardholder. It is then the
508 responsibility of the Acceptor to deliver a product or a service which complies with the product(s)
509 contained in this list.
2 Message Exchange and Processes - 20 - 2.2 Scope of Card Payments

510 2.3 Types of environments
511 Depending on business constraints and the types of equipment used, typical implementations may be
512 classified in:
513  Online-only
514  Offline with online capability
515  Offline-only with batch capture
516 2.3.1 Online only

517 In this mode all transactions are processed in a pure on-line mode of operation. The only required
518 exchanges are Authorisation and Completion:
519 Completion is required:
520  In case of reversal
521  For financial capture when not done during authorization.
522  In case of request in the authorization response or by configuration.
523 2.3.1.1 Financial capture made during the authorisation exchange
524 Case of a successful transaction

525 An AcceptorAuthorisationRequest message is sent by an Acceptor to an Acquirer to request the
526 approval of a payment transaction. The transaction succeeds after the approval of the authorisation. In
527 some cases, the Acquirer may require a completion exchange for this transaction.
528 An AcceptorAuthorisationResponse message is returned by the Acquirer to inform the Acceptor of the
529 outcome of the request. The responsibility of the financial data (financial capture) is transferred from
530 the Acceptor to the Acquirer with the AcceptorAuthorisationRequest message. The Acquirer then
531 stores this information for the further clearing and settlement of the transaction.
Acceptor Acquirer
AcceptorAuth
orisationReque
st
authorisation approval
and capture
orisa tionResponse
AcceptorAuth
transaction
completed
successfully
532 Figure 1: Authorisation with capture (successful transaction)
2 Message Exchange and Processes - 21 - 2.3 Types of environments

533 Case of a failed transaction

535 approval of a transaction. The transaction fails after the approval of the authorisation or if the Acceptor
536 has not received a response to the AcceptorAuthorisationRequest message. A completion exchange
537 is initiated by the Acceptor to reverse both the authorisation and the financial capture of the
538 transaction.
Acceptor Acquirer
AcceptorAuth
orisationReque
st
and capture
nse
orisationRespo
AcceptorAuth
transaction fails
negative completion to
reverse the transaction AcceptorComple
tionAdvice
Authorisation and
capture reversed
tionAdvice Response
AcceptorComple
539 Figure 2: Authorisation with capture (failed transaction)

540 2.3.1.2 Financial capture made during the completion exchange
541 Case of a successful transaction

543 approval of the transaction. The transaction succeeds after the approval of the authorisation.
544 An AcceptorCompletionAdvice message is sent by the Acceptor to the Acquirer to capture the
545 transaction. An AcceptorCompletionAdviceResponse message is sent back by the Acquirer to the
546 Acceptor to notify the Acceptor about the successful receipt of the advice.
Acceptor Acquirer
AcceptorAuthor
isa tionRequest
Transaction
authorised
e
isationRespons
AcceptorAuthor
Transaction
authorised
AcceptorComp
letionAdvice
Transaction
authorised
and captured
esponse
Transaction completed letionAdviceR
AcceptorComp
successfully
547 Figure 3: Completion with capture (successful transaction)

548 Case of a failed transaction

550 approval of the transaction. The transaction fails after the approval of the authorisation and/or the
551 Acceptor has not received a response to the AcceptorAuthorisationRequest message. A completion
552 exchange is then initiated by the Acceptor to reverse the authorisation of the transaction.
Acceptor Acquirer
AcceptorAuth
orisationReque
st
Transaction
authorised
nse
orisationRespo
AcceptorAuth
transaction fails
Negative completion to AcceptorComple

reverse the tionAdvice
authorisation
Authorisation
reversed
onse
tionAdviceResp
AcceptorComple
553 Figure 4: Completion with capture (failed transaction)

554 2.3.2 Semi-online authorisations
555 Authorisations are processed either online or offline depending on the context of the transaction. In
556 normal cases, the financial capture of the transaction is made during the completion exchange.
557 2.3.2.1 Capture of offline and online transactions during completion
558 In this scenario, financial capture of previously online and offline authorised transactions is carried out
559 during completion.
Acceptor Acquirer
AcceptorAuthor
authorisation isationRequest
online
authorisation approved
online Transaction
authorised
isationResponse
AcceptorAuthor
Transaction
authorised
AcceptorCompl
etionAdvice
Transaction
authorised
(online) and
captured
tionAdv iceResponse
AcceptorComple
offline
authorisation authorisation
approval
offline
AcceptorCompl
etionAdvice
Transaction
authorised
(offline) and
onse captured
tionAdviceResp
AcceptorComple
560 Figure 5: Capture of offline and online transactions during completion

561 2.3.2.2 Capture during authorisation for online transactions and during completion
562 for offline authorisations
563 In order to reduce the number of exchanges, the financial capture may be carried out during
564 authorisation exchanges for on-line authorisations and during completion exchanges for off-line
565 authorisations.
Acceptor Acquirer
AcceptorAuthor
isationRequest
online
authorisation authorisation Transaction
approved authorised (online)
online and captured
isationResponse
transaction AcceptorAuthor
completed
successfully
offline authorisation
offline
transaction
completes
successfully AcceptorCompl
etionAdvice
Transaction
authorised
(offline) and
onse captured
tionAdviceResp
AcceptorComple
566 Figure 6: Capture during authorisation for online transactions

567 and during completion for offline transactions

568 2.3.3 Offline only
569 In this scenario, an AcceptorCompletionAdvice is used to inform the Acquirer about the outcome of a
570 previously offline-authorised transaction and to advise the Acquirer to capture the financial data for
571 clearing and settlement.
Acceptor Acquirer
offline
AcceptorComp
letionAd vice
Transaction
authorised
(offline) and
captured
letionAd viceResponse
transaction completed AcceptorComp
successfully
offline
AcceptorComp
letionAd vice
Transaction
authorised
transaction completed (offline) and
successfully
letionAd viceResponse captured
AcceptorComp
572 Figure 7: Capture through completion of previously offline-authorised transactions

573 2.3.4 Capture by Batch
574 The financial capture of transactions proceeds in batch.
575 The main relevant types of batch situations are:

576  authorisation through an authorisation exchange without completion with capture in batch
577  authorisation through authorisation and completion exchanges with capture in batch
578  offline authorisation with capture in batch
579  unsuccessful transactions communicated to the Acquirer in batch
580 2.3.4.1 Authorisation through an authorisation exchange without completion with

581 capture in batch
582 In this scenario, an AcceptorBatchTransfer message is used by an Acceptor to advise an Acquirer to

583 capture in batch mode transactions authorised through previous online or offline authorisation
584 exchanges. The Acquirer captures the financial data of the transactions for clearing and settlement.
Acceptor Acquirer
AcceptorAuthor
isationRequest
online Authorisation
authorisation Transaction
initiated
authorised
online e
isationRespons
AcceptorAuthor
offline Authorisation
authorisation initiated
offline
AcceptorBatch
Capture through batch Tr ansfer
Transaction
authorised
Transaction and captured
nse
completed Tr ansferRespo
AcceptorBatch
successfully
585 Figure 8: Authorisation through an authorisation exchange without completion with capture in
586 batch

587 2.3.4.2 Authorisation through authorisation and completion exchanges with capture in
588 batch
589 In this scenario, an AcceptorBatchTransfer message is used by the Acceptor to advise the Acquirer to
590 capture in batch mode transactions authorised through previous authorisation and completion
591 exchanges. The Acquirer captures the financial data of the transactions for clearing and settlement.
Acceptor Acquirer
AcceptorAuthor
isationR equest
Authorisation initiated Transaction
online authorised
se
isationRespon
AcceptorAuthor
Advise of authorised AcceptorComp

letionAd vice Transaction
transaction
authorised and
completed waiting
etionAd viceResponse capture
AcceptorCompl
AcceptorBatch
Transfer
Capture through batch
Transaction
authorised
se and captured
TransferRespon
AcceptorBatch
592 Figure 9: Authorisation through authorisation and completion exchanges with capture in batch

593 2.3.4.3 Offline authorisation with capture in batch
594 In this scenario, an AcceptorBatchTransfer message is used by the Acceptor to advise the Acquirer to
595 capture in batch mode transactions that were previously authorised offline and stored. The Acquirer
596 captures the financial data of the transactions for clearing and settlement.
Acceptor Acquirer
offline Transaction
authorisation authorised
offline
offline Transaction
authorisation authorised
offline
Capture
through batch AcceptorBatch
Tr ansfer
Transactions
authorised
nse and captured
Tr ansferRespo
AcceptorBatch
597 Figure 10: Off-line authorisation with capture in batch

598 2.3.4.4 Capture of unsuccessful transactions in batch
599 In this scenario, an AcceptorBatchTransfer message is used by the Acceptor to send to the Acquirer
600 for capture in batch modeunsuccessfully completed and reversed transactions.
Acceptor Acquirer
Transaction
authorised
authorisation response
timeout
Authorisation reversed
through a negative
completion Authorisation reversed
Capture through
batch of
authorised or
Unsucessufully Transactions
completed and captured
reversed
authorised
transactions
601 Figure 11: Capture of unsuccessful transactions in batch

602 2.3.5 Batch of Authorisations
603 An AcceptorBatchTransfer exchange is used by the Acceptor to send a collection of Authorisation

604 Requests to the Acquirer to authorise transactions.
605 In the example below these authorisation are sent in a dedicated data set along with data set
606 containing offline transactions. The AcceptorBatchTransferResponse messages contain only
607 acknowledgement for offline transactions.
608 The Acquirer is sending back to the Acceptor in an AcceptorBatchTransfer the corresponding
609 Authorisation Responses with the outcome of the authorisation process. The AcceptorBatchTransfer
610 message sent by the acquirer contains only response for authorisation.
Acceptor Acquirer
DataSet 1 Offline
transactions
Transactions
DataSet 2 start offline
and pending
AcceptorBatch
Transfer
Acknowledgement
of DataSet 1
se
TransferRespon
AcceptorBatch
Result of
authorisation
Transfer of DataSet 2
AcceptorBatch
Transactions
of DataSet 2
are processed
and captured AcceptorBatch
Transfer
se
TransferRespon
AcceptorBatch
611 Figure 12: Batch of Authorisations

612 2.4 Cancellation
613 Cancellation is initiated by Acceptor to cancel a payment which was successfully completed. . A
614 cancellation is a user requested reversal. A cancellation cannot be revoked.
615 An AcceptorCancellationRequest is used by an Acceptor to ask the Acquirer whether a cancellation

616 can be performed, before sending an AcceptorCancellationAdvice.
617 An AcceptorCancellationAdvice - with or without a prior AcceptorCancellationRequest is used by an

618 Acceptor to inform the Acquirer that a cancellation has been completed. It is also used to indicate that
619 no response to an AcceptorCancellationRequest was received and that the cancellation was declined.
620 An AcceptorCancellationAdvice can only be used without an AcceptorCancellationRequest if the

621 Acceptor is aware that the transaction was not yet cleared.
622 An Acquirer can never decline an AcceptorCancellationAdvice . If the Acceptor does not receive an
623 AcceptorCancellationAdviceResponse , the Acceptor has to resend a AcceptorCancellationAdvice
624 until the Acceptor receives the corresponding response from the Acquirer (see 3.3 Message
625 Retransmission section).
626 Should an Acquirer decline an AcceptorCancellationRequest, an Acceptor always has the possibility to
627 refund the cardholder in cash or with a refund transaction.
628 The cancellation process may be affected by POI configuration parameters defined outside of the
629 present protocol.
2 Message Exchange and Processes - 33 - 2.4 Cancellation

630 2.4.1 Cancellation through cancellation advice or batch
631 A cancellation is carried out through an AcceptorCancellationAdvice exchange without a prior

632 AcceptorCancellationRequest.
633 This type of cancellation is used when:

634  no financial capture of the original transaction occured (by message or by batch), or
635  a financial capture of the original transaction occurred, and
636  the Acceptor is aware that the original transaction has not been cleared by the Acquirer
637 (see note below)
638  the Acceptor has all the data of the original transaction required for building up the
639 AcceptorCancellationAdvice.
640 Note: The Acceptor is able to know that the Acquirer did not clear the transaction because:
641  the clearing of the transactions is only allowed after closing the corresponding reconciliation
642 period by a reconciliation exchange, and
643  a reconciliation message to close the reconciliation period has not been sent for the
644 reconciliation period that includes the transaction.
645 A typical scenario is the following one:

646  an Acceptor performs an authorisation without financial capture. The transaction is authorised
647 offline or online by the Acquirer. The transaction is successfully completed and stored by the
648 Acceptor.
649  since no financial capture occurred, the Acceptor cancels the stored transaction and sends an
650 AcceptorCancellationAdvice to advise the Acquirer to reverse the authorisation.
651  the Acquirer sends back an AcceptorCancellationAdviceResponse to inform the Acceptor that
652 the advice was acknowledged by the Acquirer and the authorisation reversed.

Acceptor Acquirer
Transaction
authorised offline
or
AcceptorAutho
Authorised online risati onRequest
Transaction
authorised
e
risationRespons
AcceptorAutho
Transaction
authorised
AcceptorComp
letion Advice Transaction
Transaction completed authorised and
without capture completed without
e
letion AdviceRespons capture
AcceptorComp
Cancellation performed
locally
Option 1: Cancellation
advice used to reverse AcceptorCancell
ationAdvice
authorisation Authorisation
reversed
onse
ationAdviceResp
AcceptorCancell
Option 2: Batch used

to reverse AcceptorBatch
Tr ansfer
authorisation
Authorisation
reversed
Tr ansferR esponse
AcceptorBatch
653 Figure 13: Cancellation through cancellation advice or batch
654 The message flow is the same as if the Acceptor had sent previously an AcceptorCompletionAdvice
655 without financial capture for the authorised transaction before the cancellation was processed.
656 For offline transactions, it is:
657  optional to send an AcceptorCancellationAdvice if no AcceptorCompletionAdvice for the

658 transaction was previously sent
659  mandatory to send an AcceptorCancellationAdvice if an AcceptorCompletionAdvice was
660 previously sent.
661 When the Acceptor uses batch transfer for financial capture, the Acceptor sends a batch transfer
662 depending on the configuration, with either:
663  Include both the original debit (or credit) and cancellation transaction
664  Remove the original debit (or credit) from the batch

665 An alternative scenario (with financial capture) is the following one:
666  An Acceptor initiated several authorisations with financial capture (by individual messages or
667 batch).
668  The transactions are authorised and captured by the Acquirer.
669  The Acceptor is aware that the Acquirer has not yet cleared the transactions and he
670 completes the cancellation offline.
671  The Acceptor sends an AcceptorCancellationAdvice to notify the Acquirer of the cancellation
672 of the authorisation and financial capture on his side.
673  The Acquirer sends back an AcceptorCancellationAdviceResponse to inform the Acceptor
674 that the advice was received by the Acquirer. The Acquirer reverses the authorised and
675 captured transactions.
676  Should batch transfer be used by the Acceptor for financial capture, the Acceptor sends a
677 batch transfer depending on the configuration, with either:
678  Include both the original debit (or credit) and cancellation transaction
679  Remove the original debit (or credit) from the batch

Acceptor Acquirer
Transaction
authorised offline
or
Autorisation requested
online AcceptorAuthor
isationRequest Transaction
authorised
e
isationRespons
AcceptorAuthor
Transaction
authorised
AcceptorComp
letionAdvice
Option 1: Completion Transaction
Advice used for authorised
financial capture and captured
letionAdvic eResponse
AcceptorComp
AcceptorBatch
Tr ansfer
Option 2: Batch Transaction
transfer used for authorised
financial capture nse and captured
Tr ansferRespo
AcceptorBatch
Option 1 : Cancellation
AcceptorCancell
carried out through a ationAdvice
Cancellation Advice
Financial capture and
authorisation reversed
onse
ationAdviceResp
AcceptorCancell
Option 2 : Cancellation
carried out through
batch with cancellation AcceptorBatch
Tr ansfer
flag set on
Financial capture and
nse authorisation reversed
Tr ansferRespo
AcceptorBatch
680 Figure 14: Cancellation through cancellation advice and batch exchanges

681 2.4.2 Cancellation through cancellation request and advice exchanges
682 A cancellation is carried out through an AcceptorCancellationRequest followed by an

683 AcceptorCancellationAdvice.
684 This type of cancellation is used when all the following conditions are satisfied:
685  financial capture of the transaction has already occured (by message or by batch), and
686  the Acceptor is unaware whether the Acquirer cleared the transaction or not , and
687  the Acceptor has all the data of the original transaction required for building up the
688 AcceptorCancellationRequest and AcceptorCancellationAdvice messages.
689 A typical scenario is the following one:

690  An Acceptor performs an authorisation with financial capture. The transaction is authorised
691 offline or online by the Acquirer. The transaction is successfully completed and captured by
692 the Acquirer.
693  The Acceptor sends an AcceptorCancellationRequest to ask the Acquirer whether the
694 transaction can be cancelled or not.
695  should the cancellation be possible:
696 - the Acquirer sends a positive AcceptorCancellationResponse.
697 - the Acceptor sends back an AcceptorCancellationAdvice to
698 complete the cancellation by the Acquirer.
699 - the Acquirer responds with an
700 AcceptorCancellationAdviceResponse to inform the Acceptor that the advice was
701 received by the Acquirer.
702  should the cancellation not be possible:
703 - the Acquirer declines the request with a negative
704 AcceptorCancellationResponse.
705 - the Acceptor does not send an AcceptorCancellationAdvice
706 except if the AcceptorCancellationResponse was not received.

Acceptor Acquirer
Transaction
authorised offline
or
Autorisation
initiated
AcceptorAuth
online orisationRequ
est
Transaction
authorised
nse
orisationRespo
AcceptorAuth
Transaction
authorised
AcceptorCom
pletionAdvice Transaction
Option 1:
Completion used for authorised and
financial capture Respo
captured
pletionAdvice
AcceptorCom
nse
AcceptorBatc
hTransfer
Option 2 :Batch Transaction
transfer used for authorised and
capture nse captured
hTransferRespo
AcceptorBatc
Cancellation initiated
through a AcceptorCancel
lationRequest
cancellation request
Capture reversed
lationResponse
Capture reversed AcceptorCancel
Option 1:
AcceptorCancel
Cancellation advice lationAdvice
used to complete Capture and
cancellation Authorisation
po
lationAdviceRes reversed
AcceptorCancel
nse
Option 2: Batch
used to complete
cancellation (flag to
cancel transactions) AcceptorBatc
hTransfer
Capture and
Authorisation
nse reversed
hTransferRespo
AcceptorBatc
707 Figure 15: Cancellation through cancellation request and advice exchanges

708 2.4.3 Cancellation declined by the Acquirer
709 Should an AcceptorCancellationRequest be declined by the Acquirer, no further

710 AcceptorCancellationAdvice is sent by the Acceptor.
711 When the Acceptor used batch transfer for financial capture, the Acceptor may add the cancellation in
712 the batch according to the batch configuration.
Acceptor Acquirer
Transaction
authorised offline
or
Authorisation initiated
online AcceptorAutho
risationReques
t
Transaction
authorised
se
risationRespon
AcceptorAutho
Transaction
authorised
AcceptorComple
tionAdvice
Option 1 : Completion Transaction
Advice used for authorised and
capture onse captured
tionAdviceResp
AcceptorComple
AcceptorBatch
Transfer
Option 2 : Batch used Transaction
for capture authorised and
se
TransferRespon captured
AcceptorBatch
Option 1 :
AcceptorCanc
Cancellation initiated ellationRequest
Cancellation declined
(transaction still
se captured)
ellationRespon
Cancellation declined AcceptorCanc
Declined Cancellation
can be sent in next
Batch transfer, if
Batch transfer is used
Option 2: Flag
transactions as AcceptorBatch
Transfer
cancelled or remove Cancellation declined
from batch (transactions still
se captured)
TransferRespon
Cancellation declined AcceptorBatch
713 Figure 16: Declined cancellation of a captured transaction

714 2.4.4 Error in Cancellation Message Exchanges

715 In this chapter several scenarios are described where the Acceptor did not receive a response from
716 the Acquirer to AcceptorCancellationRequest messages.
717 2.4.4.1 Cancellation declined after timeout of a cancellation request
718 In this scenario:

719  the Acceptor received an AcceptorCompletionAdviceResponse from the Acquirer
720  the transaction was captured by the Acquirer
721  the Acceptor did not receive a response to an AcceptorCancellationRequest.
722 In this case the Acceptor must decline the cancellation to the cardholder. An
723 AcceptorCancellationAdvice is sent to the Acquirer:
724  to inform the Acquirer that the cancellation was declined to the cardholder
Acceptor Acquirer
Transaction
authorised offline
or
authorisation Initiated
online
Transaction
authorised
Completion Advice for

capture Transaction
authorised and
captured
Transaction authorised
and captured
Cancellation initiated
If request received,
Cancellation
Cancellation is processed
declined as no reply
Cardholder informed
that the cancellation
was declined
Advises Acquirer about

declined cancellation Transaction
authorised and re-
captured (if relevant)
725 Figure 17: Cancellation declined after timeout of a cancellation request

726 2.4.4.2 Cancellation successful after timeout of a completion advice

728  the Acceptor sent an AcceptorCompletionAdvice to capture the transaction and
729  the Acceptor did not receive an AcceptorCompletionAdviceResponse and
730  the Acceptor wants to cancel the transaction
731 Without having received an AcceptorCompletionAdviceResponse, the Acceptor is unaware whether

732 the transaction was captured or not.
733 Furthermore, the Acceptor is unaware whether the transaction was cleared or not (if the transaction
734 was actually captured).
735 The Acceptor sends an AcceptorCancellationRequest to ask the Acquirer whether a cancellation is
736 possible or not.
737
738 Should the cancellation be possible:
739  the Acquirer sends a AcceptorCancellationResponse to inform the Acceptor that the
740 transaction can be cancelled.
741  the Acceptor informs the cardholder about the success of the cancellation and sends an
742 AcceptorCancellationAdvice to inform the Acquirer about the successful completion of the
743 cancellation.
744  the Acquirer responds with an AcceptorCancellationAdviceResponse to inform the Acceptor
745 that the advice was received by the Acquirer.
746 Should clearing occur between the receipt of the AcceptorCancellationRequest and the
747 AcceptorCancellationAdvice, the Acquirer will refund the cardholder through an Acquirer to Issuer
748 exchange.

Acceptor Acquirer
Transaction
authorised offline
or
Authorisation initiated
isationRequest
Transaction
authorised
e
isationRespons
AcceptorAuthor
Completion Advice for AcceptorCom

capture pletionAdvice Transaction
authorised and
possibly captured
letion
AcceptorComp e
Acceptor unaware AdviceRespons
whether the transaction
was captured or not
Cancellation initiated AcceptorCancell

ationRequest
Cancellation approved
ationResponse
AcceptorCancell
Capture reversed (but

authorisation still active)
Complete cancellation AcceptorCancell

ationAdvice
and reverse
Authorisation and
authorisation
capture (if relevant)
onse reversed
ationAdviceResp
Transaction AcceptorCancell
successfully cancelled
749 Figure 18: Cancellation successful after timeout of a completion advice

750 2.4.4.3 Cancellation declined after timeout of a completion advice

753  the Acceptor did not receive an AcceptorCompletionAdviceResponse and
754  the Acceptor wants to cancel the transaction.
755 Without having received an AcceptorCompletionAdviceResponse, the Acceptor is unaware whether

756 the transaction was captured or not.
757 Furthermore, the Acceptor is unaware whether the transaction was cleared or not (if the transaction
758 was actually captured).
761 Option 1
762 The cancellation is declined by the Acquirer because the transaction has already been captured and
763 cleared:
764  the Acquirer sends an AcceptorCancellationResponse to inform the Acceptor that the
765 cancellation was declined.
766  the Acceptor informs the cardholder that the cancellation was declined by the Acquirer
767  the Acceptor needs to send an AcceptorCompletionAdvice with the financial data for capture
768 by the Acquirer because he does not know that the transaction is already captured. The
769 Acquirer discards the message since the transaction has already been captured.
770 Option 2
771 The cancellation is declined by the Acquirer because he did not receive the
772 AcceptorCompletionAdvice message:
775  the Acceptor informs the cardholder that the cancellation was declined by the Acquirer
776  the Acceptor needs to send an AcceptorCompletionAdvice with the financial data for capture
777 by the Acquirer. The Acquirer captures the financial data for a further clearing.
778 The cardholder needs to get a refund for both options.

Acceptor Acquirer
Transaction
authorised offline
or
Autorisation initiated
isationRequest
Transaction
authorised
e
isationRespons
Transaction AcceptorAuthor
successfully
completed
AcceptorCompletio
Option 1 nAdvice
Transaction captured
letion and cleared
AcceptorComp e
AdviceRespons
Option 2 AcceptorCom
pletionAdvice
Message not received
Cancellation requested AcceptorCancell

ationRequest
ationResponse
AcceptorCancell
Completion advice
for capture AcceptorComp
letionAdvice
Transaction captured
(option 2)
onse
tionAdviceResp
AcceptorComple
779 Figure 19: Cancellation declined after timeout of a completion advice

780 2.4.4.4 Cancellation declined after timeout

783  the Acceptor did not receive an AcceptorCompletionAdviceResponse.
784 The Acceptor wants to cancel the transaction but is unaware whether the Acquirer has already cleared
785 the transaction or not.
788 The Acceptor does not receive a response for the AcceptorCancellationRequest (timeout):
789  the Acceptor informs the cardholder that the cancellation was declined
790  the Acceptor sends back an AcceptorCompletionAdvice with the financial data for capture by
791 the Acquirer
792  After receiving an AcceptorCompletionAdviceResponse from the Acquirer, the Acceptor sends
793 an AcceptorCancellationAdvice to inform the Acquirer that the cancellation was declined.
794  The Acquirer acknowledges this advice with an AcceptorCancellationAdviceResponse.

Acceptor Acquirer
Transaction
authorised offline
or
online
Transaction
authorised
Transaction
successfully
completed
Completion advice for

capture
Transaction possibly
captured
Acceptor unaware
was captured or not
Request cancellation
If request received:
Approve or decline
cancellation;
If approved reverse
capture (if relevant)
Cancellation declined to
cardholder
Repeat Completion
advice for capture
Transaction
authorised and
captured
Advise about declined

cancellation Transaction still
authorised and
captured
795 Figure 20: Cancellation declined after timeout

796 2.4.4.5 Cancellation successful after completion errors

799  the Acceptor didn’t receive an AcceptorCompletionAdviceResponse.
800 The Acceptor wants to cancel the transaction and knows that the Acquirer did not clear the transaction
801 yet.
802 The Acceptor sends an AcceptorCancellationAdvice (without sending a prior
803 AcceptorCancellationRequest) to advise the Acquirer about the cancellation of the transaction.
804 The Acquirer accepts the cancellation:

805  the Acquirer voids both the authorisation and financial capture associated to the transaction, if
806 required
807  the Acquirer sends an AcceptorCancellationAdviceResponse to inform the Acceptor that the
808 cancellation succeeded.
Acceptor Acquirer
Transaction
authorised offline
or
online
Transaction
authorised
Transaction
successfully
completed
Completion Advice
with capture
captured
Acceptor is aware that

the transaction has not
been cleared by the
Acquirer
Cancellation completed
offline
Void capture and

authorisation
809 Figure 21: Cancellation successful after completion errors

810 2.4.4.6 Cancellation in batch mode

812  the Acceptor sent an AcceptorCompletionAdvice without capture and
813  the Acceptor received an AcceptorCompletionAdviceResponse.
814 The Acceptor sends an AcceptorBatchTransfer to capture the transaction, but did not receive an
815 AcceptorBatchTransferResponse.
820 The Acquirer accepts the cancellation:

821  if needed, the Acquirer voids the financial capture associated with the transaction
823 cancellation was possible.
824  the Acceptor informs the cardholder that the cancellation was accepted
825  the Acceptor sends back an AcceptorCancellationAdvice to the Acquirer about the successful
826 cancellation of the transaction.
827  the Acquirer voids the authorisation associated with the transaction
829 cancellation has been received.
830 The Acceptor sends a batch transfer depending on the configuration, with either:

Acceptor Acquirer
Transaction
authorised offline
or
risationReques
t
Transaction
authorised
se
risationRespon
Transaction AcceptorAutho
successfully
completed
Completion advice (no

capture) AcceptorCom
pletionAdvice
Transaction
authorised and
tionAdvice Response completed
AcceptorComple
Batch transfer with AcceptorBatch

capture Transfer
captured
Transfer
Acceptor unaware AcceptorBatch
Resp on se
was captured or not
Cancellation initiated AcceptorCanc

ellationRequest
Cancellation approved
and capture reversed
se
ellationRespon (if relevant)
AcceptorCanc
but transaction still
authorised
Advise cancellation AcceptorCanc

ellationAdvice
through cancellation
advice Authorisation and
capture reversed
esponse
ellationAdviceR
AcceptorCanc
Advise cancellation AcceptorBatch

Transfer
through batch
(transactions flagged as Authorisation and
cancelled or remove capture reversed
from batch) tchTransfer
AcceptorBa
Re onse
sp
833 Figure 22: Cancellation in batch mode

834 2.4.4.7 Declined cancellation in batch mode

838 The Acceptor sends an AcceptorBatchTransfer to capture the transaction, but does not receive an
844 The Acquirer declines the cancellation:

846 cancellation was not possible.
847  the Acceptor informs the cardholder that the cancellation was declined
848 The Acceptor has to resend the AcceptorBatchTransfer that failed. No AcceptorCancellationAdvice is
849 sent by the Acceptor.

Acceptor Acquirer
Transaction
authorised offline
or
risationRequest
Transaction
authorised
se
risationRespon
Transaction AcceptorAutho
successfully
completed
Completion advice (no

capture) AcceptorComp
letionAdvice
Transaction
authorised
dviceResponse
Acce ptorCompletionA
Batch transfer with AcceptorBatchT

capture ransfer
captured
Transfer
whether the transaction Resp on se
was captured or not
Cancellation initiated AcceptorCancell

ationRequest
ationResponse
AcceptorCancell
Repeat batch transfer AcceptorBatchT

with capture ransfer
Transaction
authorised and
capture
chTransfer
AcceptorBat
Response
850 Figure 23: Declined cancellation in batch mode

851 2.4.4.8 Declined cancellation after timeout in batch mode and cancellation request

857 The Acceptor wants to cancel the transaction but is unaware whether the Acquirer already has cleared
861 The Acceptor does not received the response to the AcceptorCancellationRequest message
862  the Acceptor has to decline the cancellation to the cardholder
863  the Acceptor sends an AcceptorCancellationAdvice to inform the Acquirer about the declined
867 Once the Acceptor has sent the AcceptorCancellationAdvice, it has to resend the
868 AcceptorBatchTransfer for the financial capture by the Acquirer since the transaction was not
869 cancelled.

Acceptor Acquirer
Transaction
authorised offline
or
risationReques
t
Transaction
se authorised
risationRespon
AcceptorAutho
Transaction
successfully
completed
AcceptorCom
pletionAdvice
Completion advice
Transaction
(no capture)
se authorised
ionAdviceRespon
AcceptorComplet
Capture through batch AcceptorBatch

Transfer
captured
Transfer
whether the transaction Resp onse
was captured or not
Initiated cancellation for a

AcceptorCanc If request received:
transaction in previous ellationRequest
batch Approve or decline
cancellation;
ellation If approved void
AcceptorCanc
Cancellation declined to Response capture
cardholder
Cancellation advice to
advise about declined AcceptorCanc
ellationAdvice
cancellation Transaction
authorised and
capture reversed
esponse
Confirmation about ellationAdviceR
declined cancellation AcceptorCanc
Use batch to capture

the « un-captured » AcceptorBatch
Transfer
authorised transaction Transactions
authorised and
captured
tchTransfer
AcceptorBa
Response
870 Figure 24: Declined cancellation after timeout in batch mode and cancellation request

871 2.4.4.9 Declined cancellation in batch mode after timeout in cancellation request

875 The Acceptor sends an AcceptorBatchTransfer to capture the transaction and he receives an
876 AcceptorBatchTransferResponse to confirm the financial capture.
881 The Acceptor did not received a response to the AcceptorCancellationRequest:

882  the Acceptor has to decline the cancellation to the cardholder
883  the Acceptor sends an AcceptorCancellationAdvice to inform the Acquirer about the declined
886 cancellation was reversed.
887 Once the Acquirer has declined the cancellation, no AcceptorBatchTransfer needs to be exchanged
888 since the Acquirer has already made the financial capture and the transaction was not cancelled.

Acceptor Acquirer
Transaction
authorised offline
or
risationReques
t
Transaction
authorised
se
risationRespon
AcceptorAutho
Transaction
successfully
completed
AcceptorCom
pletionAdvice
Completion advice
Transaction
without capture
sponse authorised
AcceptorCom pletionAdviceRe

capture Transfer
Transaction
authorised and
captured
hTransfer
Acceptor receives AcceptorBatc
response Response
Request cancellation AcceptorCanc If request received:

ellationRequest
Acceptor unaware Approve or decline
whether the transaction cancellation;
ellation If approved void
was captured or not AcceptorCanc
Response capture
Inform Acquirer about AcceptorCanc

declined cancellation ellationAdvice
Transaction remains
captured or is
esponse captured again
ellationAdviceR
AcceptorCanc
889 Figure 25: Declined cancellation in batch mode after timeout cancellation request

890 2.4.4.10 Cancellation in batch mode of a transaction captured but not yet cleared

896 The Acceptor wants to cancel the transaction and is aware that the Acquirer has not cleared the
897 transaction yet.
898 In that scenario:

899  The Acceptor sends an AcceptorCancellationAdvice to inform the Acquirer about the
901  The Acquirer voids the authorisation and financial capture of the transaction
902  The Acquirer sends an AcceptorCancellationAdviceResponse to inform the Acceptor that the
903 cancellation of the transaction suceeded.
904 The Acceptor sends a batch transfer depending on the configuration, with either:
907 .

Acceptor Acquirer
Transaction
authorised offline
or
autorisation initiated
risationReques
t
Transaction
authorised
se
risationRespon
AcceptorAutho
Transaction
successfully
completed
AcceptorCom
pletionAdvice
Completion advice
Transaction
without capture might
authorised and
be used
tionAdvice Response completed
AcceptorComple

capture Transfer
Transaction
authorised and
possibly captured
Transfer
whether the transaction Resp onse
was captured or not
Acceptor aware that the

transaction was not
cleared yet
offline
AcceptorCanc
ellationAdvice
Authorisation and
capture reversed
esponse
ellationAdviceR
AcceptorCanc
Batch transfer with
transaction flagged as AcceptorBatch
Transfer
cancelled
tchTransfer
AcceptorBa
Response
908 Figure 26: Cancellation in batch mode of a transaction captured but not yet cleared

909 2.5 Batch
910 2.5.1 Introduction
911 Batch allows an Acceptor to send groups of transactions in a single message or a file to the Acquirer
912 for financial capture.
913 A batch transfer exchange is composed of an AcceptorBatchTransfer and an

914 AcceptorBatchTransferResponse used to acknowledge or to reject some or all transactions contained
915 in a batch.
916 Towards the Acquirer
917 The AcceptorBatchTransfer to be uploaded contains locally stored offline and online transactions.
918 In addition to financial transactions (payments, refunds, etc.) non-financial transactions (incomplete,
919 declined, etc.) may be added to an AcceptorBatchTransfer.
920 TransactionTotals are part of the file to enable reconciliation.
921 Message or File integrity may be ensured through a security trailer.
922 Towards the Acceptor
923 The Acquirer informs the acceptor about the validation of AcceptorBatchTransfer content by sending
924 an AcceptorBatchTransferResponse message.
925 The Acceptor retains the stored transactions which were previously sent to the Acquirer until receiving
926 an AcceptorBatchTransferResponse message from the Acquirer.
927 The AcceptorBatchTransferResponse provides status information about the data received.
928 The Acquirer informs the Acceptor about the transfer of data.
929
930 Once the Acceptor has received this notification, from a protocol perspective, the Acceptor is freed of
931 any technical responsibility to keep the data .
2 Message Exchange and Processes - 59 - 2.5 Batch

932 2.5.2 Data Organisation
933 2.5.2.1 AcceptorBatchTransfer
934 The upload of the data to be captured is initiated by an Acceptor using either a file transfer exchange
935 or exchanges of messages.
936 Data to be sent is organised into sets. An AcceptorBatchTransfer contains one or more sets.
937 A DataSet contains one or more financial and/or non-financial transactions. However it is possible that
938 a data set contains no transactions.
939 Data common to all transactions of a set may be factorised and sent prior to the transactions (e.g.
940 Acquirer data, POI data…)
941 The content of the set and its organisation depend on the POI configuration.
942 Its structure is represented as follows:
Header DataSet Trailer
0 .. n
DataSet Traceability DataSet Transaction Common Transaction

Identification Initiator Totals Data
943 Figure 27: BatchTransfer structure
944 2.5.2.2 AcceptorBatchTransferResponse

945 The Acquirer validates an AcceptorBatchTransfer with an AcceptorBatchTransferResponse according
946 to the following process:
947 The Acquirer sends back an AcceptorBatchTransferResponse to the Acceptor in

948 case of a message exchange, or
949  The Acceptor downloads an AcceptorBatchTransferResponse file.
950 The AcceptorBatchTransferResponse contains the response from the Acquirer for each DataSet that
951 has been processed. Any individual transactions that have been rejected by the Acquirer will be

952 contained within the appropriate DataSet response. An Acquirer can only send a DataSet in a
953 AcceptorBatchTransferResponse when all transactions in that DataSet have been processed.
954 If a set is partially approved, the element “DataSet” is present. It contains the details of rejected
955 transactions.
956 The content of the DataSet and its organisation depend on POI configuration.
957 File structure may be represented as follows:
Header TransactionTotals DataSet Trailer
0 .. n 0 .. n
DataSetIdentification DataSetResult RemoveDataSet DataSetInitiator TransactionTotals RejectedTransaction
0 .. n 0 .. n
958 Figure 28: BatchTransferResponse structure
959 2.5.2.3 Data Factorisation
960 To prevent file size problems, some data of an AcceptorBatchTransfer may be factorised to reduce the
961 occurrences of repetitive data.
962 The Acquirer must support factorisation. The Acceptor may choose whether to perform factorisation or
963 not.
964 Factorisation is limited to the following data:

965  Acquirer
966  Merchant
967  POI
968  PaymentContext
969  SaleContext
970  TransactionType
971  AdditionalService
972  ServiceAttribute
973  MerchantCategoryCode
974  Currency
975 All transaction components within a DataSet will inherit data from the values held in CommonData
976 unless different data is held in the transaction component itself.

977 The Acquirer sends an AcceptorBatchTransferResponse with the same DataSet factorisation as in the
978 related AcceptorBatchTransfer.
979 2.5.2.4 Multiplicity

980 Data elements which are mandatory in an AcceptorCompletionAdvice message are de facto
981 mandatory in an AcceptorBatchTransfer. Some of the elements may be factorised in CommonData
982 and in that case need not appear in the Transaction components but they must all be present in one
983 place or the other.
984 2.5.3 Types of Batch Transfer
985 A batch is generally used as a collection of transactions to be sent to an Acquirer for processing.
986 2.5.3.1 Batch containing Completion and Cancellation Transactions
987 An AcceptorBatchTransfer is sent by an Acceptor to an Acquirer. It contains a collection of completion

988 and cancellation transactions.
989 Completion transactions which may be sent as:

990  Successful debit transactions:
991  “TransactionType” with the value “CardPayment”; “CashAdvance",
992 "Reservation” or “DeferredPayment” and
993  “TransactionSuccess” with the value “True”
994  Successful credit transactions:
995  “TransactionType” with the value “Refund” or "OriginalCredit" and
996  “TransactionSuccess” with the value “True”
997  Failed or declined transactions:
998  “TransactionSuccess” with the value “False”;
999 Cancelled transactions are sent with “TransactionSuccess” having the value “True”
1000 Depending on a TMS configuration, the following types of transactions can be present or not :
1001  Debit and Credit transaction
1002  Failed transactions
1003  Declined transactions
1004  Cancelled transactions
1005 The AcceptorBatchTransferResponse file contains the response from the Acquirer for each DataSet
1006 that has been processed. Any individual transactions that have been rejected by the Acquirer must be
1007 contained within the appropriate DataSet response.
1008 An Acquirer can only send a DataSet in a BatchTransferResponse when all transactions in that
1009 DataSet have been processed.

1010 If a DataSet is not sent in the current AcceptorBatchTransferResponse, it will be added in a following
1011 AcceptorBatchTransferResponse and not necessary the next one. In consequence of which :
1012  Responses to one AcceptorBatchTransfer can be sent in several
1014  Responses for several AcceptorBatchTransfer can be sent in one
1015 AcceptorBatchTransferResponse. (See section 4.6 Batch.)
1016 The acquirer has to give a response in one DataSet for all the transactions contained in a DataSet
1017 received and only for these transactions.
1018 2.5.3.2 Batch containing Authorisation Transactions
1019 An AcceptorBatchTransfer is sent

1020  by an Acceptor to an Acquirer containing a collection of authorisation requests
1021  by an Acquirer to an Acceptor containing a collection of authorisation responses only.
1022 The use of authorisations in BatchTransfer is not configurable but depends on a bilateral agreement
1023 between an Acceptor and Acquirers involved.
1024 In the case of batch transferred authorisations:

1025  A DataSet in the batch sent from an Acceptor to an Acquirer contains only
1026 AuthorisationRequests,
1027  The batch sent from an Acquirer to an Acceptor contains only AuthorisationResponses.
1028 A batch of authorisations may contain:
1029  Debit transactions : AuthorisationRequest occurrences with “transactionType” data element
1030 value equal to “CardPayment”;
1031  Credit transactions : AuthorisationRequest occurrences with “transactionType” data element
1032 value equal to “ “Refund”;
1033  Debit transactions : AuthorisationResponse occurrences;
1034  Credit transactions :AuthorisationResponse occurrences .
1035 The rejected AuthorisationRequests are sent in a related AuthorisationResponse with Response
1036 set to "Declined". The BatchTransferResponse is not used for acknowledging AuthorisationRequests.
1037 In this case, a completion can be sent to nullify the effect of the authorisation request.
1038 A dataset containing a set of AuthorisationRequest in an AcceptorBatchTransfer message may be

1039 answered with multiple AcceptorBacthTransfer messages containing a dataset with the same
1040 identification.
1041 In this case, all the rejected transactions must be present in the first dataset containing responses.
1042 Responses contained in a dataset must refer to requests contained in only one dataset
1043 The acquirer can require to receive completions in the batch for previously authorised online
1044 transactions and / or authorised offline transactions.
1045  transactions authorised online are configured to be captured in batch (e.g. the TMS parameter
1046 AcquirerProtocolParameters.OnlineTransaction.FinancialCapture is equal to Batch)
1047  transactions authorised offline are configured to be captured in batch (e.g. the TMS parameter
1048 AcquirerProtocolParameters.OfflineTransaction.FinancialCapture is equal to Batch)

Acceptor Acquirer
Transaction initiated
offline
AcceptorBatch
Tr an
Authorisations initiated (AuthorisationRe sfer
by batch with capture quest)
Transactions
authorised and
captured
tchTransfer
AcceptorBa
ionResponse)
(Authorisat
Transaction
successfully
completed (approved/
declined) or rejected
AcceptorBatch
Transfer
(completion)
Batch transfer with
capture to void rejected
transactions
Rejected transaction
voided
hTransfe rResponse
AcceptorBatc
1049 Figure 29: Batch containing Financial Authorisations

Acceptor Acquirer
Transaction initiated
offline
AcceptorBatch
Transfer
Authorisations initiated (AuthorisationR
equest)
by batch
Transactions
authorised
chTransfer
AcceptorBat esponse)
nR
(Authorisatio
Transaction
successfully
completed (approved/
declined) or rejected
AcceptorBatch
Capture initiated by Transfer
(completion)
batch
Transactions
captured
spon se
hTransferRe
AcceptorBatc
1050 Figure 30: Batch containing Authorisations
1051 2.5.4 Configuration
1052 To configure batch exchange policy, the following rules must be applied:
1053  Month mean calendar month.
1054  Use the last day of the month for a monthly cyclic call when the day is bigger than the last day
1055 of the current month
1056  Combination of month and day don't need to be supported and a configuration with a
1057 combination may be rejected by a POI
1058  It's recommanded to put start time in the past and no end time.
1059  If the start time is in the future, the period is open until the start time
1060  If the end time is over, a manual reconciliation has to be done to close the period.
1061 Although theses rules are provided in the present document, the reference for configuration is the
1062 TMS MUG and not the Acquirer MUG

1063 2.6 Reconciliation Process
1065 Reconciliation is the process of performing checks and balances of transactions previously captured.
1066 This process is carried out between an Acceptor and an Acquirer for a given reconciliation period.
1067 An Acceptor initiates a reconciliation exchange to ensure that the debits and credits match the
1068 computed balances by the Acquirer and performed during the same reconciliation period.
1069 An AcceptorReconciliationRequest message is sent by the Acceptor to inform the Acquirer about the
1070 totals accumulated during the reconciliation period.
1071 An AcceptorReconciliationResponse message is returned by the Acquirer to inform the Acceptor

1072 about the totals accumulated during the reconciliation period.
Acceptor Acquirer
AcceptorReconciliationRequ
est
nse
AcceptorReconciliationRespo
1073 Figure 31: Reconciliation Exchange
1074 Should the Acceptor or the Acquirer detect a difference in totals, the discrepancy must then be
1075 resolved by other means and is outside the scope of this protocol.
1076 Reconciliation is not mandatory and reconciliation messages are never exchanged when the
1077 configuration parameter AcquirerProtocolParameters.ReconciliationExchange.ExchangePolicy defined
1078 in the AcceptorConfigurationUpdate TMS message has the value None or is absent.
2 Message Exchange and Processes - 66 - 2.6 Reconciliation Process

1079 2.6.2 Reconciliation Period Identification
1080 If reconciliation between an Acceptor and an Acquirer is required, each transaction belongs to one and
1081 only one reconciliation period identified by the message element
1082 Transaction.ReconciliationIdentification.
1083 Assignment of transactions to a reconciliation period can be made by either the Acceptor or the
1084 Acquirer depending on the TMS configuration parameter flag ReconciliationByAcquirer.
1085 If the reconciliation period assignment is under the control of the Acceptor (ReconciliationByAcquirer
1086 parameter is False), the reconciliation period is identified by the message element
1087 Transaction.ReconciliationIdentification in the AcceptorAuthorisationRequest,
1088 AcceptorCompletionAdvice, AcceptorCancellationRequest and AcceptorCancellationAdvice
1089 messages.
Acceptor Acquirer
ReconciliationIdentification:112 AcceptorAuthorisationReq
uest
onse
AcceptorAuthorisationResp
ReconciliationIdentification:112 AcceptorReconciliationReques
t
ReconciliationIdentification:112
se
AcceptorReconciliationRespon
1090 Figure 32: Reconciliation Period Assigned by the Acceptor

1091 During the reconciliation exchange, the reconciliation period is identified in the message element
1092 Transaction.ReconciliationIdentification of AcceptorReconciliationRequest and
1093 AcceptorReconciliationResponse.
Acceptor Acquirer
AcceptorAuthorisationReq
uest
onse
AcceptorAuthorisationResp
ReconciliationIdentification:113 AcceptorReconciliationReques
t
se
AcceptorReconciliationRespon
1094 Figure 33: Reconciliation Period Assigned by the Acquirer
1095 The reconciliation period of the transaction is identified by the ReconciliationIdentification at the time of
1096 the transaction capture. If the capture is performed during the completion, the
1097 AcceptorCompletionAdvice may have a ReconciliationIdentification value different from the
1098 Authorisation.
Acceptor Acquirer
ReconciliationIdentification:112 AcceptorAuthorisationRequest
transaction 1
AcceptorAuthorisationResponse without capture
transaction 1
ReconciliationIdentification:112 AcceptorReconciliationRequest
transaction 1 not in the totals
AcceptorReconciliationResponse
ReconciliationIdentification:113 AcceptorCompletionAdvice
transaction 1
capture of transaction 1
ponse
AcceptorCompletionAdviceRes
transaction 1
ReconciliationIdentification:113 AcceptorReconciliationRequest
transaction 1 in the totals
1099 Figure 34: Reconciliation between the Authorisation and the Completion

1100 When the flow of transaction cannot be stopped for closing the reconciliation at the acceptor, before
1101 sending the AcceptorReconciliationRequest message, the Acceptor must:
1102  Assigne the new transactions to the next reconciliation period, and
1103  Wait for the completion of the transactions of the reconciliation period to close
1104 before sending the AcceptorReconciliationRequest message.
1105 Successive reconciliation periods are then interleaved.
Acceptor Acquirer
AcceptorCompletionAdvice
transaction 1
open reconciliation period 113
reconciliation
AcceptorCompletionAdvice period 112
transaction 2
ponse
transaction 1
close reconciliation period 112
AcceptorReconc
ReconciliationIdentification:112 iliationReques
t
ponse
transaction 2
AcceptorCompletionAdvice reconciliation
ReconciliationIdentification:113 period 113
transaction 3
ponse
transaction 2
1106 Figure 35: Overlapping of Reconciliation Periods
1107 2.6.3 Transaction Totals
1108 Transaction totals are calculated from transactions completed and captured during the reconciliation
1109 period.
1110 Before initiating a reconciliation exchange, the Acceptor must:

1111 1) Perform the capture of all the transactions integrated in the totals of the reconciliation period,
1112 2) Inform the Acquirer about all the online cancelled transactions of the reconciliation period
1113 3) Inform the Acquirer about all the offline cancelled transactions, if these are integrated in the
1114 totals of the reconciliation period, and
1115 4) Inform the Acquirer about all the reversed online transactions of the reconciliation period.
1116 Transaction totals may be split in a sequence of repeated Transaction.TransactionTotals message

1117 elements, according to the following criteria:
1118  TransactionTotals.Type: the type of transaction, which is mandatory,
1119  TransactionTotals.POIGroupIdentification: the grouping of transactions made by the Acceptor,
1120 when the two following conditions are fulfilled:

1121  the acceptor is configured to split totals (TMS configuration parameter

1122 AcquirerProtocolParameters.SplitTotals is True), and
1123  the message element POI.GroupIdentification is present in AcceptorAuthorisationRequest,
1124 AcceptorCompletionAdvice, AcceptorCancellationRequest or AcceptorCancellationAdvice
1125 messages.
1126 The transactions where POI.GroupIdentification is absent have to be combined in instances of
1127 TransactionTotals without POIGroupIdentification.
1128  TransactionTotals.CardProductProfile: the card profile, when the two following conditions are
1129 fulfilled:
1130  the acceptor is configured to split totals (TMS configuration parameter
1131 AcquirerProtocolParameters.SplitTotals is True), and
1132  the message element Card.CardProductProfile is present in the
1133 AcceptorAuthorisationRequest, AcceptorCompletionAdvice, AcceptorCancellationRequest
1134 or AcceptorCancellationAdvice messages.
1135 The transactions where CardProductProfile is absent have to be combined in instances of
1136 TransactionTotals without CardProductProfile.
1137  TransactionTotals.Currency: the currency of the transaction, when the acceptor is configured
1138 to split totals per currency (TMS configuration parameter
1139 AcquirerProtocolParameters.TotalsPerCurrency is True). When TotalsPerCurrency is False,
1140 totals are computed whatever the currency and the TransactionTotals.Currency message
1141 element is absent.
1142 The Totals of declined and failed transactions are included in the ReconciliationRequest. A
1143 Reconciliation is never rejected because of differences with declined and failed transaction totals.
1144 If a cancellation is allowed after the reconciliation of the original transaction, the original transaction is
1145 considered as a Debit or Credit for the first reconciliation period, and the cancelled transaction
1146 considered as a DebitReverse or a CreditReverse respectively for the second reconciliation period.
1147 If a transaction can be cancelled on a different POI terminal from the POI terminal where the original
1148 transaction has been performed, and the totals are accumulated per POIGroupIdentification, the
1149 cancellation (DebitReverse or CreditReverse) is counted in the totals of the POIGroupIdentification
1150 related to the original transaction, even if the Cancellation transaction belongs to another reconciliation
1151 period.
1152 A difference in totals between the Acceptor and the Acquirer may occur after reaching the maximum
1153 number of retransmissions of an AcceptorCompletionAdvice (or AcceptorCancellationAdvice) without
1154 a positive AcceptorCompletionAdviceResponse (or AcceptorCancellationAdviceResponse). In this
1155 case, it is not possible for the Acceptor to determine the knowledge of the Acquirer about the outcome
1156 of the transaction because:
1157  The Acquirer may have not received or understood the repeated AcceptorCompletionAdvice
1158 (or AcceptorCancellationAdvice) messages,
1159  The Acquirer may have received and understood an AcceptorCompletionAdvice (or
1160 AcceptorCancellationAdvice) message, but the Acceptor has not received or has not
1161 understood the AcceptorCompletionAdviceResponse (or
1162 AcceptorCancellationAdviceResponse).

1163 2.6.4 Reconciliation Exchange
1164 The configuration parameter AcquirerProtocolParameters.ReconciliationExchange.ExchangePolicy

1165 defined in the AcceptorConfigurationUpdate TMS message determines whether an
1166 AcceptorReconciliationRequest message may be used or not.
1167 The Policy component of this configuration parameter can contain the following values:
1168  Cyclic: an AcceptorReconciliationRequest message is sent periodically according to the timing
1169 conditions defined in the AcquirerProtocolParameters.ReconciliationExchange.TimeCondition
1170 component.
1171  NumberLimit: an AcceptorReconciliationRequest message is sent as soon as the sum of all
1172 TransactionTotals.TotalNumber of the current reconciliation period reaches the value
1173 configured in the AcquirerProtocolParameters.ReconciliationExchange.MaximumNumber
1174 component.
1175  TotalLimit: an AcceptorReconciliationRequest message is sent as soon as the sum of all
1176 TransactionTotals.CumulativeAmount of the current reconciliation period reaches or exceeds
1177 the value configured in the
1178 AcquirerProtocolParameters.ReconciliationExchange.MaximumAmount component.
1179  OnDemand: an AcceptorReconciliationRequest message is sent when requested by the
1180 Acceptor.
1181  None: the Acceptor never sends AcceptorReconciliationRequest messages.
1182 The component Transaction.ClosePeriod may request the closure of a reconciliation period. This
1183 request is useful when the Acquirer assigns a reconciliation period identification to transactions.
1184 The response to an AcceptorReconciliationRequest message is either an AcceptorRejection message,

1185 or an AcceptorReconciliationResponse message with Response = "Approved" or "Declined".
1186 If there is no transactions in the reconciliation period, the AcceptorReconciliationResponse message

1187 must be sent with Response = "Approved".
1188 It is possible that the verification of the totals cannot be performed in real-time before sending the
1189 response to the reconciliation. In this case, the AcceptorReconciliationResponse message must
1190 contain:
1191  Response = "Approved".
1192  ResponseReason = "Totals Unavailable".
1193  TransactionTotals must be absent.
1194 If the totals are performed in real-time by the Acquirer, and some totals are different from the totals
1195 send by the Acceptor, the AcceptorReconciliationResponse message must contain:
1196  Response = "Declined".
1197  ResponseReason = "Difference in Totals".
1198  TransactionTotals must be present, as computed by the Acquirer.
1199 Whatever the result of the reconciliation (Response = "Approved" or "Declined"), a new reconciliation
1200 period has to be started to perform new transactions. Any difference or discrepancy has to be resolved
1201 outside the protocol.

1202 If the Acceptor did not receive an acceptable response to an AcceptorReconciliationRequest, it may
1203 send a new AcceptorReconciliationRequest message, with a copy of the body ReconciliationRequest,
1204 and a new value of ExchangeIdentification and CreationDateTime in the header.
1205 It is recommended to stop exchanging transactions during a reconciliation exchange.

1206 If it is not possible:
1207  the Acceptor assigns a new reconciliation period for the transactions that may follow,
1208  the Acceptor waits until the end of the transaction of the current reconciliation period,
1209  the Acceptor sends the required AcceptorCompletionAdvice (or AcceptorCancellationAdvice)
1210 messages (see section 2.6.3)
1211  the Acceptor starts the reconciliation exchange.
1212 2.6.5 Configuration

1213 To configure reconciliation exchange policy, the following rules must be applied:
1214  Month mean calendar month.
1215  Use the last day of the month for a monthly cyclic call when the day is bigger than the last day
1216 of the current month
1217  Combination of month and day don't need to be supported and a configuration with a
1218 combination may be rejected by a POI
1219  It's recommanded to put start time in the past and no end time.
1220  If the start time is in the future, the period is open until the start time
1221  If the end time is over, a manual reconciliation has to be done to close the period.
1222 Although theses rules are provided in the present document, the reference for configuration is the
1223 TMS MUG and not the Acquirer MUG

1224 2.7 Diagnostic Messages
1225 A diagnostic exchange is composed of an AcceptorDiagnosticRequest message and an

1226 AcceptorDiagnosticResponse message.
1227 An AcceptorDiagnosticRequest is a message sent by an InitiatingParty to a RecipientParty to check
1228 the availability, the security or the configuration of the dialogue with the RecipientParty.
1229 The Diagnostic message has been designed to perform specific administrative tasks without relying on
1230 “dummy” messages.
1231 An AcceptorDiagnosticResponse message is sent back by the RecipientParty to the InitiatingParty to
1232 confirm the availability of the RecipientParty.
Initiating Party Recipient Party
AcceptorDiagnosticRequ
est
onse
AcceptorDiagnosticResp
1233 Figure 36: Diagnostic Exchange
1234 An AcceptorDiagnosticRequest message is used to:

1235  Confirm the identification of the partners of the exchanges,
1236  Ensure that security on both sides of the dialogue is synchronised,
1237  Test the communication with a RecipientParty ,
1238  Endorse the version of the configuration parameters.
1239 If the AcceptorDiagnosticRequest message is received without errors by the RecipientParty, an
1240 AcceptorDiagnosticResponse message is sent back by the RecipientParty to the InitiatingParty.
1241 The RecipientParty uses an AcceptorDiagnosticResponse message to request the InitiatingParty to

1242 notify the RecipientParty about any maintenance operations that may be required.
1243 If the RecipientParty receives an AcceptorDiagnosticRequest message with errors or cannot process
1244 the message, an AcceptorRejection message is returned to the InitiatingParty with the appropriate
1245 RejectReason:
1246  UnableToProcess: the RecipientParty cannot process messages during a temporary period.
1247  InvalidMessage: Invalid envelope of the message
1248  ParsingError: Problem of format, absence of element, content of an element, etc.
1249  Security: Security error such as an invalid key or MAC
1250  InitiatingParty, RecipientParty: identification of the InitiatingParty or the RecipientParty is
1251 invalid.
1252  DuplicateMessage: The message is a duplicate message for a given InitiatingParty and a
1253 given RecipientParty when the following fields have the same value:
1254  Header.ExchangeIdentification,
1255  CreationDateTime and
1256  HeaderRetransmissionCounter if present.
1257  ProtocolVersion: The RecipientParty cannot support the version of the protocol contained in
1258 ProtocolVersion.
2 Message Exchange and Processes - 73 - 2.7 Diagnostic Messages

AcceptorDiagnosticReque
st
invalid message
AcceptorRejection
1259 Figure 37: Diagnostic Reject
1260 Should an InitiatingParty send an AcceptorDiagnosticRequest to an Agent, the Agent returns an

1261 AcceptorDiagnosticResponse to the InitiatingParty.
1262 An AcceptorDiagnosticRequest message does not contain any information that may allow an Agent to
1263 further route the message to another Agent or RecipientParty.
Acceptor Agent Acquirer
st
nse
AcceptorDiagnosticRespo
1264 Figure 38: Diagnostic Request from an Acceptor to an Agent
1265 An Agent must never forward an AcceptorDiagnosticRequest message.
1266 An Acceptor must only use an AcceptorDiagnosticRequest message under exceptional situations to
1267 avoid any potential risk of message congestion (e.g. after the installation of a payment application or
1268 during an update of electronic keys).
1269 An Intermediary Agent uses a diagnostic exchange to check the availability of the communication with
1270 an Acquirer or another Intermediary Agent.
st
nse
AcceptorDiagnosticRespo
1271 Figure 39: Diagnostic Request from an Intermediary Agent
2 Message Exchange and Processes - 74 - 2.7 Diagnostic Messages

1272 2.8 Reject Message
1273 A RecipientParty sends an AcceptorRejection message to an InitiatingParty to indicate that the

1274 RecipientParty could not process the received message.
1275 For instance, if an InitiatingParty sends an AcceptorAuthorisationRequest message and that message
1276 is not recognised by the RecipientParty, the RecipientParty sends back an AcceptorRejection in
1277 response to that message.
InitiatingParty RecipientParty
AcceptorAuthorisationReq
uest
message couldn’t
be processed
AcceptorRejection
1278 Figure 40: Rejection of an Authorisation
1279 The AcceptorRejection message contains the reason of the rejection (RejectReason), some additional
1280 information on the rejection (AdditionalInformation) for further analysis as well as the rejected
1281 message itself (MessageInError) (to make it possible to compare with the message sent).
1282 The AcceptorRejection message must be sent in the following cases:
1283 1. The envelope of the received message is incorrect (see section 3.4.1.2 a ).
1284 RejectReason contains the value InvalidMessage. It is recommended to include the optional fields
1285 AdditionalInformation to provide the details of the error. MessageInError contains the received
1286 message with the error.
1287 2. The rejected message cannot be decoded properly (see section 3.4.1.2 b ).
1288 RejectReason contains the value ParsingError. It is recommended to include the optional fields
1289 AdditionalInformation to provide the details of the coding error. MessageInError contains the
1290 received message with the coding error.
1291 3. The identification of the rejected message is invalid (see section 3.4.1.2 e ).
1292 RejectReason contains the value InitiatingParty or RecipientParty. No other field is required.
1293 AdditionalInformation may contain the invalid identifier.
1294 4. The verification of the security of the rejected message fails (see section 3.4.1.2 d ).
1295 RejectReason contains the value Security. It is recommended to include the optional fields
1296 AdditionalInformation to provide the details of the security error. MessageInError contains the
1297 received message with the security error.
2 Message Exchange and Processes - 75 - 2.8 Reject Message

1298 5. The version of the protocol used for the message (Header.ProtocolVersion) is not supported by
1299 the RecipientParty which is not able to send a message response of this version to the
1300 InitiatingParty (see section 3.4.1.2 c ).
1301 RejectReason contains the value ProtocolVersion and AdditionalInformation the invalid protocol
1302 version.
1303 6. The rejected message has already been sent by the InitiatingParty to the RecipientParty. The
1304 message could not be processed a second time, and then a response could not be sent (see
1305 section 3.4.1.2 f ).
1306 RejectReason contains the value DuplicateMessage. No other field is required.
1307 AdditionalInformation may contain the invalid ExchangeIdentifier value.
1308 7. The RecipientParty is not able to process the message for lack of resources. For that reason, a
1309 message response could not be built and the message is not processed (see section 3.4.1.3 b ).
1310 RejectReason has the value UnableToProcess. AdditionalInformation contains the reason why
1311 the message could not be processed.
1312 The reaction of the InitiatingParty to an AcceptorRejection message depends on the RejectReason
1313 and the type of rejected message.
1314 As an AcceptorRejection message is related to a specific request or an advice message between two
1315 entities, an Agent never forwards an AcceptorRejection message.
1316 In the example illustrated below, an Agent forwards an AcceptorAuthorisationRequest message issued
1317 by an Acceptor to the relevant Acquirer. The Acquirer cannot process the message and issues an
1318 AcceptorRejection message instead of an AcceptorAuthorisationResponse. The Agent receives the
1319 rejection message and sends to the card acceptor the appropriate AcceptorAuthorisationResponse
1320 message with TransactionResponse.ResponseToAuthorisation.Response containing the value
1321 Declined
authorisation
message couldn¶t
be processed
Declined
1322 Figure 41: Rejection of an Authorisation to an Agent
1323 However, when the acquirer returns an AcceptorRejection message with RejectReason set to
1324 UnableToProcess, in case of congestion of the acquirer host, the agent must return an
1325 AcceptorRejection message with the same RejectReason.

1326 In the example below, an Agent receives an AcceptorCompletionAdvice message issued by an

1327 Acceptor:
1328  The Agent performs the completion of the transaction, including the sending of:
1329  an AcceptorCompletionAdvice to the relevant Acquirer,
1330  a positive AcceptorCompletionAdviceResponse to the Acceptor without
1331 waiting for the response of the Acquirer.
1332  The Acquirer cannot process the message and sends an AcceptorRejection message instead
1333 of an AcceptorCompletionAdviceResponse message.
1334  The Agent receives the rejection message and initiates the message retransmission process
1335 (see section 3.3).
completion
process
se
AcceptorCompletionAdviceRespon message couldn’t
be processed
AcceptorRejection
1336 Figure 42: Rejection of an Completion to an Agent

1337 3 Message Functionalities
1338 3.1 Message Organisation
1339 A CAPE message is usually composed of three major functional blocks:

1340  a Message Header containing information related to the management of the message (routing
1341 and processing)
1342  a Message Body containing information related to the application processing of the message
1343  a Security Trailer containing information related to the security aspects of the message
1344 (optional).
1345 3.1.1 Management of the message
Message item Multiplicity

A [1..1]
Header
.
MessageFunction [1..1]
ProtocolVersion [1..1]
ExchangeIdentification [1..1]
ReTransmissionCounter [0..1]
CreationDateTime [1..1]
+ InitiatingParty [1..1]
+ RecipientParty [0..1]
+ TraceabilityInfo [0..1]
1346 The Header contains primary information required to either route the message to a specific destination
1347 (e.g. an intermediary agent) or to process the message in a specific way (e.g. retransmission, financial
1348 capture, etc.).
1349 The Header is composed of three major categories of information:

1350  Management information
1351  Parties involved in the transmission of the message
1352  Traceability information
3 Message Functionalities - 78 - 3.1 Message Organisation

1353 3.1.1.1 Management information

1354 The Management information regroups data components associated with the routing and/or
1355 processing of the message.
Message Item Mult. Usage

MessageFunction [1..1] Definition: This component identifies the type of process
related to the message.
Usage: Used mainly for routing purposes, namely in cases

where the message relies on some kind of processing (e.g.
message process with financial capture or without financial
capture).
ProtocolVersion [1..1] Definition: This component identifies the version of the
protocol used in the exchange.
Usage: The management of the protocol version is

described in sections 4.2.1 and 4.2.2 of the present
specifications.
ExchangeIdentification Definition: This component provides a unique identification
of the exchange of messages (request/response) for a
specific service.
Usage: This information is structured and used according

to guidelines provided by the Acquirer.
RetransmissionCounter Definition: This component identifies the number of
retransmissions for this message.
Usage: Retransmission is used for

AcceptorCompletionAdvice, AcceptorCancellationAdvice
and
AcceptorCurrencyConversionAdvice messages.
Retransmission of other messages is not allowed.
CreationDateTime Definition: This component identifies the date and time of
the creation of the message. This information is mandatory
and needs to be present in the related message.

1356 3.1.1.2 Parties involved in the message
1357 The parties mentioned in the Header are provided with the purpose of facilitating the routing of the
1358 message. The Header is not included when applying security to the message.
MessageItem Mult. Usage

InitiatingParty Definition: Party initiating the exchange. This can either be
the Acceptor or the party that initiates the exchange on
behalf of the Acceptor. This information is not part of the
secured section of the message.
Usage: Validate the origin of the exchange. The role of

InitiatingParty stays unchanged during the whole exchange
of the message (e.g. AcceptorCompletion Advice and
AcceptorCompletion AdviceResponse). The InitiatingParty
must always be present.
RecipientParty Definition: Party recipient of the exchange. This can either
be the Acquirer, or the party that received the exchange on
behalf of the Acquirer. This information is not part of the
secured section of the message.
Usage: Validate the destination of the exchange. The role

of RecipientParty stays unchanged during the whole
exchange of the message (e.g. AcceptorCompletionAdvice
and AcceptorCompletionAdviceResponse). The presence
of RecipientParty is configurable.

1359 3.1.1.3 Traceability information
1360 The Traceability information allows a RecipientParty to monitor the upstream transport and process of
1361 a message throughout its lifetime.
1362 In order to ensure an efficient traceability process end-to-end, each intermediary entity is invited to add
1363 its own Traceability information to the incoming message before sending the resulting message to the
1364 next party in the chain.
1365 The value and interest of this process depends on the actual use of this option by all intermediaries in
1366 the message exchange chain.
1367 Traceability provides useful information as regards the processing and transport time for the exchange
1368 of messages. This information can be used to carry out a global analysis of the performance of the
1369 exchanges of messages end-to-end. In case of delays in processing card payment transactions, it can
1370 also be used to identify the possible bottlenecks or problems encountered in the routing or processing
1371 of the message.
1372 This information is conditional and is not part of the secure section of the message.
MessageItem Mult. Usage

RelayIdentification Definition: Party relaying a message. This can be the
Acceptor, the Acquirer or any Intermediary Agent relaying a
message on behalf of the Acceptor or the Acquirer.
Usage: Used essentially to inform parties about the routing

process of the exchange (actual parties involved in the
exchange chain, time spent between agents in the chain,
problems encountered whilst processing or forwarding
messages, etc.). Whilst the use of this message is
conditional - once the relevant party has completed
RelayIdentification - it must further be enriched by all
following parties in the card payment chain.
TraceDateTimeIn Date and time of incoming messages for relaying or
processing
TraceDateTimeOut Date and time of outgoing messages for relaying or
processing

1373 3.1.2 ApplicationData

A [1..1]
Body
.
+ Environment [1..1]
+ Context [1..1]
+ Transaction [1..1]
1374 The Body of the message contains information related to the processing of the message by an
1375 application.
1376 The data is grouped by functional components such as:

1377  the environment of the card payment transaction in terms of actors involved (Acquirer,
1378 Merchant, POI, Card, Cardholder),
1379  the context of the transaction (payment and sale contexts)
1380  the information related to the card payment transaction itself.

1381 3.1.2.1 Environment

1382 The environment functional component contains information related to the main actors involved in or
1383 impacted by a payment transaction.
1384 Actors need to be understood in the present context as either organisations and individuals (Acquirer,
1385 Merchant, Cardholder) or objects (POI, Card).
1386 The InitiatingParty (part of the Header) and Merchant (part of the Body) may be distinct entities.
1387 The InitiatingParty may be an entity (e.g. a Processor) acting on behalf of the Merchant (or the
1388 Acquirer) to ensure the routing and processing of the message, whilst the Merchant and the Acquirer
1389 are entities involved in a commercial relationship associated with the actual provisioning of a card
1390 payment transaction to a Cardholder.

Acquirer [1..1] Definition: A party in a contractual relation with Merchants
and Card schemes accepting payments. The Acquirer makes
payments to the Merchant based on data received from the
Acceptor.
Usage: An Acquirer acquires card payment data from an

Acceptor and forwards the data to the relevant Card Issuer.
Merchant [1..1] Definition: A party providing goods and/or services at a sales
location (physical or virtual). The Merchant signs an acquiring
agreement with an Acquirer. The Merchant can perform the
role of Acceptor or delegate it to another party.
POI Definition: A Point of Interaction defines the entry point of a
card into a payment system to accept payment and loyalty
cards at a sales location. It is a general term used to include
all situations where payment details may be entered (e.g.
petrol pump, merchant checkout, internet, mail order,
telephone order, etc.).
Usage: The identification of the POI is usually allocated by a

Merchant, an Acceptor, an Intermediary Agent or an Acquirer.
Card Definition: A physical or virtual device to enable a payment
and to identify a Cardholder account.
Usage: The card is usually identified by its PAN and may be

additionally qualified by a card sequence number.
Cardholder Definition: A person presenting a Card or card information to
a Merchant for the purchase of goods and services.
Usage: This item contains data elements used to identify and

authenticate the cardholder.

1391 3.1.2.2 Context
1392 Context describes the two main types of contexts associated to a card payment transaction: a sale
1393 context (SaleContext) that identifies elements related to the commercial aspects of the transaction
1394 exclusively and a payment context (PaymentContext) which provides the elements of information for
1395 the payment associated with the sale transaction.

PaymentContext [1..1] Definition: This component identifies the elements of the
sales environment for payment.
SaleContext [0..1] Definition: This component contains elements that identify
the sale within the sales environment.
1396 3.1.2.3 Transaction
1397 This functional block contains all the information related to a card payment for which an authorisation
1398 or another type of operation is required.

Transaction [1..1] Definition: This component contains the transaction specific
application data.
Product Definition: This component identifies the class of goods
and/or services.
1399 3.1.3 SecurityTrailer

A [0..1]
SecurityTrailer
.
ContentType [1..1]
+ AuthenticatedData [0..*]
1400 The SecurityTrailer building block is conditional. It contains a message authentication code computed
1401 on the body of the message with a cryptographic key. It allows the authentication of the Initiator and
1402 protects the content of the body against any unauthorised alteration of the message.
1403
ContentType [1..1] Definition: This component identifies the type of security
used for the message (authentication).
AuthenticatedData [0..*] Definition: This component contains the Message
Authentication Code (MAC) for the message body with the
required information to check it.

1404 3.2 Traceability

1405 3.2.1 Security level
1406 No security is required for traceability data. Traceability is not included in data elements taken into
1407 account for the computation of the MAC.
1408 3.2.2 Usage Condition

1409 The presence of Traceability is configurable. When Traceability is configured as required, traces must
1410 be present on the following messages: AcceptorAuthorisationRequest, AcceptorCompletionAdvice,
1411 AcceptorCancellationRequest and AcceptorCancellationAdvice.
1412 3.2.3 Traceability in an exchange

1413 The path of traceability goes from the Acceptor back to the Acceptor and includes all intermediate
1414 steps. In other terms, it means that when the Acceptor receives the response, the whole traceability of
1415 the Acceptor to Acquirer domain is in the header.
1416 For the entity which initiates the transaction, the value of “TraceDateTimeIn” and the value of
1417 “TraceDateTimeOut” are the same.
1418 An intermediary agent and the acquirer must populate Traceability if a previous entity has populated it;
1419 The recipient must update Traceability when a message is received containing trace information by
1420 adding a new trace entry with TraceTimeIn set to the time the recipient received the new message and
1421 TraceDateTimeOut set to the time the recipient sent the message to the next party.
3 Message Functionalities - 85 - 3.2 Traceability

AcceptorAuthorisationRequest
Identification: poi1 Identification: ia1 InitiatingParty RecipientParty
RelayIdentification Identification: ia2 Identification: acq1
Identification: poi1 RelayIdentification
TraceDateTimeIn: 2011:07:05T11:21:17.45+0200 Identification: poi1
TraceDateTimeOut: 2011:07:05T11:21:17.45+0200 TraceDateTimeIn: 2011:07:05T11:21:17.45+0200
TraceDateTimeOut: 2011:07:05T11:21:17.45+0200
RelayIdentification
Identification: ia2
TraceDateTimeIn: 2011:07:05T11:21:16.89+0200
AcceptorAuthorisationResponse
Identification: ia2 Identification: acq1
RelayIdentification
Identification: poi1
RelayIdentification
Identification: ia2
RelayIdentification
Identification: acq1
Identification: poi1 Identification: ia1
RelayIdentification
Identification: poi1
RelayIdentification
Identification: ia2
RelayIdentification
Identification: acq1
RelayIdentification
Identification: ia1
1422 Figure 43: Example of Traceability with an Intermediary Agent
3 Message Functionalities - 86 - 3.2 Traceability

1423 3.3 Message Retransmission
1424 An Acceptor retransmits a message when no response was received to an advice message sent to an
1425 Acquirer.
1426 Retransmission is used for AcceptorCompletionAdvice, AcceptorCancellationAdvice and

1427 AcceptorCurrencyConversionAdvice messages only. Retransmission of other messages is not
1428 allowed.
1429 The purpose of retransmission is to ensure that an Acquirer has received and processed such
1430 messages. The Acceptor initiates a retransmission process if the response to an advice is not
1431 received.
1432 A repeated advice message holds an unchanged copy of the message body which was originally sent.
1433 RetransmissionCounter and CreationDateTime are the only data element which are modified in the
1434 Header for each retransmission. In particular, the ExchangeIdentification has the same value for all
1435 retransmissions of the same message. For DUKPT key management, because of the key evolution,
1436 the Acceptor may have to recompute the MAC to be able to verify the MAC of the response.
1437 3.3.1 Acceptor Behaviour

1438 The RetransmissionCounter is absent from the first transmission of the advice message, or has a
1439 value of 0. This component is present in every repeated advice message, with a value of 1 for the first
1440 repetition, and incremented by 1 for each new repetition.
1441 The number of message retransmissions must be limited, according to the configuration of the POI.
1442 The protocol does not address potential errors that may arise when the limit of retransmissions is
1443 reached.
Acceptor Acquirer
RetransmissionCounter:0 Advice
RetransmissionCounter:0
AdviceResponse
AdviceResponse not received

Advice is repeated
AdviceResponse
AdviceResponse received
End of retransmissions
1444 Figure 44: Retransmission of an Advice by the Acceptor
1445 The Acceptor stops the retransmission process upon receipt of a correct AdviceResponse message.
1446 The value of RetransmissionCounter has no impact on the acceptance of the Advice Response
1447 message.
3 Message Functionalities - 87 - 3.3 Message Retransmission

1448 3.3.1.1 Late Responses to an Advice message

1449 In the example below, a response to an advice message seems to be lost, since received late.
1450 The Acceptor retransmits the advice message to the Acquirer (RetransmissionCounter set to 1).
1451 The Acceptor initiates a second retransmission of the advice message (RetransmissionCounter value
1452 of 2) before a response to the first retransmitted advice message was received from the Acquirer.
1453 The receipt of the first advice response (RetransmissionCounter value of 1) by the Acceptor stops any
1454 further retransmission of the message.
1455 The receipt of the second advice response (RetransmissionCounter value of 2) by the Acceptor is
1456 simply ignored by the same party.
Acceptor Acquirer
Advice
AdviceResponse

Advice is repeated
AdviceResponse not received,
new repetition
1st repetition of AdviceResponse RetransmissionCounter:2

received, end of retransmissions
2nd repetition of
AdviceResponse is ignored
1457 Figure 45: Late Responses to an Advice message

1458 3.3.1.2 Unordered Responses to Retransmitted Advice messages

1459 In some circumstances, AdviceResponse messages may be received in a different order from that in
1460 which they were sent. In the example below, the response to a second retransmission is received by
1461 the Acceptor before receiving a response to the first retransmission.
1462 The response to the second retransmission (RetransmissionCounter value of 2) terminates the
1463 retransmission process and the Acceptor ignores the response to the first repetition
1464 (RetransmissionCounter value of 1).
Acceptor Acquirer
Advice
AdviceResponse

Advice is repeated
AdviceResponse not received,
new repetition
2nd repetition of AdviceResponse
received, end of retransmissions AdviceResponse
1st repetition of
AdviceResponse is ignored
1465 Figure 46: Unordered Responses to Retransmitted Advice messages

1466 3.3.2 Acquirer Behaviour
1467 An advice message with RetransmissionCounter set to 0 or absent means that the received message
1468 was an original one (e.g. not retransmitted).
1469 For each advice message received, the Acquirer sends back a response message to the Acceptor
1470 containing a copy of the RetransmissionCounter value.
1471 It is required for the Acquirer to send an advice response to every retransmissions of an advice.
Acceptor Acquirer
Process Advice,
send the AdviceResponse
AdviceResponse
Send the same AdviceResponse with
a copy of RetransmissionCounter
AdviceResponse
1472 Figure 47: Retransmission of an AdviceResponse by the Acquirer
1473 Since the original advice might never reach the Acquirer (due to a problem of communication, for
1474 instance), the retransmitted message received by the Acquirer (RetransmissionCounter set to 1) has
1475 to be considered as the original one and processed as such.
Acceptor Acquirer
Advice
Process Advice,
send the AdviceResponse
AdviceResponse
Send the same AdviceResponse with
a copy of RetransmissionCounter
AdviceResponse
1476 Figure 48: Non-Receipt of an Advice by the Acquirer
1477 Similarly, advice retransmissions are not necessarily received by the Acquirer in the order adopted by
1478 the Acceptor.

1479 3.4 Error Handling

1480 This section presents the errors related to an exchange of messages which occurs at a protocol level
1481 as:
1482  The format of the message, including the security,
1483  The identification of the parties involved,
1484  The management of messages, including version management, linking a request with its
1485 response, and message duplication,
1486  The communication between the sender and the receiver of a message, including the absence
1487 of a response.
1488 3.4.1 Error Cases

1489 Error cases, summarised in the figure below, are presented in the order the messages are
1490 processed by the parties during the exchange.
Acceptor Acquirer
Unable to send the message (3.4.4.1)

send the message Request or Unacceptable message (3.4.1.2)
Advice Or DuplicateMessage (3.4.1.8)
Unable to process the message (3.4.1.3)

wait for the response
process the message
Unable to send the message (3.4.1.4)

Response not received (3.4.1.5)
receive the response Response or send the response
AdviceResponse
Unacceptable message (3.4.1.6)
Or DuplicateMessage (3.4.1.8)
Unable to process the response (3.4.1.7)

process the response
1491 Figure 49: Error Cases in Message Exchange
1492 3.4.1.1 Acceptor is Unable to Send a Message

1493 An Acceptor is unable to send a request or an advice, and is aware that the Acquirer did
1494 not receive the complete message. This error occurs when:
1495 a) No open transport connection is available, and no transport connection to the Acquirer
1496 host could be opened, after reaching a maximum number of retries, or
1497 b) The sending of the complete message has failed for some reason reported by the
1498 transport layer.
3 Message Functionalities - 91 - 3.4 Error Handling

1499 3.4.1.2 Acquirer Receives an Unacceptable Message

1500 The message received by the Acquirer is not an acceptable message for one or several of
1501 the following reasons:
1502 a) The envelope of the received message is invalid:

1503  The tag of the XML root element is not Document,
1504  The root element contains more than one (child) element,
1505  The root element is empty and does not contain any element,
1506  The tag of the unique root child is not one of the following values: AccptrAuthstnReq,
1507 AccptrCmpltnAdvc, AccptrCxlReq, AccptrCxlAdvc, AccptrRcncltnReq, AccptrBtchTrf,
1508 AccptrDgnstcReq, AccptrCcyConvsReq or AccptrCcyConvsAdvc .
1509 b) The message cannot be decoded properly:

1510  The size of the message exceeds the maximum size the Acquirer is able to handle.
1511  The XML parser generates a parsing error. For instance, the message is not a well formed
1512 XML document, element that contains other elements has a non-empty content, elements
1513 contain mixed content, or the message contains unexpected entities as DTD or Processing
1514 Instructions.
1515  The XML version of the document is not 1.0,
1516  The character encoding is defined either in the XML prolog or in a byte order mark (BOM), but
1517 not as UTF-8 or EF BB BF respectively (the usage of a BOM for the messages is not
1518 recommended).
1519  The document contains invalid UTF-8 characters.
1520  The root element Document has no default XML Namespace declaration, or the name of the
1521 Namespace is incorrect, or the name of the Namespace is inconsistent with the single child of
1522 the root element (e.g. the AcceptorAuthorisationRequest message name is different from
1523 urn:iso:std:iso:20022:tech:xsd:caaa.001.001.xx) where xx = as it is set in
1524 version of the message defined in the Message Definition Report
1525  The sequence of elements defined in the schema for the message is not respected. The
1526 sequence of optional elements in a data structure must respect the sequence of elements
1527 defined in the XML/Schema (e.g. In the InitiatingParty, the data element Type cannot be after
1528 Issuer).
1529  A mandatory data structure, a mandatory data element is absent or a data element configured
1530 as "Mandatory" is absent (e.g. Header.ExchangeIdentification is absent).
1531  A data element has not a valid value for the type defined in the schema. For instance, a
1532 numeric data containing non numeric characters.
1533  The value of a data element is not belonging to the set of enumerated values defined in the
1534 schema or is not allowed (see section 4 Messages and Usage).
1535  The size of the value exceeds the maximum size defined in the schema.
1536  Inconsistency between data elements (e.g. Header.MessageFunction value inconsistent with
1537 the body of the message).
1538  A rule or a condition of presence defined in the section 4 is not respected (e.g.
1539 Response=Approved and an Action with ActionType=Referral in the
1540 AcceptorAuthorisationResponse message).
1541 If an optional data element that is not expected but present in the message it must be ignored, and the
1542 message is not rejected.
1543 If a data element or a data structure is not known by the receiver of the message (i.e. not present in
1544 the enclosing data structure definition), this data element is ignored (the schema validation of the XML
1545 message is not required).

1546 c) The version of the protocol used for the message (Header.ProtocolVersion) is not supported by the
1547 RecipientParty.
1548 d) The verification of the security of the message fails:

1549  A cryptographic key identification is invalid (including the Key Serial Number identification part
1550 of a DUKPT key),
1551  The cryptographic key has expired,
1552  The computed MAC does not match the MAC value sent in the message,
1553  The decrypted data is inconsistent (e.g. wrong format or invalid content).
1554 e) The identification of the sender (Header.InitiatingParty) or the receiver (Header.RecipientParty) of

1555 the message is invalid.
1556 f) The message is a duplicated message for a a given InitiatingParty and a given RecipientParty
1557 when the following fields have the same value:
1558  Header.ExchangeIdentification
1559  CreationDateTime
1560  Header.RetransmissionCounter if present.
1561 3.4.1.3 Acquirer is Unable to Process the Message

1562 The message received by the RecipientParty cannot be performed for one of the following
1563 reasons:
1564 a) The type of message (Header.MessageFunction) is not supported by the RecipientParty, which is
1565 not able to process the message and send a response message to the InitiatingParty.
1566 b) The RecipientParty is not able to process the message for lack of resources (e.g. congestion of
1567 server, HSM unavailable). For that reason, a message response could not be built and the
1568 message is not processed.
1569 3.4.1.4 Acquirer is Unable to Send a Message

1570 The Acquirer is unable to send a response to a request or an advice, and is sure that the
1571 complete message has not been received by the Acceptor. The error occurs when the
1572 transport connection previously open by the Acceptor to send the request or the advice,
1573 has been broken or released before the sending of the complete response message.

1574 3.4.1.5 Acceptor has not Received a Response Message

1575 No response to a request or an advice message has been received by the Acceptor,
1576 resulting from one of the following reasons:
1577 a) The transport connection used to send the request or advice has been released or broken, and the
1578 Acquirer is then unable to send the response messsage.
1579 b) The timer monitoring the receipt of the response message has expired before the receipt of the
1580 complete response message.
1581 3.4.1.6 Acceptor Receives an Unacceptable Message

1582 The message received by the Acceptor is not an acceptable message for one or several of
1583 the following reasons:
1584 a) The envelope of the received message is incorrect:

1585  The tag of the XML root element is not Document,
1586  The root element contains more than one (child) element,
1587  The root element does not contain any element,
1588  The tag of the unique root child is not one of the following values: AccptrAuthstnRspn,
1589 AccptrCmpltnAdvcRspn, AccptrCxlRspn, AccptrCxlAdvcRspn, AccptrCcncltnRspn,
1590 AccptrBtchTrfRspn, AccptrDgnstcRspn, AccptrRjctn, AccptrCcyConvsRspn or
1591 AccptrCcyConvsAdvcRspn .
1592 b) The message cannot be decoded properly:

1593  The size of the message exceeds the maximum size the Acceptor is able to handle.
1594  The XML parser generates a parsing error. For instance, the message is not a well formed
1595 XML document, element that contains other elements has a non-empty content, elements
1596 contain mixed content, or the message contains unexpected entities as DTD or Processing
1597 Instructions.
1598  The XML version of the document is neither 1.0, 1.1 nor 2.0,
1599  The character encoding is defined either in the XML prolog or in a byte order mark (BOM), but
1600 not as UTF-8 or EF BB BF respectively (the usage of a BOM for the messages is not
1601 recommended).
1602  The document contains invalid UTF-8 charaters.
1603  The root element Document has no default XML Namespace declaration, or the name of the
1604 Namespace is incorrect, or the name of the Namespace is inconsistent with the single child of
1605 the root element (e.g. the AcceptorAuthorisationResponse message name is different from
1606 urn:iso:std:iso:20022:tech:xsd:caaa.002.001.xx) where xx = as it is set in
1607 version of the message defined in the Message Definition Report
1608  The sequence of elements defined in the schema for the message is not respected (e.g.
1609 Header.InitiatingParty appears before Header.MessageFunction).
1610  A mandatory data structure or a mandatory data element is absent (e.g.
1611 Header.ExchangeIdentification is absent).
1612  A data element has not a valid value for the type defined in the schema. For instance, a
1613 numeric data containing non numeric characters.
1614  The value of a data element is not belonging to the set of enumerated values defined in the
1615 schema or is not allowed (see section 4 Messages and Usage).

1616  The size of the value exceeds the maximum size defined in the schema.
1617  Inconsistency between data elements (e.g. Header.MessageFunction value inconsistent with
1618 the body of the message).
1619  A rule or a condition of presence defined in the section 4 is not respected (e.g.
1620 ProtectedCardData and PlainCardData both present in the AcceptorAuthorisationResponse
1621 message).
1622  A data element in a Response message (resp. AdviceResponse message) is specified as
1623 "Copy", and has not the same value as in the related Request message (resp. Advice
1624 message).
1625 If a data element or data structure is not known by the receiver of the message, this data element is
1626 ignored (the schema validation of the XML message is not required).
1627 c) The verification of the security of the rejected message fails:

1628  A cryptographic key identification is invalid (including the Key Serial Number identification part
1629 of a DUKPT key), or is not the same than in the request,
1630  The cryptographic key has expired,
1631  The computed MAC does not match the MAC value sent in the message,
1632  The decrypted data is inconsistent (e.g. wrong format or invalid content).
1633 3.4.1.7 Acceptor is Unable to Process the Response Message

1634 The response message received by the Acceptor cannot be processed for one of the
1635 following reasons:
1636 a) The message cannot be considered as a response to the request or the advice:
1637  Message identification (Header.ExchangeIdentification, Header.InitiatingParty,
1638 Header.RecipientParty) does not have the same value as the request or the advice.
1639  If the response is not an AcceptorRejection, the message types (Header.MessageFunction or
1640 the message body) is not related to the request or the advice (e.g.
1641 MessageFunction=FinancialAuthorisationRequest in the request message and
1642 MessageFunction=AuthorisationResponse in the response message, or the message body
1643 AuthorisationRequest is in the request message and CancellationResponse in the response
1644 message).
1645  A data element specified as to be copied from the request or the advice has not the same
1646 value (e.g. Transaction.TransactionIdentification.TransactionDateTime or
1647 Transaction.TransactionIdentification.TransactionReference)
1648 b) The message received is an AcceptorRejection related to the request or the advice.
1649 c) The response message is received too late, i.e. after the expiration of the time out, or just after the
1650 transport connection release.
1651 3.4.1.8 Acquirer or Acceptor has received a Duplicate Message.
1652 Regardless of the root cause, the message received by the RecipientParty has already
1653 been received.
1654 See duplicate message definition below.
1655 In that case, the RejectReason is set to DuplicateMessage

1656 3.4.2 Acceptor Error Handling
1657 Errors handling of the Acceptor follow the process below:

1658 1) Error case detection, as described in the previous section (see 3.4.1 Error Cases).
1659 2) Error processing at a protocol level, depending on the type of exchange.
1660 3) Continue to process the exchange or
1661 4) Terminate the exchange and notify the error to the application.
1662 Following sections describe each type of error handling of the Acceptor and the
1663 conditions under which this handling has to be performed. The diagram below
1664 summarises for each error case defined in the section 3.4.1, the error handling per
1665 message the Acquirer must perform.
Acceptor
Unable to process
No response
Unacceptable unmatched response Unable to send
Unacceptable matched response
Too late response
DuplicateMessage
AuthorisationRequest CompletionAdvice Reconciliation All messages All messages

CancellationRequest CancellationAdvice Diagnostic
1 2 3 4 3
Reverse the Terminate Terminate
Retransmission Ignore
Transaction Exchange Exchange
Send Retransmit Terminate No action Terminate

CompletionAdvice CompletionAdvice exchange in error exchange in error
CancellationAdvice CancellationAdvice
with Reversal flag
Terminate
exchange in error
1666 Figure 50: Acceptor Error Handling in a Message Exchange

1667 3.4.2.1 Reverse the Transaction
1668 3.4.2.1.1 Conditions

1669 This process is executed by the Acceptor after sending an AcceptorAuthorisationRequest or an
1670 AcceptorCancellationRequest for the following error situations:
1671  The Acceptor has not received a response message (see section 3.4.1.5).
1672  The message is not an acceptable response (see section 3.4.1.6), and match a request in
1673 progress.
1674  The Acceptor is unable to process the response message (see section 3.4.1.7 a and b), and
1675 matches a request in progress.
1676 3.4.2.1.2 Action

1677 The Acceptor sends an AcceptorCompletionAdvice or an AcceptorCancellationAdvice to reverse the
1678 respectively the AcceptorAuthorisationRequest and the AcceptorCancellationRequest (setting
1679 Transaction.Reversal to the value True), and notifies the application of the failure of the exchange.
1680 3.4.2.2 Retransmission of the Advice

1682 This process is executed by the Acceptor after sending an AcceptorCompletionAdvice message or an
1683 AcceptorCancellationAdvice message for the following error situations:
1685  The message is not an acceptable response (see section 3.4.1.6), and matches an advice in
1686 progress.
1688 matches an advice in progress.
1689 3.4.2.2.2 Action

1690 The Acceptor retransmits the AcceptorCompletionAdvice or the AcceptorCancellationAdvice message
1691 in accordance to the section 3.3.1 Message Retransmission.

1692 3.4.2.3 Terminate the Exchange in Progress

1694 Whatever the type of exchange, this process is executed for the following error situations:
1695  The Acceptor is unable to send a request or an advice message (see section 3.4.1.1).
1696 This process is also executed after sending an AcceptorReconciliationRequest or an

1697 AcceptorDiagnosticRequest message for the following error cases:
1699  The message is not an acceptable response (see section 3.4.1.6), and matches a request in
1700 progress.
1702 matches an advice in progress.
1703 3.4.2.3.2 Action

1704 The Acceptor terminates the exchange in progress, and notifies the application of the failure of the
1705 exchange (e.g. unable to go online).
1706 3.4.2.4 Ignore the Error

1708 Whatever the type of exchange, this process is executed for the following circumstances:
1709  The message is not an acceptable response (see section 3.4.1.6), and could not be linked to
1710 the request or the advice in progress (unmatched response).
1712 could not be linked to the request or the advice in progress (unmatched response).
1713  The response message arrives too late (see section 3.4.1.7 c ).
1714 3.4.2.4.2 Action

1715 The Acceptor does not take any action, including any termination of exchange in progress.

1716 3.4.3 Acquirer Error Handling
1717 Errors handling of the Acquirer follow the process below:

1718 1) Error case detection, as described in the section 3.4.1 Error Cases.
1719 2) Error processing at a protocol level, depending on the type of exchange.
1720 3) Complete the exchange sending the appropriate response or
1721 4) Terminate the exchange and notify the error to the application.
1722 Following sections describe each type of error handling of the Acquirer and the conditions
1723 under which this process has to be performed.
Acquirer
Unacceptable message Retransmission of an Advice Unable to send

Unable to process the message
Message duplicated
CompletionAdvice
All messages CancellationAdvice All messages
CurrencyConversion
Advice
1 2 3
Message
Retransmission Ignore
Rejection
Send an Retransmit No action,

AcceptorRejection AdviceResponse exchange completed
1724 Figure 51: Acquirer Error Handling in a Message Exchange
1725 3.4.3.1 Message Rejection

1727 Whatever the type of request or advice message, this error handling process is executed for the
1728 following error cases:
1729  The Acquirer receives an unacceptable message (see section 3.4.1.2),
1730  The Acquirer is unable to process the message (see section 3.4.1.3),
1731  The Acquirer receives a duplicated message (see section 3.4.1.8).
1732 3.4.3.1.2 Action

1733 The Acquirer sends an AcceptorRejection message with the appropriate content, including the
1734 RejectReason value related to the type of error (see section 2.8 Reject Message).

1735 3.4.3.2 Retransmission of the Response

1737 This process is executed when the Acceptor retransmits an AcceptorCompletionAdvice message or an
1738 AcceptorCancellationAdvice message (see section 3.3).
1739 3.4.3.2.2 Action

1740 The Acquirer sends an advice response in accordance to the section 3.3.2 Message Retransmission.
1741 3.4.3.3 Ignore the Error

1743 Whatever the type of request or advice message, this process is executed for the following error case:
1744  The Acquirer is Unable to Send a Message (see section 3.4.1.4),
1745 3.4.3.3.2 Action

1746 The Acquirer does not take any action.

1747 4 Messages and Usage

1748 This chapter explains the usage, rules and conditions of presence for all data elements involved in
1749 normal payment transactions, and complements the Message Definition Report on the usage of
1750 message elements.
1751 4.1 Configuration Parameters/ Condition of Presence

1752 The "Rule" column contains the condition of presence for optional data elements, or some values for
1753 mandatory data elements. Those rules have been grouped in following classes:
1754  Config: the condition of presence and possibly the value of a component in the message
1755 depend on a configuration parameter of the Initiator of the message (e.g. the merchant
1756 common name – CommonName). The value may depend on the Recipient and/or the
1757 Acquirer of the transaction.
1758  Appli: the condition of presence of a component of the protocol depends on the payment
1759 application exclusively (e.g. the PIN – CardholderOnlinePIN).
1760  Copy : the value of the mandatory component or element is copied from a related message
1761 (e.g. the message exchange identification in the message response header –
1762 ExchangeIdentification – contains a copy of that in the request header)
1763  CCopy: this condition is specific to Advice message. The condition of presence and the value
1764 of a component of the Advice message complies to the following rules in that order:
1765  In the case of presence of this component in the Authorisation Response message,
1766 the value of the component is copied from the Authorisation Response message ;
1767  Or in case of presence of this component in the Authorisation Request message,
1768 the value of the component is copied from the Authorisation Request message ;
1769  Or when no authorisation exchange preceeded the completion one, the condition
1770 associated with the component of the authorisation applies also to the Completion
1771 Advice message.
1772 The "Usage" column may contain some information about the condition of presence of an optional
1773 element:
1774  Default: a default value is associated with the component of the message. The absence of the
1775 component produces the same result as the presence of the component with the default value
1776 (e.g. the message item Environment.Acquirer.Identification.Type has the comment "default
1777 Acquirer" at the beginning of the Rule column, meaning that an absent Acquirer.Identification
1778 is to having the value "Acquirer").
1779  Message-related: the condition of presence of a component of the protocol depends on the
1780 presence or value of another component in a related message. This kind of condition is also
1781 expressed at the beginning of the "Usage" column (e.g. the encrypted alternative of the
1782 sensitive card data – ProtectedCardData – is present if the following condition is satisfied "if
1783 Card.PlainCardData absent").
1784  On the last line of the Usage, the ISO 20022 short name used for XML encoding is provided.
1785 The data type is also provided for simple elements.
1786  Some sub elements are not provided to avoid redundancy. In this case, the comment “See
1787 MDR for sub element” is added in the line above the XML tag.
1788 The “Constraint” (Cstr) column contains information about conditional presence or interdependency
1789 between elements of the message:
1790  ‘*’: if a constraint exists directly on the presence or the value of an element (mark by a star ‘*’)
1791  ‘C<number>’: if a constraint exists due to interdependency of elements of the messages (e.g
1792 data element A must be present if data element B equals X). In this latter case the constraint
1793 is labelled as ‘C’ plus a number. These constraints may serve for semantic analysis.
4 Messages and Usage - 101 - 4.1 Configuration Parameters/ Condition of Presence

1794 4.2 Authorisation Messages
1795 4.2.1 AcceptorAuthorisationRequest (caaa.001.001.08)
Lvl AcceptorAuthorisationRequest Mult. Rule Cstr Usage

1 Header [1..1] It conveys information related to the protocol
management on a segment of the path from the
Acceptor to the Acquirer:
<Hdr>
2 MessageFunction [1..1] C1 The only valid codes to request an authorisation for a
C13 normal payment are:
AuthorisationRequest: Request without financial
capture (TransactionCapture="False")
FinancialAuthorisationRequest: Request with financial
capture TransactionCapture="True")
(if an invalid value is received, a Reject message is sent
by the Recipient with RejectReason equal to
"ParsingError")
<MsgFctn>::MessageFunction14Code
2 ProtocolVersion [1..1] * The current version is 8.0 (reference list of specification
documents). version is 8.0
<PrtcolVrsn>::Max6Text
2 ExchangeIdentification [1..1] Identifier per InitiatingParty/RecipientParty and per pair
of messages used to assign a response to a request and
to identify duplicate messages.
It may be used in combination with CreationDateTime to
allow the Recipient to identify retransmissions.
It may be a cyclic counter that increments by one with
each new message, starting at 0.
<XchgId>::Number
2 CreationDateTime [1..1] Date and time of the creation of the message Time
accuracy has to be at least tenth of a second.
<CreDtTm>::ISODateTime
2 InitiatingParty [1..1] Information used to identify the initiator of an exchange.
The content is bilaterally agreed between InitiatingParty
and RecipientParty.
<InitgPty>
3 Identification [1..1] Config The value of this identifier is bilaterally agreed between
InitiatingParty and RecipientParty. The Recipient of the
message must validate without ambiguity the Initiator of
the message.
<Id>::Max35Text
3 Type [0..1] Config * Indicates the type of InitiatingParty, allowed values:
OriginatingPOI: from POI Terminal to an Intermediary
Agent or an Acquirer.
IntermediaryAgent: from an Intermediary Agent to
another Intermediary Agent or an Acquirer.
Acceptor: from a POI server performing functions of
the payment application.
<Tp>::PartyType3Code
3 Issuer [0..1] Config Indicates the assigner of the Identification value of the
InitiatingParty.
<Issr>::PartyType4Code
4 Messages and Usage - 102 - 4.2 Authorisation Messages


3 Country [0..1] Config <Ctry>::Min2Max3AlphaText
3 ShortName [0..1] Config <ShrtNm>::Max35Text
2 RecipientParty [0..1] Config Information used to identify the recipient of an exchange.
The structure and content is bilaterally agreed between
InitiatingParty and RecipientParty.
<RcptPty>
3 Identification [1..1] Config <Id>::Max35Text
3 Type [0..1] Config * Indicates the type of RecipientParty, allowed values:
IntermediaryAgent: from POI System or an
Intermediary Agent to an Intermediary Agent.
Acquirer: from POI System or an Intermediary Agent
to an Acquirer.
3 Issuer [0..1] Config <Issr>::PartyType4Code
3 RemoteAccess [0..1] Based on NetworkParameters
<RmotAccs>
2 Traceability [0..*] Config see section 3.2 Traceability
<Tracblt>
3 RelayIdentification [1..1] <RlayId>
4 Identification [1..1] <Id>::Max35Text
4 Type [1..1] <Tp>::PartyType3Code
4 Country [0..1] <Ctry>::Min2Max3AlphaText
3 ProtocolName [0..1] <PrtcolNm>::Max35Text
3 ProtocolVersion [0..1] <PrtcolVrsn>::Max6Text
3 TraceDateTimeIn [1..1] <TracDtTmIn>::ISODateTime
3 TraceDateTimeOut [1..1] <TracDtTmOut>::ISODateTime
1 AuthorisationRequest [1..1] C1 The Header.MessageFunction must be
"AuthorisationRequest" or
"FinancialAuthorisationRequest".
(In case of an invalid value, a Reject message is sent by
the Recipient with RejectReason equal to "ParsingError")
<AuthstnReq>
2 Environment [1..1] <Envt>
3 Acquirer [0..1] Config Acquirer configuration parameter defines if this
component needs to be present.
<Acqrr>
4 Identification [0..1] Config <Id>
5 Identification [1..1] Appli Identification of the Acquirer or the Intermediary Agent
determined by the application from the card and other
data used in this transaction.
<Id>::Max35Text
5 Type [0..1] Appli * default Acquirer
Allowed values: Acquirer, IntermediaryAgent
5 Issuer [0..1] * Allowed values: Acquirer and IntermediaryAgent

5 Country [0..1] Country of the Acquirer (must be ISO 3166-1 alpha-2 or
alpha-3)
<Ctry>::Min2Max3AlphaText
5 ShortName [0..1] Name of the Acquirer or Intermediary Agent (e.g. name
of the bank or the processor)
<ShrtNm>::Max35Text
4 ParametersVersion [1..1] This value can be used by the Acquirer or the
Intermediary Agent to:
- decline the request if the configuration parameters
are obsolete,
- checks if a request to the POI to initiate an update
of its configuration parameters (populating
TMSTrigger in the response) is necessary.
This element may be filled with a configuration parameter
(DataSet.Identification.Version of the TMS data set of the
AcceptorConfigurationUpdate message)
<ParamsVrsn>::Max256Text
3 Merchant [0..1] C2 Present if it contains any data.
<Mrchnt>
5 Identification [1..1] Appli Identification of the Merchant determined by the
application profile.
<Id>::Max35Text
5 Type [0..1] Appli * default Merchant
Allowed values: Merchant, Acceptor, IntermediaryAgent
Merchant may be used to mention the retailer
headquarters name and/or details
Acceptor is used to identify the actual POI entity
processing the transaction (e.g. a subsidiary of the
Merchant)
5 Issuer [0..1] Config * The party assigning the identification.
Allowed values: Acquirer and IntermediaryAgent
5 ShortName [0..1] Config Name of the merchant assigned by the Acquirer or
IntermediaryAgent.
<ShrtNm>::Max35Text
4 CommonName [0..1] Config Name of the merchant as appearing on the receipt.
<CmonNm>::Max70Text
4 LocationCategory [0..1] Config Code usually derived from the merchant contract.
Indicates the type of location where the transaction took
place (e.g. train, in-flight, nomadic, etc.).
Note:
 for this data element MOTO corresponds to virtual
shop including electronic commerce
 Fixed corresponds to physical shop
<LctnCtgy>::LocationCategory1Code
4 LocationAndContact [0..1] Config Based on CommunicationAddress
<LctnAndCtct>


4 SchemeData [0..1] Config <SchmeData>::Max140Text
3 POI [0..1] <POI>
4 Identification [1..1] Identification of a POI terminal or system.
<Id>
5 Identification [1..1] Appli Part of the Acquirer/IntermediaryAgent or Merchant
configuration.
<Id>::Max35Text
5 Type [0..1] * default OriginatingPOI
Allowed values: OriginatingPOI, IntermediaryAgent
5 Issuer [0..1] Config * Allowed values: Merchant, Acquirer and
IntermediaryAgent
4 SystemName [0..1] Config Allows a fast identification of the POI type by the
Acquirer to monitor the transaction.
<SysNm>::Max70Text
4 GroupIdentification [0..1] Config This identifier can be used as a way for a merchant to
group a set of POI transactions for reconciliation.
<GrpId>::Max35Text
4 Capabilities [0..1] C3 Present if it contains any data.
<Cpblties>
5 CardReadingCapabilities [0..*] Config Capabilities available to the payment application.
<CardRdngCpblties>::CardDataReading5Code
CardholderVerificationCapabilities [0..*] Config Capabilities available to the payment application.
<CrdhldrVrfctnCpblties>::CardholderVerificationCapabilit
y4Code
PINLengthCapabilities [0..1] <PINLngthCpblties>::Number
ApprovalCodeLength [0..1] <ApprvlCdLngth>::Number
MaxScriptLength [0..1] <MxScrptLngth>::Number
CardCaptureCapable [0..1] <CardCaptrCpbl>::TrueFalseIndicator
5 OnLineCapabilities [0..1] Config Indicates whether the POI authorises transactions
exclusively offline (OffLine), exclusively online (OnLine)
or only authorises online if required by the payment
application (Semi OffLine).
<OnLineCpblties>::OnLineCapability1Code
5 MessageCapabilities [0..*] <MsgCpblties>
6 Destination [1..*] <Dstn>::UserInterface4Code
6 AvailableFormat [0..*] <AvlblFrmt>::OutputFormat1Code
6 NumberOfLines [0..1] <NbOfLines>::Number
6 LineWidth [0..1] <LineWidth>::Number
6 AvailableLanguage [0..*] <AvlblLang>::LanguageCode
4 TimeZone [0..1] Time zone name as defined by IANA (Internet Assigned
Numbers Authority) in the time zone data base. America/
Chicago or Europe/Paris are examples of time zone
names.
<TmZone>::Max70Text


4 TerminalIntegration [0..1] Indicates the type of integration of the POI terminal in the
sale environment.
INDR Indoor Indoor terminal.

IPMP Inside Pump Terminal incorporated in the pump
dispensing petrol.
MPOI Multiple POITerminal Multiple terminals linked
to a unique sale terminal.
MPMP MultiplePump Outdoor terminal serving
several petrol pumps.
MSLE MultipleSaleTerminal Terminal serving multiple
sale terminals.
SSLE SingleSaleTerminal Terminal linked to a unique
sale terminal.
VNDG VendingMachine Terminal integrated in a vending
machine
<TermnlIntgtn>::LocationCategory3Code
4 Component [0..*] Config / Based on PointOfInteractionComponent
Appli
Information used by the Acquirer for :
 The traceability of components used for the
transaction.
 Identifying the version of the component (this
information may cause the TMSTrigger to be set in
the response).
 The approval of POI components.
<Cmpnt>
3 Card [0..1] Config The Acquirer configuration indicates if either
ProtectedCardData or PlainCardData is present (e.g.
TMS parameter
AcquirerProtocolParameters.ProtectCardData).
<Card>
4 ProtectedCardData [0..1] C4 Present if Card.PlainCardData absent.
Encryption of the PlainCardData component, including
the envelope, using CMS ContentType.EnvelopedData..
See MDR for sub elements
<PrtctdCardData>
4 PrivateCardData [0..1] Can be used to carry Card data encrypted by private
format not covered by nexo Standard, P2PE product for
example.
<PrvtCardData>::Max100KBinary
4 PlainCardData [0..1] C4 Present if ProtectedCardData absent.
<PlainCardData>
5 PAN [1..1] <PAN>::Min8Max28NumericText
5 CardSequenceNumber [0..1] Appli <CardSeqNb>::Min2Max3NumericText
5 EffectiveDate [0..1] Appli <FctvDt>::Max10Text
5 ExpiryDate [1..1] <XpryDt>::Max10Text
5 ServiceCode [0..1] Appli <SvcCd>::Exact3NumericText
5 Track1 [0..1] <Trck1>::Max76Text
5 CardholderName [0..1] <CrdhldrNm>::Max45Text
4 PaymentAccountReference [0..1] Unique reference to the card, used by both merchants
and acquirers to link tokenised and non-tokenised
transactions associated to the same underlying card.


<PmtAcctRef>::Max70Text
4 MaskedPAN [0..1] <MskdPAN>::Max30Text
4 IssuerBIN [0..1] Bank identifier number of the issuer for routing purpose
<IssrBIN>::Max15NumericText
4 CardCountryCode [0..1] Appli Alphabetic with 2 or 3 characters, or numeric code
conforms to ISO 3166 – 1. Indicates the country of the
card issuer.
<CardCtryCd>::Max3Text
4 CardCurrencyCode [0..1] Currency code of the card issuer (ISO 4217 numeric
code).
<CardCcyCd>::Exact3AlphaNumericText
4 CardProductProfile [0..1] Config Defines the acceptance processing and rules performed
by the POI, after analysis of the application profile.
Assigned by the Acquirer.
<CardPdctPrfl>::Max35Text
4 CardBrand [0..1] Appli Brand name of the card or the scheme.
<CardBrnd>::Max35Text
4 CardProductType [0..1] <CardPdctTp>::CardProductType1Code
4 CardProductSubType [0..1] <CardPdctSubTp>::Max35Text
4 InternationalCard [0..1] “True” if the card may be used abroad. Else “False” for
domestic cards only.
<IntrnlCard>::TrueFalseIndicator
4 AllowedProduct [0..*] Product that can be purchased with the card. The list of
allowed products contained in some specific cards (eg.
Petrol cards)
<AllwdPdct>::Max70Text
4 ServiceOption [0..1] Options to the service provided by the card.
<SvcOptn>::Max35Text
4 AdditionalCardData [0..1] Appli Additional data taken from specific card products.
<AddtlCardData>::Max70Text
3 CustomerDevice [0..1] Device used by the customer to perform the payment
transaction
<CstmrDvc>
4 Identification [0..1] Identification of the customer device used for payment
<Id>::Max35Text
4 Type [0..1] Type of the device in free text
<Tp>::Max35Text
4 Provider [0..1] Provider of the device
<Prvdr>::Max35Text
3 Wallet [0..1] Container for tenders used by the customer to perform
the payment transaction.
<Wllt>
4 Identification [0..1] Identification of the wallet used for payment
<Id>::Max35Text
4 Type [0..1] Type of wallet in free text


<Tp>::Max35Text
4 Provider [0..1] Provider of the wallet
<Prvdr>::Max35Text
3 PaymentToken [0..1] Based on type CardPaymentToken..
<PmtTkn>
3 Cardholder [0..1] C5 Present if it contains any data.
<Crdhldr>
4 Identification [0..1] Appli For verification of the Cardholder identity. A Cardholder
may be identified by more than one identification method.
<Id>
5 DriverLicenseNumber [0..1] <DrvrLicNb>::Max35Text
5 DriverLicenseLocation [0..1] <DrvrLicLctn>::Max35Text
5 DriverLicenseName [0..1] <DrvrLicNm>::Max35Text
5 DriverIdentification [0..1] <DrvrId>::Max35Text
5 CustomerNumber [0..1] <CstmrNb>::Max35Text
5 SocialSecurityNumber [0..1] <SclSctyNb>::Max35Text
5 AlienRegistrationNumber [0..1] <AlnRegnNb>::Max35Text
5 PassportNumber [0..1] <PsptNb>::Max35Text
5 TaxIdentificationNumber [0..1] <TaxIdNb>::Max35Text
5 IdentityCardNumber [0..1] <IdntyCardNb>::Max35Text
5 EmployerIdentificationNumber [0..1] <MplyrIdNb>::Max35Text
5 EmployeeIdentification-Number [0..1] <MplyeeIdNb>::Max35Text
5 JobNumber [0..1] <JobNb>::Max35Text
5 Department [0..1] <Dept>::Max35Text
5 EmailAddress [0..1] <EmailAdr>::Max256Text
5 DateAndPlaceOfBirth [0..1] <DtAndPlcOfBirth>
6 BirthDate [1..1] <BirthDt>::ISODate
6 ProvinceOfBirth [0..1] <PrvcOfBirth>::Max35Text
6 CityOfBirth [1..1] <CityOfBirth>::Max35Text
6 CountryOfBirth [1..1] <CtryOfBirth>::CountryCode
5 Other [0..*] <Othr>
6 IdentificationType [1..1] <IdTp>::Max35Text
4 Name [0..1] Appli For verification of the Cardholder identity.
<Nm>::Max45Text
4 Language [0..1] Appli Advise the Acquirer of the cardholder language so that
messages to the Cardholder can be customized to that
language.
<Lang>::LanguageCode
4 BillingAddress [0..1] Based on PostalAddress22
<BllgAdr>
4 TripNumber [0..1] <TripNb>::Max35Text
4 Vehicle [0..1] <Vhcl>
5 VehicleNumber [0..1] <VhclNb>::Max35NumericText
5 TrailerNumber [0..1] <TrlrNb>::Max35NumericText
5 VehicleTag [0..1] <VhclTag>::Max35Text
5 VehicleTagEntryMode [0..1] <VhclTagNtryMd>::CardDataReading5Code


5 UnitNumber [0..1] <UnitNb>::Max35NumericText
5 ReplacementCar [0..1] <RplcmntCar>::TrueFalseIndicator
5 Odometer [0..1] <Odmtr>::DecimalNumber
5 Hubometer [0..1] <Hbmtr>::DecimalNumber
5 TrailerHours [0..1] <TrlrHrs>::Max35Text
5 ReferHours [0..1] <RefrHrs>::Max35Text
5 MaintenanceIdentification [0..1] <MntncId>::Max35Text
5 DriverOrVehicleCard [0..1] <DrvrOrVhclCard>
6 AdditionalCardData [0..*] <AddtlCardData>::Max35Text
6 EntryMode [0..1] <NtryMd>::CardDataReading5Code
5 AdditionalVehicleData [0..*] <AddtlVhclData>
6 Type [0..1] <Tp>::Max35Text
6 Data [1..1] <Data>::Max35Text
4 Authentication [0..*] Appli Method and data used or intended to be used for this
transaction to authenticate the owner of the card.
<Authntcn>
5 AuthenticationMethod [1..1] Method used to authenticate the cardholder:
<AuthntcnMtd>::AuthenticationMethod5Code
5 AuthenticationValue [0..1] C6 Present if AuthenticationMethod="SecureCertificate" or
"SecureNoCertificate".
(e.g. Visa Cardholder Authentication Verification Value
(CAVV) or Mastercard Accountholder Authentication
Value (AVV).
<AuthntcnVal>::Max5000Binary
5 ProtectedAuthenticationValue [0..1] See MDR for sub elements
<PrtctdAuthntcnVal>
5 CardholderOnLinePIN [0..1] C7 Present if AuthenticationMethod="PINOnline"
PIN verification by the Issuer during an online
authorisation.
<CrdhldrOnLinePIN>
6 EncryptedPINBlock [1..1] Transport the PIN in an encrypted form using the
EnvelopedData CMS data structure.
<NcrptdPINBlck>
6 PINFormat [1..1] Appli <PINFrmt>::PINFormat3Code
6 AdditionalInput [0..1] Appli Additional information required for the PIN verification,
(e.g. the driver number for some fleet cards).
<AddtlInpt>::Max35Text
5 CardholderIdentification [0..1] See MDR for sub elements
<CrdhldrId>
5 AddressVerification [0..1] C8 Present if it contains any data
For verifying the cardholder's billing address.

<AdrVrfctn>
6 AddressDigits [0..1] Appli Numerics from the cardholder's address excluding the
postal code (i.e. house number).
<AdrDgts>::Max5NumericText
6 PostalCodeDigits [0..1] Appli Numerics from the cardholder's postal code.
<PstlCdDgts>::Max5NumericText
5 AuthenticationType [0..1] Type of authentication for a given method - e.g. three-
domain authentication, scheme-proprietary
authentication, etc.
<AuthntcnTp>::Max35Text
5 AuthenticationLevel [0..1] Level of authentication for a given type – e.g. value
assigned by scheme rules or by bilateral agreements
<AuthntcnLvl>::Max35Text
5 AuthenticationResult [0..1] Result of authentication
<AuthntcnRslt>::AuthenticationResult1Code
5 AuthenticationAdditional- [0..1] Additional information related to the result of the
Information authentication
<AuthntcnAddtlInf>::Max35Text
4 TransactionVerificationResult [0..*] Result of performed verifications for the transaction.
Several methods may have been used for verification
<TxVrfctnRslt>
5 Method [1..1] Method of verification that has been performed.
<Mtd>::AuthenticationMethod6Code
5 VerificationEntity [0..1] Entity or device that has performed the verification
<VrfctnNtty>::AuthenticationEntity2Code
5 Result [0..1] Result of the verification.
<Rslt>::Verification1Code
5 AdditionalResult [0..1] Additional result of the verification
<AddtlRslt>::Max500Text
4 PersonalData [0..1] Appli Not to be used for cardholder identification or
authentication.
<PrsnlData>::Max70Text
3 ProtectedCardholderData [0..1] See MDR for sub elements
<PrtctdCrdhldrData>
2 Context [1..1] <Cntxt>
3 PaymentContext [0..1] <PmtCntxt>
4 CardPresent [0..1] C9 default True
Indicates whether the transaction has been initiated by a
card physically present or not:
Not present if CardDataEntryMode="AccountData",
Present or not if CardDataEntryMode="Physical",
Present for other values of CardDataEntryMode.
<CardPres>::TrueFalseIndicator
4 CardholderPresent [0..1] C10 default True
Indicates whether the transaction has been initiated in
presence of the cardholder or not (e.g. False for the 2nd
and subsequent payments on a recurring transaction).

<CrdhldrPres>::TrueFalseIndicator
4 OnLineContext [0..1] <OnLineCntxt>::TrueFalseIndicator
4 AttendanceContext [0..1] Config C10 If CardholderPresent is "True":
Attended: an attendant is present and performs the
financial transaction (face to face).
SemiAttended: one attendant monitors several POIs, to
offer assistance if needed.
Unattended: an attendant is not present
Otherwise the element is absent
<AttndncCntxt>::AttendanceContext1Code
4 TransactionEnvironment [0..1] default Merchant
Information required by some Acquirers or card
schemes:
Merchant: POI is located at the premises of the
merchant.
Private: remote payment, not at the premises of the
merchant
Public: POI is located in a public area, not at the
premises of the merchant.
<TxEnvt>::TransactionEnvironment1Code
4 TransactionChannel [0..1] Config Information required by some Acquirers or card schemes
for specific environments.
MailOrder: services or good purchased by mail
(written).
TelephoneOrder: services or good purchased by phone
(voice)
ElectronicCommerce: services or good purchased by
Internet (electronic)
TelevisionPayment: services or good purchased by TV
<TxChanl>::TransactionChannel5Code
4 AttendantMessageCapable [0..1] C11 default True
Indicates to the Acquirer whether a message in the
authorisation response can be displayed to the Cashier
or not.
<AttndntMsgCpbl>::TrueFalseIndicator
4 AttendantLanguage [0..1] C11 Present If AttendantMessageCapable is True
Indicates to the Acquirer in the Authorisation Response
message the language of the message to be displayed
to the Cashier.
<AttndntLang>::LanguageCode
4 CardDataEntryMode [0..1] C9 The entry mode used to get the card data, and not the
list of entry modes in case of fall-back.
.
<CardDataNtryMd>::CardDataReading6Code
4 FallbackIndicator [0..1] Appli default False
Card data entry mode fallback..
<FllbckInd>::CardFallback1Code
4 SupportedOption [0..*] Payment options the card acceptor can support.
<SpprtdOptn>::SupportedPaymentOption1Code
3 SaleContext [0..1] C12 Present if it contains any data.
Information provided by the sale system (e.g. EPAS
Retailer protocol).
<SaleCntxt>
4 SaleIdentification [0..1] Appli <SaleId>::Max35Text


4 SaleReferenceNumber [0..1] Appli <SaleRefNb>::Max35Text
SaleReconciliationIdentification [0..1] Appli <SaleRcncltnId>::Max35Text
4 CashierIdentification [0..1] Appli <CshrId>::Max35Text
4 CashierLanguage [0..*] <CshrLang>::LanguageCode
4 ShiftNumber [0..1] Appli <ShftNb>::Max2NumericText
4 CustomerOrderRequestFlag [0..1] <CstmrOrdrReqFlg>::TrueFalseIndicator
4 PurchaseOrderNumber [0..1] <PurchsOrdrNb>::Max35Text
4 InvoiceNumber [0..1] <InvcNb>::Max35Text
4 DeliveryNoteNumber [0..1] <DlvryNoteNb>::Max35Text
4 SponsoredMerchant [0..*] <SpnsrdMrchnt>
5 CommonName [1..1] <CmonNm>::Max70Text
5 Address [0..1] <Adr>::Max140Text
5 CountryCode [1..1] <CtryCd>::ISO3NumericCountryCode
5 MerchantCategoryCode [1..1] <MrchntCtgyCd>::Min3Max4Text
5 RegisteredIdentifier [1..1] <RegdIdr>::Max35Text
4 SplitPayment [0..1] <SpltPmt>::TrueFalseIndicator
4 RemainingAmount [0..1] <RmngAmt>::ImpliedCurrencyAndAmount
4 ForceOnlineFlag [0..1] <ForceOnlnFlg>::TrueFalseIndicator
4 ReuseCardDataFlag [0..1] <ReuseCardDataFlg>::TrueFalseIndicator
4 AllowedEntryMode [0..*] <AllwdNtryMd>::CardDataReading6Code
4 SaleTokenScope [0..1] <SaleTknScp>::SaleTokenScope1Code
4 AdditionalSaleData [0..1] Appli <AddtlSaleData>::Max70Text
3 DirectDebitContext [0..1] <DrctDbtCntxt>
4 DebtorIdentification [0..1] <DbtrId>
5 Debtor [0..1] <Dbtr>::PartyIdentification178Choice
6 AnyBIC [1..1] <AnyBIC>::AnyBICDec2014Identifier
6 ProprietaryIdentification [1..1] <PrtryId>
7 Issuer [1..1] <Issr>::Max35Text
7 SchemeName [0..1] <SchmeNm>::Max35Text
6 NameAndAddress [1..1] <NmAndAdr>
7 Name [1..1] <Nm>::Max70Text
7 Address [1..1] Based on PostalAdress2
<Adr>
5 AccountIdentification [0..1] <AcctId>::CashAccountIdentification7Choice
6 IBAN [1..1] <IBAN>::IBAN2007Identifier
6 BBAN [1..1] <BBAN>::BBANIdentifier
6 UPIC [1..1] <UPIC>::UPICIdentifier
6 DomesticAccount [1..1] <DmstAcct>
4 CreditorIdentification [1..1] <CdtrId>
5 Creditor [1..1] <Cdtr>::PartyIdentification178Choice


7 Address [1..1] Based on PostalAdress2
<Adr>
5 RegistrationIdentification [0..1] <RegnId>::Max35Text
4 MandateRelatedInformation [1..1] <MndtRltdInf>
5 MandateIdentification [1..1] <MndtId>::Max35Text
5 DateOfSignature [0..1] <DtOfSgntr>::ISODate
5 MandateImage [0..1] <MndtImg>::Max2MBBinary
2 Transaction [1..1] <Tx>
3 TransactionCapture [1..1] C13 If "True", this financial transaction must be captured for
clearing by the Acquirer.
MessageFunction value must be "AuthorisationRequest"
if TransactionCapture = "False",
"FinancialAuthorisationRequest" if TransactionCapture =
"True".
<TxCaptr>::TrueFalseIndicator
3 TransactionType [0..1] C14 <TxTp>::CardPaymentServiceType12Code
3 AdditionalService [0..*] <AddtlSvc>::CardPaymentServiceType9Code
3 ServiceAttribute [0..1] <SvcAttr>::CardPaymentServiceType3Code
3 LastTransactionFlag [0..1] <LastTxFlg>::TrueFalseIndicator
3 MerchantCategoryCode [0..1] Code assigned by the Acquirer, containing the
ISO18245-4 MCC code associated with the category of
services or goods purchased in this transaction (the
merchant can have several MCCs associated to its
business).
<MrchntCtgyCd>::Min3Max4Text
3 CustomerConsent [0..*] This enables retailers, if they so wish, to clearly indicate
whether the consent of the customer was explicitly
obtained for a given service instead of being implicitly
derived.
<CstmrCnsnt>::TrueFalseIndicator
3 CardProgrammeProposed [0..*] The card program proposed by a retailer to a cardholder
among a series of payment programmes offered by the
retailer.
<CardPrgrmmPropsd>::Max35Text
3 CardProgrammeApplied [0..1] * The card program actually selected by the cardholder
among the ones supported by the retailer and/or the one
actually proposed to him. At most one
CardProgrammeApplied should be provided.
<CardPrgrmmApld>::Max35Text
3 SaleReferenceIdentification [0..1] <SaleRefId>::Max35Text
3 TransactionIdentification [1..1] Based on TransactionIdentifier
Identification of the transaction assigned by the POI.
<TxId>
3 OriginalTransaction [0..1] Appli C15 Not used if TransactionType="CardPayment",
"DeferredPayment" or "CashBack". If
TransactionType="Refund", when available it must be
used to provide elements from the original transaction.
Not used if TransactionType="Reservation” and
ServiceAttribute=”InitialReservation”
If TransactionType="Reservation” and
ServiceAttribute=”UpdateReservation”, when available it
must be used to provide elements from the original
transaction.
Not used if TransactionType="Reservation and


ServiceAttribute=”“AdditionalPayment”
<OrgnlTx>
<TxId>
4 POIIdentification [0..1] Appli <POIId>
5 Type [0..1] default OriginatingPOI
InitiatorTransactionIdentification [0..1] If present in the original transaction
<InitrTxId>::Max35Text
RecipientTransactionIdentification [0..1] If present in the original transaction
<RcptTxId>::Max35Text
4 TransactionType [1..1] <TxTp>::CardPaymentServiceType12Code
4 CardDataEntryMode [0..1] <CardDataNtryMd>::CardDataReading5Code
4 TransactionResult [0..1] Appli <TxRslt>
5 AuthorisationEntity [0..1] <AuthstnNtty>
6 Issuer [0..1] Copy <Issr>::PartyType4Code
6 ShortName [0..1] Copy <ShrtNm>::Max35Text
ResponseToAuthorisation [1..1] <RspnToAuthstn>
6 Response [1..1] <Rspn>::Response4Code
6 ResponseReason [0..1] Appli <RspnRsn>::Max35Text
6 AdditionalResponse-Information [0..1] <AddtlRspnInf>::Max140Text
5 AuthorisationCode [0..1] Appli <AuthstnCd>::Min6Max8Text
3 InitiatorTransactionIdentification [0..1] Appli A value provided by the card acceptor that is meaningful
in the card acceptor’s system and that the acquirer can
use in referencing back to this transaction.
3 ReconciliationIdentification [0..1] Appli Identification of the reconciliation period assigned by the
POI to the transaction.
Conforming to the configuration parameters (by the
EPAS TMS configuration parameters
ReconciliationByAcquirer and ReconciliationExchange),
absent if:
The acquirer assigns the reconciliation period, and
provides it in the response, or
There is no reconciliation exchange (e.g. capture in
batch)
<RcncltnId>::Max35Text
3 TransactionDetails [1..1] <TxDtls>
4 Currency [0..1] Appli Currency of TotalAmount and DetailedAmount if present


<Ccy>::ActiveCurrencyCode
4 TotalAmount [1..1] Requested amount to be authorised, including
DetailedAmount occurrences.
<TtlAmt>::ImpliedCurrencyAndAmount
4 CumulativeAmount [0..1] <CmltvAmt>::ImpliedCurrencyAndAmount
4 AmountQualifier [0..1] C14 default Actual
Allowed values depends on the TransactionType value:
"CardPayment": Actual
"DeferredPayment": Estimated or Maximum
"Reservation": Estimated, Incremental or Decremental
<AmtQlfr>::TypeOfAmount8Code
4 DetailedAmount [0..1] Appli <DtldAmt>
5 AmountGoodsAndServices [0..1] <AmtGoodsAndSvcs>::ImpliedCurrencyAndAmount
5 CashBack [0..1] <CshBck>::ImpliedCurrencyAndAmount
5 Gratuity [0..1] <Grtty>::ImpliedCurrencyAndAmount
5 Fees [0..*] <Fees>
6 Amount [1..1] <Amt>::ImpliedCurrencyAndAmount
6 Label [0..1] <Labl>::Max140Text
5 Rebate [0..*] <Rbt>
5 ValueAddedTax [0..*] <ValAddedTax>
5 Surcharge [0..*] <Srchrg>
4 RequestedAmount [0..1] <ReqdAmt>::ImpliedCurrencyAndAmount
4 AuthorisedAmount [0..1] <AuthrsdAmt>::ImpliedCurrencyAndAmount
4 InvoiceAmount [0..1] <InvcAmt>::ImpliedCurrencyAndAmount
4 ValidityDate [0..1] Appli <VldtyDt>::ISODate
4 OnLineReason [0..*] Appli Indicates to the Acquirer the primary reason why the
transaction has been sent online by the Card Acceptor.
<OnLineRsn>::OnLineReason1Code
4 UnattendedLevelCategory [0..1] Appli Some card schemes may require for unattended POI
terminals that the application determines the category
level for the transaction.
The value of this data is set by the application in
compliance with the rules of the card scheme.
<UattnddLvlCtgy>::Max35NumericText
4 AccountType [0..1] Appli defaut Default
Allows a cardholder to select the type of account used for
the transaction.
<AcctTp>::CardAccountType3Code
4 CurrencyConversionResult [0..1] <CcyConvsRslt>
5 AcceptedByCardholder [0..1] <AccptdByCrdhldr>::TrueFalseIndicator
5 Conversion [0..1] <Convs>
6 CurrencyConversion-Identification [0..1] <CcyConvsId>::Max35Text
6 TargetCurrency [1..1] <TrgtCcy>
7 AlphaCode [1..1] <AlphaCd>::ActiveCurrencyCode


7 NumericCode [1..1] <NmrcCd>::Exact3NumericText
7 Decimal [1..1] <Dcml>::Number
6 ResultingAmount [1..1] <RsltgAmt>::ImpliedCurrencyAndAmount
6 ExchangeRate [1..1] <XchgRate>::PercentageRate
6 InvertedExchangeRate [0..1] <NvrtdXchgRate>::PercentageRate
6 QuotationDate [0..1] <QtnDt>::ISODateTime
6 ValidUntil [0..1] <VldUntil>::ISODateTime
6 SourceCurrency [1..1] <SrcCcy>
6 OriginalAmount [1..1] <OrgnlAmt>
7 ActualAmount [0..1] Actual amount to be converted
<ActlAmt>::ImpliedCurrencyAndAmount
7 MinimumAmount [0..1] Minimum amount for conversion (in case of range of
amounts)
<MinAmt>::ImpliedCurrencyAndAmount
7 MaximumAmount [0..1] Maximum amount for conversion (in case of range of
amounts)
<MaxAmt>::ImpliedCurrencyAndAmount
6 CommissionDetails [0..*] <ComssnDtls>
7 AdditionalInformation [0..1] <AddtlInf>::Max350Text
6 MarkUpDetails [0..*] <MrkUpDtls>
7 Rate [1..1] <Rate>::PercentageRate
6 DeclarationDetails [0..1] <DclrtnDtls>
7 Format [0..1] <Frmt>::OutputFormat1Code
7 MessageContent [1..1] <MsgCntt>::Max20000Text
4 Instalment [0..1] Appli <Instlmt>
5 InstalmentPlan [0..*] <InstlmtPlan>::InstalmentPlan1Code

5 PlanIdentification [0..1] <PlanId>::Max35Text
5 SequenceNumber [0..1] <SeqNb>::Number
5 PeriodUnit [0..1] <PrdUnit>::Frequency3Code
5 InstalmentPeriod [0..1] <InstlmtPrd>::Number
5 TotalNumberOfPayments [0..1] <TtlNbOfPmts>::Number
5 FirstPaymentDate [0..1] <FrstPmtDt>::ISODate
5 TotalAmount [0..1] <TtlAmt>::CurrencyAndAmount
5 FirstAmount [0..1] <FrstAmt>::ImpliedCurrencyAndAmount
5 Charges [0..1] <Chrgs>::ImpliedCurrencyAndAmount
4 AggregationTransaction [0..1] Appli <AggtnTx>
5 FirstPaymentDateTime [0..1] <FrstPmtDtTm>::ISODateTime
5 LastPaymentDateTime [0..1] <LastPmtDtTm>::ISODateTime
5 NumberOfPayments [0..1] <NbOfPmts>::Number
5 IndividualPayment [0..*] <IndvPmt>


6 DateTime [1..1] <DtTm>::ISODateTime
6 ICCRelatedData [0..1] <ICCRltdData>::Max10000Binary
4 ProductCodeSetIdentification [0..1] <PdctCdSetId>::Max10Text
4 SaleItem [0..*] Appli <SaleItm>
5 ItemIdentification [0..1] <ItmId>::Max35Text
5 ProductCode [1..1] <PdctCd>::Max70Text
5 AdditionalProductCode [0..1] <AddtlPdctCd>::Max70Text
5 UnitOfMeasure [0..1] <UnitOfMeasr>::UnitOfMeasure6Code
5 ProductQuantity [0..1] <PdctQty>::DecimalNumber
5 UnitPrice [0..1] <UnitPric>::ImpliedCurrencyAndAmount
5 UnitPriceSign [0..1] <UnitPricSgn>::PlusOrMinusIndicator
5 ProductAmount [1..1] <PdctAmt>::ImpliedCurrencyAndAmount
5 ProductAmountSign [0..1] <PdctAmtSgn>::PlusOrMinusIndicator
5 ValueAddedTax [0..1] <ValAddedTax>::ImpliedCurrencyAndAmount
5 TaxType [0..1] <TaxTp>::Max35Text
5 ProductDescription [0..1] <PdctDesc>::Max140Text
5 DeliveryLocation [0..1] <DlvryLctn>::Max10Text
5 DeliveryService [0..1] <DlvrySvc>::AttendanceContext2Code
5 SaleChannel [0..1] <SaleChanl>::Max70Text
5 AdditionalProductDescription [0..1] <AddtlPdctDesc>::Max256Text
4 AdditionalInformation [0..*] <AddtlInf>
5 Value [0..1] <Val>::Max100KBinary
5 ProtectedValue [0..1] See MDR for sub elements
<PrtctdVal>
4 ICCRelatedData [0..1] Appli A sequence of one or more TLV data elements in
accordance with ISO 7816-6, not in a specific order.
<ICCRltdData>::Max10000Binary
3 MerchantReferenceData [0..1] <MrchntRefData>::Max70Text
3 AccountFrom [0..1] <AcctFr>
4 SelectionMethod [0..1] <SelctnMtd>::AccountChoiceMethod1Code
4 SelectedAccountType [0..1] <SelctdAcctTp>::CardAccountType3Code
4 AccountName [0..1] <AcctNm>::Max70Text
4 AccountOwner [0..1] <AcctOwnr>
5 Address [1..1] Based on PostalAddress1
<Adr>
4 Currency [0..1] <Ccy>::ActiveCurrencyCode
4 AccountIdentifier [0..1] <AcctIdr>::AccountIdentification39Choice
5 Card [1..1] <Card>::Min8Max28NumericText
5 MSISDN [1..1] <MSISDN>::Max16Text
5 EMail [1..1] <EMail>::Max256Text
5 IBAN [1..1] <IBAN>::IBANIdentifier


5 Domestic [1..1] <Dmst>::Max35Text
5 Other [1..1] <Othr>::Max35Text
4 Servicer [0..1] <Svcr>::PartyIdentification177Choice
3 AccountTo [0..1] <AcctTo>
4 SelectionMethod [0..1] <SelctnMtd>::AccountChoiceMethod1Code
4 SelectedAccountType [0..1] <SelctdAcctTp>::CardAccountType3Code
4 AccountName [0..1] <AcctNm>::Max70Text
4 AccountOwner [0..1] <AcctOwnr>
5 Address [1..1] <Adr>
4 AccountIdentifier [0..1] <AcctIdr>::AccountIdentification39Choice
5 Card [1..1] <Card>::Min8Max28NumericText
5 MSISDN [1..1] <MSISDN>::Max16Text
5 EMail [1..1] <EMail>::Max256Text
5 IBAN [1..1] <IBAN>::IBANIdentifier
5 Domestic [1..1] <Dmst>::Max35Text
5 Other [1..1] <Othr>::Max35Text
4 Servicer [0..1] <Svcr>::PartyIdentification177Choice
3 AdditionalTransactionData [0..*] Appli <AddtlTxData>::Max70Text
2 SupplementaryData [0..*] Appli <SplmtryData>

3 PlaceAndName [0..1] <PlcAndNm>::Max350Text
3 Envelope [1..1] <Envlp>
1 SecurityTrailer [0..1] The MAC of the message body AuthorisationRequest
(including the body envelope) held in the
AuthenticatedData element of the CMS data structure.
<SctyTrlr>
1796 4.2.1.1 Constraints

1797 This section lists all business rules implying at least 2 different elements inside the message.
Constraint Definition Involved elements

Number
C1 When AuthorisationRequest is present the  Header.MessageFunction
Header.MessageFunction must be  AuthorisationRequest
AuthorisationRequest” or

“FinancialAuthorisationRequest”
C2 If  AuthorisationRequest.Environment.Merch
AuthorisationRequest.Environment.Merchant ant
is present it must have at least one child
C3 If  AuthorisationRequest.Environment.POI.Ca
AuthorisationRequest.Environment.POI.Capabi pabilities
lities is present it must have at least one child
C4 Either  AuthorisationRequest.Environment.Card.P
AuthorisationRequest.Environment.Card.Prote rotectedCardData
ctedCardData or  AuthorisationRequest.Environment.Card.P
AuthorisationRequest.Environment.Card.Plain lainCardData
CardData must be present.
C5 If  AuthorisationRequest.Environment.Cardh
AuthorisationRequest.Environment.Cardholde older
r is present it must have at least one child
C6 AuthenticationValue must be present if  AuthorisationRequest.Environment.Cardh
AuthenticationMethod is "SecureCertificate" older.
or "SecureNoCertificate". Authentication.AuthenticationMethod
 AuthorisationRequest.Environment.Cardh
older. Authentication.AuthenticationValue
C7 CardholderOnlinePIN must be present if  AuthorisationRequest.Environment.Cardh
AuthenticationMethod is "PINOnline". older.Authentication.AuthenticationMetho
d
 AuthorisationRequest.Environment.Cardh
older.
Authentication.CardholderOnlinePIN
C8 If AddressVerification is present it must have  AuthorisationRequest.Environment.Cardh
at least one child older. Authentication. AddressVerification
C9 CardPresent must be absent if  AuthorisationRequest.Context.PaymentCo
CardDataEntryMode="AccountData", ntext.CardPresent
CardPresent must be present if  AuthorisationRequest.Context.PaymentCo
CardDataEntryMode has any other value than ntext.CardDataEntryMode
"AccountData" and "Physical"
C10 AttendanceContext must present only if  AuthorisationRequest.Context.Attendance
CardholderPresent is "True" and has value Context
“Attended”, “SemiAttended” or “Unattended”  AuthorisationRequest.Context.Cardholder
Present
C11 AttendantLanguage must be present If  AuthorisationRequest.Context.
AttendantMessageCapable is “True” AttendantLanguage
 AuthorisationRequest.Context.
AttendantMessageCapable
C12 If SaleContext is present it must have at least  AuthorisationRequest.Context.SaleContex
one child t
C13 MessageFunction value must be  Header.MessageFunction
"AuthorisationRequest" if TransactionCapture  AuthorisationRequest.Transaction.Transa
= "False", "FinancialAuthorisationRequest" if ctionCapture
TransactionCapture = "True".
C14 If TransactionType value is "CardPayment" or  AuthorisationRequest.Transaction.Transa
“Refund” then AmountQualifier value must ctionType
be “Actual” or absent. If TransactionType  AuthorisationRequest.Transaction.Transa
value is "DeferredPayment" then ctionDetails.AmountQualifier
AmountQualifier value must be either
“Estimated” or “Maximum”.
If TransactionType value is "Reservation"
then AmountQualifier value must be either
“Estimated”, “Incremental” or “Decremental”
C15 Not used if TransactionType="CardPayment",  AuthorisationRequest.Transaction.Transa
"DeferredPayment" or "CashBack". If ctionType
TransactionType="Refund", when available it  AuthorisationRequest.Transaction.Origina
must be used to provide elements from the lTransaction
original transaction.
Not used if TransactionType="Reservation”
and ServiceAttribute=”InitialReservation”
If TransactionType="Reservation” and
ServiceAttribute=”UpdateReservation”, when
available it must be used to provide elements
from the original transaction.
Not used if TransactionType="Reservation
and ServiceAttribute=”“AdditionalPayment”


1798 4.2.2 AcceptorAuthorisationResponse (caaa.002.001.08)
Lvl AcceptorAuthorisationResponse Mult. Rule Cstr Usage

1 Header [1..1] see AcceptorAuthorisationRequest
<Hdr>
2 MessageFunction [1..1] C1 The only valid codes in a normal payment response are:
AuthorisationResponse: Response for
AuthorisationRequest
FinancialAuthorisationResponse: Response for
FinancialAuthorisationRequest
2 ProtocolVersion [1..1] Copy The Recipient Party has to adapt the
AcceptorAuthorisationResponse format to the version of
the Initiator sent in the AuthroisationRequest. If this
version is not supported the Recipient must reject the
request.with RejectReason = ProtocolVersion.
2 ExchangeIdentification [1..1] Copy <XchgId>::Number
2 CreationDateTime [1..1] Date and time of the creation of the message response.
Time accuracy has to be at least tenth of a second.
2 InitiatingParty [1..1] Copy <InitgPty>
2 RecipientParty [0..1] Copy <RcptPty>
<RmotAccs>
2 Traceability [0..*] Present and completed if present in the request.
see section 3.2 Traceability
<Tracblt>
1 AuthorisationResponse [1..1] C1 The Header.MessageFunction must be


AuthorisationResponse or
FinancialAuthorisationResponse.
(if not the case, a Reject message is sent by the
Recipient with RejectReason equal to ParsingError)
<AuthstnRspn>
3 AcquirerIdentification [0..1] Appli If the identification is present in the request:
It must be present in the response, but it may be
different.
If the identification is absent in the request:
It may be absent in the response (if the POI does not
need it for capture, reconciliation, reporting, etc)
It may be present in the response (if the choice is not
made by the POI, and the POI needs it)
<AcqrrId>
4 Type [0..1] default Acquirer
4 Issuer [0..1] <Issr>::PartyType4Code
4 ShortName [0..1] <ShrtNm>::Max35Text
3 MerchantIdentification [0..1] If the identification is present in the request:
It must be present in the response, but it may be
different from the request.
If the identification is absent in the request:
It may be absent in the response (if the POI don’t
need it for capture, reconciliation, report, etc)
<MrchntId>
4 Type [0..1] default Merchant
3 POIIdentification [0..1] Appli May be different from the request.
<POIId>
3 Card [0..1] <Card>
4 ProtectedCardData [0..1] Appli - - Encryption of the PlainCardData component,
including the envelope, using CMS
ContentType.EnvelopedData.
Present if:
- - the protection of sensitive card data is
required (TMS parameter
ProtectedCardData equal to True) and
- - the validation of card data by the acceptor is
required. These card data could be a
subset of those in the reques
<PrtctdCardData>
4 PrivateCardData [0..1] <PrvtCardData>::Max100KBinary


4 PlainCardData [0..1] Appli Present if:
- sensitive card data does not require a
protection
- (TMS parameter ProtectedCardData equal to
False) and
- the validation of card data by the acceptor is
required.
<PlainCardData>
5 CardSequenceNumber [0..1] <CardSeqNb>::Min2Max3NumericText
5 EffectiveDate [0..1] <FctvDt>::Max10Text
5 ServiceCode [0..1] <SvcCd>::Exact3NumericText
4 PaymentAccountReference [0..1] <PmtAcctRef>::Max70Text
4 IssuerBIN [0..1] <IssrBIN>::Max15NumericText
4 CardCountryCode [0..1] <CardCtryCd>::Max3Text
4 CardCurrencyCode [0..1] <CardCcyCd>::Exact3AlphaNumericText
4 CardProductProfile [0..1] <CardPdctPrfl>::Max35Text
4 CardBrand [0..1] <CardBrnd>::Max35Text
4 InternationalCard [0..1] <IntrnlCard>::TrueFalseIndicator
4 AllowedProduct [0..*] <AllwdPdct>::Max70Text
4 ServiceOption [0..1] <SvcOptn>::Max35Text
4 AdditionalCardData [0..1] <AddtlCardData>::Max70Text
<PmtTkn>
3 TransactionIdentification [1..1] Copy Based on TransactionIdentifier
For verification.
<TxId>
3 InitiatorTransactionIdentification [0..1] <InitrTxId>::Max35Text
3 RecipientTransactionIdentification [0..1] Appli Used by the InitiatingParty when it refers back to the
transaction of the RecipientParty (e.g. reconciliation
mismatch). If supplied, it is mandatory in the completion
and the batch.
3 ReconciliationIdentification [0..1] Copy or Conforming to the configuration parameters
Appli ReconciliationByAcquirer and ReconciliationExchange.
Present if:
The acquirer copies the value of the request assigned
by the acceptor.
The acquirer assigns the reconciliation period, and
provides it in the response.

3 InterchangeData [0..1] Appli Data received from a card scheme message and
required by the card scheme to be sent in the financial
capture.
<IntrchngData>::Max140Text
4 Currency [0..1] Copy <Ccy>::ActiveCurrencyCode
4 TotalAmount [1..1] If the Response is PartialApproved, the TotalAmount (ie
the amount authorised) must be different from the
amount requested; otherwise it must be the same as in
the request message. PartialApproved may be in case of
payment with cashback, where only the payment part is
approved or may be for prepaid card, where approved
amount is the remaining balance.
4 AmountQualifier [0..1] <AmtQlfr>::TypeOfAmount8Code
4 OnLineReason [0..*] <OnLineRsn>::OnLineReason1Code
4 UnattendedLevelCategory [0..1] <UattnddLvlCtgy>::Max35NumericText
4 AccountType [0..1] Appli If present in the request this field must contain a copy of
the request value.
If not present in the request, it may inform the cardholder
about the account used for the transaction.
6 CurrencyConversionIdentification [0..1] <CcyConvsId>::Max35Text


7 ActualAmount [0..1] <ActlAmt>::ImpliedCurrencyAndAmount
7 MinimumAmount [0..1] <MinAmt>::ImpliedCurrencyAndAmount
7 MaximumAmount [0..1] <MaxAmt>::ImpliedCurrencyAndAmount
4 Instalment [0..1] <Instlmt>
4 AggregationTransaction [0..1] <AggtnTx>
4 SaleItem [0..*] <SaleItm>


<PrtctdVal>
4 ICCRelatedData [0..1] A sequence of one or more TLV data elements in
accordance with ISO 7816-6, not in a specific order.
2 TransactionResponse [1..1] <TxRspn>
3 AuthorisationResult [1..1] <AuthstnRslt>
4 AuthorisationEntity [0..1] Identifies the entity which initially sets the Response
value (approves, declines, or generates a "technical
error" ).
<AuthstnNtty>
5 Type [1..1] Intermediary Agent, Acquirer: conforming to the rules of
the card scheme, the Acquirer authorises the transaction
(e.g. because a stand-in process, or declined because of
technical problem).
CardIssuer: the standard case.
DelegateIssuer: for this transaction, the Issuer delegated
the authorising right to another entity, for some reason.
5 Issuer [0..1] Appli <Issr>::PartyType4Code
5 ShortName [0..1] Appli <ShrtNm>::Max35Text
4 ResponseToAuthorisation [1..1] <RspnToAuthstn>
5 Response [1..1] C6 Declined: authorisation is declined or the requested
capture is not performed.
Approved: authorisation is approved for the full amount
requested, including capture if requested
PartialApproved: same as Approved, with TotalAmount
lower in the response than in the request.
<Rspn>::Response4Code
5 ResponseReason [0..1] Appli Additional information related to the response.

<RspnRsn>::Max35Text
4 AuthorisationCode [0..1] Appli This code proves the approval delivered by the
authorising entity (e.g. ISO 8583 - Elem. 38 - approval
code).
<AuthstnCd>::Min6Max8Text
4 CompletionRequired [0..1] If the flag has the value "True", an
AcceptorCompletionAdvice has to be sent after the end
of the transaction (see Table 2 : List of Payment Cases
for the details)
<CmpltnReqrd>::TrueFalseIndicator
4 TMSTrigger [0..1] Appli Present when the POI needs maintenance. The POI may
require maintenance prior to the execution of a specific
service.
<TMSTrggr>
5 TMSContactLevel [1..1] * Allowed values:
C3 Critical: TMS to be contacted before the next
transaction
ASAP: TMS to be contacted as soon as possible (e.g.
after reconciliation)
DateTime: TMS to be contacted at the date and time
provided in TMSContactDateTime
<TMSCtctLvl>::TMSContactLevel1Code
5 TMSIdentification [0..1] Appli * Must be present if TMSTrigger is not empty
<TMSId>::Max35Text
5 TMSContactDateTime [0..1] C3 Present if TMSContactLevel = DateTime
<TMSCtctDtTm>::ISODateTime
3 TransactionVerificationResult [0..*] Present if data structure is not empty
<TxVrfctnRslt>
4 Method [1..1] <Mtd>::AuthenticationMethod6Code
4 VerificationEntity [0..1] <VrfctnNtty>::AuthenticationEntity2Code
4 Result [0..1] <Rslt>::Verification1Code
4 AdditionalResult [0..1] <AddtlRslt>::Max500Text
3 AllowedProductCode [0..*] <AllwdPdctCd>
3 NotAllowedProductCode [0..*] <NotAllwdPdctCd>
3 AdditionalAvailableProduct [0..*] <AddtlAvlblPdct>
4 AmountLimit [0..1] <AmtLmt>::ImpliedCurrencyAndAmount
4 QuantityLimit [0..1] <QtyLmt>::DecimalNumber
3 Balance [0..1] Appli <Bal>
3 ProtectedBalance [0..1] See MDR for sub elements
<PrtctdBal>
3 Action [0..*] Appli Several combinations of actions may be sent in the
response (e.g. CaptureCard plus a display message for


the merchant, or Referral plus separate display and print
messages for the cardholder and merchant)
<Actn>
4 ActionType [1..1] C5 Additional actions to complete the transaction:
C6 DisplayMessage: Display a message.
PrintMessage: Print a message.
One of the following actions may be sent, if the
Response is “Declined”:
Busy: Server busy. Try later.
CaptureCard: Capture card.
ForbidOverride: Payment application cannot offer to
the merchant the possibility to override the
transaction.
IDRequired: Additional identification required
(passport, ID card, etc.).
PINRetry: PIN verification retry.
PINLastTry: Last PIN try.
Referral: Referral with a voice authorisation has to be
performed.
RequestData: Request additional data through a
displayed text and request confirmation by
attendant.
<ActnTp>::ActionType7Code
4 MessageToPresent [0..1] C5 if ActionType is DisplayMessage or PrintMessage
<MsgToPres>
5 MessageDestination [1..1] <MsgDstn>::UserInterface4Code
MessageContentSignature [0..1] Appli <MsgCnttSgntr>::Max140Binary
CurrencyConversionEligibility [0..1] <CcyConvsElgblty>
CurrencyConversion-Identification [0..1] <CcyConvsId>::Max35Text
TargetCurrency [1..1] <TrgtCcy>
AlphaCode [1..1] <AlphaCd>::ActiveCurrencyCode
NumericCode [1..1] <NmrcCd>::Exact3NumericText
Decimal [1..1] <Dcml>::Number
Name [0..1] <Nm>::Max35Text
ResultingAmount [1..1] <RsltgAmt>::ImpliedCurrencyAndAmount
ExchangeRate [1..1] <XchgRate>::PercentageRate
InvertedExchangeRate [0..1] <NvrtdXchgRate>::PercentageRate
QuotationDate [0..1] <QtnDt>::ISODateTime
ValidUntil [0..1] <VldUntil>::ISODateTime
SourceCurrency [1..1] <SrcCcy>
AlphaCode [0..1] <AlphaCd>::ActiveCurrencyCode
NumericCode [0..1] <NmrcCd>::Exact3NumericText
Decimal [0..1] <Dcml>::Number
Name [0..1] <Nm>::Max35Text
OriginalAmount [1..1] <OrgnlAmt>
ActualAmount [0..1] Actual amount to be converted
<ActlAmt>::ImpliedCurrencyAndAmount
MinimumAmount [0..1] Minimum amount for conversion (in case of range of
amounts)


<MinAmt>::ImpliedCurrencyAndAmount
MaximumAmount [0..1] Maximum amount for conversion (in case of range of
amounts)
<MaxAmt>::ImpliedCurrencyAndAmount
CommissionDetails [0..*] <ComssnDtls>
Amount [1..1] <Amt>::ImpliedCurrencyAndAmount
AdditionalInformation [0..1] <AddtlInf>::Max350Text
MarkUpDetails [0..*] <MrkUpDtls>
Rate [1..1] <Rate>::PercentageRate
AdditionalInformation [0..1] <AddtlInf>::Max350Text
DeclarationDetails [0..1] <DclrtnDtls>
Format [0..1] <Frmt>::OutputFormat1Code
MessageContent [1..1] <MsgCntt>::Max20000Text
SupplementaryData [0..*] See MDR for sub elements
<SplmtryData>
1 SecurityTrailer [0..1] CMS data structure ContentInfoType with the
AuthenticatedData alternative, containing the MAC of the
message body AuthorisationResponse including the
body envelope (see chapter ).
<SctyTrlr>


Number
C1 When AuthorisationResponse is present the  Header.MessageFunction
Header.MessageFunction must be  AuthorisationResponse
“AuthorisationResponse” or
“FinancialAuthorisationResponse”.
C3 TMSContactDateTime must be present if  AuthorisationResponse.TransactionRespo
TMSContactLevel = “DateTime” nse.TMSTrigger. TMSContactDateTime
 AuthorisationResponse.TransactionRespo
nse.TMSTrigger. TMSContactDateTime
C5 MessageToPresent must be present if  AuthorisationResponse.TransactionRespo
ActionType is “DisplayMessage” or nse.Action.ActionType
“PrintMessage”  AuthorisationResponse.TransactionRespo
nse.Action.MessageToPresent
C6 One of the following actions may be sent, if the  AuthorisationResponse.TransactionRespo
Response is “Declined”: nse.ResponseToAuthorisation.Response
Busy: Server busy. Try later.  AuthorisationResponse.TransactionRespo
CaptureCard: Capture card. nse.Action.ActionType
ForbidOverride: Payment application cannot
offer to the merchant the possibility to
override the transaction.
IDRequired: Additional identification
required (passport, ID card, etc.).
PINRetry: PIN verification retry.
PINLastTry: Last PIN try.
Referral: Referral with a voice authorisation
has to be performed.
RequestData: Request additional data
through a displayed text and request
confirmation by attendant.

1801 4.3 Completion Messages
1802 4.3.1 AcceptorCompletionAdvice (caaa.003.001.08)
Lvl AcceptorCompletionAdvice Mult. Rule Cstr Usage

1 Header [1..1] <Hdr>
2 MessageFunction [1..1] C1 The only valid codes to advice a normal payment are:
C5 CompletionAdvice: Completion without financial
capture (TransactionCapture=False,
Reversal=False) or
(TransactionCapture=False, Reversal=True,
TransactionSuccess=True)
FinancialCompletionAdvice: Completion with financial
capture (TransactionCapture=True,
Reversal=False) or
(TransactionCapture=True, Reversal=True,
TransactionSuccess =True)
ReversalAdvice: Reversal of an authorisation without
financial capture (TransactionCapture=False,
Reversal=True, TransactionSuccess =False)
FinancialReversalAdvice: Reversal of a
FinancialAuthorisation (TransactionCapture=True,
Reversal=True, TransactionSuccess =False)
(in case of an invalid value, a Reject message is sent by
the Recipient with RejectReason equal to ParsingError)
2 ProtocolVersion [1..1] * see AcceptorAuthorisationRequest
2 ExchangeIdentification [1..1] see AcceptorAuthorisationRequest
<XchgId>::Number
2 ReTransmissionCounter [0..1] default 0
see 3.3 Message Retransmission
<ReTrnsmssnCntr>::Max3NumericText
2 CreationDateTime [1..1] see AcceptorAuthorisationRequest
2 InitiatingParty [1..1] see AcceptorAuthorisationRequest
<InitgPty>
2 RecipientParty [0..1] Config see AcceptorAuthorisationRequest
<RcptPty>
4 Messages and Usage - 130 - 4.3 Completion Messages


<RmotAccs>
2 Traceability [0..*] Config <Tracblt>
1 CompletionAdvice [1..1] C1 The Header.MessageFunction must be
CompletionAdvice, FinancialCompletionAdvice,
ReversalAdvice or FinancialReversalAdvice.
<CmpltnAdvc>
3 Acquirer [0..1] Config If Acquirer identification has been sent in the
Authorisation response, this value has to be used in
CompletionAdvice.
<Acqrr>
4 Identification [0..1] <Id>
5 Type [0..1] * default Acquirer
see AcceptorAuthorisationRequest
4 ParametersVersion [1..1] CCopy For online authorisation, the value has to be the same as
that in the Authorisation.
3 Merchant [0..1] CCopy Conditional copy for online transactions.
Configurable for offline transactions.
<Mrchnt>
4 LocationCategory [0..1] Allowed values Fixed, Aboard, Nomadic and Home
<LctnAndCtct>


4 SchemeData [0..1] <SchmeData>::Max140Text
3 POI [0..1] Copy from AcceptorAuthorisationRequest.
<POI>
4 Identification [1..1] Copy from AcceptorAuthorisationResponse if any.
<Id>
5 Identification [1..1] Identification of a POI terminal or system.
<Id>::Max35Text
4 SystemName [0..1] <SysNm>::Max70Text
4 GroupIdentification [0..1] <GrpId>::Max35Text
4 Capabilities [0..1] <Cpblties>
CardReadingCapabilities [0..*] <CardRdngCpblties>::CardDataReading5Code
CardholderVerificationCapabilities [0..*] <CrdhldrVrfctnCpblties>::CardholderVerificationCapabilit
y4Code
5 OnLineCapabilities [0..1] <OnLineCpblties>::OnLineCapability1Code
4 TimeZone [0..1] <TmZone>::Max70Text
4 TerminalIntegration [0..1] <TermnlIntgtn>::LocationCategory3Code
4 Component [0..*] Based on PointOfInteractionComponent
<Cmpnt>
4 ProtectedCardData [0..1] Only present if requested by the Acquirer configuration
(e.g. TMS parameter CardDataVerification is “True” and
ProtectCardData is “True”) or
AcceptorAuthorisationResponse was not received.
<PrtctdCardData>
4 PlainCardData [0..1] Only present if requested by the Acquirer configuration
(e.g. TMS parameter CardDataVerification is “True” and
ProtectCardData is “False”) or
AcceptorAuthorisationResponse was not received.
<PlainCardData>


4 CardCountryCode [0..1] Appli see AcceptorAuthorisationRequest
4 CardProductProfile [0..1] Config see AcceptorAuthorisationRequest
4 CardBrand [0..1] Appli see AcceptorAuthorisationRequest
3 CustomerDevice [0..1] <CstmrDvc>
4 Provider [0..1] <Prvdr>::Max35Text
3 Wallet [0..1] <Wllt>
<PmtTkn>
3 Cardholder [0..1] C2 Present if it contains any data.
<Crdhldr>


5 EmployeeIdentificationNumber [0..1] <MplyeeIdNb>::Max35Text
4 Language [0..1] <Lang>::LanguageCode
4 BillingAddress [0..1] Based on PostalAddress22
<BllgAdr>
4 ShippingAddress [0..1] Based on PostalAddress22
<ShppgAdr>
4 TripNumber [0..1] <TripNb>::Max35Text
4 Vehicle [0..1] <Vhcl>
5 VehicleNumber [0..1] <VhclNb>::Max35NumericText
5 TrailerNumber [0..1] <TrlrNb>::Max35NumericText
5 VehicleTag [0..1] <VhclTag>::Max35Text
5 VehicleTagEntryMode [0..1] <VhclTagNtryMd>::CardDataReading5Code
5 UnitNumber [0..1] <UnitNb>::Max35NumericText
5 ReplacementCar [0..1] <RplcmntCar>::TrueFalseIndicator
5 Odometer [0..1] <Odmtr>::DecimalNumber
5 Hubometer [0..1] <Hbmtr>::DecimalNumber
5 TrailerHours [0..1] <TrlrHrs>::Max35Text
5 ReferHours [0..1] <RefrHrs>::Max35Text
5 MaintenanceIdentification [0..1] <MntncId>::Max35Text
5 DriverOrVehicleCard [0..1] <DrvrOrVhclCard>
6 AdditionalCardData [0..*] <AddtlCardData>::Max35Text
5 AdditionalVehicleData [0..*] <AddtlVhclData>
6 Data [1..1] <Data>::Max35Text
4 Authentication [0..*] <Authntcn>
5 AuthenticationMethod [1..1] <AuthntcnMtd>::AuthenticationMethod5Code


5 AuthenticationValue [0..1] <AuthntcnVal>::Max5000Binary
5 ProtectedAuthenticationValue [0..1] See MDR for sub elements
<PrtctdAuthntcnVal>
5 CardholderOnLinePIN [0..1] <CrdhldrOnLinePIN>
6 EncryptedPINBlock [1..1] See MDR for sub elements
<NcrptdPINBlck>
6 PINFormat [1..1] <PINFrmt>::PINFormat3Code
6 AdditionalInput [0..1] <AddtlInpt>::Max35Text
5 CardholderIdentification [0..1] <CrdhldrId>
6 EmployeeIdentificationNumber [0..1] <MplyeeIdNb>::Max35Text
5 AddressVerification [0..1] <AdrVrfctn>
6 AddressDigits [0..1] <AdrDgts>::Max5NumericText
6 PostalCodeDigits [0..1] <PstlCdDgts>::Max5NumericText
5 AuthenticationType [0..1] <AuthntcnTp>::Max35Text
5 AuthenticationLevel [0..1] <AuthntcnLvl>::Max35Text
5 AuthenticationResult [0..1] <AuthntcnRslt>::AuthenticationResult1Code
5 AuthenticationAdditionalInformation [0..1] <AuthntcnAddtlInf>::Max35Text
4 TransactionVerificationResult [0..*] <TxVrfctnRslt>
4 PersonalData [0..1] <PrsnlData>::Max70Text
<PrtctdCrdhldrData>
4 CardPresent [0..1] default True


4 CardholderPresent [0..1] default True
4 OnLineContext [0..1] default True
The flag is set to “False” if the authorisation was offline
without the need of sending an
AcceptorAuthorisationRequest during the transaction.
<OnLineCntxt>::TrueFalseIndicator
4 AttendanceContext [0..1] default Attended
4 TransactionChannel [0..1] Config see AcceptorAuthorisationRequest
4 AttendantMessageCapable [0..1] <AttndntMsgCpbl>::TrueFalseIndicator
4 AttendantLanguage [0..1] <AttndntLang>::LanguageCode
4 CardDataEntryMode [0..1] see AcceptorAuthorisationRequest
4 SupportedOption [0..*] <SpprtdOptn>::SupportedPaymentOption1Code
<SaleCntxt>


3 DirectDebitContext [0..1] See MDR for sub elements
<DrctDbtCntxt>
2 Transaction [1..1] CCopy <Tx>
3 TransactionCapture [0..1] Config C5 default False
If True, this financial transaction must be captured by the
Acquirer.
TransactionCapture is True if MessageFunction value is
FinancialCompletionAdvice or FinancialReversalAdvice
and False otherwise.
3 AdditionalService [0..*] VoiceAuthorisation if transaction approved by phone
after Referral as ActionType in the declined authorisation
<AddtlSvc>::CardPaymentServiceType9Code
3 MerchantCategoryCode [0..1] see AcceptorAuthorisationRequest
derived.
retailer.
3 CardProgrammeApplied [0..1] * The card program actually selected by the cardholder
3 TransactionIdentification [1..1] CCopy Based on TransactionIdentifier
Identification of the transaction assigned by the POI

Same value as the AuthorisationRequest if any.
<TxId>
3 OriginalTransaction [0..1] Appli <OrgnlTx>
<TxId>
4 POIIdentification [0..1] <POIId>


InitiatorTransactionIdentification [0..1] <InitrTxId>::Max35Text
RecipientTransactionIdentification [0..1] <RcptTxId>::Max35Text
TransactionType [1..1] <TxTp>::CardPaymentServiceType12Code
AdditionalService [0..*] <AddtlSvc>::CardPaymentServiceType9Code
ServiceAttribute [0..1] <SvcAttr>::CardPaymentServiceType3Code
CardDataEntryMode [0..1] <CardDataNtryMd>::CardDataReading5Code
4 TransactionResult [0..1] <TxRslt>
5 AuthorisationEntity [0..1] <AuthstnNtty>
ResponseToAuthorisation [1..1] <RspnToAuthstn>
6 ResponseReason [0..1] <RspnRsn>::Max35Text
3 TransactionSuccess [1..1] C6 True if the outcome of the transaction is successful (see

section 5)
<TxSucss>::TrueFalseIndicator
3 Reversal [0..1] default False
If True, a reversal of the online authorisation is requested
(see section 5).
<Rvsl>::TrueFalseIndicator
3 MerchantOverride [0..1] Appli default False
True if the acceptor has forced the transaction to be
successful (see section 5).
<MrchntOvrrd>::TrueFalseIndicator
3 FailureReason [0..*] Appli. C6 Mandatory if TransactionSuccess is False, or Reversal is
True or MerchantOverride is True (see section 5).
CardDeclined: Integrated circuit card declines the
transaction after the authorisation.
CustomerCancel: Customer cancellation, for example
removing the chip card after sending the
AcceptorAuthorisationRequest, but before the end of
the transaction.
Malfunction: Suspected malfunction (e.g. card reader
defect, printer out of order).
OfflineDeclined: Offline authorisation declined the
transaction.
OnLineDeclined: Online authorisation declined the
transaction.
SuspectedFraud: Card payment transaction failed
because the merchant suspected a fraud.
TimeOut: Timeout waiting for response from the
acquirer, or no response was received (for example
connection release before receiving the response).
TooLateResponse: Response to the authorisation
received too late.
UnableToComplete: Card acceptor device unable to
complete transaction after the authorisation response
(e.g. written signature invalid).


UnableToSend: Unable to deliver the
AcceptorAuthorisationRequest to the acquirer.
<FailrRsn>::FailureReason3Code
3 InitiatorTransactionIdentification [0..1] Appli Copy from AuthorisationRequest if any.
3 RecipientTransactionIdentification [0..1] Appli Copy from AuthorisationResponse if any.
3 ReconciliationIdentification [0..1] Appli For online transactions:
 If the transaction is captured during the
authorisation or by batch, copy from
AuthorisationRequest.
 If the transaction is captured by the Completion,
identification of the reconciliation period. The value
may be different from the
AcceptorAuthorisationRequest.
see AcceptorAuthorisationRequest for offline
transactions.
3 InterchangeData [0..1] Appli Copy from AuthorisationResponse if any.
4 TotalAmount [1..1] Final amount of the payment transaction when
TransactionSuccess is "True".
If TransactionSuccess is "False":
the amount of AuthorisationResponse for an online
approval,
the amount of AuthorisationRequest if unable to go
online or timeout,
the purchase amount for a declined offline
authorisation
4 AmountQualifier [0..1] Appli <AmtQlfr>::TypeOfAmount8Code


4 ValidityDate [0..1] <VldtyDt>::ISODate
4 UnattendedLevelCategory [0..1] Appli Present if AttendanceContext is Unattended
<UattnddLvlCtgy>::Max35NumericText
4 AccountType [0..1] Appli defaut Default
6 CurrencyConversion-Identification [0..1] <CcyConvsId>::Max35Text


<PrtctdVal>
accordance with ISO 7816-6
3 AuthorisationResult [0..1] Appli Present for online authorisation if an
AcceptorAuthorisationResponse has been received.
<AuthstnRslt>
4 AuthorisationEntity [0..1] CCopy see AcceptorAuthorisationResponse if received,
otherwise absent.
<AuthstnNtty>


4 ResponseToAuthorisation [1..1] see AcceptorAuthorisationResponse
<RspnToAuthstn>
4 AuthorisationCode [0..1] Appli Obtained from the corresponding
AcceptorAuthorisationResponse if any. For Voice
Authorisation the AuthorisationCode is obtained from the
Acquirer (see section 6.1).
3 TransactionVerificationResult [0..*] Appli <TxVrfctnRslt>
3 AccountFrom [0..1] See MDR for sub elements
<AcctFr>
3 AccountTo [0..1] See MDR for sub elements
<AcctTo>
2 SupplementaryData [0..*] Appli See MDR for sub elements

<SplmtryData>
message body CompletionAdvice including the body
envelope.
<SctyTrlr>


Number
C1 When CompletionAdvice is present the  Header.MessageFunction
Header.MessageFunction must be  CompletionAdvice
“CompletionAdvice”,
“FinancialCompletionAdvice”,
“ReversalAdvice” or
“FinancialReversalAdvice”.
C2 If Cardholder is present it must have at least  CompletionAdvice.Environment.CardHold
one child er
C3 
C4 If SaleContext is present it must have at least  CompletionAdvice.Context.SaleContext
one child
C5 If MessageFunction value is  Header.MessageFunction
“FinancialCompletionAdvice” or  CompletionAdvice.Transaction.Transactio
“FinancialReversalAdvice” then nCapture
TransactionCapture must be “True”. Otherwise

it must be ”False”.
C6 FailureReason must be present if  CompletionAdvice.Transaction.Transactio
TransactionSuccess is “False”. nSuccess
 CompletionAdvice.Transaction.FailureRea
son
C7 If TransactionSuccess is "True" then  CompletionAdvice.Transaction.Transactio
TotalAmount must be Final amount of the nDetails.TotalAmount
payment transaction.  CompletionAdvice.Transaction.Transactio
Otherwhise, TotalAmount is: nSuccess
the amount of AuthorisationResponse for an
online approval,
the amount of AuthorisationRequest if unable
to go online or timeout,
the purchase amount for an offline
authorisation

1805 4.3.2 AcceptorCompletionAdviceResponse (caaa.004.001.07)
Lvl AcceptorCompletionAdviceResponse Mult. Rule Cstr Usage

2 MessageFunction [1..1] C1 The only valid codes are:
CompletionAdviceResponse: response for
CompletionAdvice
FinancialCompletionAdviceResponse: response for
FinancialCompletionAdvice
ReversalAdviceResponse: response for
ReversalAdvice
FinancialReversalAdviceResponse: response for
FinancialReversalAdvice
2 ProtocolVersion [1..1] * The Recipient Party has to adapt the response format to
the version of the Initiator sent in the advice. If this
version is not supported the Recipient must reject the
advice with RejectReason = ProtocolVersion.
2 ReTransmissionCounter [0..1] CCopy <ReTrnsmssnCntr>::Max3NumericText
2 CreationDateTime [1..1] <CreDtTm>::ISODateTime
<RmotAccs>
2 Traceability [0..*] Present if present in the completion advice.
<Tracblt>


1 CompletionAdviceResponse [1..1] C1 <CmpltnAdvcRspn>
3 AcquirerIdentification [0..1] Copy from AcceptorCompletionAdvice if present
<AcqrrId>
3 MerchantIdentification [0..1] Copy from AcceptorCompletionAdvice if present
<MrchntId>
3 POIIdentification [0..1] Copy from AcceptorCompletionAdvice
<POIId>
4 ProtectedCardData [0..1] Appli see AcceptorAuthorisationResponse
<PrtctdCardData>
4 PlainCardData [0..1] Appli see AcceptorAuthorisationResponse
<PlainCardData>


<PmtTkn>
Copy from AcceptorCompletionAdvice if present
<TxId>
and the batch.
3 ReconciliationIdentification [0..1] see AcceptorAuthorisationResponse
3 Response [1..1] Approved: the CompletionAdvice is accepted.
For other responses, an error resolution process has to
be performed which is out of scope of the protocol.
2 TMSTrigger [0..1] Appli see AcceptorAuthorisationResponse
<TMSTrggr>
3 TMSContactLevel [1..1] C2 <TMSCtctLvl>::TMSContactLevel1Code
3 TMSIdentification [0..1] Appli <TMSId>::Max35Text
see AcceptorAuthorisationResponse
2 SupplementaryData [0..*] See MDR for sub elements
<SplmtryData>
message body CompletionAdviceResponse including the
body envelope, using the MAC key of the related
AcceptorCompletionAdvice message.
<SctyTrlr>



Number
C1 When CompletionAdviceResponse is present  Header.MessageFunction
the Header.MessageFunction must be  CompletionAdviceResponse
“CompletionAdviceResponse”,
“FinancialCompletionAdviceResponse”,
“ReversalAdviceResponse”,
“ReversalAdvice”,
“FinancialReversalAdviceResponse”
C2 TMSContactDateTime must be present if  CompletionAdviceResponse.TMSTrigger.
TMSContactLevel = “DateTime” TMSContactDateTime
 CompletionAdviceResponse.TMSTrigger.
TMSContactDateTime

1808 4.4 Cancellation Messages
1809 4.4.1 AcceptorCancellationRequest (caaa.005.001.08)
Lvl AcceptorCancellationRequest Mult. Rule Cstr Usage

2 MessageFunction [1..1] C1 The only valid code is CancellationRequest (CCAQ) to
request a cancellation for a previously completed
transaction, where the original transaction could not
retrieved at the POI.
2 ProtocolVersion [1..1] see AcceptorAuthorisationRequest
<XchgId>::Number
<InitgPty>
<RcptPty>
<RmotAccs>
<Tracblt>
3 RelayIdentification [1..1] Config <RlayId>
4 Messages and Usage - 148 - 4.4 Cancellation Messages


3 TraceDateTimeIn [1..1] Config <TracDtTmIn>::ISODateTime
1 CancellationRequest [1..1] C1 The Header.MessageFunction must be
CancellationRequest.
Recipient with RejectReason equal to “ParsingError”)
<CxlReq>
2 Environment [1..1] see AcceptorAuthorisationRequest
<Envt>
3 Acquirer [0..1] Config <Acqrr>
5 Identification [1..1] Appli <Id>::Max35Text
4 ParametersVersion [1..1] see AcceptorAuthorisationRequest
3 Merchant [0..1] C2 Present if it contains any data.
<Mrchnt>
4 Identification [0..1] Config see AcceptorAuthorisationRequest
<Id>
4 LocationAndContact [0..1] Based on CommunicationAddress
<LctnAndCtct>
3 POI [0..1] see AcceptorAuthorisationRequest
<POI>
4 SystemName [0..1] Config see AcceptorAuthorisationRequest

<SysNm>::Max70Text
4 GroupIdentification [0..1] Config see AcceptorAuthorisationRequest
<GrpId>::Max35Text
4 Capabilities [0..1] Present if it contains any data
<Cpblties>
CardReadingCapabilities [0..*] Config <CardRdngCpblties>::CardDataReading5Code
CardholderVerificationCapabilities [0..*] Config <CrdhldrVrfctnCpblties>::CardholderVerificationCapabilit
y4Code
5 OnLineCapabilities [0..1] Config <OnLineCpblties>::OnLineCapability1Code
4 Component [0..*] Config Based on PointOfInteractionComponent
<Cmpnt>
3 Card [0..1] Appli see AcceptorAuthorisationRequest
<Card>
4 ProtectedCardData [0..1] see AcceptorAuthorisationRequest
<PrtctdCardData>
4 PlainCardData [0..1] see AcceptorAuthorisationRequest
<PlainCardData>
4 CardCountryCode [0..1] Appli <CardCtryCd>::Max3Text


4 CardProductProfile [0..1] Config <CardPdctPrfl>::Max35Text
4 CardBrand [0..1] Appli <CardBrnd>::Max35Text
<PmtTkn>
3 Cardholder [0..1] See MDR for sub elements
<Crdhldr>
<PrtctdCrdhldrData>
3 PaymentContext [0..1] Context of the cancellation transaction
<PmtCntxt>
4 AttendanceContext [0..1] Config see AcceptorAuthorisationRequest
4 AttendantMessageCapable [0..1] C4 default True
Indicates to the acquirer whether a message in the
cancellation response can be displayed to the attendant.
<AttndntMsgCpbl>::TrueFalseIndicator
4 AttendantLanguage [0..1] C4 Present If AttendantMessageCapable is True
Indiciates the language of message in the cancellation
response to be displayed to the attendant


<AttndntLang>::LanguageCode
4 CardDataEntryMode [0..1] The entry mode used to get the card data for the
cancellation, the same values as in the
AcceptorAuthorisationRequest are allowed.
Alternative for the card data entry mode of the
cancellation transaction.
3 SaleContext [0..1] Appli C5 Present if it contains any data.
<SaleCntxt>
<DrctDbtCntxt>
3 TransactionCapture [0..1] Not used in this version
derived.


retailer.
3 CardProgrammeApplied [0..*] * The card program actually selected by the cardholder
3 TransactionIdentification [1..1] Identification of the cancellation transaction assigned by
the POI. This identification must be different from the
original transaction that is being cancelled.
<TxId>
3 OriginalTransaction [1..1] Appli Information about the transaction to be cancelled.
The OriginalTransaction components must have the
value of the related components of the transaction to
cancel.
<OrgnlTx>
4 TransactionIdentification [1..1] Appli Based on TransactionIdentifier
Identification of the transaction to cancel assigned by the

POI.
<TxId>
4 POIIdentification [0..1] Appli POI where the transaction to cancel was performed.
<POIId>
InitiatorTransactionIdentification [0..1] Appli Present if present in the transaction to cancel, with the
same value.
RecipientTransactionIdentification [0..1] Appli Present if present in the transaction to cancel, with the
same value.
4 TransactionType [1..1] Copy TransactionType of the original transaction.
<TxTp>::CardPaymentServiceType12Code
4 AdditionalService [0..*] Copy Cancellation of a transaction must cancel all associated
additional services; partial cancellation is not permitted.
4 ServiceAttribute [0..1] Copy Cancellation of the original transaction cancels the
transaction with its service attributes.
<SvcAttr>::CardPaymentServiceType3Code
4 TransactionResult [0..1] Appli TransactionResult of the transaction to cancel.
<TxRslt>
5 AuthorisationEntity [0..1] Appli AuthorisationEntity which has approved the transaction
to be cancelled.


<AuthstnNtty>
ResponseToAuthorisation [1..1] ResponseToAuthorisation of the transaction to be
cancelled.
<RspnToAuthstn>
5 AuthorisationCode [0..1] Appli AuthorisationCode of the transaction to be cancelled.
3 RecipientTransactionIdentification [0..1] <RcptTxId>::Max35Text
POI to the cancellation transaction.
4 Currency [0..1] Copy Currency of TotalAmount of the transaction to cancel
4 TotalAmount [1..1] Copy Amount to cancel which is always the TotalAmount of the
approved transaction to cancel. Only the full amount of
the transaction can be cancelled.

accordance with ISO 7816-6.
message body CancellationRequest including the body
envelope.
<SctyTrlr>



Number
C1 When CancellationRequest is present the  Header.MessageFunction
Header.MessageFunction must be  CancellationRequest
“CancellationRequest “
C2 If Merchant is present it must have at least one  CancellationRequest.Environment.Mercha
child nt
C3 If Capabilities is present it must have at least  CancellationRequest.Environment.POI.Ca
one child pabilities
C4 If AttendantMessageCapable is “True” then  CancellationRequest..Context.PaymentCo
AttendantLanguage must be present. ntext AttendantMessageCapable
 CancellationRequest..Context.PaymentCo
ntext AttendantLanguage
C5 If Salecontext is present it must have at least  CancellationRequest..Context.SaleContex
one child t

1812 4.4.2 AcceptorCancellationResponse (caaa.006.001.07)
Lvl AcceptorCancellationResponse Mult. Rule Cstr Usage

2 MessageFunction [1..1] The only valid codes in a response to a cancellation
request is :
CancellationResponse
2 ProtocolVersion [1..1] Copy C1 The Recipient Party has to adapt the
AcceptorCacellationResponse format to the version of
the Initiator sent in the AcceptorCancellationRequest. If
this version is not supported the Recipient must reject
the request.
2 CreationDateTime [1..1] see AcceptorAuthorisationResponse
<RmotAccs>
2 Traceability [0..*] Present if present in the request.
<Tracblt>
1 CancellationResponse [1..1] C1 <CxlRspn>
3 AcquirerIdentification [0..1] Appli see AcceptorAuthorisationResponse
<AcqrrId>


3 MerchantIdentification [0..1] see AcceptorAuthorisationResponse
<MrchntId>
3 POIIdentification [0..1] Appli see AcceptorAuthorisationResponse
<POIId>
<PrtctdCardData>
<PlainCardData>


<PmtTkn>
<TxId>
3 RecipientTransactionIdentification [0..1] Appli see AcceptorAuthorisationResponse
3 ReconciliationIdentification [0..1] Copy or see AcceptorAuthorisationResponse
Appli
3 InterchangeData [0..1] Appli see AcceptorAuthorisationResponse
4 TotalAmount [1..1] Amount to cancel which is always the TotalAmount of the
transaction to cancel. Only the full amount of the
transaction can be cancelled.
3 AuthorisationResult [1..1] Outcome of the CancellationRequest
<AuthstnRslt>
4 AuthorisationEntity [0..1] Qualify and allows recognition the entity which has
authorises the cancellation offline or line:
<AuthstnNtty>
5 Issuer [0..1] Appli <Issr>::PartyType4Code
5 ShortName [0..1] Appli <ShrtNm>::Max35Text
4 ResponseToAuthorisation [1..1] <RspnToAuthstn>
5 Response [1..1] * Valid values are:
Approved: cancellation is approved, including capture
if requested.
Declined: cancellation is declined.
5 ResponseReason [0..1] Appli see AcceptorAuthorisationResponse

<TMSTrggr>
5 TMSContactLevel [1..1] C2 <TMSCtctLvl>::TMSContactLevel1Code
3 Action [0..*] Appli see AcceptorAuthorisationResponse
<Actn>
4 ActionType [1..1] * Allowed values: Busy, CaptureCard, DisplayMessage or
C3 PrintMessage
<ActnTp>::ActionType7Code
4 MessageToPresent [0..1] C3 if ActionType is DisplayMessage or PrintMessage
<MsgToPres>
5 MessageDestination [1..1] <MsgDstn>::UserInterface4Code
MessageContentSignature [0..1] Appli <MsgCnttSgntr>::Max140Binary
message body CancellationResponse including the body
envelope, using the MAC key of the related
AcceptorCancellationRequest message.
<SctyTrlr>


Number
C1 When CancellationResponse is present the  Header.MessageFunction
Header.MessageFunction must be  CancellationResponse
“CancellationResponse”
C2 TMSContactDateTime must be present if  CancellationResponse.TMSTrigger.
TMSContactLevel = “DateTime” TMSContactDateTime
 CancellationResponse.TMSTrigger.
TMSContactDateTime
C3 MessageToPresent must be present if  CancellationResponse.TransactionRespon
ActionType is “DisplayMessage” or se.Action.ActionType
“PrintMessage”  CancellationResponse.TransactionRespon
se.Action.MessageToPresent

1815 4.4.3 AcceptorCancellationAdvice (caaa.007.001.08)
Lvl AcceptorCancellationAdvice Mult. Rule Cstr Usage

2 MessageFunction [1..1] C1 The only valid code to advice a cancellation for a
previously completed transaction is :
CancellationAdvice (CCAV)
<XchgId>::Number
<InitgPty>
3 Type [0..1] Config <Tp>::PartyType3Code
<RcptPty>
3 Type [0..1] Config <Tp>::PartyType3Code
<RmotAccs>
<Tracblt>


1 CancellationAdvice [1..1] C1 The Header.MessageFunction must be
CancellationAdvice.
<CxlAdvc>
3 Acquirer [0..1] Config see AcceptorAuthorisationRequest
<Acqrr>
4 ParametersVersion [1..1] see AcceptorAuthorisationRequest and
3 Merchant [0..1] see AcceptorAuthorisationRequest
<Mrchnt>
4 CommonName [0..1] Config <CmonNm>::Max70Text
4 LocationCategory [0..1] Config Allowed values Fixed, Aboard, Nomadic and Home
<LctnAndCtct>
3 POI [0..1] <POI>
4 Identification [1..1] see AcceptorAuthorisationRequest
<Id>
4 SystemName [0..1] Config <SysNm>::Max70Text
4 GroupIdentification [0..1] Config <GrpId>::Max35Text
4 Capabilities [0..1] C2 Present if it contains any data


<Cpblties>
CardReadingCapabilities [0..*] Config <CardRdngCpblties>::CardDataReading5Code
CardholderVerificationCapabilities [0..*] Config <CrdhldrVrfctnCpblties>::CardholderVerificationCapabilit
y4Code
5 OnLineCapabilities [0..1] Config <OnLineCpblties>::OnLineCapability1Code
4 Component [0..*] Config Based on PointOfInteractionComponent
<Cmpnt>
3 Card [0..1] Appli Card components retrieved from the transaction to
cancel (e.g. log or receipt), or read from the card.
<Card>
4 ProtectedCardData [0..1] see AcceptorAuthorisationRequest
<PrtctdCardData>
4 PlainCardData [0..1] see AcceptorAuthorisationRequest
<PlainCardData>
4 CardCountryCode [0..1] Appli see AcceptorAuthorisationRequest
4 CardProductProfile [0..1] Config see AcceptorAuthorisationRequest


4 CardBrand [0..1] Appli see AcceptorAuthorisationRequest
<PmtTkn>
<Crdhldr>
<PrtctdCrdhldrData>
2 Context [0..1] C3 Present if it contains any data
<Cntxt>
3 PaymentContext [0..1] Context of the cancellation transaction
<PmtCntxt>
4 OnLineContext [0..1] default True
True if a CancellationRequest has been sent previously.
<OnLineCntxt>::TrueFalseIndicator
4 AttendanceContext [0..1] Config default Attended
4 CardDataEntryMode [0..1] see AcceptorAuthorisationRequest

4 FallbackIndicator [0..1] default False
Context of the cancellation transaction
<SaleCntxt>
<DrctDbtCntxt>
3 CustomerConsent [0..*] <CstmrCnsnt>::TrueFalseIndicator
3 CardProgrammeProposed [0..*] <CardPrgrmmPropsd>::Max35Text
3 CardProgrammeApplied [0..*] <CardPrgrmmApld>::Max35Text
Identification of the cancellation transaction assigned by

the POI. This identification must be different from the
original transaction to cancel, but the same as in the
AcceptorCancellationRequest if any.
<TxId>
3 OriginalTransaction [0..1] see AcceptorCancellationRequest

<OrgnlTx>
4 TransactionIdentification [1..1] Appli Based on TransactionIdentifier
see AcceptorCancellationRequest
<TxId>
4 POIIdentification [0..1] Appli see AcceptorCancellationRequest
<POIId>
InitiatorTransactionIdentification [0..1] Appli see AcceptorCancellationRequest
RecipientTransactionIdentification [0..1] Appli see AcceptorCancellationRequest
4 TransactionType [1..1] Copy see AcceptorCancellationRequest
4 AdditionalService [0..*] see AcceptorCancellationRequest
4 ServiceAttribute [0..1] see AcceptorCancellationRequest
<SvcAttr>::CardPaymentServiceType3Code
4 TransactionResult [0..1] Appli see AcceptorCancellationRequest
<TxRslt>
5 AuthorisationEntity [0..1] Appli AuthorisationEntity which has approved the transaction
to cancel.
<AuthstnNtty>
ResponseToAuthorisation [1..1] ResponseToAuthorisation of the transaction to cancel.
<RspnToAuthstn>
5 AuthorisationCode [0..1] Appli AuthorisationCode of the transaction to cancel.
3 TransactionSuccess [1..1] <TxSucss>::TrueFalseIndicator
3 Reversal [0..1] Default: False


True: no acceptable CancellationResponse message
has been received, or cancellation couldn't be completed
successfully after an approved cancellation request.
<Rvsl>::TrueFalseIndicator
3 FailureReason [0..*] * No acceptable CancellationResponse message has
been received.
Allowed values: Malfunction or Timeout (see
AcceptorCompletionAdvice).
<FailrRsn>::FailureReason3Code
3 RecipientTransactionIdentification [0..1] Appli see AcceptorCancellationRequest
POI to the cancellation transaction.
see AcceptorCompletionAdvice
3 InterchangeData [0..1] Appli see AcceptorCompletionAdvice
4 Currency [0..1] copy Currency of TotalAmount of the transaction to cancel
4 TotalAmount [1..1] copy TotalAmount of the transaction to cancel

accordance with ISO 7816-6.
3 AuthorisationResult [0..1] Result of the outcome of the
AcceptorCancellationResponse if any.
<AuthstnRslt>
4 AuthorisationEntity [0..1] see AcceptorCancellationResponse
<AuthstnNtty>
4 ResponseToAuthorisation [1..1] see AcceptorCancellationResponse
<RspnToAuthstn>
4 AuthorisationCode [0..1] <AuthstnCd>::Min6Max8Text
4 TMSTrigger [0..1] Not used in this message.
<TMSTrggr>
5 TMSContactLevel [1..1] <TMSCtctLvl>::TMSContactLevel1Code


5 TMSIdentification [0..1] <TMSId>::Max35Text
5 TMSContactDateTime [0..1] <TMSCtctDtTm>::ISODateTime
message body CancellationAdvice including the body
envelope.
<SctyTrlr>


Number
C1 When CancellationAdvice is present the  Header.MessageFunction
Header.MessageFunction must be  CancellationAdvice
“CancellationAdvice”
C2 If Capabilities is present it must have at least  CancellationAdvice.Environment.POI.Capa
one child bilities
C3 If Context is present it must have at least one  CancellationAdvice.Context
child
C4 If SaleContext is present it must have at least  CancellationAdvice.Context.SaleContext
one child

1818 4.4.4 AcceptorCancellationAdviceResponse (caaa.008.001.07)
Lvl AcceptorCancellationAdviceResponse Mult. Rule Cstr Usage

2 MessageFunction [1..1] The only valid code in a response to a cancellation
advice is:
CancellationAdviceResponse
2 ProtocolVersion [1..1] Copy <PrtcolVrsn>::Max6Text
2 CreationDateTime [1..1] see AcceptorCompletionAdviceResponse
3 Identification [1..1] Copy <Id>::Max35Text
<RmotAccs>
2 Traceability [0..*] Present if present in the advice.
<Tracblt>
1 CancellationAdviceResponse [1..1] <CxlAdvcRspn>
3 AcquirerIdentification [0..1] Appli Copy from AcceptorCancellationAdvice if present
<AcqrrId>


3 MerchantIdentification [0..1] see AcceptorCompletionAdviceResponse
<MrchntId>
3 POIIdentification [0..1] Copy <POIId>
<PrtctdCardData>
<PlainCardData>
<PmtTkn>


For verification.
<TxId>
and the batch.
3 ReconciliationIdentification [0..1] see AcceptorAuthorisationResponse
3 Response [1..1] see AcceptorCompletionAdvice.
<TMSTrggr>
3 TMSContactDateTime [0..1] Present if TMSContactLevel = DateTime
message body CancellationAdviceResponse including
the body envelope, using the MAC key of the related
AcceptorCancellationAdvice message.
<SctyTrlr>

1819 4.5 Reconciliation Messages
1820 4.5.1 AcceptorReconciliationRequest (caaa.009.001.07)
Lvl AcceptorReconciliationRequest Mult. Rule Cstr Usage

1 Header [1..1] Unless stated otherwise, see
AcceptorAuthorisationRequest message header usage.
<Hdr>
2 MessageFunction [1..1] C1 The only valid code to request the reconciliation is
ReconciliationRequest.
2 ExchangeIdentification [1..1] <XchgId>::Number
2 InitiatingParty [1..1] <InitgPty>
2 RecipientParty [0..1] Config <RcptPty>
<RmotAccs>
2 Traceability [0..*] <Tracblt>
1 ReconciliationRequest [1..1] C1 The Header.MessageFunction must be
ReconciliationRequest.
<RcncltnReq>
3 Acquirer [0..1]
<Acqrr>
4 Messages and Usage - 171 - 4.5 Reconciliation Messages


4 Identification [0..1] Appli <Id>
5 Issuer [0..1] default Acquirer
4 ParametersVersion [1..1] <ParamsVrsn>::Max256Text
3 Merchant [0..1] <Mrchnt>
<LctnAndCtct>
3 POI [0..1] <POI>
5 CardReadingCapabilities [0..*] <CardRdngCpblties>::CardDataReading5Code
5 CardholderVerificationCapabilities [0..*] <CrdhldrVrfctnCpblties>::CardholderVerificationCapabilit
y4Code
5 PINLengthCapabilities [0..1] <PINLngthCpblties>::Number
5 ApprovalCodeLength [0..1] <ApprvlCdLngth>::Number
5 MaxScriptLength [0..1] <MxScrptLngth>::Number
5 CardCaptureCapable [0..1] <CardCaptrCpbl>::TrueFalseIndicator
<Cmpnt>


3 Card [0..1] * Must be absent
<Card>
3 CustomerDevice [0..1] * Must be absent
<CstmrDvc>
3 Wallet [0..1] * Must be absent
<Wllt>
3 PaymentToken [0..1] * Must be absent
Based on type CardPaymentToken..
<PmtTkn>
3 Cardholder [0..1] * Must be absent
<Crdhldr>
3 ProtectedCardholderData [0..1] * Must be absent
<PrtctdCrdhldrData>
3 ClosePeriod [0..1] default True
True: notifies that the reconciliation period must be
closed after the reconciliation exchange.
False: the current reconciliation period must stay open
after this exchange.
<ClsPrd>::TrueFalseIndicator
3 ReconciliationTransactionIdentification [1..1] Based on TransactionIdentifier
Identification of the reconciliation transaction.
<RcncltnTxId>
3 ReconciliationIdentification [1..1] Identification of the reconciliation period.
If ClosePeriod is True, ReconciliationIdentification
identifies the current reconciliation period.
If ClosePeriod is False, ReconciliationIdentification
identifies the current or a closed reconciliation period.
3 TransactionTotals [0..*] TransactionTotals of the reconciliation period.
TransactionTotals is absent if the reconciliation period
contains no transactions.
<TxTtls>
4 POIGroupIdentification [0..1] Appli Collection of transactions containing this value sent in
the POI.GroupIdentification component of the message
request and advice.
<POIGrpId>::Max35Text
4 CardProductProfile [0..1] Appli Collection of transactions containing this value sent in
the Card.CardProductProfile component of the message
request and advice.
4 Currency [0..1] Appli Currency is present when TransactionTotals are
computed per currency (TMS configuration parameter
AcquirerProtocolParameters.TotalsPerCurrency is True).
4 Type [1..1] * All the values are allowed:


Debit: Debit transactions (TransactionType is
CardPayment, CashBack, CashAdvance,
DeferredPayment) during the reconciliation period.
DebitReverse: Cancelled debit transactions.
Credit: Credit transactions (TransactionType is
Refund) during the reconciliation period.
CreditReverse: Cancelled credit transactions.
Declined: transactions declined online or offline.
Failed: failed transactions.
<Tp>::TypeTransactionTotals2Code
4 TotalNumber [1..1] * Total number of transactions for the related Type,
Currency, CardProductProfile and
POIGroupIdentification, performed by the InitiatingParty
during the reconciliation period
ReconciliationIdentification.
<TtlNb>::Number
4 CumulativeAmount [1..1] * Total amount of transactions for the related Type,
POIGroupIdentification, performed by the InitiatingParty
ReconciliationIdentification.
<CmltvAmt>::ImpliedCurrencyAndAmount
3 AdditionalTransactionData [0..1] Appli <AddtlTxData>::Max70Text

message body ReconciliationRequest including the body
envelope.
<SctyTrlr>


Number
C1 When ReconciliationRequest is present the  Header.MessageFunction
Header.MessageFunction must be  ReconciliationRequest
“ReconciliationRequest”

1823 4.5.2 AcceptorReconciliationResponse (caaa.010.001.06)
Lvl AcceptorReconciliationResponse Mult. Rule Cstr Usage

1 Header [1..1] Unless stated otherwise, see Authorisation Response
message header usage.
<Hdr>
2 MessageFunction [1..1] C1 The only valid code to request the reconciliation is
ReconciliationResponse.
<RmotAccs>
1 ReconciliationResponse [1..1] C1 The Header.MessageFunction must be
ReconciliationResponse.
RecipientParty with RejectReason equal to ParsingError)
<RcncltnRspn>
3 AcquirerIdentification [0..1] Copy <AcqrrId>


3 MerchantIdentification [0..1] CCopy see AcceptorCompletionAdviceResponse
<MrchntId>
3 Card [0..1] See MDR for sub elements
<Card>
3 PaymentToken [0..1] See MDR for sub elements
Based on type CardPaymentToken..
<PmtTkn>
3 Response [1..1] * The following codes are allowed:
Approved: The reconciliation is accepted, totals of
transactions performed by the Recipient are
provided in the response, or not computed in real-
time.
Declined: Totals are different.
3 ResponseReason [0..1] One of the reasons defined in section 2.6.4 p. 71, if
Response is not Approved.
3 AdditionalResponseInformation [0..1] <AddtlRspnInf>::Max140Text
3 ClosePeriod [0..1] Copy <ClsPrd>::TrueFalseIndicator
3 ReconciliationTransactionIdentification [1..1] Copy <RcncltnTxId>
3 ReconciliationIdentification [1..1] Copy if the value of the request is not 0, otherwise put
the last used value of the ReconciliationIdentification.
3 TransactionTotals [0..*] TransactionTotals is absent if the reconciliation period
contains no transactions, or the totals computation is not
performed in real-time by the acquirer.
The sequence of TransactionTotals components, if
present, must be in the same order as the request,
according to the value of Type, Currency,
CardProductProfile and POIGroupIdentification.
In case of discrepancy, additional TransactionTotals
must be located at the end of the sequence.
<TxTtls>
4 POIGroupIdentification [0..1] Appli see AcceptorReconciliationRequest


4 CardProductProfile [0..1] Appli see AcceptorReconciliationRequest
4 Currency [0..1] Appli see AcceptorReconciliationRequest
4 Type [1..1] <Tp>::TypeTransactionTotals2Code
4 TotalNumber [1..1] * Total number of transactions for the related Type,
POIGroupIdentification, performed by the RecipientParty
ReconciliationIdentification. The value can be zero.
<TtlNb>::Number
4 CumulativeAmount [1..1] * Sum of TotalAmount of transactions for the related Type,
POIGroupIdentification, performed by the RecipientParty
ReconciliationIdentification. The value can be zero.
3 AdditionalTransactionData [0..1] Appli <AddtlTxData>::Max70Text

message body ReconciliationResponse including the
body envelope, using the MAC key of the related
AcceptorReconciliationRequest message.
<SctyTrlr>


Number
C1 When ReconciliationResponse is present the  Header.MessageFunction
Header.MessageFunction must be  ReconciliationResponse
“ReconciliationResponse”

1826 4.6 Batch
1827 4.6.1 AcceptorBatchTransfer (caaa.011.001.08)

Lvl Or AcceptorBatchTransfer Mult. Rule Cstr Type / Definition / Code List
2 DownloadTransfer [1..1] True if BatchTransfer/Transaction occurrences
contain AuthorisationResponse.
False otherwise
<DwnldTrf>::TrueFalseIndicator
2 FormatVersion [1..1] Same value as ProtocolVersion
<FrmtVrsn>::Max6Text
2 ExchangeIdentification [1..1] Unique identifier for the InitiatingParty to detect
duplication of the transfer for a period of time.
It is a cyclic counter that increments by one with
each new transfer between the InitiatingParty
and the RecipientParty.
<XchgId>::Number
2 CreationDateTime [1..1] Date and time of the file creation. Time accuracy
has to be at least tenth of a second.
<InitgPty>
3 Identification [1..1] The value of this identifier is bilaterally agreed
between InitiatingParty and RecipientParty. The
Recipient of the message must identify without
ambiguity the Initiator of the message.
<Id>::Max35Text
3 Type [0..1] Appli Indicates the type of InitiatingParty:
Acceptor, Merchant, OriginatingPOI,
IntermediaryAgent.
3 Issuer [0..1] Config Indicates the assigner for identifying the
InitiatingParty.
2 RecipientParty [0..1] Config Information used to identify the recipient of an
exchange. The structure and content is
bilaterally agreed between InitiatingParty and
RecipientParty.
<RcptPty>
3 Type [0..1] Indicates the type of RecipientParty:
Acceptor, Merchant, IntermediaryAgent,
Acquirer, DelegateIssuer.
4 Messages and Usage - 178 - 4.6 Batch


<RmotAccs>
1 BatchTransfer [1..1] <BtchTrf>
2 TransactionTotals [0..*] Appli TransactionTotals of the whole BatchTransfer.
TransactionTotals is absent if the batch contains
no transactions.
<TxTtls>
3 CardProductProfile [0..1] Appli see AcceptorReconciliationRequest
3 Currency [0..1] see AcceptorReconciliationRequest
3 Type [1..1] see AcceptorReconciliationRequest
3 TotalNumber [1..1] see AcceptorReconciliationRequest
<TtlNb>::Number
3 CumulativeAmount [1..1] see AcceptorReconciliationRequest
2 DataSet [0..*] A data set may include both financial
(completed transactions) and non financial
transactions (uncompleted transactions).
<DataSet>
3 DataSetIdentification [1..1] Unique identifier for each of the DataSet for the
InitiatingParty
<DataSetId>
4 Name [1..1] Identifier of the DataSet for the InitiatingParty
<Nm>::Max256Text
4 Type [1..1] BatchCapture
<Tp>::DataSetCategory8Code
4 Version [0..1] Not used in batch capture context
<Vrsn>::Max256Text
4 CreationDateTime [1..1] Date and time of the creation of the data set.
Time accuracy has to be at least tenth of a
second
3 Traceability [0..*] Config An intermediary Agent must include its own
traceability info, if traceability was present in the
data set received and if the data set is
forwarded with the same transactions.
<Tracblt>


4 RelayIdentification [1..1] Information used to identify the recipient of an
exchange. The structure and content is
bilaterally agreed between InitiatingParty and
RecipientParty.
<RlayId>
5 Type [1..1] Indicates the type of RecipientParty:
Acceptor, Merchant, IntermediaryAgent,
Acquirer, DelegateIssuer:
3 DataSetInitiator [0..1] Config The initiating party and the dataset initiator can
be the same entity. If not, it is possible for each
data set to identify the entity that creates it by
populating DataSetInitiator.
<DataSetInitr>
4 Identification [1..1] Information used to identify the initiator of a
dataset. The structure and content is bilaterally
agreed between InitiatingParty and
RecipientParty.
<Id>::Max35Text
4 Type [0..1] Indicates the type of DataSetInitiator
Acceptor, Merchant, OriginatingPOI,
IntermediaryAgent:
default OriginatingPOI
4 Issuer [0..1] Indicates the assigner for identifying the
DatasetInitiator.
Acceptor, Merchant, , IntermediaryAgent,
acquirer:
3 TransactionTotals [1..*] TransactionTotals of the DataSet.
<TxTtls>
4 CardProductProfile [0..1] Config see AcceptorReconciliationRequest
4 Currency [0..1] Appli see AcceptorReconciliationRequest
4 Type [1..1] see AcceptorReconciliationRequest


4 TotalNumber [1..1] see AcceptorReconciliationRequest
<TtlNb>::Number
4 CumulativeAmount [1..1] see AcceptorReconciliationRequest
3 CommonData [0..1] Data common to transactions of a DataSet may
be factorised in CommonData to reduce the
message length.
All transactions of the DataSet inherit the data
element value present in CommonData except if
this data element is present in the occurrence of
TransactionToCapture.
<CmonData>
5 Acquirer [0..1] <Acqrr>
6 LocationCategory [0..1] Allowed values Fixed, Aboard, Nomadic and
Home
5 POI [0..1] C1 <POI>
7 CardholderVerificationCapabilities [0..*] <CrdhldrVrfctnCpblties>::CardholderVerification
Capability4Code


<Cmpnt>
6 CardPresent [0..1] <CardPres>::TrueFalseIndicator
6 CardholderPresent [0..1] <CrdhldrPres>::TrueFalseIndicator
6 AttendanceContext [0..1] <AttndncCntxt>::AttendanceContext1Code
6 TransactionEnvironment [0..1] <TxEnvt>::TransactionEnvironment1Code
6 TransactionChannel [0..1] <TxChanl>::TransactionChannel5Code
6 FallbackIndicator [0..1] <FllbckInd>::CardFallback1Code
5 SaleContext [0..1] <SaleCntxt>
6 SaleIdentification [0..1] <SaleId>::Max35Text
6 SaleReferenceNumber [0..1] <SaleRefNb>::Max35Text
6 SaleReconciliationIdentification [0..1] <SaleRcncltnId>::Max35Text
6 CashierIdentification [0..1] <CshrId>::Max35Text
6 ShiftNumber [0..1] <ShftNb>::Max2NumericText
6 AdditionalSaleData [0..1] <AddtlSaleData>::Max70Text


5 DirectDebitContext [0..1] <DrctDbtCntxt>
6 DebtorIdentification [0..1] <DbtrId>
7 Debtor [0..1] <Dbtr>::PartyIdentification178Choice
9 Address [1..1] See MDR for sub elements
<Adr>
7 AccountIdentification [0..1] <AcctId>::CashAccountIdentification7Choice
8 IBAN [1..1] <IBAN>::IBAN2007Identifier
8 DomesticAccount [1..1] <DmstAcct>
6 CreditorIdentification [1..1] <CdtrId>
7 Creditor [1..1] <Cdtr>::PartyIdentification178Choice
9 Address [1..1] See MDR for sub elements
<Adr>
7 RegistrationIdentification [0..1] <RegnId>::Max35Text
6 MandateRelatedInformation [1..1] <MndtRltdInf>
7 MandateIdentification [1..1] <MndtId>::Max35Text
7 DateOfSignature [0..1] <DtOfSgntr>::ISODate
7 MandateImage [0..1] <MndtImg>::Max2MBBinary
4 TransactionType [0..1] see AcceptorAuthorisationRequest.
4 MerchantCategoryCode [0..1] C3 <MrchntCtgyCd>::Min3Max4Text
4 ReconciliationIdentification [0..1] <RcncltnId>::Max35Text
3 Transaction [1..*] Transaction of the data set.It must be a
completion, a cancellation advice, an
authorisation request or an authorisation
response.
<Tx>::CardPaymentDataSetTransaction7Choic
e
4 {Or Completion [1..1] <Cmpltn>


[1..1] Cancelled card payment transaction.
4 Or Cancellation
<Cxl>
[1..1] Authorisation request of a card payment
4 Or AuthorisationRequest transaction.
<AuthstnReq>
[1..1] Authorisation response of a card payment
4 Or} AuthorisationResponse transaction.
<AuthstnRspn>
1 SecurityTrailer [0..1] See MDR for sub elements
<SctyTrlr>


Number
C1 POI must either be present in CommonData or  BatchTransfer.DataSet.CommonData.Envi
in Transaction ronment.POI
 BatchTransfer.DataSet.Transaction.Compl
etion.Environment.POI
 BatchTransfer.DataSet.Transaction.Cance
llation.Environment.POI
 BatchTransfer.DataSet.Transaction.Autho
risationRequest.Environment.POI
risationResponse.Environment.POI
C2 If Context is present it must have at least one  BatchTransfer.DataSet.Transaction.Compl
child etion.Context
llation.Context
risationRequest. Context
risationResponse. Context
C3 MerchantCategoryCode must be present either  BatchTransfer.DataSet.CommonData.
in CommonData or in Transaction MerchantCategoryCode
 BatchTransfer.DataSet.Transaction.Compl
etion.Transaction.
MerchantCategoryCode
llation. Transaction.
risationRequest. Transaction.
risationResponse. Transaction.

1830 4.6.2 AcceptorBatchTransferResponse (caaa.012.001.07)
Lvl AcceptorBatchTransferResponse Mult. Rule Cstr Usage

2 DownloadTransfer [1..1] True
<DwnldTrf>::TrueFalseIndicator
2 FormatVersion [1..1] The Recipient Party has to adapt the batch transfer
response format to the version of the Initiator sent in the
batch transfer.
<FrmtVrsn>::Max6Text
2 ExchangeIdentification [1..1] Copy Several AcceptorBatchTransferResponse related to the
same AcceptorBatchTransfer share the same
ExchangeIdentification value.
Duplication of a AcceptorBatchTransferResponse is
detected with a common value of CreationDateTime.
Mixing DataSet from different AcceptorBatchTransfer in
the same AcceptorBatchTransferResponse is forbidden.
<XchgId>::Number
2 CreationDateTime [1..1] see AcceptorBatchTransfer
2 InitiatingParty [1..1] Copy Initiator of the AcceptorBatchTransfer
see AcceptorBatchTransfer
<InitgPty>
<RmotAccs>
1 BatchTransferResponse [1..1] <BtchTrfRspn>
2 TransactionTotals [0..*] Appli <TxTtls>
3 POIGroupIdentification [0..1] Appli <POIGrpId>::Max35Text
3 CardProductProfile [0..1] Appli <CardPdctPrfl>::Max35Text
3 Type [1..1] <Tp>::TypeTransactionTotals2Code
3 TotalNumber [1..1] <TtlNb>::Number
2 DataSet [0..*] DataSet result concerns all the transactions present in
the original DataSet.
Each occurrence of DataSet present in the
AcceptorBatchTransferResponse must be present in the
original AcceptorBatchTransfer.
Part of the DataSet could be missing and transferred in


another AcceptorBatchTransferResponse.
<DataSet>
3 DataSetIdentification [1..1] Copy <DataSetId>
4 Type [1..1] CaptureResponse
<Tp>::DataSetCategory8Code
4 Version [0..1] Not used in Batch Capture context
<Vrsn>::Max256Text
3 DataSetResult [1..1] Global result of the DataSet.
<DataSetRslt>
4 Response [1..1] C1 Approved: all transactions in DataSet are accepted.
Declined: all transactions in DataSet are rejected.
PartialApproved: only a subset of transactions is
accepted and the others are rejected.
4 AdditionalResponseInformation [0..1] <AddtlRspnInf>::Max140Text
3 RemoveDataSet [1..1] May be used to inform the Initiator to remove the
transactions from the memory.
<RmvDataSet>::TrueFalseIndicator
3 DataSetInitiator [0..1] Copy <DataSetInitr>
4 Identification [1..1] Copy <Id>::Max35Text
4 Type [0..1] Copy <Tp>::PartyType3Code
3 TransactionTotals [1..*] <TxTtls>
4 POIGroupIdentification [0..1] Copy <POIGrpId>::Max35Text
4 CardProductProfile [0..1] Copy <CardPdctPrfl>::Max35Text
4 Type [1..1] Copy See AcceptorReconciliation Request
4 TotalNumber [1..1] This data element contains the total number of
transactions calculated by the recipient.
In case of a difference with the total calculated by the
InitatingParty, the InitiatingParty has to take care of the
error which has to be resolved by other mean.
<TtlNb>::Number
4 CumulativeAmount [1..1] This data element contains the cumulative amount of
transactrions calculated by the recipient.
In case of a difference with the CumulativeAmount
calculated by the InitatingParty, the InitiatingParty has to
take care of the error which has to be resolved by other
mean.
3 RejectedTransaction [0..*] C1 Present if DataSetResult.Response is PartialApproved.
All transactions with TransactioResponse equal to
Declined or TechnicalError must be present.


<RjctdTx>
TransactionSequenceCounter [1..1] Copy <TxSeqCntr>::Max9NumericText
5 Response [1..1] * Allowed values : Declined or TechnicalError.
5 AcquirerIdentification [0..1] Copy <AcqrrId>
6 Type [0..1] Copy <Tp>::PartyType3Code
5 MerchantIdentification [0..1] Copy <MrchntId>
6 ProtectedCardData [0..1] Copy see AcceptorBatchTransfer
<PrtctdCardData>
6 PlainCardData [0..1] Copy see AcceptorBatchTransfer
<PlainCardData>
CardSequenceNumber [0..1] <CardSeqNb>::Min2Max3NumericText


<PmtTkn>
<TxId>
5 Response [1..1] Same value as
RejectedTransaction.TransactionResponse.Response
(not to be verified by the RecipientParty)
<SctyTrlr>


Number
C1 If DataSetResult.Response is “PartialApproved”  BatchTransferResponse.DataSet.DataSet
then Result.Response
RejectedTransaction must be present.  BatchTransferResponse.DataSet.Rejected
Transaction

1833 4.7 Diagnostic Messages
1834 4.7.1 AcceptorDiagnosticRequest (caaa.013.001.07)
Lvl AcceptorDiagnosticRequest Mult. Rule Cstr Usage

2 MessageFunction [1..1] C1 The only valid code is DiagnosticRequest to request a
diagnostic.
<XchgId>::Number
<InitgPty>
<RcptPty>
<RmotAccs>
1 DiagnosticRequest [1..1] C1 The Header.MessageFunction must be
DiagnosticRequest.
4 Messages and Usage - 189 - 4.7 Diagnostic Messages

Lvl AcceptorDiagnosticRequest Mult. Rule Cstr Usage

Recipient with RejectReason equal to “ParsingError”)
<DgnstcReq>
2 Environment [1..1] see AcceptorAuthorisationRequest
<Envt>
4 Identification [0..1] Appli <Id>
3 AcquirerAvailabilityRequested [0..1] <AcqrrAvlbtyReqd>::TrueFalseIndicator
3 MerchantIdentification [0..1] Config see AcceptorAuthorisationRequest
<MrchntId>
3 POIComponent [0..*] Based on PointOfInteractionComponent
<POICmpnt>
3 AcquirerAvailable [0..1] <AcqrrAvlbl>::TrueFalseIndicator
message body DiagnosticRequest including the body
envelope.
<SctyTrlr>

Number
C1 When DiagnosticRequest is present the  Header.MessageFunction
Header.MessageFunction must be  DiagnosticRequest
DiagnosticRequest

1837 4.7.2 AcceptorDiagnosticResponse (caaa.014.001.06)
Lvl AcceptorDiagnosticResponse Mult. Rule Cstr Usage

2 MessageFunction [1..1] The only valid code in a response to a diagnostic is :
DiagnosticResponse
2 ProtocolVersion [1..1] Copy see AcceptorAuthorisationResponse
<RmotAccs>
1 DiagnosticResponse [1..1] <DgnstcRspn>

Lvl AcceptorDiagnosticResponse Mult. Rule Cstr Usage

4 ParametersVersion [1..1] Copy <ParamsVrsn>::Max256Text
3 AcquirerAvailabilityRequested [0..1] <AcqrrAvlbtyReqd>::TrueFalseIndicator
3 MerchantIdentification [0..1] see AcceptorAuthorisationResponse
<MrchntId>
3 POIComponent [0..*] Based on PointOfInteractionComponent
<POICmpnt>
3 AcquirerAvailable [0..1] <AcqrrAvlbl>::TrueFalseIndicator
<TMSTrggr>
3 TMSContactDateTime [0..1] Present if TMSContactLevel = DateTime
message body DiagnosticResponse including the body
envelope, using the MAC key of the related
AcceptorDiagnosticRequest message.
<SctyTrlr>

1838 4.8 Reject Message
1839 4.8.1 AcceptorRejection (caaa.015.001.05)

Lvl AcceptorRejection Mult. Rule Cstr Usage
1 Header [1..1] see AcceptorAuthorisationRequest
<Hdr>
2 MessageFunction [1..1] * The only valid codes to be used in the case a reject
message is sent is:
Rejection: The receiving party could not handle the
request or the advice.
2 ProtocolVersion [1..1] see AcceptorAuthorisationResponse
2 ExchangeIdentification [0..1] Copy from the request if successfully extracted.
<XchgId>::Number
2 InitiatingParty [0..1] Copy from the request if successfully extracted .
<InitgPty>
2 RecipientParty [0..1] Copy from the request if successfully extracted,
otherwise absent.
<RcptPty>
<RmotAccs>
1 Reject [1..1] <Rjct>
4 Messages and Usage - 193 - 4.8 Reject Message

Lvl AcceptorRejection Mult. Rule Cstr Usage

2 RejectReason [1..1] High level information allowing the sender of a request or
an advice to know the types of error, and handle them
accordingly (see section 3.4 p. 91).
UnableToProcess: Not possible to process the
message (e.g. Host unavailable, Hardware Security
Module unavailable, problem of resource)
InvalidMessage: Invalid message envelope:
ParsingError: Invalid message, at least one of the
data element or data structure is not present, or the
format or the content of one data element or one data
structure is not correct.
This addresses the formatting of the field and also
high level accuracy of its content (e.g
MessageFunction).
Security: any security related error (e.g. invalid key,
incorrect MAC result...)
InitiatingParty: Invalid identification data for the
sender IniatingParty.
RecipientParty: Invalid identification data for the the
receiver RecipientParty.
DuplicateMessage: Duplicate message, i.e. same
ExchangeIdentification and CreationDateTime as for a
previous message from the initiator.
ProtocolVersion: The ProtocolVersion is not
supported by the recipient.
<RjctRsn>::RejectReason1Code
2 AdditionalInformation [0..1] Appli Additional information related to the sending of a reject
message in response to a request or an advice.
For logging purpose, in order to allow further analysis,
statistics and deferred processing on the success or the
failure of the request processing.
<AddtlInf>::Max500Text
2 MessageInError [0..1] Appli Message received by the recipient which has been
rejected and produced this AcceptorRejection message.
<MsgInErr>::Max100KBinary
1840 4.9 Dynamic Currency Conversion Messages
1841 4.9.1 AcceptorCurrencyConversionRequest (caaa.016.001.06)
Lvl AcceptorCurrencyConversionRequest Mult. Rule Cstr Usage

2 MessageFunction [1..1] <MsgFctn>::MessageFunction14Code
2 ProtocolVersion [1..1] * The current version is 8.0 (reference list of specification
documents).
4 Messages and Usage - 194 - 4.9 Dynamic Currency Conversion Messages


<RmotAccs>
1 CurrencyConversionRequest [1..1] <CcyConvsReq>
<LctnAndCtct>
3 POI [0..1] <POI>


5 CardholderVerificationCapabilities [0..*] <CrdhldrVrfctnCpblties>::CardholderVerificationCapabilit
y4Code
<Cmpnt>
4 ProtectedCardData [0..1] See MDR for sub elements
<PrtctdCardData>
4 PlainCardData [0..1] <PlainCardData>


<PmtTkn>
<Crdhldr>
<PrtctdCrdhldrData>
3 TransactionCapture [0..1] <TxCaptr>::TrueFalseIndicator
<TxId>
3 OriginalTransaction [0..1] <OrgnlTx>
4 TransactionIdentification [1..1] <TxId>
4 CurrencyConversion [1..1] <CcyConvs>
5 Result [1..1] <Rslt>::CurrencyConversionResponse3Code
5 ResultReason [0..1] <RsltRsn>::Max35Text
5 ConversionDetails [0..*] * At least one occurrence must be present.
<ConvsDtls>


3 IssuerReferenceData [0..1] <IssrRefData>::Max35Text
4 Currency [0..1] * Mandatory
4 TotalAmount [1..1] <TtlAmt>::ImpliedCurrencyAndAmount
4 DetailedAmount [0..1] <DtldAmt>


4 AccountType [0..1] <AcctTp>::CardAccountType3Code


<PrtctdVal>
3 CustomerOrder [0..1] <CstmrOrdr>
4 CustomerOrderIdentification [1..1] <CstmrOrdrId>::Max35Text
4 OpenOrderState [0..1] <OpnOrdrStat>::TrueFalseIndicator
4 StartDate [1..1] <StartDt>::ISODateTime
4 EndDate [0..1] <EndDt>::ISODateTime
4 Unit [0..1] <Unit>::AmountUnit1Code
4 ForecastedAmount [1..1] <FrcstdAmt>::ImpliedCurrencyAndAmount
4 CurrentAmount [0..1] <CurAmt>::ImpliedCurrencyAndAmount
4 AccessedBy [0..1] <AccsdBy>::Max35Text
3 CustomerToken [0..1] See MDR for sub elements
Based on type Erreur : source de la référence non

trouvée.
<CstmrTkn>


3 CustomerConsent [0..1] <CstmrCnsnt>::TrueFalseIndicator
3 CardProgrammeProposed [0..*] <CardPrgrmmPropsd>::Max35Text
3 CardProgrammeApplied [0..1] <CardPrgrmmApld>::Max35Text
3 SaleToPOIData [0..1] <SaleToPOIData>::Max70Text
3 SaleToAcquirerData [0..1] <SaleToAcqrrData>::Max70Text
3 SaleToIssuerData [0..1] <SaleToIssrData>::Max70Text
3 AdditionalTransactionData [0..*] <AddtlTxData>::Max70Text
<SctyTrlr>
1842 4.9.2 AcceptorCurrencyConversionResponse (caaa.017.001.06)
Lvl AcceptorCurrencyConversionResponse Mult. Rule Cstr

2 RecipientParty [0..1] <RcptPty>
<RmotAccs>
1 CurrencyConversionResponse [1..1] <CcyConvsRspn>
3 AcquirerIdentification [0..1] <AcqrrId>


3 MerchantIdentification [0..1] <MrchntId>
<PrtctdCardData>
<PmtTkn>
3 TransactionIdentification [1..1] < Based on TransactionIdentifier
TxId>


3 InterchangeData [0..1] <IntrchngData>::Max140Text
4 Currency [0..1] * Mandatory




<PrtctdVal>
3 Result [1..1] <Rslt>::CurrencyConversionResponse3Code
3 ResultReason [0..1] <RsltRsn>::Max35Text
3 ConversionDetails [0..*] * At least one occurrence must be present
<ConvsDtls>
CurrencyConversionIdentification [0..1] <CcyConvsId>::Max35Text
<SctyTrlr>

1843 4.9.3 AcceptorCurrencyConversionAdvice (caaa.018.001.03)

Lvl AcceptorCurrencyConversionAdvice Mult. Rule Cstr Usage
<RmotAccs>
1 AcceptorCurrencyConversionAdvice [1..1] <AccptrCcyConvsAdvc>


<PrtctdCardData>
<PmtTkn>
<TxId>
3 InterchangeData [0..1] <IntrchngData>::Max140Text






<PrtctdVal>
2 CurrencyConversionResult [0..1] Must be present
<CcyConvsRslt>
<SctyTrlr>

1844 4.9.4 AcceptorCurrencyConversionAdviceResponse (caaa.019.001.02)
Lvl AcceptorCurrencyConversionAdvice- Mult. Rule Cstr

Response
2 RecipientParty [0..1] <RcptPty>
<RmotAccs>
1 CurrencyConversionAdviceResponse [1..1] <CcyConvsAdvcRspn>

Lvl AcceptorCurrencyConversionAdvice- Mult. Rule Cstr

Response
<PrtctdCardData>
<PmtTkn>
<TxId>
2 TMSTrigger [0..1] <TMSTrggr>
3 TMSIdentification [0..1] <TMSId>::Max35Text
3 TMSContactDateTime [0..1] <TMSCtctDtTm>::ISODateTime
<SctyTrlr>

1845 4.10 Common nexo Acquirer message principles.
1846 In the following part of this chapter we describe types that are used in various messages.
1847 In some cases, the same type could be used with different message element names.
1848 4.10.1 CardPaymentToken.
1849 CardPaymentToken (type of PaymentToken) provides necessary and sufficient information to identify
1850 a surrogate value of a PAN. This value may be provided by the card issuer, and is known as the card
1851 payment token, or it may be provided by any other actors in the payment process.
1852 This surrogate may be only for the time of a transaction (e.g. in a multi-channel situation), or for a
1853 longer period (e.g. to recognise a customer after the first visit at a store or at a merchant site) and
1854 could be grouped in a two different kinds:
1855 1) Issuer Token: the token is an alternate PAN, usable in dedicated payment domain defined
1856 during its issuance by the token service provider of the card Issuer. The token has the same format
1857 as a PAN and belongs to a BIN range reserved to payment tokens.
1858 2) Acquirer Token: the token is an encrypted PAN or value attached to the PAN, generated by the
1859 POI System, an Acquirer or any Agent between, to replace the PAN during a payment transaction
1860 on a segment between the Merchant (or Card Acceptor) and the Acquirer.
1861 According to the characteristics of this token, this surrogate value may be used for payment services
1862 or not.
Lvl MessageName Mult. Rule Cstr Usage

1 Token [0..1] Surrogate value of the PAN
<Tkn>::Min8Max28NumericText
1 CardSequenceNumber [0..1] Identify a payment token inside a set of cards with the
same PAN.
<CardSeqNb>::Min2Max3NumericText
1 TokenExpiryDate [0..1] Expiration date of the payment token that is generated
by and maintained in the token vault.
<TknXpryDt>::Max10Text
1 TokenCharacteristic [0..*] Additional payment token information. We recommend to
at least use the following exclusive values
 TRANSACTION : The token is generated to
recognise a customer during the time of a
transaction.
 CUSTOMER : The token is generated to
recognise a customer for a longer period.
<TknChrtc>::Max35Text
1 TokenRequestor [0..1] <TknRqstr>
2 ProviderIdentification [1..1] Identifier of the token provider.
<PrvdrId>::Max35Text
2 RequestorIdentification [1..1] Identifier of the token requestor.
<RqstrId>::Max35Text
4 Messages and Usage - 213 - 4.10 Common nexo Acquirer message principles.
1 TokenAssuranceLevel [0..1] Level of confidence resulting of the identification and

authentication of the cardholder performed and the entity
that performed it.
<TknAssrncLvl>::Number
1 TokenAssuranceData [0..1] Information about the identification and verification of the
cardholder.
<TknAssrncData>::Max500Binary
1863 4.10.2 TransactionIdentifier.
1 TransactionDateTime [1..1] Appli UTC date and time with offset or local date time.
<TxDtTm>::ISODateTime
1 TransactionReference [1..1] Appli Identification of the transaction that has to be unique in
combination with TransactionDateTime for the merchant
and the POI.
<TxRef>::Max35Text
1864 4.10.3 NetworkParameters.
1 NetworkType [1..1] Type of communication network. Allowed values:

"InternetProtocol"A transport protocol using an IP
network.
"PublicTelephone" A transport protocol using Public
Switched Telephone Network (PSTN).
<NtwkTp>::NetworkType1Code
1 AddressValue [1..1] Value of the address:
The value of an internet protocol address contains the
IP address or the DNS (Domain Name Server)
address, followed by the character ':' and the TCP port
number if the default port is not used.
The value of a public telephone address contains the
phone number with possible prefix and extensions.
<AdrVal>::Max70Text
1 UserName [0..1] Username for identification of the POI e.g. to login into
a server
<UsrNm>::Max35Text
1 AccessCode [0..1] Password for authentication of the POI e.g. to login into
a server
<AccsCd>::Max35Binary
1 ServerCertificate [0..*] X.509 Certificate required to authenticate the server.
<SvrCert>::Max10KBinary
1 ServerCertificateIdentifier [0..*] Identification of the X.509 Certificate required to
authenticate the server, for instance a digest of the
certificate, the certificate serial number with the
certificate issuer name.
<SvrCertIdr>::Max140Binary
1 ClientCertificate [0..*] X.509 Certificate required to authenticate the client.
<ClntCert>::Max10KBinary
1 SecurityProfile [0..1] Identification of the set of security elements to access
the host.
<SctyPrfl>::Max35Text
1865 4.10.4 PointOfInteractionComponent.
1 Type [1..1] * Components to be sent in the online authorisation are

configured locally or by TMS configuration.
<Tp>::POIComponentType5Code
1 Identification [1..1] Identification of the component.
<Id>
2 ItemNumber [0..1] <ItmNb>::Max35Text
2 ProviderIdentification [0..1] Identifies the provider of the component class (it replaces
the data element ManufacturerIdentification of version 1).
<PrvdrId>::Max35Text
2 Identification [0..1] Identification of the component assigned by the provider
(it replaces the data element Model of version 1).
<Id>::Max35Text
2 SerialNumber [0..1] Serial number of the component if available.
<SrlNb>::Max35Text
1 Status [0..1] Actual status of the component.
<Sts>
2 VersionNumber [0..1] Current version of component that may include the
release number.
<VrsnNb>::Max256Text
2 Status [0..1] <Sts>::POIComponentStatus1Code
2 ExpiryDate [0..1] <XpryDt>::ISODate
1 StandardCompliance [0..*] Identification of the standard for which the component
complies with.
<StdCmplc>
2 Identification [1..1] Identification of the standard.
<Id>::Max35Text
2 Version [1..1] Version of the standard.
<Vrsn>::Max35Text
2 Issuer [1..1] Entity assigning the identification
<Issr>::Max35Text
1 Characteristics [0..1] Only used in TMS protocol.
<Chrtcs>
2 Memory [0..*] <Mmry>

3 TotalSize [1..1] <TtlSz>::DecimalNumber
3 FreeSize [1..1] <FreeSz>::DecimalNumber
3 Unit [1..1] <Unit>::MemoryUnit1Code
2 Communication [0..*] <Com>
CommunicationType [1..1] <ComTp>::POICommunicationType2Code
3 RemoteParty [1..*] <RmotPty>::PartyType7Code
3 Active [1..1] <Actv>::TrueFalseIndicator
SecurityAccessModules [0..1] <SctyAccsMdls>::Number
SubscriberIdentityModules [0..1] <SbcbrIdntyMdls>::Number
2 SecurityElement [0..*] See MDR for sub elements
<SctyElmt>
1 Assessment [0..*] Only used in TMS protocol.
<Assmnt>
2 Type [1..1] <Tp>::POIComponentAssessment1Code
2 Assigner [1..*] <Assgnr>::Max35Text
2 DeliveryDate [0..1] <DlvryDt>::ISODateTime
2 ExpirationDate [0..1] <XprtnDt>::ISODateTime
2 Number [1..1] <Nb>::Max35Text
1866 4.10.5 CommunicationAddress.
1 PostalAddress [0..1] Based on PostalAdress22

<PstlAdr>
1 Email [0..1] <Email>::Max256Text
1 URLAddress [0..1] <URLAdr>::Max256Text
1 Phone [0..1] <Phne>::PhoneNumber
1 CustomerService [0..1] <CstmrSvc>::PhoneNumber
1 AdditionalContactInformation [0..1] <AddtlCtctInf>::Max256Text
1867 4.10.6 PostalAddress22
1 AddressLine [0..2]
1 StreetName [0..1]
1 BuildingNumber [0..1]
1 PostCode [0..1]
1 TownName [1..1]
1 CountrySubDivision [0..2]
1 Country [1..1]
1 StreetName [0..1] <StrtNm>::Max70Text

1 PostCodeIdentification [1..1] <PstCdId>::Max16Text
1 TownName [1..1] <TwnNm>::Max35Text
1 CountrySubDivision [0..1] <CtrySubDvsn>::Max35Text
1 Country [1..1] <Ctry>::CountryCode
1 AddressType [0..1] <AdrTp>::AddressType2Code

1 AddressLine [0..5] <AdrLine>::Max70Text
1 StreetName [0..1] <StrtNm>::Max70Text
1 BuildingNumber [0..1] <BldgNb>::Max16Text
1 PostCode [0..1] <PstCd>::Max16Text
1 TownName [0..1] <TwnNm>::Max35Text
1 CountrySubDivision [0..1] <CtrySubDvsn>::Max35Text
1 Country [1..1] <Ctry>::CountryCode
1870 5 Dynamic of the Payment Exchanges
1871 5.1 Introduction
1872 This chapter presents an exhaustive catalogue of payment transactions cases by:
1873  Listing exhaustively the cases from the various process flows of the payment transaction,
1874  presenting the associated sequences of Authorisation, Completion and Batch exchanges
1875 between an Acceptor and an Acquirer,
1876  determining the values of the message data components and configuration parameters
1877 relevant for theses exchanges of messages, the financial capture and the outcome of the
1878 transaction.
1879 5.2 Determination of Payment Cases
1880 5.2.1 Elements Impacting the Message Flow

1881 The following sections addresse the message flows of the transactions by focusing on conditions
1882 influencing the sequence of messages such as:
1883  authorisation type,
1884  authorisation result,
1885  incidents after the authorisation,
1886  transactions forced by the merchant,
1887  capture type, and
1888  use of completion messages,
1889  acquirer configuration parameters.
1890 5.2.1.1 Authorisation Type

1891 An authorisation can be made:
1892  online (exchange of authorisation messages between the Acceptor and the Acquirer)
1893  offline (no exchange of messages between the Acceptor and the Acquirer). In such a case,
1894 the payment approval follows the rules of the POI payment application.
1895 AcceptorCompletionAdvice or BatchTransfer messages contains the information indicating whether

1896 the authorisation has been made online or offlline in the data element
1897 Context.PaymentContext.OnLineContext.
5 Dynamic of the Payment Exchanges - 218 - 5.2 Determination of Payment Cases

1898 5.2.1.2 Authorisation Result
1899 The result of the authorisation can be:

1900  Approved online by the Acquirer or offline at the POI.
1901  Declined online by the Acquirer or offline at the POI.
1902  No Acceptable Response:
1903  When the Acceptor has tried to send an AcceptorAuthorisationRequest message to the
1904 Acquirer without receiving a response in time (online authorisation only):
1905  Transaction.FailureReason contains one of the values UnableToSend,
1906 TimeOut or TooLateResponse,
1907  Transaction.Reversal flag is set to True.
1908 5.2.1.3 Incident after Authorisation

1909 After an online or offline authorisation, the transaction can terminate with incident.
1910 Transaction.FailureReason has then one of the following values:
1911  CustomerCancel, transaction cancelled by the Cardholder
1912  CardDeclined, payment transaction finally declined by the card,
1913  Malfunction, malfunction of the card or of the card reader
1914  UnableToComplete, POI or Sale unable to complete transaction after the authorisation (e.g.
1915 written signature invalid, risk too high for the Acceptor).

1916 5.2.1.4 Merchant Forced Acceptance
1917 The Merchant (Acceptor) may force the acceptance of a transaction (eg. in case of a trusted or loyal
1918 customer).
1919 A transaction can only be forced if it is allowed by the Acquirer and in accordance with the rules of the
1920 card scheme.
1921 The option to force a transaction may be presented to the Acceptor when a transaction does not
1922 complete as approved, since:
1923  No response was received
1924  The transaction was declined
1925  Some incident occurred after authorisation at the POI.
1926 If the Merchant forces the payment transaction , in the AcceptorCompletionAdvice message the
1927 following values are used:
1928  Transaction.MerchantOverride flag is set to True,
1929  Transaction.FailureReason is present with one of the values: CardDeclined, Malfunction,
1930 OfflineDeclined, OnlineDeclined, TimeOut, TooLateResponse, UnableToSend or
1931 UnableToComplete value.
1932 5.2.1.5 Capture Type
1933 The capture of the transaction can occur in:

1934  the authorisation exchange, when the configuration parameter
1935 OnlineTransaction.FinancialCapture has the value Authorisation.
1936  the completion exchange, when the configuration parameter
1937 OnlineTransaction.FinancialCapture (if the authorisation was online) or
1938 OfflineTransaction.FinancialCapture (if the authorisation was offline) has the value
1939 Completion.
1940  a batch transfer, when the configuration parameter OnlineTransaction.FinancialCapture (if the
1941 authorisation was online) or OfflineTransaction.FinancialCapture (if the authorisation was
1942 offline) has the value Batch.
1943 This configuration information is neither sent in the AcceptorAuthorisationRequest, nor in the
1944 AcceptorCompletionAdvice messages.

1945 5.2.1.6 Completion Exchange

1946 A completion exchange for successful approved transactions is required depending on the value of the
1947 TMS parameter CompletionExchange.ExchangePolicy:
1948  None: For Online transaction, a Completion advice is never sent to the Acquirer. For offline
1949 transaction, a completion is always sent to the Acquirer by message or batch,
1950  Any other value defined in ExchangePolicy except OnDemand: a Completion advice is
1951 always sent to the Acquirer. In addition, the value of the parameter determines the conditions
1952 of the exchange (e.g. TotalLimit: exchange performed after reaching a cumulative amount of
1953 transactions). The ExchangePolicy has the priority over a CompletionRequired flag set to
1954 False.
1955  Immediately : A completion exchange should start immediately after the
1956 transaction
1957  AsSoonAsPossible : A completion exchange starts after the next online
1958 transaction.
1959  NumberLimit : A completion exchange starts after a fixed number of
1960 online/offline transactions.
1961  TotalLimit : A completion exchange starts when the transactions totals for
1962 online/offline exceed a total limit amount online/offline.
1963  AsGroup : All completion messages are sent as a series of messages
1964 when a TimeCondition is reached
1965 On demand CompletionAdvice is sent after the Authorisation exchange if the CompletionRequired flag
1966 of the AcceptorAuthorisationResponse message is set to True. The OnDemand value of the
1967 CompletionExchange.ExchangePolicy has no effect on the completion behavior.
1968 Regardless of the above values, a completion exchange is also required when:
1969  The transaction completes successfully and the capture is realised during the completion
1970 exchange.
1971  An online authorisation needs to be reversed (e.g. no acceptable response to an
1972 AcceptorAuthorisationRequest or incident after an approved authorisation).
1973  The merchant successfully forces the transaction (see 5.2.1.4) and the capture must be made
1974 on-line (i.e. with an authorisation exchange or a completion exchange).
1975  a successful voice authorisation was performed and the capture must be made with the
1976 completion exchange.
1977  The authorisation is declined or the payment transactions failed and the TMS parameter
1978 BatchTransferContent is set to send declined or failed transactions.
1979 In case of reversal (Transaction.Reversal has the value True), the AcceptorCompletionAdvice
1980 message should be sent immediately after the transaction is completed, whatever the value of
1981 CompletionExchange.ExchangePolicy.

1982 5.2.2 List of Payment Cases

1983 In the following figures, Figure 52: Payment Cases Tree List and Figure 53: Payment Cases Tree List
1984 (Con't), payment cases are identified through the combination of the elements described in the
1985 previous section.
1986 Some combinations may be irrelevant and so do not produce cases, for instance:
Incident after Merchant Capture Sending
The completion exchange is Authorisation Forces Type Completion
qu.
always required if the payment no compl. re Case 1
uth
transaction completes tu re a compl. require
d
Case 2
completed without incident cap
successfully and is captured capture compl. Case 3
by the completion exchange ved
appro
(case 3).
Authorisation Incident after Merchant

Result Authorisation Forces
ent
incid
h out
d wit
plete The merchant cannot force the transaction if the
com
payment transaction completes successfully after an
fail
approved authorisation.
ved
ure
afte ed
forc
ro
r aut not
app
hor
isa
tion
mer
cha
nt fo
rces
Authorisation Incident after Merchant

Result Authorisation Forces
If an incident occurs for an offline authorisation,

the result of the offline authorisation (declined or
approved) is not taken into consideration.
1987 On the right side of the tree, after the case number, the figure provides the sequence of exchange
1988 related to the case:
1989  auth: Authorisation exchange (AcceptorAuthorisationRequest/Response),
1990  compl: Completion exchange (AcceptorCompletionAdvice/Response),
1991  reversal: Completion exchange with reversal(AcceptorCompletionAdvice/Response),
1992  batch: Batch exchange (AcceptorBatchTransfer/Response)
1993 The exchange is in bold and underlined if the capture is realised during that exchange, in square
1994 bracket if the exchange is optional, and define as reversal for a completion which is a reversal :
auth compl Capture is done with the Authorisation exchange, the Completion is required by the
Acquirer (without capture).
auth compl Capture is done with the Completion exchange.
auth batch Capture is done by Batch.
auth reversal Capture is done with the Authorisation exchange, no response is received by the
POI, a "financial reversal" is performed with the Completion.
auth [batch] The payment transaction fails, the transaction must be included in the batch if the
Acceptor is configured to do so.

1995 The form of "auth" and "compl" gives the value of the Header.MessageFunction component of the
1996 Authorisation and Completion messages, as summarized in the table below:
MessageFunction
auth "AuthorisationRequest" "AuthorisationResponse"
auth "FinancialAuthorisationRequest" "FinancialAuthorisationResponse"
compl "CompletionAdvice" "CompletionAdviceResponse"
compl "FinancialCompletionAdvice" "FinancialCompletionAdviceResponse"
reversal "ReversalAdvice" "ReversalAdviceResponse"
reversal "FinancialReversalAdvice" "FinancialReversalAdviceResponse"
1997 Table 2: MessageFunction Values

Authorisation Authorisation Incident after Merchant Capture Sending

Type Result Authorisation Forces Type Completion
qu.
no compl. re Case 1 auth
h
aut compl. requ Case 2 auth compl
ture ired
cap
t
capture compl. Case 3 auth compl
iden bat
t inc ch qu.
dw ithou c apt
u no compl. re Case 4 auth batch
plete re
com compl. requ
ired Case 5 auth compl batch
Case 6 auth reversal

failu
re a capture auth
fter ed capture compl. Case 7 auth reversal
aut forc batch captur
hor not e Case 8 auth reversal[batch]
isa
tion
mer Case 9 auth compl
ch ant capture auth
forc
es capture compl. Case 10 auth compl
batch captur
e Case 11 auth compl batch
qu.
th
au compl. requ
ired Case 13 auth compl
pt ure
ved
ca mpl . requ.
no co Case 14 auth
appro
capture compl
rce
d ba compl. requ
ot fo tch
ca
n ptu mpl . requ.
re no co Case 16 auth [batch]
compl. requ
ired Case 17 auth compl [batch]
Case 18 auth compl
auth
capture
batc qu.
h ca no compl. re Case 20 auth batch
ptur
e
compl. requ
declined qu.
th
au compl. requ
re
p tu
ca qu.
capture compl
rce
d ba compl. requ
t fo tch
no ca .
ptu no compl. requ Case 26 auth [batch]
re
compl. requ
ired Case 27 auth compl [batch]
no ac
Case 28 auth compl

auth
capture
cepta
Case 29 auth compl

batc capture compl.
qu.
no compl. re
auth.
ble re
h ca
ptur Case 30 auth batch
e
compl. requ
s
Online
ponse
capture auth
ed capture compl. Case 33 auth reversal
forc batch captur
not e Case 34 auth reversal[batch]
ch ant capture auth
forc
es capture compl. Case 36 auth compl
batch captur
capture auth
failur
e afte
r auth ed capture compl. Case 39 auth reversal
forc batch captur
orisa
tion not e Case 40 auth reversal[batch]
ca ch ant
forc capture auth
rd
a pp es capture compl. Case 42 auth compl
rov batch captur
es e Case 43 auth compl batch
Off
line
capture auth
Case 44 auth compl
a

uth
batch captur
.
1998 Figure 52: Payment Cases Tree List

Authorisation Authorisation Incident after Merchant Capture Sending

Type Result Authorisation Forces Type Completion
.
auth
ne
Onli
capture co
mpl Case 47 compl
qu.
batch c no compl. re Case 48 batch
apture
compl. requ
ired Case 49 compl batch
Off
lin
ed qu.
rov re no compl. re Case 50
ea
app captu l
p
com
ut h
compl. requ
ired Case 51 compl
.
ed qu.
forc batc no compl. re Case 52 [batch]
not h captu
re
compl. requ
ired Case 53 compl [batch]
declined me
rch mpl Case 54 compl
ant
for capture co
ces qu .
apture
compl. requ
fa
ilu
re qu.
re
captu l no compl. re Case 57
p
com compl. requ Case 58 compl
ired
ed qu.
forc batc no co mpl . re
Case 59 [batch]
not h captu
re
compl. requ
ired Case 60 compl [batch]
me
rch mpl Case 61 compl
ant
for capture co
ces qu.
apture
compl. requ
1999 Figure 53: Payment Cases Tree List (Con't)

2000 5.3 Table of Payment Cases
2001 The table below provides for each case the value of the key data components inside the messages or
2002 configuration parameters.
2003 It reads as follows:
Authorisation Refers to both AcceptorAuthorisationRequest and

AcceptorAuthorisationResponse messages.
CompletionAdvice Refers to an AcceptorCompletionAdvice message.
Batch Refers to a BatchTransfer message.
Authorisation
Txn Capt. Refers to TransactionCapture flag to be used in an
AcceptorAuthorisationRequest message.
Response Refers to Response data component to be used in an
AcceptorAuthorisationResponse messages to give the outcome of the on-line
authorisation:
 Appr.: for the values Approved or PartialApproved.
 Decl.: for the values Declined.
Compl.Requ. An AcceptorCompletionAdvice message has to be sent in this instance. For
declined and failed transaction, this flag has the priority over the configuration
parameters ExchangeDeclined and ExchangeFailed.
CompletionAdvic
e
condition Express the condition for Completion exchange:
 mandatory: the Completion exchange always
occurs,
 ExchPol = None (or ≠ None): the configuration
parameter OfflineTransaction.ExchangePolicy or
OfflineTransaction.ExchangePolicy has (or has not ) the value None.
 ExchDecl = True or False: the configuration
parameter ExchangeDeclined has the value True or False.
 ExchFail = True or False: the configuration
parameter ExchangeFailed has the value True or False.
 required : Completion is sent according to the
ExchangePolicy.
Txn. Succ. Refers to TransactionSuccess flag to be used in an AcceptorCompletionAdvice
message to provide the success or the failure of the transaction.
In addition to the value of this flag, it contains the value of MessageFunction in
the Completion messages:
(c): "CompletionAdvice"
(fc): "FinancialCompletionAdvice"
(r): "ReversalAdvice"
5 Dynamic of the Payment Exchanges - 226 - 5.3 Table of Payment Cases

(fr): "FinancialReversalAdvice"
Txn. Capt. Refers to TransactionCapture flag to be used in an AcceptorCompletionAdvice
message to indicate whether the transaction needs to be captured or not.
Reversal Refers to Reversal flag to be used in an AcceptorCompletionAdvice message
to indicate whether the message is to be considered as a reversal or not.
Failure Reason Refers to FailureReason data component to be used in an
AcceptorCompletionAdvice message which contains the reasons of the failure
causing the reversals, merchant override or failure of the transaction. A “+”
mean that an acceptor may send more than one failure reason.
Merch. Overr. Refers to MerchantOverride flag to be used in an AcceptorCompletionAdvice
message to indicate whether the merchant forced the acceptance of the
transaction or not.
Batch
condition Express the condition to include the payment transaction in a Batch transfer:
 Empty cell: the transaction is never included in a
Batch transfer,
 BatchCont=DebitCredit: the transaction is included
in the Batch transfer if the configuration parameter BatchTransferContent
has the value DebitCredit,
 BatchCont=Declined: the transaction is included in
the Batch transfer if the configuration parameter BatchTransferContent has
the value Declined,
 BatchCont= Failed: the transaction is included in
the Batch transfer if the configuration parameter BatchTransferContent has
the value Failed.
The number below the condition refers to the line number containing the value
of the flags TransactionSuccess, Reversal, MerchantOverride, and the data
elements FailureReason and Response of the related transaction in the
BatchTransfer.
2004 An empty cell means that the component is absent.
Authorisation CompletionAdvice Batch

Txn Resp. Compl condition Txn Txn Rev- Failure Merch. Condition
Capt. Requ Succ. Capt. ersal Reason Overr.
Online approved
1 Capture Auth. True Appr. False
No Completion
Online approved True
True
2 Capture Auth. True Appr. False
absent required (c)
Completion
3 False Appr. absent mandatory True
Capture Compl. (fc)
Online approved BatchCont=
4 Batch Capture False Appr. False ExchPol=None DebitCredit
Compl. not requ. 3
Online approved True ExchPol=None BatchCont=
True
5 Batch Capture False Appr. False DebitCredit
absent required (c)
Compl. required 3


mandatory CustCancel
Online approved
False Malfunction
6 Incident after Auth. True Appr. True True
(fr) CardDecline
Capture Auth.
Unab2Com
CustCancel
Online approved
False Malfunction
7 Incident after Auth. False Appr. absent mandatory False True
(r) CardDecline
Capture Compl.
Unab2Com
CustCancel
Online approved BatchCont=
mandatory False Malfunction
8 Incident after Auth. False Appr. False True Failed
(r) CardDecline
Batch Capture 8
Unab2Com
Online approved
Incident after Auth. Malfunction
mandatory True
9 True Appr. True True CardDecline True
(fc)
Merchant forces Unab2Com
Capture Auth.
Online approved
Incident after Auth. Malfunction
1 True
False Appr. absent mandatory True True CardDecline True
0 (fc)
Merchant forces Unab2Com
Capture Compl.
Incident after Auth. Malfunction BatchCont=
1 True
False Appr. False True CardDecline True DebitCredit
1 (c)
Merchant forces absent required Unab2Com 10
Batch Capture
Online declined False
1
Capture Auth. True Decl.
2 absent
Compl. not requ. ExchDecl=False
Online declined True
1 False
Capture Auth. True Decl. False OnlineDecl
3 absent (c)
Compl. required ExchDecl=True
1
Capture Compl. False Decl.
4 absent
Compl. not requ. ExchDecl=False
1 False
Capture Auth. False Decl. False OnlineDecl
5 absent (c)
Compl. required ExchDecl=True
Online declined False BatchCont=
1
Batch Capture False Decl. Declined
6 absent
Compl. not requ. ExchDecl=False 17
Online declined True BatchCont=
1 False
Batch Capture False Decl. False OnlineDecl Declined
7 absent (c)
Compl. required ExchDecl=True 17
Online declined absent
1 True
Merchant forces True Decl. or mandatory True OnlineDecl True
8 (fc)
Capture Auth. present
Online declined absent
1 True
Merchant forces False Decl. or mandatory True OnlineDecl True
9 (fc)
Capture Compl. present


Online declined
BatchCont=
2 Merchant forces
False Decl. False DebitCredit
0 Batch Capture
19
Compl. not requ.
BatchCont=
2 Merchant forces True
False Decl. False OnlineDecl True DebitCredit
1 Batch Capture absent required (c)
19
Compl. required
Incident after Auth.
2
True Decl.
2 absent
Capture Auth. ExchFail=False
Compl. not requ.
True OnlineDecl
Online declined
+
2 False CustCancel
True Decl. False
3 absent (c) Malfunction
Capture Auth. ExchFail=True
CardDecline
Compl. required
Unab2Com
2
False Decl.
4 absent
Capture Compl. ExchFail=False
Compl. not requ.
True OnlineDecl
Online declined
+
2 False CustCancel
False Decl. False
Capture Compl. ExchFail=True
CardDecline
Compl. required
Unab2Com
Incident after Auth. BatchCont=
2
False Decl. Failed
6 absent
Batch Capture ExchFail=False 27
Compl. not requ.
True OnlineDecl
Online declined
+
Incident after Auth. BatchCont=
2 False CustCancel
False Decl. False Failed
Batch Capture ExchFail=True 27
CardDecline
Compl. required
Unab2Com
Online declined OnlineDecl
Incident after Auth. +
2 True
True Decl. absent mandatory True Malfunction True
8 (fc)
Merchant forces CardDecline
Capture Auth. Unab2Com
Online declined OnlineDecl
Incident after Auth. +
2 True
False Decl. absent mandatory True Malfunction True
9 (fc)
Merchant forces CardDecline
Capture Compl. Unab2Com
Online declined
BatchCont=
3
False Decl. False ExchPol=OnDem DebitCredit
0 Merchant forces
29
Batch Capture
Compl. not requ.
False Decl. True False True


Online declined
OnlineDecl
+ BatchCont=
3 True
absent required Malfunction DebitCredit
1 Merchant forces (c)
CardDecline 29
Batch Capture
Unab2Com
Compl. required
Appr. mandatory
3 Online no resp. False TimeOut
True or True True
2 Capture Auth. (fr) Unable2Send
Decl.
Appr.
3 Online no resp. required False TimeOut
False or absent False True
3 Capture Compl. (r) Unable2Send
Decl.
Appr. BatchCont=
3 Online no resp. mandatory False TimeOut
False or False True Failed
4 Batch Capture (r) Unable2Send
Decl. 34
Online no resp. Appr.

3 mandatory True TimeOut
Merchant forces True or True True True
5 (fc) Unable2Send
Capture Auth. Decl.

3 required True TimeOut
Merchant forces False or True True True
6 (fc) Unable2Send
Capture Compl. Decl.
Online no resp. Appr. BatchCont=

Merchant forces False or False True True DebitCredit
7 (c) Unable2Send
Batch Capture Decl. 36
TimeOut
Unable2Send
Online no resp.
Appr. +
3 Incident after Auth. mandatory False
True or True True CustCancel
8 (fr)
Decl. Malfunction
Capture Auth.
CardDecline
Unab2Com
TimeOut
Unable2Send
Online no resp.
Appr. +
3 Incident after Auth. required False
False or False True CustCancel
9 (r)
Decl. Malfunction
Capture Compl.
CardDecline
Unab2Com
TimeOut
Unable2Send
Online no resp.
Appr. + BatchCont=
4 Incident after Auth. required False
False or False True CustCancel Failed
0 (r)
Decl. Malfunction 40
Batch Capture
CardDecline
Unab2Com


TimeOut
Online no resp.
Unable2Send
Incident after Auth. Appr.
4 mandatory True +
True or True True True
1 (fc) Malfunction
Merchant forces Decl.
CardDecline
Capture Auth.
Unab2Com
TimeOut
Online no resp.
Unable2Send
Incident after Auth. Appr.
4 mandatory True +
False or absent True True True
2 (fc) Malfunction
Merchant forces Decl.
CardDecline
Capture Compl.
Unab2Com
TimeOut
Online no resp.
Unable2Send
Incident after Auth. Appr. BatchCont=
4 required True +
False or False True True DebitCredit
3 (c) Malfunction
Merchant forces Decl. 42
CardDecline
Batch Capture
Unab2Com

Card approves True or True True
4 (fc) Unable2Send
Capture Auth. Decl.

Card approves False or absent True True
5 (fc) Unable2Send
Capture Compl. Decl.
Online no resp. Appr. BatchCont=

Card approves False or False True DebitCredit
6 (c) Unable2Send
Batch Capture Decl. 45
4 Offline approved True

mandatory True
7 Capture Compl. (fc)
Offline approved BatchCont=
4
Batch Capture ExchPol=None DebitCredit
8
Compl. not requ. 47
Offline approved BatchCont=
4 required True
Batch Capture False DebitCredit
9 (c)
Compl. required 47
Offline declined
5
Capture Compl. ExchDecl=False
0
Compl. not requ.
Offline declined
5 False
Capture Compl. ExchDecl=True False OfflineDecl
1 (c)
Compl. required
Offline declined BatchCont=
5
Batch Capture ExchDecl=False Declined
2
Compl. not requ. 53
Offline declined BatchCont=
5 False
Batch Capture ExchDecl=True False OfflineDecl Declined
3 (c)
Compl. required 53
Offline declined
5 True
Merchant forces mandatory True OfflineDecl True
4 (fc)
Capture Compl.


Offline declined
BatchCont=
5 Merchant forces
ExchPol=None DebitCredit
5 Batch Capture
54
Compl. not requ.
Offline declined
BatchCont=
5 Merchant forces required True
False OfflineDecl True DebitCredit
6 Batch Capture (c)
54
Compl. required
Offline failure
5
Capture Compl. ExchFail=False
7
Compl. not requ.
CustCancel
Offline failure
5 False False Malfunction
Capture Compl. ExchFail=True
8 (c) CardDecline
Compl. required
Unab2Com
Offline failure BatchCont=
5
Batch Capture ExchFail=False Failed
9
Compl. not requ. 60
CustCancel
Offline failure BatchCont=
6 False Malfunction
Batch Capture ExchFail=True False Failed
0 (c) CardDecline
Compl. required 60
Unab2Com
Offline failure Malfunction
6 True
Merchant forces mandatory True CardDecline True
1 (fc)
Capture Compl. Unab2Com
Offline failure
BatchCont=
6 Merchant forces
ExchPol=None DebitCredit
2 Batch Capture
61
Compl. not requ.
Offline failure
Malfunction BatchCont=
6 Merchant forces required True
False CardDecline True DebitCredit
3 Batch Capture (c)
Unab2Com 61
Compl. required
2005 Table 3: List of Payment Cases
2006 5.4 Cancellation Exchange
2007 A cancellation exchange should rely on a configuration with 3 possible options:

2008  The usage of both AcceptorCancellationRequest and AcceptorCancellationAdvice messages
2009 to fulfil a cancellation
2010  The usage of solely AcceptorCancellationAdvice message to fulfil a cancellation
2011  Cancellation is not supported by the acquirer.
5 Dynamic of the Payment Exchanges - 232 - 5.4 Cancellation Exchange

2012 5.4.1 List of Cancellation Cases
2013 In the Figure 54 Cancellation Cases Tree List cancellation cases are described, based on the type of
2014 capture and the combination of Cancellation Request and Cancellation Advice requested. For batch
2015 file, the tree also shows the case where cancelled transactions must (or must not) be included in the
2016 batch transfer.
2017 Case 5 to 14 are the same, the only difference being the authorisation type. This has no impact on
2018 cancellation processing.
2019 The tree also covers the case where the transaction is not available in the log file because of at least
2020 one of the followings:
2021  the cancellation is done in a new batch
2022  the cancellation and the original transaction are not in the same reconciliation period
2023  The original transaction originates from another POI.
2024 In this case cancellation request is mandatory and a cancellation advice must be sent if the request is
2025 approved.
2026 In the right hand side of the tree, after the case number, the figure provides the sequence of
2027 exchanges related to the case:
2028  auth: Authorisation exchange (AcceptorAuthorisationRequest/Response),
2029  compl: Completion exchange (AcceptorCompletionAdvice/Response),
2030  batch: Batch exchange (AcceptorBatchTransfer/Response)
2031  canreq: Cancellation request exchange (AcceptorCancellationRequest/Response)
2032  canadv: Cancellation advice exchange (AcceptorCancellationAdvice/Response)
2033 The exchange is in bold and underlined if the capture was done in the payment processing. As for the
2034 payment case, the message is in bold and underlined if the financial capture was done. Cancellation
2035 request or advice are in bold and italic if the capture is undone.
auth canadv Capture was done on authorisation, no cancellation request and capture is
undone with a cancellation advice.
compl canreq canadv Capture was done with a completion, a cancellation request is accepted and
undo the capture, followed by a cancellation advice.
canreq canadv batch The capture hasn’t occured yet, transaction is cancelled by request and advice
and both original transaction and cancellation are included in batch.
2036 For cancellation, “canreq” and “canadv” gives the value of the Header.MessageFunction component of
2037 the Cancellation Request and CancellationAdvice messages, as summarized in the table below:
MessageFunction
canreq “CancellationRequest” “CancellationResponse”
canadv “CancellationAdvice” “CancellationAdviceResponse”
2038 Table 4: Cancellation MessageFunction Values

Aut horisa tion Capture Cancellation Cancellation Cancellation Batch Transfert

Type Type Reque st Result Adv ice content
canadv
Case 1 auth canadv
Case 2 auth canreq canadv
Case 3 auth canreq
Case 4 auth canreq canadv
Case 5 compl canadv
canadv
Case 6 compl canreq canadv
Case 7 compl canreq

canadv
Case 9 canadv batch
canadv
canreq Case 10 canadv
accepte d
Case 11 canreq canadv batch
Case 12 canreq canadv
Case 13 canreq batch

canadv
canadv
Case 5 compl canadv
canadv
Case 7 compl canreq

canadv
Case 9 canadv bat ch
canadv
Case 10 canadv
Case 11 canreq canadv bat ch
Case 13 canreq batch

canadv batch
Canreq
accepte d
canreq requ.
Case 16 canreq
canadv canreq canadv

Case 17
Canreq
accepte d
canreq requ.
Case 19 canreq
Case 20
Canreq
accepte d
canreq requ.
Case 22 canreq

Case 23
2039 Figure 54 Cancellation Cases Tree List

2040 5.4.2 Table of Cancellation Cases
2041 The table below provides for each case the value of the key data components inside the messages or
2042 configuration parameters.
2043 It reads as follows:
Payment Case Refers to the possible payment that can be cancelled according to the
cancellation case.
Cancellation Refers to both AcceptorCancellationRequest and
Request AcceptorCancellationResponse messages.
Cancellation Refers to an AcceptorCancellationAdvice message.
Advice
Batch Refers to a BatchTransfer message.
Cancellation
Request
condition Express the condition for Cancellation exchange:
 CancExch = Advice: the configuration parameter
OnlineTransaction. CancellationExchange or OfflineTransaction.
CancellationExchange has the value Advice.
 CancExch = Request: the configuration parameter
OnlineTransaction. CancellationExchange or OfflineTransaction.
CancellationExchange has the value Request.
Response Refers to Response data component to be used in an

AcceptorCancellationResponse messages to give the outcome of the
requested cancellation:
 Appr.: for the values Approved.
 Decl.: for the values Declined.
Capture undone Give the final outcome of the cancellation.

Cancellation
Advice
Advice Sent Express the requirement to send or not an Advice.:
 True: A cancellation advice MUST be sent.
 False: A cancellation advice MUST NOT be sent.
Capture undone Give the final outcome of the cancellation.

Reverse Flag Refers to the Reversal component to be used in an
AcceptorCancellationAdvice to inform the acquirer that no response was
received for a CancellationRequest:
 False: Default value.
 True: no acceptable CancellationResponse
message has been received, or cancellation couldn't be completed
successfully after an approved cancellation request.
Batch
Cancellation in Express the condition to include the cancellation transaction in a Batch
batch transfer:
 Empty cell: the cancellation is never included in a
Batch transfer,
 BatchCont=Cancellation: the cancellation
transaction is included in the Batch transfer because the configuration
parameter BatchTransferContent has the value Cancellation.,
 BatchCont≠Cancellation: the cancellation
transaction is not included in the Batch transfer because the configuration
parameter BatchTransferContent has not the value Cancellation.,
Cancellation Request Cancellation Advice Batch

Payment Revers
Case Capture Advice Capture Cancellatio
Condition Resp e
Undone sent undone n in batch
flag
Capture Auth.
No cancellation
CancExch=
1 requ. 1,2 True True False
Advice
Cancellation
advice
Capture Auth.
Cancellation requ.
CancExch=
2 Canc. approved 1,2 Appr. True True False False
Request
Cancellation
advice
Capture Auth.
CancExch=
3 Cancellation requ. 1,2 Decl. False False
Request
Canc. declined


Payment Revers
Condition Resp e
flag
Capture Auth.
Cancellation requ.
CancExch= No
4 Canc. no response 1,2 False True False True
Request resp.
Cancellation
advice
Capture
Completion. 3,9,10,18,19,2
No cancellation 8,29,35,36,41, CancExch=
5 True True False
requ. 42,44,45,47,5 Advice
Cancellation 4,61
advice
Capture
Completion
3,9,10,18,19,2
Cancellation requ. 8,29,35,36,41, CancExch=
6 Appr. True True False False
Canc. approved 42,44,45,47,5 Request
4,61
Cancellation
advice
Capture 3,9,10,18,19,2
Completion 8,29,35,36,41, CancExch=
7 Decl. False False
Cancellation requ. 42,44,45,47,5 Request
Canc. declined 4,61
Capture
Completion
3,9,10,18,19,2
Cancellation requ. 8,29,35,36,41, CancExch= No
8 False True False True
Canc. no response 42,44,45,47,5 Request resp.
4,61
Cancellation
advice
Batch Capture .
No cancellation
requ. 4,5,11,20,21,3 BatchCont
0,31,37,43,46, CancExch= =
9 Cancellation True False False
48,49,55,56,6 Advice Cancellatio
advice 2,63 n
Cancellation in
batch
Batch Capture
No cancellation
requ. 4,5,11,20,21,3 BatchCont
1 0,31,37,43,46, CancExch= ≠
True False False
0 Cancellation 48,49,55,56,6 Advice Cancellatio
advice 2,63 n
Cancellation not in
batch
Batch Capture
Cancellation requ.
4,5,11,20,21,3 BatchCont
1 Canc. approved 0,31,37,43,46, CancExch= =
Appr. True True False False
1 Cancellation 48,49,55,56,6 Request Cancellatio
advice 2,63 n
Cancellation in
batch
Batch Capture
Cancellation requ.
4,5,11,20,21,3 BatchCont
1 Canc. approved 0,31,37,43,46, CancExch= ≠
Appr. True True False False
2 Cancellation 48,49,55,56,6 Request Cancellatio
advice 2,63 n
Cancellation not in
batch


Payment Revers
Condition Resp e
flag
Batch Capture 4,5,11,20,21,3
1 0,31,37,43,46, CancExch=
Cancellation requ. Decl. False False
3 48,49,55,56,6 Request
Canc. declined 2,63
Batch Capture
Cancellation requ. 4,5,11,20,21,3
1 0,31,37,43,46, CancExch= No
False True False True
4 Canc. no response 48,49,55,56,6 Request resp.
Cancellation 2,63
advice
Auth Capture 1,2,3,4,5,9,10,
Transaction not in 11,18,19,20,2
log 1,28,29,30,31,
1 35,36,37,41,4
Cancellation requ. N/A Appr. True True False False
5 2,,43,44,45,,4
Canc. approved 6,47,48,49,54,
Cancellation 55,56,61,62,6
advice 3
Auth Capture 1,2,3,4,5,9,10,
Transaction not in 11,18,19,20,,2
1 log 1,28,29,30,31,
35,36,37,41,4 N/A Decl. False False
6 Cancellation requ.
2,43,44,45,,46
Canc. declined ,47,48,49,54,5
5,56,61,62,63
Auth Capture
1,2,3,4,5,9,10,
log 1,28,29,30,31,
1 No
Cancellation requ. 35,36,37,41,4 N/A False True False True
7 resp.
Canc. no response 2,43,44,45,,46
,47,48,49,54,5
advice
Compl Capture 1,2,3,4,5,9,10,
log 1,28,29,30,31,
1 35,36,37,41,4
8 2,,43,44,45,,4
Canc. approved 6,47,48,49,54,
advice 3
Compl Capture 1,2,3,4,5,9,10,
1 log 1,28,29,30,31,
9 Cancellation requ.
2,43,44,45,,46
5,56,61,62,63
Compl Capture
1,2,3,4,5,9,10,
log 1,28,29,30,31,
2 No
0 resp.
,47,48,49,54,5
advice


Payment Revers
Condition Resp e
flag
Batch Capture 1,2,3,4,5,9,10,
log 1,28,29,30,31, BatchCont
2 35,36,37,41,4 =
1 2,,43,44,45,,4 Cancellatio
Canc. approved 6,47,48,49,54, n
advice 3
Batch Capture 1,2,3,4,5,9,10,
BatchCont
1,28,29,30,31,
2 log ≠
2 Cancellation requ. Cancellatio
2,43,44,45,,46
n
5,56,61,62,63
Batch Capture
1,2,3,4,5,9,10,
log BatchCont
1,28,29,30,31,
2 No ≠
3 resp. Cancellatio
n
,47,48,49,54,5
advice
2044 Table 5: List of Cancellation Cases

2045 6 Additional Payment Services

2046 Unless stated otherwise, specifications presented in the previous sections refer to the standard
2047 payment (i.e. Transaction.TransactionType = "CardPayment" with AdditionalService and
2048 ServiceAttribute absents). This section contains specifications related to other values of
2049 TransactionType, or AdditionalService and ServiceAttribute when these are presents.
2050 6.1 Voice Authorisation

2051 Voice Authorisation is an additional feature to approve a transaction over the phone when requested in
2052 the AcceptorAuthorisationResponse.
2053 1. The Acceptor performs an online authorisation, sending an AcceptorAuthorisationRequest for a
2054 main service populated in the TransactionType component.
2055 2. The Acquirer declined the authorisation (Response= "Declined"), and requests a voice
2056 authorisation setting the action Referral in the message element Action.ActionType of the
2057 AcceptorAuthorisationResponse message. The Acceptor is expected to provide information
2058 included in the authorisation exchanged to the Voice Authorisation service verbally.
2059 3. If the transaction is approved through the Voice Authorisation,
2060 a. The Voice Authorisation service provides an authorisation code by phone to the Acceptor
2061 and the transaction can be successfully completed.
2062 b. The transaction must be captured by completion or batch with the following information:
2063  One occurrence of AdditionalService added and set to "VoiceAuthorisation",
2064  TransactionSuccess equal "True",
2065  AuthorisationResult.AuthorisationCode containing the authorisation code provided
2066 with the Acquirer,
2067  ResponseToAuthorisation.Response set to "Declined",
2068 c. In the Completion exchange TransactionCapture is present with the value "True" if the
2069 Acceptor is configured to make the financial capture with the Authorisation or the
2070 Completion.
Acceptor Acquirer
AcceptorAutho
online authorisation 1 risationReques
t
Response:Declined
2
se ActionType:Referral
risationRespon
AcceptorAutho
Voice authorisation by phone:

approved authorisation with 3
a
authorisation code x...x
TransactionCapture:True
AdditionalService:VoiceAuthorisation
3 AcceptorComple
TransactionSuccess:True b tionAdvice
ResponseToAuthorisation:Declined
AuthorisationCode:x...x
se
ionAdviceRespon
AcceptorComplet
2071 Figure 55: Successful Voice Authorisation captured with Completion
6 Additional Payment Services - 240 - 6.1 Voice Authorisation

2072 4. If the voice authorisation is declined, the transaction fails. The Acceptor must not send a capture,
2073 and has to follow the the standard process flow of the declined transactions for the Completion
2074 exchange (see section 5 Dynamic of the Payment Exchanges). If the transaction is sent in a
2075 completion or a batch, it contains the following informations:
2076  TransactionCapture present with the value "False".
2077  An occurrence of AdditionalService must be added and set to "VoiceAuthorisation",
2078  TransactionSuccess equal "False".
2079  AuthorisationResult.AuthorisationCode is absent.
2080  ResponseToAuthorisation.Response set to "Declined"
Acceptor Acquirer
AcceptorAutho
online authorisation 1 risationReques
t
Response:Declined
2
se ActionType:Referral
risationRespon
AcceptorAutho

declined authorisation, no 4
authorisation code
TransactionCapture:False AcceptorComple
tionAdvice
TransactionSuccess:False
ResponseToAuthorisation:Declined se
ionAdviceRespon
AcceptorComplet
2081 Figure 56: Unsuccessful Voice Authorisation captured with Completion.

2082 The Acceptor is not necessary blocked between the declined/referral authorisation and the result of
2083 the Voice Authorisation. Other transactions may be interleaved between the declined/referral
2084 authorisation and the Completion containing the outcome of the Voice Authorisation. In the figure
2085 below:
2086  An AcceptorAuthorisationRequest is declined with the ActionType "Referral" (transaction 1);
2087  Another payment transaction is performed on the terminal with an online authorisation and a
2088 completion exchange (transaction 2);
2089  The Acceptor contact the voice authorisation center to get the authorsation code for
2090 transaction 1;
2091  The Acceptor initiates a Completion after entering the authorisation code.
Acceptor Acquirer
AcceptorAuthorisationReque
start transaction 1 st 1
Response:Declined
1 ActionType:Referral
AcceptorAuthorisationReque
st 2
Response:Approved
2
transaction 2
AcceptorCompletionAdvice 2
esponse 2
AcceptorCompletionAdviceR

approved authorisation with
end transaction 1 AcceptorCompletionAdvice 1

AdditionalService:
VoiceAuthorisation esponse 1
AcceptorCompletionAdviceR
2092 Figure 57: Successful Voice Authorisation Interleaved with another transaction

2093 An example of successful Voice Authorisation with Batch capture and no Completion is presented in
2094 the figure below. The batch contains one occurrence of TransactionToCapture with:
2095  AdditionalService = "VoiceAuthorisation",
2096  TransactionSuccess = "True",
2097  ResponseToAuthorisation.Response = "Declined",
2098  AuthorisationCode containing the code provided by phone.
Acceptor Acquirer
AcceptorAuthor
online authorisation isationRequest
Response:Declined
ActionType:Referral
isationResponse
AcceptorAuthor

approved authorisation with
other transactions [other transactions]
TransactionToCapture[n]
AcceptorBatch
TransactionSuccess:True Tr ansfer
ResponseToAuthorisation:Declined
AuthorisationCode:x...x
ansferResponse
AcceptorBatchTr
2099 Figure 58: Successful Voice Authorisation Captured with Batch without Completion

2100 6.2 Deferred Payments

2102 Deferred payment is a service which enable the Acceptor to:
2103  Request an authorisation to get a maximum amount to be able to pay,
2104  Complete the delivery of goods or use of service to be paid up to the maximum amount,
2105  Inform the Acquirer of the payment of these goods or services with the final amount within a
2106 limited time frame.
2107 Deferred Payment is available in attended and unattended environments. This is widely used in the
2108 petrol environment. This is also called “Outdoor Petrol” when used in the specific petrol sector.
2109 The Authorisation and Completion exchanges are required to perform a deferred payment transaction.
Acceptor Acquirer
AcceptorAuthorisationRequ
est
maximum amount
maximum amount nse
AcceptorAuthorisationRespo
Delivery of goods
Use of service
final amount
se
AcceptorCompletionAdviceRespon
2110 Figure 59: Deferred Payment
2111 During delivery of goods, other payment transactions can be performed, and the two steps of a
2112 deferred payment transaction (Authorisation exchange and Completion exchange) may be interleaved.
Acceptor Acquirer
1
1
Delivery of goods 2
transaction 1
2
AcceptorCompletionAdvice 1
Delivery of goods
nse 1
AcceptorCompletionAdviceRespo transaction 2
2
nse 2
AcceptorCompletionAdviceRespo
2113 Figure 60: Interleaved Deferred Payment Transactions
2114 A deferred payment transaction is characterised in the exchanged messages by the value
2115 "DeferredPayment" of the data element TransactionType.
6 Additional Payment Services - 244 - 6.2 Deferred Payments

2116 6.2.2 Constraints on the Protocol

2117 The deferred payment transaction respects the following rules, particular to this service:
2118 1. The Authorisation is performed online.
2119 2. If an approved AcceptorAuthorisationResponse is received by the Acceptor, and goods or

2120 services have been delivered, an AcceptorCompletionAdvice message must be sent with:
2121  MessageFunction = "CompletionAdvice" or "FinancialCompletionAdvice",
2122  TotalAmount with the final amount,
2123  Reversal = "False" or absent,
2124  TransactionSuccess = "True".
Acceptor Acquirer
maximum amount
Response:Approved
delivery of goods/service
TotalAmount:final amount
AcceptorCompletionAdviceResponse
2125 Figure 61: Approved Deferred Payment without Delivery

2126 3. The Completion exchange is mandatory, except when the two following conditions are
2127 fullfilled:
2128  the AcceptorAuthorisationResponse has been received by the Acceptor, the authorisation
2129 is declined and the payment transaction is not overridden by the Merchant, and
2130  the Acceptor is not configured to send a completion for declined online authorisations
2131 (see section 5, Dynamic of the Payment Exchanges),
2132 The AcceptorAuthorisationResponse of a declined deferred payment must have the final
2133 amount TotalAmount with a copy of the value sent in the AcceptorAuthorisationRequest.
Acceptor Acquirer
Response:Declined
maximum amount
No delivery of goods/service
(if configured to not send
declined)
2134 Figure 62: Declined Deferred Payment
2135 4. If the AuthorisationRequest contains AmountQualifier value:

2136  "Estimated", the AuthorisationResponse may contain TotalAmount higher, equal or
2137 lower than in the request,
2138  "Maximum", the AuthorisationResponse may contain TotalAmount equal or lower than
2139 in the request,
2140 If the authorisation is approved, ResponseToAuthorisation.Response must be :

2141  "Approved" when TotalAmount of the AuthorisationResponse is higher than or

2142 equal to the requested amount,
2143  "PartialApproved" when TotalAmount of the AuthorisationResponse is lower than in
2144 the request.
2145 5. If the authorisation is approved, the Completion exchange must be performed according to the
2146 configuration after the finalisation of the delivery of goods or service with:
2147  A value of TotalAmount lower or equal the value of TotalAmount sent in the
2148 AcceptorAuthorisationResponse,
2149  AmountQualifier absent or equal to "Actual".
2150 The configuration parameters of the Completion (TMS parameters
2151 OnlineTransaction.CompletionExchange or OfflineTransaction.CompletionExchange) as well
2152 as the CompletionRequired of the AuthorisationResponse are ignored.
2153 6. The financial capture must be performed either within the Completion exchange, or through a
2154 batch transfer. It cannot be performed as part of the Authorisation exchange.
Acceptor Acquirer
maximum amount
Response:Approved
Delivery of goods/
Use of service
TransactionCapture:True
onse
AcceptorCompletionAdviceResp
2155 Figure 63: Deferred Payment Captured by Completion
Acceptor Acquirer
maximum amount
Response:Approved
Delivery of goods/
Use of service
TransactionCapture:False
nse
AcceptorCompletionAdviceRespo
AcceptorBatchTr ansfer
e
AcceptorBatchTransferRespons
2156 Figure 64: Deferred Payment Captured by Batch

2157 7. After confirmation to the sale system that the goods can be delivered (e.g. after the payment
2158 response to the sale system of the Retailer protocol), if the goods or services have not been
2159 delivered because the customer did not continue or the delivery failed, an
2160 AcceptorCompletionAdvice message must be sent with:
2161  MessageFunction = "CompletionAdvice" or "FinancialCompletionAdvice",
2162  TotalAmount with the value "0",
2163  Reversal = "False",
2164  TransactionSuccess = "True",
2165  FailureReason = "CustomerCancel", "Malfunction".
Acceptor Acquirer
maximum amount
Response:Approved
No delivery of goods/service
TotalAmount:0
AcceptorCompletionAdviceResponse
2166 Figure 65: Approved Deferred Payment without Delivery
2167 8. If there is an incident after receiving an approved AcceptorAuthorisationResponse, but before

2168 confirming to the sale system that the goods can be delivered, an AcceptorCompletionAdvice
2169 message must be sent with:
2170  MessageFunction = "ReversalAdvice",
2171  TotalAmount with the maximum authorised amount,
2172  Reversal = "True",
2173  TransactionSuccess = "False",
2174  FailureReason = "CardDeclined", "CustomerCancel", "Malfunction" or
2175 "UnableToComplete".
2176 9. The following scenarios from the Table 3 - List of Payment Cases do not apply to the
2177 DeferredPayment type of transaction:
2178  All the offline authorisation cases are irrelevant (cases 47 to 63)
2179  All the cases where financial capture is performed during the
2180 authorisation (cases 1, 2, 6, 9,12, 13, 18, 22, 23, 28, 32, 35, 38, 41 and 44),
2181  The successful transaction cases where the completion is not required
2182 (cases 4, 20, and 30).

2183 6.3 Cashback

2184 This feature allows the cardholder to obtain cash from the Card Acceptor in conjunction with a
2185 payment. The cardholder receives the extra cash amount in notes or coins along with the
2186 goods/services.
2187 It is an additional feature on a payment and does not change message exchanges.
2188 A cashback transaction must only permit the dispensing of cash on successful authorisation or
2189 successful referral.
2190 A cashback transaction must obey the following rules :

2191 1. The cardholder must be present at the POI (PaymentContext.CardholderPresent = ”True”)
2192 2. Cashback is requested in the AcceptorAuthorisationRequest (Transaction.TransactionType=
2193 ”CashBack”)
2194 3. An instance of TransactionDetails.DetailedAmount must be included in AuthorisationRequest and
2195 AuthorisationResponse messages:
2196  Type=”CashBack”
2197  Value=(cashback amount)
2198 4. If Response = “Approved” or "PartialApproved", the authorised cashback amount (which may be
2199 0) is returned in the AcceptorAuthorisationResponse message.
2200 5. Any cashback given to the cardholder must be included in the AcceptorCompletionAdvice and
2201 AcceptorBatchTransfer messages. If no cashback is delivered, a value of 0 is used.
6 Additional Payment Services - 248 - 6.3 Cashback

2202 6.4 Cash Advance

2203 This is a service which allows the card acceptor to give cash to the cardholder without any other goods
2204 or services.
2205 It is a special case of a payment and does not change message exchanges.
2206 A cash advance transaction must only permit the dispensing of cash on successful authorisation or
2207 successful referral.
2208 Normally a cash advance would be a face-to-face transaction between the card acceptor and
2209 cardholder but with the rise of internet-based currency exchanges, this protocol does not limit the cash
2210 advance service to this environment.
2211 A cash advance transaction must obey the following rules :

2212 1. Cash advance is requested in the AcceptorAuthorisationRequest with TransactionType=
2213 ”CashAdvance”.
2214 2. The amount of cash advance transaction (TransactionDetails.TotalAmount) is the amount of
2215 cash being distributed.
2216 3. The Authorisation is always online ( PaymentContext.OnLineContext=”True”).
6 Additional Payment Services - 249 - 6.4 Cash Advance

2217 6.5 Gratuity

2218 This feature allows adding a supplementary amount to the payment of goods/services.
2219 It is an additional service on a payment and does not change message exchanges.
2220 This protocol does not address any business rules regarding when in the payment process a gratuity
2221 may be added to the transaction nor when a gratuity may need additional authorisations.
2222 This protocol shows two different methods for implementing gratuity :
2223 1. Gratuity is added before authorisation
2224 2. Gratuity is added after authorisation
2225 The cardholder must be present at the POI,PaymentContext.CardholderPresent=”True”.
2226 Whenever a gratuity amount is included in a message exchange it must be clearly identified in an
2227 instance of TransactionDetails.DetailedAmount as follows :
2228  Type=”Gratuity”
2229  Value=(gratuity amount)
2230 Gratuity added before authorisation

2231 1. A card payment is requested in the AcceptorAuthorisationRequest
2232  Transaction.AddtionalService=”Gratuity”
2233 2. The total amount, TransactionDetails.TotalAmount, of a gratuity transaction
2234 (TransactionDetails.TotalAmount) in the AcceptorAuthorisationRequest is the sum amount of
2235 purchase amount and the gratuity amount.
2236 3. If Response = “Approved” or "PartialApproved", the authorised gratuity amount (which may be
2237 0) is returned in the AcceptorAuthorisationResponse message.
2238 Gratuity added after authorisation

2239 Gratuity must only be present in the AcceptorCompletionAdvice or AcceptorBatchTransfer.
2240 Any gratuity must be included in the AcceptorCompletionAdvice and AcceptorBatchTransfer

2241 messages related to the transaction and TotalAmount must contain the sum amount of purchase
2242 amount and the gratuity amount.
2243 6.6 Reservation
2245 A reservation service is mostly used in hotels and for rental business (car, video …). The reservation
2246 service is implemented through one mandatory and four optional steps:
2247 Mandatory step for standard case :

2248  Initial Reservation
2249 Optional steps

2250  Update Reservation
6 Additional Payment Services - 250 - 6.6 Reservation

2251  Cancellation of the Reservation (before payment)
2252  Payment after Reservation, it may be a No-show Payment
2253  Additional Payment after Reservation
2254 A No-Show payment can be performed without prior reservation.
2255 6.6.2 Reservation steps
2256 6.6.2.1 Initial Reservation

2257 The “Initial Reservation” allows the card acceptor to reserve an amount for a period of time in order to
2258 secure that sufficient fund is available to complete a subsequent payment.
2259 6.6.2.2 Update Reservation

2260 The “Update Reservation” allows the card acceptor to change the amount and/or the specified period
2261 of a Reservation.
2262 6.6.2.3 Cancellation of the Reservation (before payment)

2263 If the Cancellation of the reservation occurs before the payment is performed; then it allows the card
2264 acceptor to cancel a previously approved reservation.
2265 6.6.2.4 Payment for the Reservation

2266 The Payment for the Reservation allows the card acceptor to make a payment using a previously
2267 approved initial or updated reservation.
2268 The amount may be zero.
2269 6.6.2.5 No-Show Payment for the Reservation

2270 The “No-Show Payment for the Reservation” allows the card acceptor to charge the cardholder for an
2271 agreed amount because the cardholder did not show up as expected.
2272 6.6.2.6 Additional Payment (after Payment for the Reservation)

2273 The “Additional Payment” allows the card acceptor to charge the cardholder for additional expenses
2274 after the “Payment for the Reservation” has been done.
2275 If the cardholder is absent during this phase, stored card data will be used which implies that the card
2276 security code is not present. This transaction has to be identified as Additional Payment linked to the
2277 reservation.
2278 6.6.2.7 No-show payment without performing a prior reservation service

2279 A no-show transaction can be performed although no prior reservation transaction was carried out.
2280 6.6.3 Message flows

2281 Message flows regarding the Authorisation Request, Authorisation Response, Completion Advice and
2282 Completion Response are the same as for any other service and are therefore not specifically
2283 documented here.

2284 6.6.4 Description of the steps
2285 6.6.4.1 Initial reservation

2286 The initial reservation transaction always processes an online Authorisation to reserve an
2287 amount for a specific period for a later payment of goods or services. Financial Capture
2288 with the authorisation is not applicable.
2289 If the authorisation request is approved by the card acceptor:

2290  A completion must be sent
2291  The possible subsequent steps are:
2292 o The reservation can be cancelled
2293 o The reservation can be updated
2294 o A payment after reservation can be done
2295 o Or a No-Show payment after reservation can be done
2296 If the authorisation request is declined:

2297  The reservation process is ended and, based on configuration, a completion may
2298 be sent.
2299 A completion for an unsuccessful transaction must be sent under the following conditions:
2300  An approved authorisation is not correctly completed at card acceptor side
2301  There is no response to the authorization request
2302  The response of the authorization request is received too late:
2303 Then the reservation process is ended
2304 6.6.4.2 Update reservation

2305 The update reservation transaction always processes an online Authorisation to change
2306 the previous reservation amount and/or the specified period. Financial Capture with the
2307 authorisation is not applicable
2308 If the authorisation request is approved and correctly processed by the card acceptor:
2309  A completion must be sent
2310  The possible subsequent steps are:
2311 o The reservation can be cancelled
2312 o A new update reservation can be done
2313 o A payment after reservation or a No-Show payment after reservation can

2314 be done

2315 If the authorisation request is declined:

2316  The previous reservation remains unchanged.
2317 If an approved update authorisation transaction is not correctly completed or if there is

2318 no response or if the response is received too late :
2319  An unsuccessful completion must be sent.
2320  The previous reservation remains unchanged.
2321 6.6.4.3 Cancellation of the reservation (before payment)

2322 A reservation can be cancelled before the payment takes place. A reversal (completion) is
2323 sent on line to reverse the reservation. The reservation process is ended.
2324 6.6.4.4 Payment after reservation

2325 A payment after reservation is carried out through a completion advice or batch transfer.
2326 A Payment After Reservation can be a No-Show payment
2327 The reservation process is ended, nevertheless, the following subsequent steps are
2328 possible:
2329  An additional payment can be done.
2330  The payment for the reservation can be cancelled.
2331 6.6.5 Reservation transaction data

2332 Message structures regarding the Authorisation Request, Authorisation response, Completion Advice
2333 and Completion Response are the same as for a normal payment and only the components with
2334 specific reservation tags or values are represented in these tables.
2335 6.6.5.1 Initial reservation
2336 6.6.5.1.1 AcceptorAuthorisationRequest

AcceptorAuthorisationRequest Mult. Rule Usage
Header [1..1] It conveys information related to the protocol management on a segment of
the path from the Acceptor to the Acquirer:
MessageFunction [1..1] The only valid codes to request an authorisation for an initial reservation is:
AuthorisationRequest: Request without financial capture
(TransactionCapture="False")
(if an invalid value is received, a Reject message is sent by the Recipient

with RejectReason equal to "ParsingError")
…
AuthorisationRequest [1..1] The Header.MessageFunction must be "AuthorisationRequest".
(In case of an invalid value, a Reject message is sent by the Recipient with
RejectReason equal to "ParsingError")
…
Transaction [1..1]
TransactionCapture [1..1] TransactionCapture = "False"
TransactionType [1..1] " Reservation "
…


ServiceAttribute [0..1] Mandatory. Equal to “InitialReservation”
…
SaleReferenceIdentification [0..1] Mandatory for reservation
…
OriginalTransaction [0..1] Appli Not used if TransactionType="Reservation” and
ServiceAttribute=”InitialReservation”
…
TransactionDetails [1..1]
…
AmountQualifier [0..1] “Estimated”
…
ValidityDate [0..1] Config The date after which the reservation expires
...

2337 6.6.5.1.2 AcceptorAuthorisationResponse

AcceptorAuthorisationResponse Mult. Rule Usage
Header [1..1] see AcceptorAuthorisationRequest
MessageFunction [1..1] The only valid codes to request an authorisation for an initial reservation is:
AuthorisationResponse:
…
AuthorisationResponse [1..1] The Header.MessageFunction must be AuthorisationResponse
…
Transaction [1..1]
…
…
ValidityDate [0..1] Config Depending of the scheme rules, the value of validity date in the
authorisation response may differ from the value contained in the
authorisation request
…
2338 6.6.5.1.3 AcceptorCompletionAdvice

AcceptorCompletionAdvice Mult. Rule Usage
Header [1..1]
MessageFunction [1..1] The only valid codes to advice an initial reservation are :
CompletionAdvice: Completion without financial capture
(TransactionCapture=False, Reversal=False) or
(TransactionCapture=False, Reversal=True, TransactionSuccess=True)
ReversalAdvice: Reversal of an authorisation without financial capture
(TransactionCapture=False, Reversal=True, TransactionSuccess =False)
in case of an invalid value, a Reject message is sent by the Recipient with
RejectReason equal to ParsingError
…
CompletionAdvice [1..1] The Header.MessageFunction must be CompletionAdvice, or
ReversalAdvice
(if not the case, a Reject message is sent by the Recipient with
RejectReason equal to ParsingError)
…
Transaction [1..1] CCopy
TransactionCapture [0..1] Config False or is absent
TransactionType [1..1] “”Reservation”

ServiceAttribute [0..1] “InitialReservation”
…
…
OriginalTransaction [0..1] Appli Not used if TransactionType="Reservation and
ServiceAttribute=”InitialReservation”"
…
MerchantOverride [0..1] Appli False or is absent
FailureReason [0..*] Appli CardDeclined, CustomerCancel, UnableToComplete, TimeOut
…
…
AmountQualifier [0..1] Appli ““Estimated”


…
ValidityDate [0..1] Config
…
2339 6.6.5.1.4 AcceptorCompletionAdviceResponse

AcceptorCompletionAdviceRespon Mult. Rule Usage
se
Header [1..1]
MessageFunction [1..1] The only valid codes are:
CompletionAdviceResponse: response for CompletionAdvice
ReversalAdviceResponse: response for ReversalAdvice
(in case of an invalid value, a Reject message is sent by the Recipient
with RejectReason equal to ParsingError)
…
2340 6.6.5.2 Update reservation

MessageFunction [1..1] The only valid codes to request an authorisation for an update reservation
is:

…
AuthorisationRequest [1..1] The Header.MessageFunction must be "AuthorisationRequest".

…
Transaction [1..1]
TransactionCapture [1..1] TransactionCapture = "False"
TransactionType [1..1] " Reservation "
…
ServiceAttribute [0..1] “UpdateReservation”
…
SaleReferenceIdentification [0..1] Must be the same value as the initial value
…
OriginalTransaction [0..1] Appli Mandatory if available. Identify the previous transaction within the
reservation process
…
TransactionType [1..1] “Reservation"
…
ServiceAttribute [0..1] “InitialReservation” or “UpdateReservation”
…
…
CumulativeAmount [0..1] Contains the updated total amount of all authorisations related to the
reservation transaction (same SaleReferenceIdentification ).

AmountQualifier [0..1] “Estimated” – The estimated amount could be above or below

“Incremental” - Incremental amount for reservation
“Decremental” – Decremental amount for reservation
…
...
2342 6.6.5.2.2 AcceptorAuthorisationResponse

AcceptorAuthorisationResponse Mult. Rule Usage
Header [1..1] see AcceptorAuthorisationRequest
MessageFunction [1..1] The only valid codes to request an authorisation for an update reservation
is:
AuthorisationResponse:
…
AuthorisationResponse [1..1] The Header.MessageFunction must be AuthorisationResponse
…
Transaction [1..1]
…
…
AmountQualifier [0..1] Appli In case of multiple authorisations for the same transaction, the acquirer may
set the value “Reserved” to indicate to the actual amount reserved for the
reservation transaction (same SaleReferenceIdentification).
…
ValidityDate [0..1] Config Depending of the scheme rules, the value of validity date in the
authorisation response may differ from the value contained in the
authorisation request
…

Header [1..1]
MessageFunction [1..1] The only valid codes to advice an update reservation are :
(TransactionCapture=False, Reversal=True, TransactionSuccess=True)
(TransactionCapture=False, Reversal=True, TransactionSuccess =False)
…
ReversalAdvice
…


ServiceAttribute [0..1] “UpdateReservation”
…
…
OriginalTransaction [0..1] Appli Mandatory, Identify the previous transaction within the reservation process
…
…
ServiceAttribute [0..1] “InitialReservation” or “updateReservation”
…
FailureReason [0..*] Appli “CardDeclined, ” CustomerCancel, UnableToComplete, TimeOut
…
…
AmountQualifier [0..1] Appli ““Estimated”
…
…

se
Header [1..1]
CompletionAdviceResponse: response for CompletionAdvice
…
2345 6.6.5.3 Cancellation of a Reservation before payment

Header [1..1]
MessageFunction [1..1] The only valid codes to advice an initial reservation is :
…
ReversalAdvice
…



ServiceAttribute [0..1] “InitialReservation” or “UpdateReservation”
…
SaleReferenceIdentification [0..1] Must be the same value as the initial reservation
…
OriginalTransaction [0..1] Appli Must be present if available
…
TransactionSuccess [1..1] True
Reversal [0..1] Appli True
FailureReason [0..*] Appli CustomerCancel, Malfunction
…
…
TotalAmount [1..1] Appli Must be equal to zero as specified for normal payment: “equal to Final
amount of the payment transaction when TransactionSuccess is "True””.
AmountQualifier [0..1] Appli Actual or is absent
…
AuthorisedAmount [0..1] Appli Must be present as specified for normal payment. “Amount authorised for
the payment transaction, , mandatory if the authorized amount
(TotalAmount of the AcceptorAuthorisationResponse) is different from the
requested amount (TotalAmount of the AcceptorAuthorisationRequest)”
…
ValidityDate [0..1] Mandatory for reservation
…

se
Header [1..1]
MessageFunction [1..1] The only valid codes is:
…
2348 6.6.5.4 Payment after reservation

Header [1..1]
MessageFunction [1..1] The only valid codes to advice a payment after reservation is:
FinancialCompletionAdvice: Completion with financial capture
(TransactionCapture=True, Reversal=False)
(in case of an invalid value, a Reject message is sent by the Recipient with
…
CompletionAdvice [1..1] The Header.MessageFunction must be FinancialCompletionAdvice.


…
TransactionCapture [0..1] Config True

AdditionalService [0..*] “NoShow” is possible for a payment after reservation
ServiceAttribute [0..1] “PaymentReservation”
…
…
Reversal [0..1] False or is absent”
…
OriginalTransaction [0..1] Appli Mandatory, Identify the previous transaction within the reservation process
…
ServiceAttribute [0..1] “InitialReservation” or “updateReservation”
…
…
AmountQualifier [0..1] Appli “Actual” or is absent
…
…

se
Header [1..1]
FinancialCompletionAdviceResponse: response for CompletionAdvice
…
2351 6.6.5.4.3 AcceptorCancellationRequest

AcceptorCancellationRequest Mult. Rule Usage
…
CancellationRequest [1..1] The Header.MessageFunction must be CancellationRequest.
RejectReason equal to “ParsingError”)
…
Transaction [1..1]
…
…
…


…
2352 6.6.5.4.4 AcceptorCancellationResponse
2353 Refer to Normal Payment
2354 6.6.5.4.5 AcceptorCancellationAdvice

AcceptorCancellationAdvice Mult. Rule Usage
CancellationAdvice [1..1] The Header.MessageFunction must be CancellationAdvice.

Transaction [1..1]

…
2355 6.6.5.4.6 AcceptorCancellationAdviceResponse
2357 6.6.5.5 Additional payment

MessageFunction [1..1] The only valid codes to request an authorisation for payment after
reservation are:
FinancialAuthorisationRequest: Request with financial capture
TransactionCapture="True")
…
AuthorisationRequest [1..1] The Header.MessageFunction must be "AuthorisationRequest" or
"FinancialAuthorisationRequest".
…
Transaction [1..1]
…


TransactionType [1..1] "Reservation"
…
ServiceAttribute [0..1] “AdditionalPayment”
…
…
ServiceAttribute=”“AdditionalPayment”
…
…
AmountQualifier [0..1] “Actual”
…
...
2359 6.6.5.5.2 AcceptorauthorisationResponse

Header [1..1]
MessageFunction [1..1] The only valid codes to advice a payment after reservation are:
TransactionSuccess=True)
(TransactionCapture=True, Reversal=False) or
(TransactionCapture=True, Reversal=True, TransactionSuccess
=True)
(TransactionCapture=False, Reversal=True, TransactionSuccess
=False)
FinancialReversalAdvice: Reversal of a FinancialAuthorisation
(TransactionCapture=True, Reversal=True, TransactionSuccess
=False)
…
CompletionAdvice [1..1] The Header.MessageFunction must be CompletionAdvice,
FinancialCompletionAdvice, ReversalAdvice or FinancialReversalAdvice.
…
…
…
ServiceAttribute [0..1] “AdditionalPayment
…


SaleReferenceIdentification [0..1] Must be the same value as the inital reservation
…
ServiceAttribute=”AdditionalPayment”"
…
…
…

…
CancellationRequest [1..1] The Header.MessageFunction must be CancellationRequest.
RejectReason equal to “ParsingError”)
…
Transaction [1..1]
…
…
…
…

CancellationAdvice [1..1] The Header.MessageFunction must be CancellationAdvice.

Transaction [1..1]


…
2370 6.6.5.6 No-show payment without prior reservation

Header [1..1]
MessageFunction [1..1] The only valid codes to advice No-Show payment is ::
(TransactionCapture=True, Reversal=False)
…
CompletionAdvice [1..1] The Header.MessageFunction must be FinancialCompletionAdvice.
…
…
TransactionType [1..1] “”CardPayment”
AdditionalService [1..1] “”NoShow”
…


2382 6.6.5.7 Batch
2383 6.6.5.7.1 AcceptorBatchTransfer

Or AceptorBatchTransfer Mult. Rule Type / Definition / Code List
Header [1..1]
…
BatchTransfer [1..1]
…
DataSet [0..*] A data set may include both financial (completed transactions)
and non financial transactions (uncompleted transactions).
TransactionTotals [1..*] TransactionTotals of the DataSet.
…
Type [1..1] see AcceptorReconciliationRequest for Reservation
…
CommonData [0..1] Data common to transactions of a DataSet may be factorised in
CommonData to reduce the message length.
All transactions of the DataSet inherit the data element value
present in CommonData except if this data element is present
in the occurrence of Transaction.
…
TransactionType [0..1] “Reservation”
AdditionalService [0..*] “NoShow” is possible
…
Transaction [1..*] Transaction of the data set. It must be a completion, a
cancellation advice, an authorisation request or an authorisation
response.
{Or Completion [1..1]
…
Transaction [1..1]
TransactionType [0..1] “Reservation”
AdditionalService [0..*] “NoShow” is possible
…
SaleReferenceIdentification [0..1] Appli Mandatory for Reservation
…
TransactionIdentification [1..1] Based on TransactionIdentifier
see AcceptorCompletionAdvice for Reservation after payment

…
OriginalTransaction [0..1] Appli see AcceptorCompletionAdvice for Reservation after payment
…
TransactionDetails [1..1] see AcceptorCompletionAdvice for Reservation after payment
…
Or Cancellation [1..1] Cancelled card payment transaction.
…
Transaction [1..1] see AcceptorCancellationAdvice for reservation after payment
…
Or AuthorisationRequest [1..1] Authorisation request of a card payment transaction.
…
Transaction [1..1] see AcceptorAuthorisationRequest for Initial and update
reservation
…

Or AceptorBatchTransfer Mult. Rule Type / Definition / Code List

Or} AuthorisationResponse [1..1] Authorisation response of a card payment transaction.
…
Transaction [1..1] see AcceptorAuthorisationResponse for Initial and update
reservation
…
2384 6.6.5.8 Reconciliation
2385 6.6.5.8.1 AcceptorReconciliationRequest

AcceptorReconciliationRequest Mult. Rule Usage
…
ReconciliationRequest [1..1] The Header.MessageFunction must be ReconciliationRequest.
(if not the case, a Reject message is sent by the Recipient with RejectReason
equal to ParsingError)
…
Transaction [1..1]
…
TransactionTotals [0..*] TransactionTotals of the reconciliation period.
TransactionTotals is absent if the reconciliation period contains no transactions.
…
Type [1..1] All the values are allowed:
Debit: Debit transactions (TransactionType is CardPayment, CashBack,
CashAdvance, DeferredPayment, Reservation) during the reconciliation
period.
DebitReverse: Cancelled debit transactions.
Credit: Credit transactions (TransactionType is Refund during the
reconciliation period.
CreditReverse: Cancelled credit transactions.
Declined: transactions declined online or offline.
Failed: failed transactions.
2386 6.6.5.8.2 AcceptorReconciliationResponse

2388 6.7 Dynamic Currency Conversion (DCC)
2390 Some transactions may be handled in foreign currencies which makes difficult for a
2391 cardholder to estimate the actual amount he will have to pay in his own currency at the
2392 moment of the payment.
2393 A Dynamic Currency Conversion is a service offered by a merchant to allow the

2394 cardholder to make the payment in the currency of his card instead of the currency of the
2395 merchant when different.
2396 The cardholder can accept or not the DCC service. When DCC is allowed by the
2397 merchant, the currency conversion is managed through a DCC service provider proposing
2398 to the cardholder the converted amount to be ultimately debited on his card.
2399 If the DCC service is refused by the cardholder, the transaction then proceeds as a
2400 normal card payment transaction in the currency of the merchant.
2401 The DCC service may be relying on an agent acting between the merchant and the DCC
2402 service provider. The following use cases involve agents in the process, but direct
2403 exchanges between a merchant and a DCC service provider or between a merchant and
2404 an acquirer do follow the same logic.
2405 The role of the DCC service provider can be played by any party (Agent, Acquirer, etc.).
2406 6.7.2 Currency conversion during the authorisation
2407 In this process, the Dynamic Currency Conversion service is implemented during the
2408 authorisation through an AcceptorAuthorisationRequest message (“implicit rate
2409 request”).
2410 The Acceptor or Agent asks the DCC service provider whether the card is eligible for a
2411 Dynamic Currency Conversion service or not.
2412 The actual authorisation is carried out either in the currency of the card or in the currency
2413 of the merchant depending on the outcome of the DCC process and the decision of the
2414 cardholder.
6 Additional Payment Services - 268 - 6.7 Dynamic Currency Conversion (DCC)

2415 The conversion service is carried out along the following steps:
2416 1. The Acceptor sends an AcceptorAuthorisationRequest message to an Agent or an
2417 Acquirer.
2418 2. The Agent or Acquirer detects whether the transaction is eligible for DCC and
2419 sends an AcceptorCurrencyConversionRequest message to the DCC service
2420 provider to ensure the eligibility of the card and to get the conversion rate for the
2421 transaction in case of eligibility.
2422 3. The DCC Provider answers with an AcceptorCurrencyConversionResponse
2423 message with the requested information.
2424 4. The Agent or Acquirer sends back an AcceptorAuthorisationResponse message to
2425 the Acceptor with the proposed currency conversion data when eligibility has been
2426 confirmed.
2427 5. The Cardholder accepts the proposed currency conversion.
2428 6. The Acceptor sends an AcceptorAuthorisationRequest message to the Agent or
2429 Acquirer with the accepted converted amount and all relevant information related
2430 to the conversion process.
2431 7. The Agent or Acquirer forwards the AcceptorAuthorisationRequest for
2432 authorisation.
2433 8. The next steps follow a normal transaction flow (i.e. Completion capture, batch
2434 capture, etc.) with some additional information related to the conversion process.
2435 9. If the DCC service was accepted by the cardholder, the Agent or Acquirer advises
2436 the DCC service provider with an AcceptorCurrencyConversionAdvice that the DCC
2437 transaction was completed
2438 10. The DCC service provider responses with an
2439 AcceptorCurrencyConversionAdviceResponse about the completion of the
2440 transaction on his side.
Acceptor Agent DCC Provider
AcceptorAuthori Transaction eligible for

sationRequest
DCC
AcceptorCu
rrencyConv
ersionReques
t Transaction
eligible for
Respons e DCC
ncyConversion
AcceptorCurre
onse
orisationResp
DCC accepted or not AcceptorAuth
by Cardholder
AcceptorAuthori
sationRe quest Acquirer
Transaction
AcceptorAuthori authorised
sationRe quest either in the
currency of
the card or in
onse
orisationResp the currency
Transaction AcceptorAuth
of the
successfully
onse Acceptor
authorised either in orisationResp
AcceptorAuth
the currency of the
card or in the currency DCC Provider
of the Acceptor Next steps follow the normal Next steps follow the normal
transaction flow transaction flow
AcceptorCurrenc DCC
yConversion Advice Provider
informed
about the
AdviceR espons outcome of
ncyConversion e
AcceptorCurre the DCC
service
2441 Figure 66: Currency conversion during the authorisation

2442 6.7.2.1 Transaction eligible for DCC and DCC accepted by the Cardholder
2443 In this scenario, the transaction is considered eligible for DCC by the Agent and the DCC
2444 service provider. The Cardholder accepts the DCC service for the amount in the currency
2445 of his card presented to him. The transaction proceeds as a normal card payment
2446 transaction in the currency of the card.
2447 1. The Acceptor sends an AcceptorAuthorisationRequest message to an Agent. The
2448 message contains the following information :
2449  CurrencyConversion: absent.
2450  TransactionType : CardPayment, CashAdvance, Refund, Reservation,
2451 QuasiCash or DeferredPayment.
2452  AdditionalService : Cashback, Gratuity (if TransactionType = CardPayment)
2453  TransactionDetails.TotalAmount: Total Amount in the Acceptor’s currency.
2454 2. The Agent sends an AcceptorCurrencyConversionRequest to the DCC service
2455 provider with the following information :
2457  Card.CardCurrencyCode: Target currency (currency of the card).
2458  TransactionDetails.Currency: Source currency (currency of the Acceptor).
2459  TransactionCapture: not relevant.
2460  TransactionType : copy from AcceptorAuthorisationRequest.
2461 3. The DCC service provider answers with an AcceptorCurrencyConversionResponse
2462 message with the following information:
2463  Result of currency conversion: Allowed.
2464  Conversion details.
2465 4. The Agent sends back an AcceptorAuthorisationResponse to the Acceptor with the
2466 proposed currency conversion data and the response code “Declined” with the
2467 action type “AcceptCurrencyConversion”.
2469 6. The Acceptor sends an AcceptorAuthorisationRequest with the following data:
2470  TransactionIdentification: copy of the original
2471 AcceptorAuthorisationRequest message
2472  TransactionType: copy of the original AcceptorAuthorisationRequest
2473 message.
2474  TransactionDetail.Currency: copy of Conversion.TargetCurrency of the
2475 original AcceptorAuthorisationResponse message.
2476  TransactionDetail.TotalAmount: copy of the Conversion.ResultingAmount of
2478  AdditionalService: copy of original AcceptorAuthorisationRequest plus DCC.
2479  AcceptedByCardholder: True.
2480  CurrencyConversion: copy of AcceptorCurrencyConversionResponse
2481 message.
2482 7. The Agent forwards the AcceptorAuthorisationRequest message to the Acquirer.
2483 8. The next steps follow the normal transaction flow (i.e. Completion capture, batch
2485 9. The Agent or Acquirer advises the DCC service provider with an
2486 AcceptorCurrencyConversionAdvice that the DCC transaction was completed.

AcceptorAuthori Transaction eligible

sationRequest
for DCC
AcceptorCu
rrencyConv
ersionReques
t
Transaction
eligible for
Response DCC
ncyConversion
AcceptorCurre
on se Acquirer
orisationResp
AcceptorAuth
DCC accepted by AcceptorAuthori
sationRequest
Cardholder
AcceptorAuthori
sationRe quest
Transaction
authorised
se in the
on
orisationResp currency of
AcceptorAuth
Transaction onse the card
orisationResp
successfully AcceptorAuth
authorised in
the currency of
DCC Provider
the card Next steps follow the normal Next steps follow the normal
AcceptorCurrenc DCC
yConversion Advice Provider
informed
about the
AdviceR espons
ncyConversion e success
AcceptorCurre
2490 Figure 67: Transaction eligible for DCC and DCC accepted by the Cardholder

2491 6.7.2.2 Transaction eligible for DCC and partially approved by the Issuer
2493 service provider. It is also assumed that the DCC service provider accept to deliver a
2494 catalogue of a range of amounts for which DCC is offered to the cardholder which would
2495 permit partial authorisation by the Issuer. The Cardholder accepts the DCC service for the
2496 amount in the currency of his card presented to him. The transaction is authorised by the
2497 Issuer but for a reduced amount in the currency of his card (PartialAuthorisation). The
2498 Cardholder accepts the transaction for this reduced amount. The transaction proceeds as
2499 a normal card payment transaction in the currency of the card and for the reduced
2500 authorised amount.
2501 1. The Acceptor sends an AcceptorAuthorisationRequest message to an Agent. The
2502 message contains the following information :
2503  CurrencyConversion: absent.
2505 QuasiCash or DeferredPayment.
2508 2. The Agent sends an AcceptorCurrencyConversionRequest to the DCC service
2509 provider with the following information :
2517  CurrencyConversionResult.Result: CATG (Conversion accepted for a range
2518 of amounts - rate and fees specific per range of amounts)
2519  Conversion details per range of amounts provided.
2520 4. The Agent sends back an AcceptorAuthorisationResponse to the Acceptor with the
2521 proposed currency conversion data ranges and the response code “Declined” with
2522 the action type “AcceptCurrencyConversion”.
2524 6. The Acceptor sends an AcceptorAuthorisationRequest with the following data:
2525  TransactionIdentification: copy of the original
2526 AcceptorAuthorisationRequest message
2527  TransactionType: copy of the original AcceptorAuthorisationRequest
2528 message.
2529  TransactionDetail.Currency: copy of Conversion.TargetCurrency of the
2531  TransactionDetail.TotalAmount: copy of the Conversion.ResultingAmount of
2533  AdditionalService: copy of original AcceptorAuthorisationRequest plus DCC.
2534  AcceptedByCardholder: True.
2536 message
2537 7. The Agent forwards the AcceptorAuthorisationRequest message to the Acquirer.
2538 8. The Issuer authorised the transaction but for a reduced amount. The Acquirer
2539 sends back an AcceptorAuthorisationResponse message to the Agent. The Agents
2540 computes the actual amount to be presented to the cardholder (after computation

2541 of fees and taking into account the reduced authorised amount by the Issuer) and
2542 forwards the amended message to the Acceptor. The Acceptor presents to the
2543 cardholder the reduced authorised amount after the withdrawal of fees and in the
2544 currency of his card.
2545 9. The Cardholder accepts the DCC transaction for the proposed reduced authorised
2546 amount in the currency of his card.
2547 10. The Acceptor sends an AcceptorAuthorisationRequest message to the Agent for
2548 the reduced amount which is then forwards to the Acquirer.
2552 AcceptorCurrencyConversionAdvice that the DCC transaction was completed but
2553 for a reduced amount. The details of the reduced amount accepted by the
2554 cardholder are provided to the DCC service provider.
AcceptorAuthori Transaction possibly

sationRequest eligible for DCC
AcceptorCu DCC
rrencyConv
ersionReques
t accepted
and
conditions
Respons e
ncyConversion provided
AcceptorCurre
onse
DCC accepted by orisationResp
AcceptorAuth
Cardholder AcceptorAuthori Acquirer
sationRequest
AcceptorAuthori Acquirer
sationRe quest authorising
for a
reduced
Agent computes actual amount to be
onse amount
presented to Cardholder orisationResp
AcceptorAuth
Cardholder accepts the onse
orisationResp
reduced authorised AcceptorAuth
amount
AcceptorComple
tionAdvice
Agent acknowledges partial authorised
amount by the cardholder
Response DCC Provider

pletionAdvice
AcceptorCom Next steps follow the normal
authorisation flow for the reduced DCC
amount Provider
AcceptorCurrenc informed
yConversionAd
vice about the
reduced
AdviceR espons converted
ncyConversion e
AcceptorCurre amount
2558 Figure 68: Transaction eligible for DCC and partially approved by the Issuer
-

2559 6.7.2.3 Transaction not eligible for DCC by the DCC service provider
2560 In this scenario, the transaction is considered eligible for DCC by the Agent but not by the
2561 DCC service provider. The cardholder is not offered the DCC service and the transaction
2562 proceeds as a normal card payment transaction in the currency of the merchant.
2563 1. The Acceptor sends an AcceptorAuthorisationRequest message to the Agent with
2564 the following information.
2565  CurrencyConversion : absent.
2566  TransactionType : CardPayment, CashAdvance, Refund,
2567 Reservation, QuasiCash or DeferredPayment.
2568  AdditionalService : Cashback, Gratuity (if TransactionType =
2569 CardPayment)
2570  TransactionDetails.TotalAmount: Total Amount in the Acceptor’s
2571 currency.
2572 2. The Agent sends an AcceptorCurrencyConversionRequest message to the DCC
2573 Provider with the following information.
2575  TransactionDetails.Currency: Source currency (currency of the
2576 Acceptor).
2581  Result: InvalidCard, NoRate, InvalidMerchant, NotAvailable or
2582 InvalidProduct.
2583  Conversiondetails: absent.
2584 4. The Agent sends an AcceptorAuthorisationRequest message to the Acquirer in the
2585 currency of the Acceptor.
2586 5. The Acquirer sends back an AcceptorAuthorisationResponse to the Agent.
2587 6. The Agent forwards the AcceptorAuthorisationResponse to the Acceptor.
Card
eligible for
AcceptorAuth DCC as per Card not
orisationRequ
est eligible or
agent
DCC denied
AcceptorCu by DCC
rrencyConv
ers ionRequest Provider
nResponse
encyConversio
AcceptorCurr
Acquirer
AcceptorAuth
Transaction orisationRequ
est
carried out in Transaction
currency of the authorised
Acceptor nse in the
risationRespo
Transaction AcceptorAutho currency of
the
successfully sponse
thorisationRe Acceptor
authorised in AcceptorAu
the currency of
the Acceptor Next steps follow Next steps follow DCC Provider
the normal the normal
AcceptorCurr Confirmation
encyConvers ionAdvice that DCC
transaction
denied by
thorisation Response DCC
AcceptorAu Provider
2590 Figure 69: Transaction not eligible for DCC by DCC service provider

2591 6.7.2.4 Transaction not eligible for DCC by the Agent

2592 In this scenario, the transaction is considered as not eligible for DCC by the Agent. The
2593 cardholder is not offered the DCC service and the transaction proceeds as a normal card
2595 1. The Acceptor sends an AcceptorAuthorisationRequest message to the Agent. The
2596 message should have the following information.
2601 CardPayment)
2603 currency
2604 2. The Agent detects that the card is not eligible for DCC (the Acceptor doesn’t have
2605 a contract with a DCC service provider or the line to the DCC service provider is
2606 not operational).
2609 4. The Acquirer sends back an AcceptorAuthorisationResponse message to the
2610 Agent.
2611 5. The Agent forwards the AcceptorAuthorisationResponse message to the Acceptor.
AcceptorAutho
risationRequest
DCC Provider
unaware of the
DCC request
transaction is
not eligible or
line to DCC
Provider is not
up and running
Acquirer
AcceptorAutho
risationRequest
onse
orisationResp
successfully
onse
authorised in orisationResp
AcceptorAuth
the currency of
the Acceptor Next steps follow Next steps follow
the normal the normal
2614 Figure 70: Transaction not eligible for DCC by Agent

2615 6.7.2.5 Transaction eligible for DCC but DCC refused by the Cardholder
2616 In this scenario, the transaction is considered eligible for DCC by the Agent and the
2617 DCC service provider. The cardholder refused the DCC service for the amount
2618 presented to him in the currency of his card. The transaction proceeds as a normal
2619 card payment transaction in the currency of the merchant.

2621 the DCC relevant data.
2623 service provider with the DCC relevant data.
2625 message containing the following information:
2626  Result of the currency conversion: Allowed.
2627  Conversiondetails: Present
2628 4. The Agent sends back an AcceptorAuthorisationResponse message to the
2629 Acceptor with the proposed currency conversion data and the response “Declined”
2630 with the action type “AcceptCurrencyConversion”.
2631 5. The Cardholder refuses the DCC service.
2632 6. The Acceptor sends an AcceptorAuthorisationRequest message to the Agent in the
2634  TransactionIdentification: copy of original AcceptorAuthorisationRequest
2635 message
2636  TransactionType : copy of original AcceptorAuthorisationRequest message.
2637  TransactionDetail.Currency: copy of original AcceptorAuthorisationRequest
2638 message.
2639  TransactionDetail.TotalAmount: copy of original
2640 AcceptorAuthorisationRequest message.
2641  AdditionalService: copy of original AcceptorAuthorisationRequest plus DCC
2642 information.
2643  AcceptedByCardholder: False.
2645 message.
2646 7. The Agent forwards the AcceptorAuthorisationRequest message to the Acquirer in
2647 the Acceptor’s currency.
2649 Agent.
2654 AcceptorCurrencyConversionAdvice message that the DCC transaction was
2655 refused by the Cardholder.
2657 AcceptorCurrencyConversionAdviceResponse message about the completion of
2658 the transaction on his side.

AcceptorAuthori
sationRequest
AcceptorCu
rren cyConversio
nRequest
Transaction
Transaction eligible for
eligible for DCC Response DCC
ncyConversion
conversion AcceptorCurre conversion
se
ptorA uth or isationRespon
DCC refused by Acce
cardholder AcceptorAuthori
sationRequest Acquirer
AcceptorAuthori
sationRequest
onse
orisationResp
successfully onse
orisationResp
authorised in AcceptorAuth
the currency of
DCC Provider
the Acceptor
Next steps follow the normal Next steps follow the normal
AcceptorCurrenc
yConversionAd
vice
Resp onse
ionAdvice
yConvers
Currenc
Acceptro
2659 Figure 71: Transaction eligible for DCC but DCC refused by cardholder

2660 6.7.2.6 Transaction eligible for DCC but interrupted due to an incident
2661 6.7.2.6.1 Incident at the Agent level

2662 In this scenario, the transaction is considered eligible for DCC by the Agent but the
2663 response didn’t reach the Acceptor or an error was encountered in the response. The
2672 CardPayment)
2674 currency.
2675 2. The AcceptorCurrencyConversionResponse is not received by the Acceptor due to
2676 an incident.
2677 3. The Cardholder is not offered the possibility to proceed with DCC.
2680 5. The Acquirer sends back an AcceptorAuthorisationResponse to the Agent.
2681 6. The Agent forwards the AcceptorAuthorisationResponse to the Acceptor.
AcceptorAuthori
sationRequest
DCC Provider
unaware of
DCC conversion
Response of AcceptorA
Agent not uthorisatio
received or nResponse
corrupted
Acquirer
AcceptorAuthori
sationRequest
AcceptorAuthori
sationRequest Transaction
Transaction authorised
carried out in in the
currency of the currency of
risation Response
Transaction Acceptor AcceptorAutho the Acceptor
successfully
nse
authorised in risationRespo
the currency of AcceptorAutho
the Acceptor
2684 Figure 72: : Incident at Agent level

2685 6.7.2.6.2 Incident at DCC service provider level

2687 service provider but the response sent by the DCC provider didn’t reach the Agent or an
2688 error was encountered in the response. The cardholder is not offered the DCC service and
2689 the transaction proceeds as a normal card payment transaction in the currency of the
2690 merchant. A negative advice is forwarded to the DCC service provider at the end of the
2691 transaction.
2698 CardPayment)
2700 currency.
2702 service provider with the following information.
2704  TransactionDetails.Currency: Source currency (currency of the
2705 Acceptor).
2709 message to the Agent with all the relevant information.
2710 4. The AcceptorCurrencyConversionResponse message is not received by the Agent
2711 due to an incident.
2716 Agent.
2721 AcceptorCurrencyConversionAdvice message that the DCC transaction did not
2722 succeed.


Card
possibly
eligible for
AcceptorAuth
orisationRequ DCC as per
est
agent
Acceptor CurrencyCo
nversion Request
Response of
DCC service AcceptorC
provider not urrencyCo
nversionRe
received or sponse
corrupted
Acquirer
AcceptorAuth
Transaction orisationRequ
est
carried out in Transaction
currency of the authorised in
nse the currency
Acceptor risationRespo
Transaction AcceptorAutho of the
successfully sponse Acceptor
thorisationRe
the currency of
the Acceptor
DCC Provider
AcceptorCu
rrencyConv
ers ionAdvice
ionAdvice Respons
encyConvers e
AcceptorCurr
2726 Figure 73: Incident at DCC service provider level

2727 6.7.3 Currency conversion prior to the authorisation
2728 In this process, the Dynamic Currency Conversion service is implemented prior to the
2729 authorisation actually taking place and through an AcceptorCurrencyConversion
2730 exchange (“explicit rate request”)
2731 The Acceptor or Agent asks the DCC service provider whether the card is eligible for a
2732 Dynamic Currency Conversion service or not.
2733 The actual authorisation is carried out either in the currency of the card or in the currency
2734 of the merchant depending on the outcome of the DCC process and the decision of the
2735 cardholder.
2736 The conversion service is carried out along the following steps:
2737 1. The Acceptor sends an AcceptorCurrencyConversionRequest message to an Agent
2738 or an Acquirer to ask whether the card is eligible for a currency conversion.
2739 2. The Agent or Acquirer detects whether the transaction is eligible for DCC and, if
2740 eligible, forwards the AcceptorCurrencyConversionRequest message to the DCC
2741 service provider to ensure eligibility of the card and to get the conversion rate for
2742 the transaction.
2744 message with the requested information.
2745 4. The Agent or Acquirer forwards the AcceptorCurrencyConversionResponse
2746 message to the Acceptor with the proposed currency conversion data.
2748 6. The Acceptor sends an AcceptorAuthorisationRequest message to the Agent or
2749 Acquirer with the accepted converted amount and all relevant information related
2750 to the conversion process.
2751 7. The Agent or Acquirer forwards the AcceptorAuthorisationRequest message for
2752 authorisation.
2753 8. The next steps follow a normal transaction flow (i.e. Completion capture, batch
2754 capture, etc.) with some additional information related to the currency conversion
2755 process.
2758 completed.

AcceptorCurrenc
yConversionRe
que st
AcceptorCu
rrencyConv
ersionReques
t
DCC eligible
Response
ncyConversion
AcceptorCurre
onse
orisationResp
DCC accepted or not AcceptorAuth
AcceptorAuthori
by Cardholder sationRequest
AcceptorAuthori Acquirer
sationRe quest
Transaction
authorised
onse either in the
orisationResp
AcceptorAuth currency of the
Transaction card or in the
onse
successfully orisationResp currency of the
AcceptorAuth
authorised either in Acceptor
the currency of the
card or in the currency
of the Acceptor Next steps follow the normal Next steps follow the normal
DCC Provider
AcceptorCurrenc
yConversion Advice Confirmation
of DCC
accepted or
AdviceR espons denied
ncyConversion e
AcceptorCurre
2762 Figure 74: Currency conversion before authorisation

2763 6.7.3.1 Transaction eligible for DCC and DCC accepted by the Cardholder
2764 In this scenario, the transaction is considered eligible for DCC by both the Agent and
2765 the DCC service provider. The cardholder accepts the DCC service for the amount
2766 presented to him in the currency of his card. The transaction proceeds as a normal
2767 card payment transaction in the currency of the card.
2768 1. The acceptor sends an AcceptorCurrencyConversionRequest message to the

2769 Agent with the following information :
2770  CurrencyConversionResult: absent
2772 QuasiCash or DeferredPayment
2775 2. The Agent forwards the AcceptorCurrencyConversionRequest message with

2776 following information to the DCC service provider:
2780  TransactionType: copy from the AcceptorCurrencyConversionRequest
2781 message


2784  Result : Allowed
2785  ConversionDetails: Present
2786 4. The Agent forwards the AcceptorCurrencyConversionResponse message to the

2787 Acceptor with the currency conversion data.
2788 5. The cardholder accepts the proposed currency conversion.
2789 6. The Acceptor sends an AcceptorAuthorisationRequest message with the agreed
2790 currency conversion data:
2791  TransactionType : copy of the AcceptorCurrencyConversionRequest
2792 message
2793  TransactionDetail.Currency: copy of ConversionDetails.TargetCurrency of
2794 the AcceptorCurrencyConversionResponse message.
2795  TransactionDetail.TotalAmount : copy of
2796 ConversionDetails.ResultingAmount of the
2797 AcceptorCurrencyConversionResponse message
2798  AdditionalService : copy of the AcceptorCurrencyConversionRequest
2799 message plus DCC information
2800  CurrencyConversionResult.AcceptedByCardholder : True
2801  CurrencyConversionResult.ConversionDetails: copy of
2802 AcceptorCurrencyConversionResponse

2804 the currency of the card.
2809 completed.

AcceptorCurrenc
yConversionRe
que st
Transaction is AcceptorCu
rrencyConv
eligible for DCC ersionReques Transaction
t
conversion eligible for
DCC
Response
ncyConversion conversion
AcceptorCurre
sionRespon se
rencyConver
AcceptorCur
DCC accepted by
Cardholder AcceptorAuthori
sationRe quest Acquirer
AcceptorAuthori
sationRe quest Transaction
authorised in
the currency of
on se
orisationResp the card
AcceptorAuth
onse
orisationResp
successfully
authorised in the
currency of the card
DCC Provider
AcceptorCurrenc
yConversion Advice Confirmation
of DCC
accepted
AdviceR espons
ncyConversion e
AcceptorCurre
2813 Figure 75: Transaction eligible for DCC and DCC accepted by the Cardholder

2814 6.7.3.2 Transaction eligible for DCC and partially approved by the Issuer
2815 In this scenario, the transaction is considered eligible for DCC by the Agent and the
2816 DCC service provider. It is also assumed that the DCC service provider accept to
2817 deliver a catalogue of a range of amounts for which DCC is offered to the cardholder
2818 which would permit partial authorisation by the Issuer. The Cardholder accepts the
2819 DCC service for the amount in the currency of his card presented to him. The
2820 transaction is authorised by the Issuer but for a reduced amount in the currency of
2821 his card (PartialAuthorisation). The Cardholder accepts the transaction for this
2822 reduced amount. The transaction proceeds as a normal card payment transaction in
2823 the currency of the card and for the reduced authorised amount.
2824 1. The Acceptor sends an AcceptorCurrencyConversionRequest message to the

2825 Agent with the following information :
2831 2. The Agent forwards the AcceptorCurrencyConversionRequest message with
2832 following information to the DCC service provider:
2836  TransactionType: copy from the AcceptorCurrencyConversionRequest
2837 message
2840  Result : Allowed
2841  CurrencyConversionResult.Result: CATG (Conversion accepted for a range
2842 of amounts – rate and fees specified per range of amounts)
2843  Conversion details per range of amounts provided
2845 Acceptor with the currency conversion data.
2846 5. The cardholder accepts the proposed currency conversion.
2847 6. The Acceptor sends an AcceptorAuthorisationRequest message with the agreed
2848 currency conversion data:
2849  TransactionType : copy of the AcceptorCurrencyConversionRequest
2850 message
2851  TransactionDetail.Currency: copy of ConversionDetails.TargetCurrency of
2852 the AcceptorCurrencyConversionResponse message.
2853  TransactionDetail.TotalAmount : copy of
2854 ConversionDetails.ResultingAmount of the
2856  AdditionalService : copy of the AcceptorCurrencyConversionRequest
2858  CurrencyConversionResult.AcceptedByCardholder : True
2859  CurrencyConversionResult.ConversionDetails: copy of
2860 AcceptorCurrencyConversionResponse


2862 the currency of the card.
2863 8. The Issuer authorises the transaction but for a reduced amount. The Acquirer
2864 sends back an AcceptorAuthorisationResponse message to the Agent. The Agent
2865 computes the actual amount to be presented to the Cardholder (after computation
2866 of the fees and taking into account the reduced authorised amount by the Issuer)
2867 and forwards the message to the Acceptor. The Acceptor presents to the
2868 Cardholder the reduced authorised amount after the withdrawal of fees and in the
2869 currency of the card.
2870 9. The Cardholder accepts the DCC transaction for the proposed reduced authorised
2871 amount in the currency of his card.
2872 10. The Acceptor sends an AcceptorAuthorisationRequest message (confirmation of
2873 acceptance of the Cardholder) to the Agent for the reduced amount presented to
2874 the Cardholder which is then further forwarded to the Acquirer.
2879 completed.
AcceptorCurrenc
yConversionRe
que st
AcceptorCu
rrencyConv Transaction
Transaction ersionReques
t
eligible for DCC eligible for
conversion DCC
Response conversion
ncyConversion
AcceptorCurre
sionRespon se
rencyConver
AcceptorCur
Acquirer
AcceptorAuthori
sationRequest
DCC accepted by
Cardholder AcceptorAuthori Transaction
sationRe quest authorised
Agent computes actual amount to for a
be presented to the Cardholder on se reduced
orisationResp
AcceptorAuth amount
onse
Cardholder accepts orisationResp
the reduced AcceptorAuth
authorised amount AcceptorComple
tionAdvice
Agent acknowledges acceptance of the
partial authorised amount by the
Cardholder
Response
pletionAdvice DCC Provider
AcceptorCom
Next steps follow the normal

transaction flow
AcceptorCurrenc
yConversionAd
vice
AdviceR espons
ncyConversion e
AcceptorCurre
2883 Figure 76: Transaction eligible for DCC and partially approved by the Issuer

2884 6.7.3.3 Transaction not eligible for DCC by DCC service provider
2885 In this scenario, the transaction is considered eligible for DCC by the Agent but not by the
2886 DCC service provider. The cardholder is not offered the DCC service and the transaction
2887 proceeds as a normal card payment transaction in the currency of the merchant.
2889 Agent with the following information:
2895 2. The Agent detects that the transaction is eligible for DCC and forwards the
2896 AcceptorCurrencyConversionRequest message to the DCC service provider with
2897 the following information:
2901  TransactionType : copy from AcceptorCurrencyConversionRequest
2902 message

2905  Result : InvalidCard, NoRate, InvalidMerchant, NotAvailablen or
2906 InvalidProduct
2907  ConversionDetails: absent

2909 Acceptor to inform him that DCC was not possible with the following information:
2911 InvalidProduct
2912  Conversiondetails : absent
2913 4. The Acceptor sends an AcceptorAuthorisationRequest message to the Acquirer

2914 with the following information:
2915  TransactionType : copy of the original AcceptorCurrencyConversionRequest
2916 message
2917  TransactionDetails.Currency : copy of Conversion.TargetCurrency of the
2919  TransactionDetail.TotalAmount : copy of the Conversion.ResultingAmount
2920 of the AcceptorCurrencyConversionResponse message
2921  AdditionalService : copy of the original
2922 AcceptorCurrencyConversionRequest message plus DCC
2924  OriginalTransaction: Link to the original
2925 AcceptorCurrencyConversionRequest message

2927 the Acceptor’s currency
2929 capture, etc.)

AcceptorCurrenc
yConversionRe
que st
Transaction AcceptorCu
rrencyConv
eligible for DCC ersionReques Transaction
t
conversion not eligible
for DCC
Response
AcceptorCurre
sionRespon se
rencyConver
AcceptorCur
Acquirer
AcceptorAuthori
sationRe quest
Transaction
AcceptorAuthori
sationRe quest authorised
in the
currency of
on se the
orisationResp
Transaction AcceptorAuth Acceptor
successfully onse
orisationResp
authorised in the AcceptorAuth
currency of the
Acceptor DCC Provider
AcceptorCur
rencyConver Confirmation
sionAdvice
to DCC
Provider of
non-currency
Response
AcceptorCurre
2930 Figure 77: Transaction not eligible for DCC by DCC service

2931 6.7.3.4 Transaction not eligible for DCC by the Agent

2932 In this scenario, the transaction is not considered eligible for DCC by the Agent. The
2935 1. The acceptor sends the AcceptorCurrencyConversionRequest message to the
2941  TransactionDetails.TotalAmount: Total Amount in the Acceptor’s currency
2942 2. The Agent detects that the card is not eligible for DCC (the Acceptor doesn’t have
2943 a contract with a DCC service provider or the line to the DCC Provider is not
2944 operational).
2945 3. The Agent send an AcceptorCurrencyConversionResponse message to the
2946 Acceptor to inform that DCC is not possible with the following information:
2948 InvalidProduct
2949  ConversionDetails: absent
2950 4. The Acceptor sends an AcceptorAuthorisationRequest message in the currency of

2951 the Acceptor with the following information:
2953 message
2954  TransactionDetails.Currency : copy of the original
2956  TransactionDetail.TotalAmount : copy of the original
2958  AdditionalService : copy of original AcceptorCurrencyConversionRequest
2960  CurrencyConversionResult : absent
2961  OriginalTransaction: Link to AcceptorCurrencyConversionRequest message.

2965 Acceptor.
2966 7. Next steps follow the normal transaction flow (i.e. Completion capture, batch

AcceptorCurr
encyConversio
nRequest
transaction is
not eligible or
line to DCC
Provider is not
operational
onse
rsionResp
DCC not rC ur re ncyConve
Accep to Acquirer
proposed to the AcceptorAuth
Cardholder orisationReque
st
AcceptorAuth
orisationReque Transaction
st
authorised
in the
currency of
thorisatio nResponse the
Transaction AcceptorAu Acceptor
successfully
thorisatio nResponse
the currency of
the Acceptor
2968 Figure 78: Transaction not eligible for DCC by the Agent

2969 6.7.3.5 Transaction eligible for DCC but DCC refused by the Cardholder
2970 In this scenario, the transaction is considered eligible for DCC by both the Agent and the
2971 DCC service provider. The cardholder refused the DCC service for the amount presented
2972 to him in the currency of his card. The transaction proceeds as a normal card payment
2973 transaction in the currency of the merchant.

2980  TransactionDetails.TotalAmount: Total Amount in Acceptor’s currency
2981 2. The Agent forwards the AcceptorCurrencyConversionRequest message to the DCC

2982 service provider with the following information:
2985  TransactionCapture : not relevant
2987 message

2990  Result of the currency conversion : Allowed
2991  ConversionDetails: Present
2992 4. The Agent sends back an AcceptorCurrencyConversionResponse message to the
2993 Acceptor with the proposed currency conversion data.
2994 5. The cardholder refuses the DCC service.
2995 6. The Acceptor sends an AcceptorAuthorisationRequest message to the Agent in the
2996 currency of the Acceptor and with the following information:
2997  TransactionType : copy of original AcceptorCurrencyConversionRequest
2998 message
2999  TransactionDetails.Currency : copy of the original
3001  TransactionDetail.TotalAmount : copy of the original
3003  AdditionalService : copy original AcceptorCurrencyConversionRequest
3004 message plus DCC information.
3005  CurrencyConversionResult.AcceptedByCardholder : False
3006  CurrencyConversionResult.ConversionDetails: copy of original
3007 AcceptorCurrencyConversionResponse message.

3009 Acceptor’s currency.
3010 8. The Acquirer send back an AcceptorAuthorisationResponse message to the
3011 Acceptor.

3015 AcceptorCurrencyConversionAdvice that the DCC transaction was refused by the
3016 Cardholder.
3019 transaction on his side
transaction
AcceptorCurr
encyConv ersionRequest eligible to DCC
AcceptorCurr
encyConversio
nR equest
transaction
eligible to
e
encyConv ersionRespons DCC
AcceptorCurr
ponse
versionRes
eptorC urrencyCon
Acc
Cardholder refuses AcceptorAuth
orisationReque Acquirer
DCC st
AcceptorAuth Transaction
orisationReque
st authorised
in the
esponse currency of
thorisationR
AcceptorAu the
es ponse Acceptor
thorisationR
Transaction AcceptorAu
successfully DCC Provider
authorised in Next steps follow the normal Next steps follow the normal
the currency of transaction flow transaction flow DCC
the Acceptor Provider
AcceptorCurr informed
encyConversio
nA dvice
DCC
refused by
nAdviceRe Cardholder
encyConversio
AcceptorCurr sponse
3020 Figure 79: Transaction eligible for DCC but DCC refused by the Cardholder

3021 6.7.3.6 Transaction eligible for DCC but interrupted due to an incident
3022 6.7.3.6.1 Incident at the Agent level

3023 In this scenario, the transaction is considered eligible for DCC by the Agent the response
3024 of the Agent didn’t reach the Acceptor or an error was encountered in the response. The
3026 payment transaction in the currency of the merchant. A negative advice is forwarded to
3027 the DCC service provider at the end of the transaction.
3035 2. The AcceptorCurrencyConversionResponse is not received by the Acceptor due to

3036 an incident.
3041 message


AcceptorCurr
encyConversion
Request
AcceptorC
Response of urrencyCo
Agent not nversionRe
received or sponse
corrupted
Acquirer
AcceptorAuth
orisationRequ
est
AcceptorAuth
orisationReque
st
Transaction
carried out in
Transaction
currency of the
successfully
Acceptor Response
authorised in risation
AcceptorAutho
the currency of
sponse
the Acceptor thorisationRe
AcceptorAu
3055 Figure 80: Incident at the Agent level

3056 6.7.3.6.2 Incident at DCC service provider level

3058 service provider but the response sent by the DCC provider didn’t reach the Agent or an
3059 error was encountered in the response. The cardholder is not offered the DCC service and
3060 the transaction proceeds as a normal card payment transaction in the currency of the
3061 merchant. A negative advice is forwarded to the DCC service provider at the end of the
3062 transaction.
3070 8. The Agent detects that the transaction is eligible for DCC and forwards the
3071 AcceptorCurrencyConversionRequest message to the DCC service provider with
3072 the following information:
3077 message

3079 message.
3080 10. The AcceptorCurrencyConversionResponse is not received by the Agent due to an
3081 incident.
3082 11. The Agent send an AcceptorCurrencyConversionResponse message to the
3083 Acceptor to inform him that DCC was not possible with the following information:
3085 InvalidProduct
3086  Conversiondetails : absent
3091 message

3106 AcceptorCurrencyConversionAdvice message that the DCC transaction did not
3107 succeed.
3111
Card
AcceptorCurrenc eligible for
yConversionRequ DCC
est
AcceptorCu
rrencyConve
rsionRequest
AcceptorC
Response of DCC urrencyCo
service provider nversionRe
nse not received or sponse
ncyCo nversionRespo corrupted
Transaction AcceptorCurre
Acquirer
proceeds in the
currency of the AcceptorAuthori
Acceptor sationRequest Transaction
AcceptorAuthori authorised in
sationRequest
the currency
Transaction carried out
of the
in currency of the
nse Acceptor
Acceptor risationRespo
AcceptorAutho
Transaction nse
risationRespo
successfully Ac ceptorAutho
DCC Provider
authorised in
the currency of Next steps follow the normal Next steps follow the normal DCC
the Acceptor transaction flow transaction flow Provider
AcceptorCu informed
rrencyConve that
rsionAdvice
currency
conversion
spons
ionAdviceRe
encyConvers e not
AcceptorCurr
provided
3112 Figure 81: Incident at DCC service provider level

3113 6.7.4 Reconciliation Totals
3114 The following elements shall be used to compute reconciliation totals:
3115 a. TransactionDetails.TotalAmount
3116 b. TransactionDetails.Currency
3117 The Totals should be computed by Currency if the parameter TotalsPerCurrency in the
3118 AcceptorComfigurationUpdate is set to True
3119 6.8 Aggregation
3120 The Aggregation service allows the acceptor to aggregate transactions when its business activity
3121 lends it to the accumulation of multiple purchases.
3122 A single payment transaction is presented for remittance to group a customer’s activity over a defined
3123 period.
3124 An aggregated transaction must obey the following rule :

3125 1. An AdditionalService must be present with a value set to Aggregation in completion
3126 messages.
3127 Depending on the application requirements the AggregationTransaction component should be present
3128 to describe the aggregated transaction and/or the detail of all the payments.
6 Additional Payment Services - 298 - 6.8 Aggregation

3129 6.9 Externally defined Data
3130 6.9.1 Scope

3131 The Acquirer Protocol aims to meet the needs of key actors of the card payment industry (merchants,
3132 banks, card schemes, manufacturers, card payment processors, software providers, solutions
3133 providers).
3134 Some of these actors need to exchange data elements which are not directly linked to the payments
3135 process through the Acquirer Protocol messages. Furthermore these data elements are often defined
3136 by others actors and their specifications are not under Acquirer Protocol governance. This data may
3137 be corporate or private data.
3138 In order to carry such data elements the nexo Acquirer Protocol provides a message type
3139 IndustryData1 to convey these data elements
3140 6.9.2 Guidance on how to use ExternallyDefinedData
3141 Note : in next version AdditionalInformation type will be renamed ExternallyDefinedDate
3142 The envelope structure is described below

<PrtctdVal>
3143 6.9.2.1 Private Data

3144 Private data can be used by agreement between a limited number of parties.
3145 Rules:
3146  The Private Data is conveyed in the AdditionalInformation of the TransactionDetails
3147  The Identification data element is defined by the parties and is only significant for these
3148 parties. So this Private Data is not interoperable.
3149  The Type data element must be present and set to “Private Data”
3150  Either Value or ProtectedValue must be present and contain the private data exchanged by
3151 the parties
3152  The structure of the exchanged data is outside the scope of the Nexo Acquirer Protocol
3153 6.9.2.2 CardPaymentInvoice

3154 Card Payment Invoice is a feature that aims to support the corporate card payment. Since this data is
3155 not under the responsability of the nexo Acquirer Protocol, it will be conveyed as an
3156 ExternallyDefinedData.
6 Additional Payment Services - 299 - 6.9 Externally defined Data

3157 Rules:
3158  The Card Payment Invoice is conveyed in the AdditionalInformation of the TransactionDetails
3159  Since the card payment invoice must be interoperable, the Identification data element is
3160 defined by the nexo Acquirer Protocol MUG and must be set to “nexo Card Payment Invoice
3161 V1.0”.
3162  The Type data element must be present and must be set to a value defined in the following
3163 values :
3164 o “Nexo payment invoice”
3165 o Others values will be added when required
3166  Either Value or ProtectedValue must be present and contain the card payment invoice
3167 exchanged by the parties
3168  The structure of the exchanged data is defined in :
3169 o The Annex V8 for Type = “Nexo payment invoice”
3170 o Other references will be addes for other Type values
6 Additional Payment Services - 300 - 6.9 Externally defined Data

3171 7 Messages Examples

3172 The examples are now provided in new document. See “Card Payment Message Example version
3173 8.0“.
7 Messages Examples - 301 - 7 Messages Examples

3174 8 Transport Protocols and Services
3175 8.1 Protocols Organisation

3176 Protocol implementation shall follow the general principle of robustness: be strict in what you do, be
3177 tolerant in what you accept from others.
3178 The Acquirer Protocols follows the traditional organisation in five layers of the model defined for the
3179 TCP/IP protocol suite.
3180 The two layers we are interested in are the Application Layer where the Acquirer protocol is located,
3181 and the Transport Layer that the Application protocols interface with the Transport Services.

Application Application Protocol Application
Layer Layer
Transport Service Transport Service
Transport Transport Protocol Transport

Layer Layer
3182 Figure 82: Protocols Organisation
3183 The Application Protocol is independent of the Transport Protocol, and can be used without
3184 modification with various Transport Protocols, except where the interface to the Transport Services
3185 needs specific information such as the transport addresses.
3186 The Transport Protocol and the Application Protocol are also independent of the communication
3187 infrastructure used below these layers, with the exception of the quality of service of the
3188 communication which may involve tuning of some values of the configuration parameters (e.g. value of
3189 timeout).
3190 The Transport Protocol is a standard protocol allowed by the Application Protocol. Application
3191 Protocol requires the Transport Services which can be used by the Application Protocol, and specifies
3192 the way to use them.
3193 If a standard Transport Protocol used by the Application Protocol does not offer a particular Transport
3194 Service required by the Application Protocol, the Application Protocol specifies this Service through a
3195 Transport Adaptation Layer. This is for instance the case for the application message delimitation,
3196 which is a service not provided by the TCP Transport Protocol, but required for the decoding of a XML
3197 message before delivering it to the Application Layer. It could be also be used to provide a particular
3198 flow control.
Application Acquirer Protocol

Layer (CAPE messages)
Transport Services
message delimitation,
flow control...
Transport AdaptationLayer
Transport
Layer
Standard Transport Layer
3199 Figure 83: Transport Adaptation Layer
8 Transport Protocols and Services - 302 - 8.1 Protocols Organisation

3200 As far as transport services and their usage are defined, the definition in future of a new Transport
3201 Protocol compliant to the defined Transport Service, will not impact the specifications of the
3202 Application Protocol.
3203 For the current specification the only selected transport protocol is TCP (Transmission Control
3204 Protocol, specified in the RFC 793).
3205 8.2 TCP Protocol
3206 8.2.1 Typical Use

3207 Because of its widespread availability, the TCP transport protocol remains the favourite transport
3208 protocol. It can be used as:
3209 1. An end-to-end transport protocol between two entities at each extremity of the Application
3210 Protocol.
3211 Figure 84: Peer-to-peer TCP Transport Protocol

3212 2. An interface to a gateway or a driver to make the conversion of transport protocol with the
3213 other side of the Application Protocol. This case is only a transitory solution allowing the
3214 adaptation a legacy system to the Application Protocol, avoiding the specification of all the
3215 existing communication protocols.
. .
3216 Figure 85: Gateway TCP Transport Protocol
3217 8.2.2 Message Delimitation

3218 The TCP protocol is a stream protocol which does not offer message delimitation or data-unit
3219 delimiting. It uses the general mechanism of message delimitation provided for all the transport
3220 protocols.
8 Transport Protocols and Services - 303 - 8.2 TCP Protocol

3221 8.2.3 Addressing

3222 A transport address for the TCP protocol is composed of:
3223 1. The IP Address or the DNS Name to resolve of the host on which the application protocol
3224 lives.
3225 2. The TCP Port, to dispatch the connections to the application.
3226 8.3 Transport Services
3227 8.3.1 Message Delimitation
3228 8.3.1.1 Definition

3229 Message delimitation provides the recognition of the application data (i.e. application message).
3230 8.3.1.2 Specifications

3231 Application messages are prefixed by four bytes containing the length, in network order 12, of the
3232 application message. This length value does not include the the length of this prefix.
length
CAPE message
3233 Figure 86: Header Length

3234 If the four bytes are equal to zero, it is considered as a zero length application message, and these
3235 four bytes are ignored.
3236 8.3.1.3 Typical Example of Implementation

3237 For sending a message:
3238  The Application Protocol layer requests to send an application message to the interface of the
3239 transport protocol,
3240  This interface, or transport adaptation layer, adds the length prefix described above and
3241 passes the new message to the transport protocol.
3242 For the receipt of a message, the interface to the transport protocol:
3243  Waits for the receipt of four bytes to get the length L of the message to receive, and arms the
3244 timeout TC4 to monitor the receipt of the complete application message.
3245  Waits for the receipt of L bytes to provide a message to the Application Protocol layer,
3246  On the receipt of the last data unit of this message, stop the TC4 timer, and deliver to the
3247 application layer, the L bytes, content of message.
3248 Timer management is specified in section Connection and Data Management State Diagrams, which
3249 contains message sending and message receiving management.
17 12 Most significant byte first (i.e.; big endian).
8 Transport Protocols and Services - 304 - 8.3 Transport Services

3250 8.3.1.4 Notes

3251 Use of message delimitation at the transport level:
3252  Restricts message delimitation to the transport layer interface avoids partial progressive
3253 decoding of the message mixed with receipt of message fragments,
3254  Separates decoding of the message from its receipt processing.
3255  Independence of this service from the data coding used by the application, if the data coding
3256 can provide this functionality (e.g. ASN.1/BER data coding).
3257 Use of the message length to delimit a message has the advantage of being able to send any value in
3258 the application message, but prohibits resynchronisation of message after a data loss.
3259 Use of a fixed number of bytes to contain the length of the message facilitates implementation of
3260 message receipt.
3261 8.3.2 Connection and Data Transfer Management
3262 8.3.2.1 Connection Services

3263 Application protocols use the transport connection services which are organised in three phases:
3264  The Connection Establishment, to establish an association between the Initiating Party and
3265 the Recipient Party,
3266  The Transport of Data Units or Data Transfer, to exchange application messages within an
3267 already established connection, and
3268  The Connection Release service to release a connection established beforehand.
Initiator Party Recipient Party
Connection
Establishment
Data
Transfer
Connection
Release
3269 Figure 87: Connection Services
3270 These services are usually done by transport primitives’ services through various implementations:
3271  Connection Request: to send an outgoing request in order to establish a transport connection
3272 (done by the Initiating Party).
3273  Connection Indication: for the receipt an incoming request from the Initiating Party to establish
3274 a transport connection (done by the Recipient Party).
3275  Connection Response: to send the positive or negative response to the incoming request for
3276 the transport connection establishment (done by the Recipient Party).
3277  Connection Confirmation: for the receipt an incoming response from the Recipient Party to the
3278 previous outgoing request for the transport connection establishment (done by the Initiating
3279 Party).
3280  Data Request: to send an outgoing request containing data to deliver to the other peer of a
3281 transport connection (done by the Initiating Party or the Recipient Party).
3282  Data Acknowledgment: for the receipt an incoming request informing the sender of a Data
3283 Request that the transport layer has sent the related data (done by the Initiating Party or the
3284 Recipient Party).
3285  Data Indication: for the receipt an incoming request containing data delivered by the other
3286 peer of a transport connection (done by the Initiating Party or the Recipient Party).

3287  Disconnection Request: to send an outgoing request in order to release a transport connection
3288 (done by the Initiating Party or the Recipient Party).
3289  Disconnection Indication: for the receipt an incoming request to release a transport connection
3290 (done by the Initiating Party or the Recipient Party).

Application Trp Layer Adapt. Trp Layer Adapt. Application
connection
request connect req
connection
indication
connection
connect conf response
connection
confirmation
data reques
t
data
data data
ent indication
acknowledgm
data request
data
data data
indication acknowledg
ment
disconnectio
n disc req
request disconnectio
n
indication
Transport Data Units

Transport Primitives (TPDU) Transport Primitives
3291 Figure 88: Transport Connection Management Service Primitives
3292 8.3.2.2 Data Transfer

3293 The real time or interactive exchanges of the Application Protocol are exclusively dialogues of the type
3294 question/answer, involving the related transport primitives:
3295  The question is a request message sent by the Initiating Party of the message pair to the
3296 Recipient Party of the message pair.
3297  The answer is a response message sent by the Recipient Party of the message pair to the
3298 Initiating Party of the message pair.
service request Message Reques

t
processing of
the service
se
Message Respon
service result
3299 Figure 89: Application Protocol Message Flow

3300 This message sequence is used to request a service to the Recipient Party, the response message is
3301 sent to the Initiating Party with the result of the processing. In some case, the request message

3302 notifies a particular event to the Recipient Party, the response message is then an acknowledgement
3303 sent to the Initiating Party.
3304 A pair of request and response messages is identified unambiguously. If a request message is
3305 repeated with the same identifier, (e.g. in case of error, or if the response message have not been
3306 received), depending on the application protocol specification, it may be refused by the Recipient Party
3307 or generate the same response message.
3308 8.3.3 Single Message Pair Exchange

3310 Each pair of application messages is enclosed in a unique transport connection that is established for
3311 that purpose by the Initiating Party.

3313 The sequence flow of a message pair exchange inside a transport connection contains the steps
3314 presented below.
3315 1. The Initiating Party sends a transport connection request to the Recipient Party. The Initiating
3316 Party arms the timeout TC1 to wait for the transport connection response from the Recipient
3317 Party.
3318 2. The Recipient Party receives the transport connection request, accepts it and sends a
3319 transport connection confirmation. At this time the transport connection is established for the
3320 Recipient Party. The Recipient Party arms the timeout TC2 to wait for the application message
3321 request from the Initiating Party.
3322 3. After receipt of the connection confirmation, the transport connection is established for the
3323 Initiating Party, it sends the application message request.
3324 4. The Recipient Party processes the requested service and sends the result within the
3325 application message response to the Initiating Party. The Recipient Party arms the timeout
3326 TC2 to wait for the receipt of a disconnection request from the Initiating Party after it has
3327 received the application message response.
3328 5. The Initiating Party receives the application message response and sends a transport
3329 disconnection request.
3330 6. The Recipient Party receives the transport disconnection request and sends a transport
3331 disconnection request to the Initiating Party. The transport connection is then considered as
3332 released for the Initiating Party which has not to wait for the response of the Recipient Party.
Connection reques
1 t
TC1:
Connection Accept connection
response Connection resp 2
TC2:
Message
request
Message request
3
Application
time-out Processing
Message response 4
TC2:
Disconnection
request
Disconnection reques
5 t
t Accept disconnection
Disconnection reques 6
3333 Figure 90: Single Message Pair Exchange Sequence Flow

1 connection connect req

request connection
TC1: indication Accept connection
Connection 2
response connect conf connection
connection response TC2:
confirmation Message
request
3 data
data data
request (Message Request) indication
data
t Processing
Application
time-out
acknowledgmen
data data 4
data request
(Message Response)
indication
data TC2:
acknowledg
ment Disconnection
request
disconnection disc req
5 disconnection
request
indication
Accept disconnection
disc req disconnection 6
confirmation
3334 Figure 91: Single Message Pair Exchange Transport Primitives Sequence Flow
3335 8.3.3.3 Notes

3336 Each peer of the transport connection has to activate timeout to avoid loss of resources in case of
3337 event not received by one peer. These timeout control the management of the transport connection,
3338 establishment, release, sending and receipt of data.
3339 The application has to manage its own timeout to supervise the processing of the service by the
3340 Recipient Party. This is not the role of the transport service to specify the behaviour of the application
3341 layer, but on the other hand the application layer might send disconnection request for this reason or
3342 others to release the transport connection at any time.
3343 A best practice for the connection release is that the receiver of the last message has the
3344 responsibility to release the connection.
3345 The value of the timeout TC2 has to be large enough to take into account the management of
3346 connections by the Initiating Party. Its purpose is rather to avoid a forgotten transport connection that
3347 remains open forever.

3348 8.3.4 Multiple Message Pair Exchange

3350 Multiple Message Pair Exchange in the same connection is the option to keep a transport connection
3351 open (or alive) in order to send the next application message pair on the same transport connection.
3352 It allows the exchange of a sequence of message pairs on the same connection, avoiding the
3353 overhead of the connection establishment.

3355 Sequence flow of a message pair exchange inside a transport connection contains the steps below.
3356 1. The Initiating Party and the Recipient Party establish the transport connection. The Initiating
3357 Party sends the application message request number 1.
3358 2. When the Initiating Party receives the application message response number 1, it arms the
3359 timeout TC3 to wait for another message request to send from the application layer.
3360 3. The Initiating Party sends the application message request number 2 before the expiration of
3361 the timeout TC3.
3362 4. The Initiating Party receives the application message response number 2 and arms again the
3363 timeout TC3 to wait for the message response from the Recipient Party.
3364 5. In the absence of new application message to send, the TC3 timer timed out. The Requester
3365 sends then the transport disconnection request to release the connection because of
3366 inactivity.
Connection reques
1 t
Connection resp
Message request
1
Processing request 1
2 Message response
1
TC3:
Inactivity
Message request
3 2
Processing request 2
Arms inactivity TC3 4 Message response
2
no activity
on the connection
TC3 has timed out Disconnection reques

5 t
t
Disconnection reques
3367 Figure 92: Multiple Message Pair Exchange Sequence Flow

1 connection connect req

request connection
indication
connect conf connection

connection response
confirmation
data
data data
request
(Message Request 1) indication
data
t Processing request 1
acknowledgmen
data data
data request
2 (Message Response 1)
Arms inactivity TC3 indication
data
acknowledgmen
t
3 data
Desarms inactivity TC3 data data
request
(Message Request 2) indication
data
t Processing request 2
acknowledgmen
data data
data request
Arms inactivity TC3 4 (Message Response 2)
indication
data
no activity acknowledgmen
on the connection
t
TC3 has timed out disconnection

5 disc req disconnection
request
indication
disc req disconnection

confirmation
3368 Figure 93: Multiple Message Pair Exchange Transport Primitives Sequence Flow
3369 8.3.4.3 Notes

3370 The transport is based upon a connectionless network protocol like IP that does not reserve any
3371 resource on the network except at the of extremities of the transport connection. In this case the
3372 overhead of a connection establishment is the exchange of two packets, and the resource
3373 consumption of an established connection context entry in the protocol stack.
3374 This mechanism has several advantages to manage significant volume of messages:
3375  To avoid the use of a header carrying application-only information, and provide a better
3376 separation between transport and application layers.
3377  The simplicity of the message management by the transport service layer and the application
3378 layer, for the Initiating Party and the Recipient Party.
3379  To be able to verify of the response on both transport layer (the transport connection) and
3380 application layer (application data in the header of the message), with a clear separation
3381 between these two layers.
3382  The adaptability of the communication resources to the traffic of messages.
3383  The ability to isolate the processing and resolution of problems in the various message pairs.

3384 8.3.5 Addressing

3386 A peer (Recipient and Initiating Parties) is identified by its transport address; it is this address which is
3387 used when connecting to a peer.
3388 The form of the transport address depends on the type of transport protocol being used (e.g. an IP
3389 address or a DNS name of the node together with a TCP port would form a TCP transport address).

Application Application Protocol Application
Layer Layer
Transport Transport
address address
Transport Service Transport Service

Transport Transport
address address
Transport Protocol
Transport Layer Transport Layer
3390 Figure 94: Transport Address

3392 The transport address of the Recipient Party is a parameter used at the application level by the
3393 Initiating Party as a destination address to establish a connection.
3394 Application protocol may define assignment of the Recipient Party’s transport address at any level:
3395 globally for the whole application protocol, per class of message, or per service.
3396 8.3.6 Flow Control

3398 Flow control is the service which allows the control of the flow of data between the application layer
3399 and the transport layer, or between the Initiating Party and the Recipient Party.

3401 Flow control of the transport protocol may be not available in the transport service. The Application
3402 and Transport layers have to put in place a data acknowledgment mechanism to avoid resource
3403 saturation of a layer in the event that a large volume of data is to be sent to the other peer.
3404 Application protocols have to design a flow control between the Initiating Party and the Recipient
3405 Party. This flow control is completely transparent to the transport service layer.
3406 The transport service used is the Data Acknowledgment primitive, sent to the application when the
3407 transport service layer is able to take into account new data.

3408 8.3.7 Error Cases

3409 This section defines errors detected by the transport protocol and transmitted to the application layer.
3410 The responsibility and the choice of error resolution are left to the application layer, unless the
3411 transport service layer needs to perform some action to continue to work.
3412 The Application Layer Protocols must define the actions to be taken in the event of these errors as the
3413 actions will vary according to the message exchange (eg actions in the event of Authorisation failure
3414 are different to those to be taken when performing a Completion exchange).
3415 The errors are generic; the transport layer is not always able to report a specific reason for the errors.
3416 8.3.7.1 Unable to Establish a Transport Connection (ERTR01)
3417 Definition
3418 The transport layer is unable to establish the transport connection that the application layer has
3419 requested to open, because:
3420  The lower protocol layer has notified an “out of service” communication state as permanent or
3421 in response to the attempt to open the connection.
3422  The TC1 timer has expired, and the connection in progress is considered as broken (the
3423 connection establishment as a failure).
3424  The Recipient Party has denied the connection request.
3425  The transport layer has reached the maximum number of concurrent connections it can
3426 manage.
3427 Transport Service Behaviour

3428 The transport service layer considers the establishment of the transport connection as a failure, and
3429 notifies the result to the application layer.
3430 8.3.7.2 Transport Connection Broken (ERTR02)
3431 Definition
3432 The transport layer realises that an open connection is broken. Several reasons may cause this error:
3433  The transport layer receives an unexpected disconnection request.
3434  An error occurred at a lower level while the transport layer waits for the end of a message
3435 after the receipt of the length prefix and incomplete data units.
3436  The lower level notifies the transport layer that a defect occurs (e.g. on the physical interface),
3437 and the transport connection is broken.
3438  The remote peer has not respected the state diagram of the connection management. The
3439 Initiating Party has sent data after sending the message request but before the Recipient
3440 Party has finished sending the message response. The Recipient Party sends data before the
3441 Initiating Party has finished sending the message request.
3442  The remote peer has released the transport connection.
3443  A connection deemed to be inactive when TC2 expires. The connection seems to be forgotten
3444 by the Initiating Party, and the Recipient Party closes the transport connection at the
3445 expiration of the TC2.

3447 The transport service layer notifies the closing of the transport connection to the application layer.
3448 Partial messages are deleted and not sent to the application layer.

3449 8.3.7.3 Unable to Send a Message (ERTR03)
3450 Definition
3451 The transport layer cannot send an application message. Several reasons may cause this error:
3452  An error occurred at a lower level when the transport layer sends an application message at
3453 the request of the application layer.
3454  The connection was broken just before the sending of the message, and the application layer
3455 did not receive the disconnection notification before the request to the transport layer to send
3456 a message.
3457  The remote peer is not ready to receive data. The Recipient Party has not yet received the
3458 message request. The Initiating Party has not received the connection confirmation or has not
3459 yet received the message response.

3461 The transport service layer notifies the error to the application layer.
3462 Note that the transport service layer is not always able to report error to the application layer. In
3463 particular when a connection is broken, the transport service has removed the connection context, and
3464 might have some difficulty to identify the context of the error.
3465 8.3.7.4 Message Too Big (ERTR04)
3466 Definition
3467 The transport layer cannot receive an application message, because the prefix contains a message
3468 length above the limit of the transport layer memory.

3470 The transport service layer has an internal parameter containing the size limit of a message, or a
3471 global limit for the set of message buffers. When the limit is reached, the transport layer:
3472  Releases the connection on which the message has to be received.
3473  Notifies the error to the application layer.
3474 As the transport layer cannot receive the message, it has to release the transport connection. Most of
3475 the time error of this class happens when there is a desynchronisation of message delimitation
3476 between the two peers.

3477 8.3.7.5 Late Arrival (ERTR05)
3478 Definition
3479 The transport service layer receives a data unit for the application after a timeout has expired and
3480 before the request for a disconnection.
3481 The application layer must also handle this error.
3482 The drawing below shows such error example, when the application timeout on the message response
3483 expires.
Arms application data

timer data data
request
(Message Request) indication
-
data acknow
ledgement Processing request 1
data data
sponse) request
Application timer (Messag e Re
expires data acknow
-
ledgement
disc req
disconnectio
n
indication
n
disc req disconnectio
confirmation
3484 Figure 95: Late Arrival Error Example

3486 The transport service layer ignores the message or data units .
3487 The transport layer may have removed the connection context, and may not be able to identify the
3488 context of the error. In addition, the application layer will have already started the error handling and
3489 cannot process the late response.
3490 The implementation of the Transport Protocol has to ensure that any data unit is not assigned to the
3491 wrong connection.
3492 8.3.7.6 Max Number of Connections (ERTR06)
3493 Definition
3494 If, on the arrival of an incoming connection request,the transport service layer cannot open a new
3495 transport connection this error will be returned to the Application Layer. This could occur, for example,
3496 when the Application or Transport Layer has reached the maximum number of concurrent transport
3497 connections it can handle.

3499 The behaviour is implementation dependant. For instance, the transport service layer may have an
3500 internal parameter containing the limit number of open connections. When the limit is reached, the
3501 transport layer must :
3502  decline the incoming connection request,
3503  notify the error to the application layer.

3504 8.3.7.7 Incomplete Application Message (ERTR07)
3505 Definition
3506 After the receipt of an application message header, the transport layer arms the timeout TC4 to
3507 monitor the receipt of the complete application message.
3508 This error will be triggered if the TC4 timer expires before the end of the application message is
3509 received, and might happen:
3510  When a serious error occurs on a lower communication level or on the communication
3511 infrastructure between the 2 peers.
3512  The remote transport or application layer encounters a serious error, or is out of order.

3514 The transport service layer must carry out the following actions:
3515 1. discard the incomplete application message,
3516 2. close the transport connection to avoid further problems of data synchronisation (the next data
3517 unit may be the start of the next application message, or part of the previous application
3518 message),
3519 3. notify the error to the application layer.
3520 8.3.7.8 Other Errors

3521 All other errors are detected or resolved at the application layer, as:
3522  Non-understandable message: all decoding of message are made by the application layer, so
3523 this error is detected and resolved at the application layer.
3524  Busy situation: when the application layer has not enough resources to process all the
3525 messages received, it can answer that it is busy at the application level to the other peer.

3526 8.3.8 Transport Service Parameters
3527 This section summarises the set of configuration parameters required by the transport service
3528 management. These parameters are configurable and may be downloaded using the EPAS TMS
3529 protocol or another proprietary means. These values depends first upon the communication
3530 infrastructure.
Name TC1
Definition Transport connection establishment timer
Owner Initiating Party of a transport connection establishment
Usage After the sending of a transport connection request, the Initiating Party arms the TC1 timer to wait
for the response from the Recipient Party. TC1 is reset on the transport connection confirmation
being received..
Specification 8.3.3 Single Message Pair Exchange
Name TC2
Definition Transport connection idle timer
Owner Recipient Party of a transport connection
Usage Keeping open transport connections which are not being used by the Initiating Party.
After the receipt of a message request or sending of a message response, the Recipient Party arms
the TC2 timer to wait for the use of this transport connection. TC2 must be disarmed when a new
message is sent across this connection.
This timer has to be long enough to not interfere with the TC3 timer
Specification 8.3.3 Single Message Pair Exchange
Name TC3
Definition Transport connection activity timer
Owner Initiating Party on a transport connection
Usage This timer is armed by the Initiating Party before the release of a transport connection, to wait for a
new message request to send. It is armed when a response message is received and disarmed
when a new request is sent. Expiry of the timer triggers a request to close the idle connection.
It avoids the management of permanent transport connections between remote peers, the
multiplexing of message exchanges, and the re-connection for every message exchange.
Specification
Name TC4
Definition Application message receipt timer
Owner Initiating Party or Recipient Party on a transport connection
Usage This timer is armed by the Initiating Party or Recipient Party at the receipt of the application
message prefix to supervise the receipt of the complete application message. It is armed at the
receipt of a message header and disarmed when the message is complete.
It allows the detection of an incomplete application message.
Specification 8.3.7.7 Incomplete Application Message

Name Recipient Party Address

Definition Transport address of the Recipient Party
Owner Initiating Party of a transport connection
Usage This (or these) transport address is used by the Initiating Party to establish a transport connection
with the Recipient Party.
Specification 8.3.5 Addressing
3531 8.3.9 Connection and Data Management State Diagrams

3532 This section presents the state diagrams of the transport connection management on both Initiating
3533 Party and Recipient Party side.
3534 These state diagrams are valid for both Single and Multiple messages pair exchanges.
3535 The transitions between states have the syntax: Event [Condition to Activate]/Action
3536 8.3.9.1 Recipient Party Diagram
3537 States
3538 The Recipient Party may have the following states:
3539  Await Request: The Recipient Party has received a connection request, and sent the
3540 connection confirmation. The connection is established. No message pair exchange is in
3541 progress. The Recipient Party waits for the beginning of a message request, or a disconnect
3542 request.
3543  Receiving: The Recipient Party has received the beginning of a message request, which is not
3544 complete yet.
3545  Responding: The Recipient Party has received a complete message request. The transport
3546 adaptation layer waits for application layer to send the message response.
3547 Events
3548 The Recipient Party may receive the following events:
3549  CON_IND: The Recipient Party receives a connection indication from the network.
3550  DATA_IND: The Recipient Party receives data.
3551  DATA_REQ: The Recipient Party application layer wants to send data.
3552  TC2, TC4: The timer TC2 (respectively TC4) has expired.
3553  Error: There is an error situation, such as receiving a disconnection request from the network
3554 or the application layer, a message that is too big, or other errors.

3555 Diagram
CON_IND / DATA_IND [complete msg] /
Await
CON_RES, start TC2 DATA_IND, restart TC2 Responding
Request DATA_REQ /
DATA_REQ, restart TC2
TC2, DATA_IND DATA_IND,
Error / [uncomplete msg] TC2,
DISC_REQ / stop TC2, DATA_IND Error /
start TC4 [uncomplete msg] DATA_IND DISC_REQ
[complete msg]
/ DATA_IND,
start TC2
Receiving
TC4,
Error /
DISC_REQ
3556 Figure 96: Recipient Party Connection Management State Diagram
3557 8.3.9.2 Initiating Party Diagram
3558 States
3559 The Initiating Party may have the following states:
3560  Connecting: The Initiating Party has sent a connection request, and waits the positive or
3561 negative answer to that request.
3562  Connected: The Initiating Party has received a connection confirmation, positive response,
3563 and the transport connection is established. No message pair exchange is in progress. The
3564 transport adaptation layer waits for application layer to send a message request.
3565  Await Response: The Initiating Party has sent the message request, and has not received any
3566 part of the response message.
3567  Receiving: The Initiating Party has sent the message request, and has received the beginning
3568 of the response message which is not complete yet.
3569 Events
3570 The Initiating Party may receive the following events:
3571  CON_REQ: The Initiating Party application layer wants to send a connection request.
3572  CON_CNF: The Initiating Party receives a connection confirmation.
3573  DATA_REQ: The Initiating Party application layer wants to send data.
3574  DATA_IND: The Initiating Party receives data.
3575  TC1, TC4: The timer TC1 (resp. TC4) has expired.
3576  Error: There is an error situation, such as receiving a disconnection request from the network
3577 or the application layer, a message that is too big, or other errors.

3578 Diagram
CON_REQ / start TC1
DATA_REQ /
stop TC3, DATA_REQ
CON_CNF / Await
Connecting Connected
stop TC1 DATA_IND [complete msg, mult msg Response
pair] / DATA_IND, start TC3
TC1, DATA_IND, DATA_IND
TC3, Error / Error /
Error / [uncomplete msg] DISC_REQ
DISC_REQ DISC_REQ DATA_IND / start TC4
DATA_IND [uncomplete msg]
[complete msg,
mult msg pair]
/ stop TC4
DATA_IND Receiving
start TC3
DATA_IND
[complete msg, TC4,
single msg pair] Error /
/ DISC_REQ, DISC_REQ
DATA_IND
3579 Figure 97: Initiating Party Connection Management State Diagram

Cardpaymentsmessageusageguide 8.0

Uploaded by

Document Information

Original Title

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

Cardpaymentsmessageusageguide 8.0

Uploaded by

Copyright:

Available Formats

1 CAPE

2 Card Payments Acquirer

1 © 2018 nexo-standards AISBL All rights reserved.

52 2.4.4.4 Cancellation declined after timeout.............................................................................................46

102 3.4.1.3 Acquirer is Unable to Process the Message...............................................................................94

152 4.8.1 AcceptorRejection (caaa.015.001.05)..............................................................................194

200 6.6.3 Message flows................................................................................................................. 252

250 8.3.1.4 Notes........................................................................................................................................ 306

Figure 1: Authorisation with capture (successful transaction)...............................................................23

Figure 41: Rejection of an Authorisation to an Agent............................................................................84

Figure 84: Peer-to-peer TCP Transport Protocol................................................................................319

300 1.2 Intended Audience

306 1.3 Scope of the Document

310 1.4 Messages Covered in this Guide

314 It addresses the following categories of exchanges of messages:

1 Introduction - 12 - 1.4 Messages Covered in this Guide

333  Rejection message8 cover the message send by a RecipientParty to an InitiatingParty to

Message Message type and version

5 4 AcceptorCancellationRequest (caaa.005.001.08), AcceptorCancellationResponse (caaa.006.001.07),

1 Introduction - 13 - 1.4 Messages Covered in this Guide

Message Message type and version

340 1.5 How this Guide was created

345 1.6 nexo and ISO 20022

1 Introduction - 14 - 1.6 nexo and ISO 20022

364 1.7 ISO 20022 Intellectual Property Rights Policy

374 1.8 Message Transport

377 1.9 Security

380 1.10 Coding

382 1.11 Related Documents and Guides

1 Introduction - 15 - 1.11 Related Documents and Guides

396 1.12 Conventions

401 1.13 What’s new in the edition 8

402 This edition brings the following improvements:

1 Introduction - 16 - 1.13 What’s new in the edition 8

405 2 Message Exchange and Processes

406 2.1 Card Payment

407 2.1.1 Authorisation

411 The possible outcomes of an authorisation are:

416 An online authorisation exchange is made up an AcceptorAuthorisationRequest message used to

419 2.1.2 Completion

427 A completion exchange is made up an AcceptorCompletionAdvice message sent by an Acceptor to

432 An AcceptorCompletionAdvice is used for three main purposes:

2 Message Exchange and Processes - 17 - 2.1 Card Payment

439 2.1.3 Financial capture

446 A financial capture process can be done:

450 2.1.4 Batch

458 2.1.5 Dynamic Currency Conversion

2 Message Exchange and Processes - 18 - 2.1 Card Payment

473 DCC is supported by two types of exchanges:

474  Authorisation exchanges where a pair of AcceptorAuthorisationRequest and

2 Message Exchange and Processes - 19 - 2.1 Card Payment

483 2.2 Scope of Card Payments

2 Message Exchange and Processes - 20 - 2.2 Scope of Card Payments

510 2.3 Types of environments

516 2.3.1 Online only

523 2.3.1.1 Financial capture made during the authorisation exchange

524 Case of a successful transaction

532 Figure 1: Authorisation with capture (successful transaction)

2 Message Exchange and Processes - 21 - 2.3 Types of environments

533 Case of a failed transaction

534 An AcceptorAuthorisationRequest message is sent by an Acceptor to an Acquirer to request the

539 Figure 2: Authorisation with capture (failed transaction)

2 Message Exchange and Processes - 22 - 2.3 Types of environments