Cape Card Payments Terminal Management Message Usage Guide: 8.0 2nd March 2020

1
4 CAPE
5 Card Payments
6 Terminal Management
7 Message Usage Guide
8
9
10
11
12
13
14 Version 8.0
15 2nd March 2020
16
1 © 2020 nexo AISBL All rights reserved.
2 This information is protected by international intellectual property laws and its use is governed by the applicable End-User license
3
4 CAPE Terminal Management Message Usage Guide Version 8.0 – 2nd March 2020
17
18 TABLE OF CONTENTS
19
20 1 Introduction.................................................................................................................................................... 7
21 1.1 Purpose of the Document...................................................................................................................... 7
22 1.2 References............................................................................................................................................. 7
23 1.3 Terms and Definitions............................................................................................................................ 7
24 1.4 Conventions........................................................................................................................................... 8
25 1.5 What’s new in the edition 87.................................................................................................................. 8
26 1.6 Principles............................................................................................................................................... 9
27 1.6.1 Number encoding........................................................................................................................ 9
28 1.6.2 Initiating Party.............................................................................................................................. 9
29 1.6.3 DateAndTime.............................................................................................................................. 9
30 1.6.4 Encoding of Certificate................................................................................................................ 9
31 1.6.5 Encoding of Boolean value........................................................................................................ 12
32 2 Common nexo TMS message principles..................................................................................................... 13
33 2.1 CryptographicKey................................................................................................................................ 13
34 2.2 NetworkParameters............................................................................................................................. 14
35 2.3 PointOfInteractionComponent.............................................................................................................. 15
36 2.3.1 Structure.................................................................................................................................... 15
37 2.3.2 Business Rules Validation......................................................................................................... 18
38 3 StatusReport (catm.001).............................................................................................................................. 19
39 3.1 Message Usage................................................................................................................................... 19
40 3.2 Message Preparation........................................................................................................................... 27
41 3.3 Message Processing............................................................................................................................ 28
42 3.4 Business Rules Validation.................................................................................................................... 28
43 4 ManagementPlanReplacement (catm.002).................................................................................................. 30
44 4.1 Message Usage................................................................................................................................... 30
45 4.2 Message Preparation........................................................................................................................... 38
47 4.4 Execution of the Management Plan..................................................................................................... 42
48 4.4.1 One-Time Call to the Maintenance Example.............................................................................43
49 4.4.2 Cyclic Call and Acquirer Parameters Download Examples......................................................43
50 4.4.3 Cyclic Call after an Acquirer Parameters Download Examples.................................................45
51 4.4.4 Sequence of Parameters Downloads Example.........................................................................46
52 4.4.5 Sequence of Upload action Example.........................................................................................46
53 4.5 Error Handling during Management Plan Execution............................................................................47
55 5 AcceptorConfigurationUpdate (catm.003).................................................................................................... 50
5 Page ii
56 5.1 Message Usage................................................................................................................................... 50

58 5.3 Acquirer Protocol Parameters.............................................................................................................. 72
59 5.3.1 Configuration of Data Capture and Completion for Online Transactions...................................72
60 5.3.2 Configuration of Data Capture and Completion for Offline Transactions...................................74
61 5.3.3 Configuration of Reconciliation.................................................................................................. 75
62 5.3.4 Other Acquirer Protocol Configuration Parameters...................................................................77
63 5.4 Host Communication Parameters........................................................................................................ 78
64 5.5 TMS Protocol Parameters.................................................................................................................... 78
65 5.5.1 MessageItem............................................................................................................................. 78
66 5.6 Sale to POI Parameters....................................................................................................................... 81
68 5.8 Nexo parameters states lifecycle......................................................................................................... 84
69 5.8.1 Foreword................................................................................................................................... 84
70 5.8.2 Parameters lifecycle on POI...................................................................................................... 85
71 5.8.3 Parameters lifecyle on TMS...................................................................................................... 87
72 6 TerminalManagementRejection (catm.004).................................................................................................91
73 6.1 Introduction.......................................................................................................................................... 91
74 6.2 Message Usage................................................................................................................................... 92
75 7 MaintenanceDelegation............................................................................................................................... 94
76 7.1 Introduction.......................................................................................................................................... 94
77 7.2 Delegation actors................................................................................................................................. 96
78 7.3 Delegation use cases........................................................................................................................... 97
79 7.3.1 POI Identifications..................................................................................................................... 97
80 7.3.2 Setup of Delegation................................................................................................................... 98
81 7.3.3 Stopping a Delegation............................................................................................................... 98
82 7.3.4 General rules for Delegation...................................................................................................... 99
83 7.3.5 Status Report triggered by an Acquirer message....................................................................100
84 7.3.6 Rules for Key Download Delegation........................................................................................ 100
85 7.3.7 Create a Key Download Delegation......................................................................................... 100
86 7.3.8 Update a Key Download Delegation........................................................................................103
87 7.3.9 Remove a Key Download Delegation......................................................................................103
88 7.3.10 Rules for Parameters Download Delegation..........................................................................105
89 7.3.11 Create a Parameters Download Delegation..........................................................................105
90 7.3.12 Update of Parameter Download Delegation..........................................................................108
91 7.3.13 Remove of Parameter Download Delegation........................................................................109
92 7.4 Delegation examples......................................................................................................................... 110
93 7.4.1 Example: AcquirerParameters Download Delegation..............................................................110
94 7.4.2 Example: ApplicationParameters Download Delegation..........................................................112
95 7.4.3 Example: Untargeted Delegation.............................................................................................118
7 Page iii
96 7.4.4 Distributed Delegation............................................................................................................. 121

97 7.5 Delegated services and corresponding configuration message components.....................................125
98 7.6 MaintenanceDelegationRequest (catm.005)......................................................................................125
99 7.6.1 Business Rules Validation....................................................................................................... 131
100 7.7 MaintenanceDelegationResponse (catm.006)...................................................................................132
101 8 Certificate Management............................................................................................................................. 135
102 8.1 Introduction........................................................................................................................................ 135
103 8.1.1 Certificate Creation.................................................................................................................. 135
104 8.1.2 Certificate Renewal................................................................................................................. 136
105 8.1.3 Certificate Revocation............................................................................................................. 137
106 8.1.4 White List Insertion.................................................................................................................. 137
107 8.1.5 White List Removal.................................................................................................................. 138
108 8.2 CertificateManagementRequest (catm.007).......................................................................................138
110 8.3 CertificateManagementResponse (catm.008)....................................................................................142
112 9 Alternative Message Exchanges................................................................................................................ 145
113 9.1 Message Exchange only.................................................................................................................... 145
114 9.1.1 Upload StatusReport............................................................................................................... 146
115 9.1.2 ManagementPlanReplacement............................................................................................... 147
116 9.2 File Transfer only............................................................................................................................... 148
117 9.3 Upload of a StatusReport................................................................................................................... 149
118 9.3.1 Download of a ManagementPlanReplacement.......................................................................150
119 9.4 Message Exchange and File Transfer................................................................................................ 152
120 10 Error Handling.......................................................................................................................................... 153
121 11 Transport Protocol Services..................................................................................................................... 154
122 11.1 File Transfer Protocol....................................................................................................................... 154
123 11.1.1 The FTP Model...................................................................................................................... 154
124 11.2 File Transfer Services...................................................................................................................... 155
125 11.2.1 Access Commands................................................................................................................ 155
126 11.2.2 FTP Transfer Parameter Commands....................................................................................156
127 11.2.3 FTP Protocol Service Commands.........................................................................................159
128
129
130
9 Page iv
131 Figures
132
133 Figure 1 : StatusReport with no change on the ManagementPlan..................................................................46
134 Figure 2 : StatusReport with change on ManagementPlan and AcceptorConfigurationUpdate......................46
135 Figure 3 Parameters management with multiple TM......................................................................................72
136 Figure 4 Parameters lifecycle on POI............................................................................................................. 88
137 Figure 5 Parameters lifecycle on TMS............................................................................................................ 90
138 Figure 6: Rejection of a TMS message........................................................................................................... 91
139 Figure 7 One POI multiple Identifications........................................................................................................ 98
140 Figure 8 POI identification with delegation...................................................................................................... 99
141 Figure 9 Creation of Key Download delegation............................................................................................. 101
142 Figure 10 Creation of Parameters Download delegation..............................................................................105
143 Figure 11 AcquirerParameters download delegation....................................................................................110
144 Figure 12 ApplicationParameters download delegation................................................................................112
145 Figure 13 Untargeted delegation.................................................................................................................. 117
146 Figure 14 Distributed delegation................................................................................................................... 119
147 Figure 15: TMS messages transferred as message exchanges...................................................................144
148 Figure 16: TMS messages transferred as files.............................................................................................147
149 Figure 17: TMS messages transferred as both messages and file...............................................................150
150 Figure 18: The FTP Model............................................................................................................................ 152
151 Figure 19: FTP Server Directory Structure for TMS......................................................................................154
152
11 Page v
153 1 Introduction
154 1.1 Purpose of the Document
155 The present document describes how to use the messages of the nexo Terminal Management Protocol
156 described in the document "Card Payment – Terminal Management, Message Definition Report" [CAPE
157 TMS MDR].
158
159 1.2 References

160 [CAPE ACQ MDR] ISO 20022, Card Payment Exchanges, Message Definition Report, Edition March
161 2019 (Acceptor to Acquirer)
162 [CAPE ACQ MUG] CAPE, Card Payments, Message Usage Guide, Version 8.0
163 [CAPE TMS MDR] ISO 20022, Card Payment - Terminal Management, Message Definition Report,
164 Edition March 2019
165 [NEXO SECU] Card Payment Protocols Security, nexo, Version 3.0
166 [RFC2119] Key words for use in RFCs to Indicate Requirement Levels, March 1997
167
168 1.3 Terms and Definitions

169
170 CMS Cryptographic Message Syntax is defined by the RFC 5652. Use of CMS structure in nexo
171 protocols are defined and highlighted in [NEXO SECU].
172 CSTR Stands for Constraint. Mainly used in explanation of message, this column title will highlight if a
173 constraint exists directly on the presence or the value of an element (mark by a star ‘*’), or if a
174 constraint exists due to interdependency of elements of the messages (e.g data element A must
175 be present if data element B equals X). In this latter case the constraint is labelled as ‘C’ plus a
176 number. These constraints may serve for semantic analysis.
177 MDR Message Definition Report
178 MTM Master Terminal Manager is the Terminal Manager Server which is accountable of the POI
179 configuration. A POI has only one MTM but may have several TM.
180 MUG Message User Guide
181 Mult. Stands for Multiplicity. It will be mainly used for explanation on messages and to highlight how
182 many times an element is present inside a message.
183 POI Point Of Interaction is the point where the payment processing is processed in the merchant
184 domain. This device may be a dedicated one like an ICC card reader or not
185 RFC Request For Comments.
186 TM Terminal Manager is a Terminal Manager Server responsible for a specific part of the POI
187 configuration
188
189
13 Page 6
190
191 1.4 Conventions.

192
193 A grey line of any element included in a message represents a data element which are left there for
194 consistency with the MDR, but are not expected to be generated in this version of this protocol, neither
195 controlled by the receiver.
196 The words MUST, SHOULD and MAY will be used throughout this document with the meaning defined by
197 [RFC2119].
198
199 In order to build smaller message, all unnecessary white space inside XML messages should be removed.
200 All examples in this document and annexes will try to follow this best practice.
201
202 In every chapter devoted to message usage, a table is present with a "Rule" column. If this column contains
203 the value:
204  Appli: the multiplicity of a message element of the protocol could be restricted by the POI application
205 exclusively (e.g. the POIComponent).
206  Copy : only applicable to a response message. This condition means that the value of the message
207 element is copied from the request
208  Config: the message element could be set dynamically by the TMS to the value in
209 TMSProtocolParameters.MessageItem
210
211 To improve the readability of these tables within the release with revision marks, we use different colors and
212 font in order to identify addition, deletion or modification from the previous major version. The following code
213 applies:
214  Creation : green double underline
215  Update : blue underlined
216  Deletion : red strike out
217
218
219 1.5 What’s new in the edition 8.

220
221 This edition brings the following improvements:
Topic Chapter Modification Type
Encoding of Boolean 1.6.5 Creation

Addition of a new chapter to highlight common messages 2 Creation
principles
Change "Present if it contains any data" to "Present only if 3.1 Update
contains any data"
Nexo Parameter states lifecycle 5.8 Creation
Annex Updated
15 Page 7
Annex A Examples Updated

Annex B Key Downloading Updated
Annex C TMS Delegation Updated
222
17 Page 8
223
224 1.6 Principles.

225
226 1.6.1 Number encoding

227
228 According to [CAPE TMS MDR], a Number is defined as a Quantity and is made of 18 digits of totalDigits
229 and a fractionDigits equals to 0.
230 Then the following element are correct Number, according to this definition.
231  123456789012345678
232  12.
233  12.0000000000000000
234
235 1.6.2 Initiating Party.

236
237 When a Master Terminal Manager receives a message from a POI, through an intermediary agent or not, it
238 must receive it with the InitiatingParty/Identification set to the InitiatingPartyIdentification given by the MTM to
239 this POI. If it is the first time that the POI sends a message to the MTM, or if the MTM doesn't send any
240 InitiatingPartyIdentification in AcceptorConfigurationUpdate then the identification is set with the TMS
241 POIIdentification.Identification.
242
243 1.6.3 DateAndTime.

244
245 Any exchanged DateAndTime element should be specified with a timezone.
246
247 1.6.4 Encoding of Certificate

248
249 When a certificate has to be exchanged, the element to exchange in the protocol must be the ASN1 values.
250 For instance,
251 <Cert>MIIDozCCAougAwIBAgIKKrxA9NSC9evUNjANBgkqhkiG9w0BAQsFADA/MQswCQYDVQQGEwJVU
252 zEVMBMGA1UEChMMVFIzNCBTYW1wbGVzMRkwFwYDVQQDExBUUjM0IFNhbXBsZSBSb290MB4XDTE
253 3MTAwOTE0NTAwOFoXDTIxMTExNzE0NTAwOFowTzELMAkGA1UEBhMCVVMxFTATBgNVBAoMDFRS
254 MzQgU2FtcGxlczENMAsGA1UECwwEbmV4bzEaMBgGA1UEAwwRVFIzNCBTYW1wbGUgS1JEIDEwggEi
255 MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDXta0tinjU1/
256 R1rK3UhPFZbgcSP9HqtCs8tDspnCH+a/TFETD0j/
257 1oj6TigTzR4ZOj2KwryVxHa9ktLjk51D2Jdhh6XJqiRM5mlaqAhbSUfkFsGng1Dh35Qe9/
258 rpdO+kiXEeLKo0JWMK2yVH6wjsqicBtfpv15FjhAbM1JGMBqYFeLSPp6wtRFocGvF5N/
259 +uSGjZZV2R7dfQhyWI9pA4OuBMY6FzQJAJE1omC6uw3lhuq+x4vsGzH6gJBgneG5aQCrsM2PayaLhoI/
260 gjq4qK2M7NK1eCX1ZqZeJxOQIn08EU1pp9T/
261 Ry2TMLfiqTTXF5tuNiK2irbw61qEGVl9C8lxAgMBAAGjgZAwgY0wHQYDVR0OBBYEFImTTogiqHi8JKcF3A+
262 BelAo6yCEMFEGA1UdIwRKMEihQ6RBMD8xCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxUUjM0IFNhbXB
263 sZXMxGTAXBgNVBAMTEFRSMzQgU2FtcGxlIFJvb3SCAQAwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBA
264 MCB4AwDQYJKoZIhvcNAQELBQADggEBAF5IDalfV99RgavThhpbiSbrZgPD0WYiS+PtWWgXguHVYOJw1
19 Page 9
265 nXW8QtVUgYTSD14Mi8vElk+SDKgOe/
266 dtHoKPgjI0ppG4cWo9djolyEq9BYnaYtj1glJyGYVJ+rngVtKhB7l6ozL+5zVlZXEom/DGYiQes/DG9xnm/
267 CWliKycp5iZ9M3LI/
268 E9opQv+VSIUuu1qVu36zXjIodfdIOczp3B1ywiReUowiQ4pkLCOUAbSfBXpdsJgtFxhq8JqMsUIsrFTgeAVjRfd
269 lSH1Nolc/UeYgSPk57NF/E5uE/EWayNbtqgU8NFjpnJ1GoYC23N/zhhDmj07TCtzW+iTC634CMPNo=</Cert>
270 refers to the following ASN1 data elements
271 308203A33082028BA003020102020A2ABC40F4D482F5EBD436300D06092A864886F70D01010B050030
272 3F310B300906035504061302555331153013060355040A130C545233342053616D706C657331193017060
273 35504031310545233342053616D706C6520526F6F74301E170D3137313030393134353030385A170D323
274 1313131373134353030385A304F310B300906035504061302555331153013060355040A0C0C5452333420
275 53616D706C6573310D300B060355040B0C046E65786F311A301806035504030C11545233342053616D70
276 6C65204B5244203130820122300D06092A864886F70D01010105000382010F003082010A0282010100D7
277 B5AD2D8A78D4D7F475ACADD484F1596E07123FD1EAB42B3CB43B299C21FE6BF4C51130F48FFD688
278 FA4E2813CD1E193A3D8AC2BC95C476BD92D2E3939D43D8976187A5C9AA244CE6695AA8085B4947E
279 416C1A78350E1DF941EF7FAE974EFA489711E2CAA3425630ADB2547EB08ECAA2701B5FA6FD791638
280 406CCD4918C06A60578B48FA7AC2D445A1C1AF17937FFAE4868D9655D91EDD7D0872588F690383AE
281 04C63A173409009135A260BABB0DE586EABEC78BEC1B31FA8090609DE1B96900ABB0CD8F6B268B86
282 823F823AB8A8AD8CECD2B57825F566A65E271390227D3C114D69A7D4FF472D9330B7E2A934D7179B
283 6E3622B68AB6F0EB5A8419597D0BC9710203010001A3819030818D301D0603551D0E0416041489934E
284 8822A878BC24A705DC0F817A5028EB208430510603551D23044A3048A143A441303F310B30090603550
285 4061302555331153013060355040A130C545233342053616D706C65733119301706035504031310545233
286 342053616D706C6520526F6F7482010030090603551D1304023000300E0603551D0F0101FF0404030207
287 80300D06092A864886F70D01010B050003820101005E480DA95F57DF5181ABD3861A5B8926EB6603C3
288 D166224BE3ED59681782E1D560E270D675D6F10B55520613483D78322F2F12593E4832A039EFDDB47
289 A0A3E08C8D29A46E1C5A8F5D8E897212AF41627698B63D60949C8661527EAE7815B4A841EE5EA8CC
290 BFB9CD59595C4A26FC31988907ACFC31BDC679BF0969622B2729E6267D3372C8FC4F68A50BFE5522
291 14BAED6A56EDFACD78C8A1D7DD20E733A77075CB0891794A30890E2990B08E5006D27C15E976C260
292 B45C61ABC26A32C508B2B15381E0158D17DD9521F536895CFD47988123E4E7B345FC4E6E13F1166B2
293 35BB6A814F0D163A672751A8602DB737FCE18439A3D3B4C2B735BE8930BADF808C3CDA
294 Which correspond to the following certificate
295 Certificate:
296 Data:
297 Version: 3 (0x2)
298 Serial Number:
299 2a:bc:40:f4:d4:82:f5:eb:d4:36
300 Signature Algorithm: sha256WithRSAEncryption
301 Issuer: C = US, O = TR34 Samples, CN = TR34 Sample Root
302 Validity
303 Not Before: Oct 9 14:50:08 2017 GMT
304 Not After : Nov 17 14:50:08 2021 GMT
305 Subject: C = US, O = TR34 Samples, OU = nexo, CN = TR34 Sample KRD 1
306 Subject Public Key Info:
307 Public Key Algorithm: rsaEncryption
308 Public-Key: (2048 bit)
309 Modulus:
310 00:d7:b5:ad:2d:8a:78:d4:d7:f4:75:ac:ad:d4:84:
311 f1:59:6e:07:12:3f:d1:ea:b4:2b:3c:b4:3b:29:9c:
21 Page 10
312 21:fe:6b:f4:c5:11:30:f4:8f:fd:68:8f:a4:e2:81:
313 3c:d1:e1:93:a3:d8:ac:2b:c9:5c:47:6b:d9:2d:2e:
314 39:39:d4:3d:89:76:18:7a:5c:9a:a2:44:ce:66:95:
315 aa:80:85:b4:94:7e:41:6c:1a:78:35:0e:1d:f9:41:
316 ef:7f:ae:97:4e:fa:48:97:11:e2:ca:a3:42:56:30:
317 ad:b2:54:7e:b0:8e:ca:a2:70:1b:5f:a6:fd:79:16:
318 38:40:6c:cd:49:18:c0:6a:60:57:8b:48:fa:7a:c2:
319 d4:45:a1:c1:af:17:93:7f:fa:e4:86:8d:96:55:d9:
320 1e:dd:7d:08:72:58:8f:69:03:83:ae:04:c6:3a:17:
321 34:09:00:91:35:a2:60:ba:bb:0d:e5:86:ea:be:c7:
322 8b:ec:1b:31:fa:80:90:60:9d:e1:b9:69:00:ab:b0:
323 cd:8f:6b:26:8b:86:82:3f:82:3a:b8:a8:ad:8c:ec:
324 d2:b5:78:25:f5:66:a6:5e:27:13:90:22:7d:3c:11:
325 4d:69:a7:d4:ff:47:2d:93:30:b7:e2:a9:34:d7:17:
326 9b:6e:36:22:b6:8a:b6:f0:eb:5a:84:19:59:7d:0b:
327 c9:71
328 Exponent: 65537 (0x10001)
329 X509v3 extensions:
330 X509v3 Subject Key Identifier:
331 89:93:4E:88:22:A8:78:BC:24:A7:05:DC:0F:81:7A:50:28:EB:20:84
332 X509v3 Authority Key Identifier:
333 DirName:/C=US/O=TR34 Samples/CN=TR34 Sample Root
334 serial:00
335
336 X509v3 Basic Constraints:
337 CA:FALSE
338 X509v3 Key Usage: critical
339 Digital Signature
340 Signature Algorithm: sha256WithRSAEncryption
341 5e:48:0d:a9:5f:57:df:51:81:ab:d3:86:1a:5b:89:26:eb:66:
342 03:c3:d1:66:22:4b:e3:ed:59:68:17:82:e1:d5:60:e2:70:d6:
343 75:d6:f1:0b:55:52:06:13:48:3d:78:32:2f:2f:12:59:3e:48:
344 32:a0:39:ef:dd:b4:7a:0a:3e:08:c8:d2:9a:46:e1:c5:a8:f5:
345 d8:e8:97:21:2a:f4:16:27:69:8b:63:d6:09:49:c8:66:15:27:
346 ea:e7:81:5b:4a:84:1e:e5:ea:8c:cb:fb:9c:d5:95:95:c4:a2:
347 6f:c3:19:88:90:7a:cf:c3:1b:dc:67:9b:f0:96:96:22:b2:72:
348 9e:62:67:d3:37:2c:8f:c4:f6:8a:50:bf:e5:52:21:4b:ae:d6:
349 a5:6e:df:ac:d7:8c:8a:1d:7d:d2:0e:73:3a:77:07:5c:b0:89:
23 Page 11
350 17:94:a3:08:90:e2:99:0b:08:e5:00:6d:27:c1:5e:97:6c:26:
351 0b:45:c6:1a:bc:26:a3:2c:50:8b:2b:15:38:1e:01:58:d1:7d:
352 d9:52:1f:53:68:95:cf:d4:79:88:12:3e:4e:7b:34:5f:c4:e6:
353 e1:3f:11:66:b2:35:bb:6a:81:4f:0d:16:3a:67:27:51:a8:60:
354 2d:b7:37:fc:e1:84:39:a3:d3:b4:c2:b7:35:be:89:30:ba:df:
355 80:8c:3c:da
356
357
358
359 1.6.5 Encoding of Boolean value.

360
361 According to [CAPE TMS MDR], a Boolean can have the following litterals.
362  true,
363  false.
364  1
365  0
366
367
25 Page 12
368 2 Common nexo TMS message principles

369
370 A nexo TMS message is composed of three major functional blocks:
371  A message header containing information related to the management of the message (routing and
372 processing)
373  A message body containing information related to the processing of the message
374  A security trailer, which may be optional, containing information related to the security of the
375 message.
376
377 Only TerminalManagementRejection has no security trailer.
378 The security trailer is a CMS structure which is defined inside [NEXO SECU]
379
380 In the following part of this chapter we describe types that are used in various messages.
381 In some cases, the same type could be used with different message element names.
382
383 2.1 CryptographicKey

384
385 CryptographicKey (type of SecurityElement) provides necessary and sufficient information to identify or to
386 exchange securely a cryptographic key.
387
MessageName Mult Rule Cstr Usage
Lvl
.
1 Identification [1..1 <Id>::Max140Text
]
1 AdditionalIdentification [0..1 <AddtlId>::Max35Binary
]
1 Version [1..1 <Vrsn>::Max256Text
]
1 Type [0..1 <Tp>::CryptographicKeyType3Code
]
1 Function [0..*] <Fctn>::KeyUsage1Code
1 ActivationDate [0..1 <ActvtnDt>::ISODateTime
]
1 DeactivationDate [0..1 <DeactvtnDt>::ISODateTime
]
1 KeyValue [0..1 If necessary, CMS structure used to
] exchange sensitive information related to this
SecurityElement.
<KeyVal>
1 KeyCheckValue [0..1 <KeyChckVal>::Max35Binary
]
1 AdditionalManagement- [0..*] <AddtlMgmtInf>
27 Page 13
Information
2 Name [1..1 <Nm>::Max70Text
]
2 Value [0..1 <Val>::Max140Text
]
388
389
29 Page 14
390
391 2.2 NetworkParameters

392
393 NetworkParameters (type of RemoteAccess) provides necessary and sufficient information to connect to a
394 host.
395
396
MessageName Mult Rule Cstr Usage
Lvl
.
Address [1..*] Network addresses of the host. Priorities of
the addresses are defined by the order of
their appearance in the message (the first
1 one is the primary address, the second one
the secondary address, etc…).
<Adr>
NetworkType [1..1 Type of communication network. Allowed
] values:
"InternetProtocol" A transport protocol
using an IP network.
2 "PublicTelephone" A transport protocol
using Public Switched Telephone Network
(PSTN).
<NtwkTp>::NetworkType1Code
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
2 default port is not used.
The value of a public telephone address
contains the phone number with possible
prefix and extensions.
<AdrVal>::Max70Text
UserName [0..1 Username for identification of the POI e.g. to
] login into a server
1
<UsrNm>::Max35Text
AccessCode [0..1 Password for authentication of the POI e.g. to
] login into a server
1
<AccsCd>::Max35Binary
31 Page 15
ServerCertificate [0..*] X.509 Certificate required to authenticate the

server.
1
<SvrCert>::Max10KBinary
ServerCertificateIdentifier [0..*] Identification of the X.509 Certificate required
to authenticate the server, for instance a
digest of the certificate, the certificate serial
1 number with the certificate issuer name.
<SvrCertIdr>::Max140Binary
ClientCertificate [0..*] X.509 Certificate required to authenticate the
client.
1
<ClntCert>::Max10KBinary
SecurityProfile [0..1 Identification of the set of security elements to
] access the host.
1
<SctyPrfl>::Max35Text
397
398
33 Page 16
399
400 2.3 PointOfInteractionComponent

401
402 PointOfInteractionComponent (type of POIComponent) embodies a subpart of a POI from a hardware or
403 software perspective. For instance, it could symbolize a cryptographic key, a piece of software, a printer or a
404 set of parameters.
405 It provides an easy way to exchange information between a POI and a Terminal Management System.
406
407 2.3.1 Structure

408
Message element Mult Rule Cstr Usage
Lvl
.
Type [1..1 Type of component belonging to a POI.
]
<Tp>::POIComponentType5Code
1 SubTypeInformation [0..1 Confi SubTypeInformation provide free additional
] g information regarding the POIComponent.
For instance, it may identifies a subtype of
Device (e.g PRINTER, ICC Reader, etc).
<SubTpInf>::Max70Text
Identification [1..1 C1 Identification of the POI component.
1 ]
<Id>
ItemNumber [0..1 Appli Hierarchical identification of a component
] inside all the component of the POI. It is
composed of all item numbers of the upper
level components, separated by the '.'
character, ended by the item number of the
current component:
Hardware: unique identification of a
hardware component inside
the POI system.
Software: unique identification of the
software component inside
the main hardware component
executing the software.
Parameters: identify the hardware or
software component using
these parameters.
<ItmNb>::Max35Text
35 Page 17
ProviderIdentification [0..1 Appli Identifies the provider of the software,

] hardware or parameters of the POI
component:
Hardware: identify the manufacturer1.
Software: identify the software provider.
Parameters: identify the entity in charge of
the parameters.
<PrvdrId>::Max35Text
Identification [0..1 Appli Identification of the POI component assigned
] by the provider:
Hardware: identify the model2.
Software: identify the software product.
Parameters: identify the set of parameters.
<Id>::Max35Text
SerialNumber [0..1 Appli Serial number of the component:
]
Hardware: identify the physical
component.
<SrlNb>::Max35Text
Status [0..1 Status of the POI component.
]
<Sts>
VersionNumber [0..1 Current version of component that might
] include the release number.
Hardware: version of the model (optional).
Software: software version (optional).
Parameters: parameters version
(mandatory).
<VrsnNb>::Max256Text
37 1 replaces ManufacturerIdentification in version 1.0

38 2 replaces Model in version 1.0
39 Page 18
Status [0..1 Current status of the component:

]
WaitingActivation The Parameters or
Software component is not
yet activated.
InOperation The component is activated
and in operation.
OutOfOrder The component is not working
properly.
Deactivated The Parameters or Software
component has been
deactivated.
<Sts>::POIComponentStatus1Code
ExpiryDate [0..1 Expiration date of the component.
]
<XpryDt>::ISODate
StandardCompliance [0..*] Identification of the standard or specification
for which the component complies with.
<StdCmplc>
Identification [1..1 Identification of the standard.
]
<Id>::Max35Text
Version [1..1 Version of the standard.
]
<Vrsn>::Max35Text
Issuer [1..1 Issuer of the standard.
]
<Issr>::Max35Text
Characteristics [0..1 Characteristics of the Hardware or
] SecurityParameters POI component.
<Chrtcs>
Memory [0..*] Memory characteristics of the Hardware
component.
<Mmry>
Identification [1..1 Identification or name of the memory.
]
<Id>::Max35Text
TotalSize [1..1 Total size of the memory unit.
]
<TtlSz>::DecimalNumber
FreeSize [1..1 Total size of the available memory.
]
<FreeSz>::DecimalNumber
41 Page 19
Unit [1..1 Unit of the memory size, allowed values:

] ExaByte Exa byte.
PetaByte Peta byte.
TeraByte Tera byte.
GigaByte Giga byte.
3
MegaByte Mega byte.
KiloByte Kilo byte.
Byte Byte.
<Unit>::MemoryUnit1Code
Communication [0..*] Low level communication of the hardware or
software component toward another
component or an external entity.
<Com>
Communication- [1..1 Type of communication.
Type ]
.
<ComTp>::POICommunicationType2Code
RemoteParty [1..*] Entity that communicate with the current
component, using this communication device.
Acquirer Bank of the Merchant providing
goods and services.
IntermediaryAgent Party acting on
behalf of other parties to
process or forward data to
other parties.
TerminalManager Responsible for one
or several maintenance
functions of a card
payment acceptance
terminal.
SaleSystem Sale system.
POIComponent Other component of the
point of interaction.
<RmotPty>::PartyType7Code
Active [1..1 Flag indicating whether the communication is
] activated.
<Actv>::TrueFalseIndicator
SecurityAccessModules [0..1 Number of security access modules (SAM).
]
<SctyAccsMdls>::Number
SubscriberIdentity- [0..1 Number of subscriber identity modules (SIM).
Modules ]
<SbcbrIdntyMdls>::Number
2 SecurityElement [0..*] Cf chapter dedicated to CryptographicKey
43 Page 20
<SctyElmt>
Assessment [0..*] Assessments for the Hardware or Software
POI component.
<Assmnt>
Type [1..1 Type of assessment of the component.
] Evaluation Evaluation by a laboratory or a
tool.
Certification Certification number delivered
by a certification body.
Approval Approval number delivered by an
approval centre.
<Tp>::POIComponentAssessment1Code
Assigner [1..*] Body which has delivered the assessment.
<Assgnr>::Max35Text
DeliveryDate [0..1 Date when the assessment has been
] delivered.
<DlvryDt>::ISODateTime
ExpirationDate [0..1 Date when the assessment will expire.
]
<XprtnDt>::ISODateTime
Number [1..1 Unique assessment number for the
] component.
<Nb>::Max35Text
409
410 2.3.2 Business Rules Validation

411
412 This chapter lists all business rules related to PointOfInteractionComponent and must be validated any time
413 this component is used.
414
415
Constraint Literal Definition Involved elements
Number
C1 Identification must at least have one child element  Identification
416
417
418
45 Page 21
419 3 StatusReport (catm.001)

420
421 3.1 Message Usage

422
423 StatusReport is a request message sent by a POI to its MTM or to a delegated TM.
424
425 According to its configuration, a POI System may initiate a Terminal Management System (TMS) message
426 exchange (StatusReport request and ManagementPlanReplacement or StatusReport request and
427 AcceptorConfigurationUpdate response messages) in three different ways:
428  Locally. The Acceptor initiates a terminal management session manually by using a maintenance
429 command of the POI e.g. through a Man Machine Interface or by exchanging an order on any POI
430 interface. The Acceptor selects a terminal manager in the maintenance menu of the POI system.
431 The initial address of the MTM is predefined in the POI system.
432  In response to a message. An Acquirer Host sends a TMSTrigger in response to a received
433 message. The POI analyses the TMSContactLevel and TMSContactDateTime and reacts
434 accordingly.
435 The TMSIdentification contains the name of the TMS used in the POI configuration.
436  Accordingly to a schedule. The POI starts the message exchange according to a timing condition of
437 a TMS action defined in the management plan.
438
439 Depending upon the MessageItem configuration, the StatusReport message contains information about:
440  the installed parameter versions of the POI ,
441  the POI components already installed or activated,
442  the log of Event with the results of the TMS actions performed since the last status report (usually
443 these are local actions e.g. activation of data sets or a restart of the POI application), the report also
444 contains the initiation trigger.
445
Lvl StatusReport Mult. Rule Cstr Usage
Header [1..1 <Hdr>
1
]
DownloadTransfer [1..1 * False
2 ]
<DwnldTrf>::TrueFalseIndicator
FormatVersion [1..1 * The version compliant with this release of the
] MUG should be identified by "8.0".
2
<FrmtVrsn>::Max6Text
ExchangeIdentification [1..1 Unique identifier set by the InitiatingParty.
] Used to detect possible duplications of a
transfer for a period of time.
2 Used to link a StatusReport request message
with the related response message.
<XchgId>::Number
47 Page 22

CreationDateTime [1..1 Date and time of the file or messages
] creation. Time accuracy has to be at least
2 tenth of a second.
<CreDtTm>::ISODateTime
InitiatingParty [1..1 Identification of the initiator of the message
] exchange or the file transfer. Content is
bilaterally agreed between InitiatingParty and
2 RecipientParty.
<InitgPty>
Identification [1..1 C5 Unambiguous identification of the Initiator of
] the file or the message by the recipient.
3 Value is bilaterally agreed between

InitiatingParty and RecipientParty.
<Id>::Max35Text
Type [0..1 Default: "OriginatingPOI"
3 ]
<Tp>::PartyType5Code
Issuer [0..1 Appli The party assigning the Identification.
3 ]
<Issr>::PartyType6Code
Country [0..1 Appli Country of the InitiatingParty (ISO 3166-1
] alpha-2 or alpha-3).
3
<Ctry>::Min2Max3AlphaText
ShortName [0..1 Appli In case of a digital signature, this element
] may contain the identification of the
3 InitiatingParty certificate (Subject).
<ShrtNm>::Max35Text
RecipientParty [0..1 Appli Identification of the recipient of the message
] exchange or the file transfer. Structure and
content is bilaterally agreed between
2 InitiatingParty and RecipientParty.
<RcptPty>
Identification [1..1 <Id>::Max35Text
3
]
Type [0..1 * Type of RecipientParty
]
Allowed values: "MasterTerminalManager",
3 "TerminalManager"
Issuer [0..1 Appli <Issr>::PartyType6Code
3
]
49 Page 23

Country [0..1 Appli Country of the RecipientParty (ISO 3166-1
] alpha-2 or alpha-3).
3
ShortName [0..1 Appli <ShrtNm>::Max35Text
3
]
RemoteAccess [0..1 Access information to reach the target host.
] This element is mandatory if a network
provider or a gateway is involved in the
system between the POI and TM
3
Based on type NetworkParameters.
<RmotAccs>
StatusReport [1..1 StatusReport message body.
1 ]
<StsRpt>
POIIdentification [1..1 Identification of the POI terminal or POI
] system sending the message.
2
<POIId>
Identification [1..1 C5 <Id>::Max35Text
3
]
Type [0..1 * Default and allowed value "OriginatingPOI"
3 ]
Issuer [0..1 Appli * Allowed values: "MasterTerminalManager",
] "TerminalManager", "Merchant", "Acquirer"
3 and "IntermediaryAgent"
Country [0..1 Appli Country of the POI (ISO 3166-1 alpha-2 or
] alpha-3).
3
ShortName [0..1 Appli Name of the POI assigned by the TMS.
3 ]
<ShrtNm>::Max35Text
2 InitiatingTrigger [0..1 Define the actor on the initiative of the Status
] Report and the trigger context
<InitgTrggr>
3 TriggerSource [1..1 Actor who trigger the Status Report
]
<TrggrSrc>::PartyType5Code
3 SourceIdentification [1..1 Id of the trigger source
]
51 Page 24

<SrcId>::Max35Text
3 TriggerType [1..1 Identification of the context of the call
]
<TrggrTp>::ExchangePolicy1Code
3 AdditionalInformation [0..1 Additional Information related to the Staus
] Report request
<AddtlInf>::Max70Text
TerminalManagerIdentification [1..1 <TermnlMgrId>
2
]
Identification [1..1 Appli <Id>::Max35Text
3
]
Type [0..1 * Allowed values: "MasterTerminalManager" or
] "TerminalManager".
3
Issuer [0..1 Appli * Issuer of identification, not used
3 ]
Country [0..1 Appli Country of the Termminal Manager (ISO
] 3166-1 alpha-2 or alpha-3).
3
ShortName [0..1 Appli Name of the TMS assigned by the MTM or
] TM.
3
<ShrtNm>::Max35Text
DataSet [1..1 <DataSet>
2
]
Identification [1..1 Identification of the Data set (class of file)
3 ]
<Id>
Name [0..1 * Name of the status report; not used
4 ]
<Nm>::Max256Text
Type [1..1 * Allowed value: "StatusReport"
4 ]
<Tp>::DataSetCategory12Code
Version [0..1 * Version of the status report; not used
4 ]
<Vrsn>::Max256Text
CreationDateTime [0..1 * Date and time of the creation of the status
] report. Time accuracy has to be at least in
seconds. This data element is mandatory for
4 a StatusReport
53 Page 25

SequenceCounter [0..1 Increasing value allows detection of message
] replay.
3
<SeqCntr>::Max9NumericText
Content [1..1 <Cntt>
3
]
POICapabilities [0..1 Confi C1 Present if it contains any data
] g C2 Only present if DataSetRequired equal to
4 "ManagementPlan"
<POICpblties>
[0..*] Appli Capabilities defining the physical components
CardReadingCapabilities of the POI.
<CardRdngCpblties>::CardDataReading6Co
de
Cardholder- [0..*] Appli List of methods supported by the POI to
VerificationCapabilities identify the cardholder.
<CrdhldrVrfctnCpblties>::CardholderVerificati
onCapability4Code
PINLength- [0..1 Maximum number of digits the POI is able to
Capabilities ] accept when the cardholder enters its PIN.
<PINLngthCpblties>::PositiveNumber
[0..1 Maximum number of characters of the
ApprovalCodeLength ] approval code the POI is able to manage.
<ApprvlCdLngth>::PositiveNumber
[0..1 Maximum data length in bytes that a card
MaxScriptLength ] issuer can return to the ICC at the terminal.
<MxScrptLngth>::PositiveNumber
[0..1 default "False".
CardCaptureCapable ]
True if the POI is able to capture card.
<CardCaptrCpbl>::TrueFalseIndicator
[0..1 Appli Capability of the POI to go on-line and store
OnLineCapabilities ] the transaction.
5
<OnLineCpblties>::OnLineCapability1Code
[0..*] Appli Capabilities of the terminal to display or print
MessageCapabilities message to the cardholder and the merchant.
It correspond to the ISO 8583 field number
5 22-11 for the version 93, and field number 27-
6 for the version 2003.
<MsgCpblties>
55 Page 26

[1..*] Appli Destination of the message to present.
6 Destination
<Dstn>::UserInterface4Code
[0..*] Appli <AvlblFrmt>::OutputFormat1Code
6
AvailableFormat
[0..1 Appli Number
NumberOfLines ]
6 Number of lines of the display.
<NbOfLines>::Number
[0..1 Appli Number
LineWidth ]
6 Number of columns of the display or printer.
<LineWidth>::Number
[0..*] Appli LanguageCode
AvailableLanguage
Available language for the messages.
6 Reference ISO 639-1 (alpha-2) et ISO 639-2
(alpha-3).
<AvlblLang>::LanguageCode
POIComponent [0..*] Appli C3 Used to inform the Terminal Manager about:
Confi - the hardware components of the POI.
g
- the software components of the POI.
- the installed version of the parameters.
4 It may also contain some Sale Components
according to configuration.
Based on type PointOfInteractionComponent
<POICmpnt>
AttendanceContext [0..1 Appli Attended: an attendant is present and can
] survey the financial transaction (face to face).
SemiAttended: one attendant present for
4 several POIs.
Unattended: an attendant is not present
<AttndncCntxt>::AttendanceContext1Code
POIDateTime [1..1 Appli Information used by the TMS to detect a
] discrepancy of the real time clock used in the
4 POI terminal
<POIDtTm>::ISODateTime
57 Page 27

DataSetRequired [0..*] Absent if the StatusReport is sent by file
except for delegation (e.g untargeted
delegation).
4 If absent when the StatusReport is sent by

message, a ManagementPlan must be sent
in response.
<DataSetReqrd>
[1..1 It contains the data elements and the values
Identification ] of the related Action.DataSetIdentification
5 requesting the transfer of data set.
<Id>
[0..1 Action.DataSetIdentification.Name of the
Name ] related management plan action, if present.
<Nm>::Max256Text
59 Page 28

[1..1 * Action.DataSetIdentification.Type of the
Type ] related action of the management plan :
"AcquirerParameters": an
AcceptorConfigurationU
pdate message
containing all the
configuration
parameters for one or
several acquirers is
requested by the
StatusReport message.
"ApplicationParameters": an
pdate message
containing only the
application parameters
is requested by the
"ManagementPlan":
ManagementPlanRepla
cement message is
requested by the
"MerchantParameters": an
pdate message
containing only the
merchant parameters is
requested by the
"Parameters": an
pdate message is
requested by the
Content of the
pdate message
determines the types of
parameters to update.
"SecurityParameters": an
pdate message
containing only the
security parameters is
requested by the
"TerminalParameters": an
pdate message
containing only the
terminal parameters is
61 Page 29

[0..1 Action.DataSetIdentification.Version of the
Version ] related management plan action, if present.
<Vrsn>::Max256Text
[0..1 Action.DataSetIdentification.CreationDateTim
CreationDateTime ] e of the related management plan action, if
present.
[0..1 Appli Challenge generated by the POI for key
POIChallenge ] download.
<POIChllng>::Max140Binary
[0..1 Appli Challenge generated by the Terminal
TMChallenge ] Manager in a previous
ManagementPlanReplacement containing
key to dowload or
AcceptorConfigurationUpdate containing key
to store.
<TMChllng>::Max140Binary
SessionKey [0..1 Appli Temporary encryption key that the host will
] use for protecting keys to download.
Based on type CryptographicKey
<SsnKey>
[0..1 Proof of delegation to be validated by the
DelegationProof ] terminal manager receiving a status report
5 from a new POI.
<DlgtnProof>::Max5000Binary
Protected- [0..1 Protected proof of delegation.
5 DelegationProof ]
<PrtctdDlgtnProof>
Event [0..*] Confi List of all completed TMS actions which have
g been performed since the last StatusReport
message
4 Events have to be listed in chronological

order (oldest first regardless of the TM
Identification).
<Evt>
TimeStamp [1..1 Contains the POI processing time of the
] event. Time accuracy has to be at least in
5 seconds.
<TmStmp>::ISODateTime
63 Page 30

Result [1..1 * Result of the performed action. Only the
] C4 result of the last process retry is present.
The value “AnyError” must not be used as an
5 ActionResult.
<Rslt>::TerminalManagementActionResult4C
ode
Action- [1..1 Identification of the TMS action for which the
Identification ] Result is provided.
<ActnId>
[1..1 Filled with the ActionType from message
ActionType ] processed if not available like CREATE
action for AcceptorConfigurationUpdate the
6 value to used is DOWNLOAD
<ActnTp>::TerminalManagementAction4Cod
e
[0..1 Should be provided.
DataSetIdentification ]
<DataSetId>
[0..1 Should be provided to ease processing
Name ] analyses.
7
<Nm>::Max256Text
[1..1 <Tp>::DataSetCategory12Code
7
Type ]
[0..1 <Vrsn>::Max256Text
7
Version ]
[0..1 Should be provided to ease processing
CreationDateTime ] analyses.
Additional- [0..1 C4 Complete the Result, giving details on the
ErrorInformation ] error (e.g. number of retries).
<AddtlErrInf>::Max70Text
5 [0..1 Must be provided by POI systems that
] support multiple terminal managers using
TerminalManagerIdentificatio delegation.
n <TermnlMgrId>::Max35Text
Errors [0..*] Confi Manufacturer specific log file for errors (e.g.
g card reader errors)
4
<Errs>::Max140Text
65 Page 31

SecurityTrailer [0..1 Confi Digital signature or MAC of the message
] g body StatusReport, including the delimiters
(start and end tag for XML encoding).
1 This element is computed as a request
message.
<SctyTrlr>
446
447
448
67 Page 32
449 3.2 Message Preparation

450
451 This section outlines the processing of a POI prior to sending a StatusReport message to a Terminal
452 Manager.
453 1. Depending on the MessageItem configuration, the StatusReport message body contains:
454 a. Identification of POIIdentification populated with the identifier of the POI for the TM or MTM,
455 b. Identification of TerminalManagerIdentification populated with the identifier of the TM or
456 MTM, if available,
457 c. a data set with Identification containing the Type "StatusReport" and CreationDateTime of
458 the report filled with the local time stamp,
459 d. VersionNumber used for summarising the current status of the POI component and
460 capabilities. The version number should be updated if the status of the POI component is
461 changed e.g. by an update of the acquirer parameters. An update of the log of Event or
462 Errors does not influence the version of the status report.
463 e. POICapabilities filled with the installed capabilities (e.g. card readers). This component is
464 only present if DataSetRequired equal to "ManagementPlan".
465 f. POIComponent is filled using identifiers comprehensible by the recipient.
466 If the POI contains a configuration for several acquirers, the POIComponent values may
467 depend on the acquirer (e.g. the value of
468 POIComponent/Identification/IdentificationProviderIdentification).
469 g. the sequence of Event containing the result of the performed TMS actions since the last
470 report that has been successfully transferred to the TM or the MTM (the action results have
471 to be stored by the POI until they have been successfully sent to the TM or MTM). All Events
472 for a delegated TM should be reported to the MTM, where the TMIdentification is stored in
473 the AdditionalErrorInformation.
474 the POI vendor specific error description in the data element Errors.SequenceCounter is not used.
475 2. The POI may generate a security trailer for the StatusReport message. The trailer contains either:
476 a. the signature of the message body using the secret key as described in [EPAS SECU] or
477 b. the MAC as described in [EPAS SECU].
478 3. The POI builds the header of the message:
479 a. DownloadTransfer: set to False.
480 b. FormatVersion: Version supported by the POI. The version compliant with this release of the
481 MUG should be identified by "8.0".
482 c. ExchangeIdentifier: unique identifier per partner and per pair of messages. Used to assign a
483 response to a request message and to identify duplicate messages. It may be a cyclic
484 counter incremented by one for each new message.
485 d. CreationDateTime: date and time of the creation of the message. Time accuracy at least a
486 tenth of a second.
487 4. The POI establishes a connection to the TM or MTM and sends the request message.
488 5. The POI waits for the response message. In case of no response, an error is stored in the log of
489 Event with the Result "Timeout".
490
69 Page 33
491 3.3 Message Processing

492
493 1. The TM or the MTM examines the syntax and contents of the message header and checks whether:
494 a. the identifier present in the message element InitiatingParty.Identification is valid3.
495 b. the version in FormatVersion is supported. If not, the TMS responds with a
496 TerminalManagementRejection message containing the Header.FormatVersion it supports
497 and a RejectReason equals to “ProtocolVersion ».
498 2. If the MTM or the TM are configured to require security trailers, then SecurityTrailer is verified: The
499 MTM or TM security configuration may be defined outside of the protocol. The POI implementation
500 will determine whether messages contain a security trailer or not. This will be configured outside of
501 the protocol.
502 a. Should the SecurityTrailer contains a digital signature:
503 i. the Common Name of the Subject may be checked against the message element
504 ShortName of POIIdentification
505 ii. the digital signature is validated using the POI's certificate, according to the [EPAS
506 SECU]
507 b. Should the SecurityTrailer contains a message authentication:
508 i. the MAC of the message is validated according to the [EPAS SECU].
509 The message is discarded in case of an invalid digital signature or MAC.
510 3. The TMS verifies the contents of the status report, if it is correct; it prepares and sends either a
511 ManagementPlanReplacement or an AcceptorConfigurationUpdate message. Otherwise it sends a
512 TerminalManagementRejection
513
514 3.4 Business Rules Validation

515
516 This chapter lists all business rules implying at least 2 different elements inside the message.
517
Number
C1 If POICapabilities is present it must have at least  DataSet.Content.POICapabilities
one child
C2 POICapabilities must only be present if Type of  DataSet.Content.DataSetRequired.Identification.Type
DataSetRequired equals ManagementPlan  DataSet.Content.POICapabilities
C3 POIComponent/Identification must at least have  DataSet.Content.POIComponent.Identification
one child element
C4 AdditionalErrorInformation must be present if the  DataSet.Content.Event.Result
value of Result is “UnlistedError”.  DataSet.Content.Event.AdditionalErrorInformation
C5 Identification of initiatingParty must be the same  Header.InitiatingParty.Identification
 StatusReport.POIID.Identification
518
519
71 3 For the first contact to the TM in the life cycle of the POI, the TM may use POIIdentification or DelegationProof of the StatusReport
72 message to register the POI and send back a first management plan to the POI.
73 Page 34
520
521 4 ManagementPlanReplacement (catm.002)

522

524
525 ManagementPlanReplacement is a response message sent by a TM or a MTM to a POI.
526
527 It contains information about the:
528  TMS actions to be performed by the POI,
529  TMS systems to be connected and the corresponding communication parameters,
530  error actions in case of unsuccessful TMS actions.
531
532 The message contains the management plan replacing a previous one.
533
Lvl ManagementPlanReplacement Mult. Rule Cstr Usage
1 Header [1..1 <Hdr>
]
2 DownloadTransfer [1..1 * True
]
2 FormatVersion [1..1 * The version compliant with this release of the
2 ExchangeIdentification [1..1 See StatusReport.
]
Used to link a ManagementPlanReplacement
response message to a StatusRequest
message. Unique identifier set by the
InitiatingParty to assign a
ManagementReplacement response
message to the StatusReport request
message, or to detect duplication of
ManagementReplacement file transfer.
<XchgId>::Number
2 CreationDateTime [1..1 See StatusReport
]
2 InitiatingParty [1..1 See StatusReport
]
<InitgPty>
3 Identification [1..1 See StatusReport
]
<Id>::Max35Text
75 Page 35

3 Type [0..1 * In case of message exchange the allowed
] value is "OriginatingPOI".
In case of file transfer; allowed values are:
"TerminalManager"
or "MasterTerminalManager" .
3 Issuer [0..1 Appli See StatusReport
]
3 Country [0..1 Appli See StatusReport
]
3 ShortName [0..1 Appli In case of digital signature, may contain the
] identification of the TM or MTM certificate
(Subject).
<ShrtNm>::Max35Text
2 RecipientParty [0..1 Appli See StatusReport
]
<RcptPty>
]
<Id>::Max35Text
3 Type [0..1 * Message exchange: allowed values are
] "MasterTerminalManager" and
"TerminalManager".
In case of File transfer: "OriginatingPOI "
3 Issuer [0..1 See StatusReport
]
]
3 ShortName [0..1 Appli In case of digital signature and message
] exchange, this element may contain the
identification of the POI certificate (Subject).
<ShrtNm>::Max35Text
3 RemoteAccess [0..1 Based on type NetworkParameters
]
<RmotAccs>
1 ManagementPlan [1..1 ManagementPlanReplacement message
] body.
<MgmtPlan>
77 Page 36

2 POIIdentification [0..1 Appli Identification of a POI terminal, system or
] group of terminals.
For a message exchange, this is a copy of
the request related data element.
<POIId>
3 Identification [1..1 Part of the TMS/Acquirer/IntermediaryAgent
] or Merchant configuration.
<Id>::Max35Text
3 Type [0..1 * Default "OriginatingPOI"
]
Allowed value: OriginatingPOI
3 Issuer [0..1 Appli * Allowed values: "MasterTerminalManager,
] "TerminalManager", "Merchant", "Acquirer"
and "IntermediaryAgent"
3 Country [0..1 Appli <Ctry>::Min2Max3AlphaText
]
3 ShortName [0..1 Appli Name of the POI assigned by the TMS.
]
<ShrtNm>::Max35Text
2 TerminalManagerIdentification [1..1 <TermnlMgrId>
]
3 Identification [1..1 Appli <Id>::Max35Text
]
3 Type [0..1 * See StatusReport
]
3 Issuer [0..1 Appli * Not used.
]
]
3 ShortName [0..1 Appli See StatusReport
]
<ShrtNm>::Max35Text
2 DataSet [1..1 The data set contains a management plan
]
<DataSet>
3 Identification [1..1 Identification of the management plan.
]
<Id>
79 Page 37

4 Name [0..1 Name of the management plan
]
<Nm>::Max256Text
4 Type [1..1 * Allowed value: "ManagementPlan".
]
4 Version [0..1 Version of the management plan.
]
<Vrsn>::Max256Text
4 CreationDateTime [0..1 Date and time of the management plan. Time
] accuracy has to be at least in seconds.
Checked by the POI to assess whether the
management plan needs to be replaced or
not.
3 SequenceCounter [0..1 * Not used
]
<SeqCntr>::Max9NumericText
3 Content [0..1 Contents of the management plan. The
] absence of Content means that current
management plan needs not to be replaced.
<Cntt>
4 TMChallenge [0..1 Terminal Manager challenge that the POI has
] to send in a StatusReport requesting key
download.
Used for key download delegated action.
KeyEncipherment- [0..*] Certificate chain containing the signed public
Certificate key encryption key of the Terminal Manager
used by the POI to send a session key
encryption key.
The format of the certificate is compliant with
the DER X.509 format.
The certificate chain must be ordered by
starting with the higher certificate level and
ending with the leaf.
Used for key download delegated action.
<KeyNcphrmntCert>::Max10KBinary
4 Action [1..*] List of TMS actions associated to the
management plan to be performed by the
POI.
<Actn>
5 Type [1..1 * Allowed values:
]
C6 "Delete", "Restart", "Download", "Upload",
81 Page 38
C12 "Bind", "Rebind", "Unbind".

C13 The "Bind", "Rebind", "Unbind" are allowed
for key downloading
C14
C16 <Tp>::TerminalManagementAction4Code
C20
5 [0..1 C20 Terminal Manager host access information.
RemoteAccess ]
<RmotAccs>
5 Key [0..*] Identification of Key to use to perform the
Action.
<Key>
6 [1..1 <KeyId>::Max140Text
KeyIdentification ]
6 [1..1 <KeyVrsn>::Max140Text
KeyVersion ]
6 [0..1 <SeqNb>::Number
SequenceNumber ]
6 [0..1 <DerivtnId>::Min5Max16Binary
DerivationIdentification ]
6 [0..1 <Tp>::CryptographicKeyType3Code
Type ]
6 [0..*] <Fctn>::KeyUsage1Code
Function
[0..1 Must be absent if
TerminalManager- ] ManagementPlan.TerminalManagerId.Type is
Identification not ‘MasterTerminalManager’,
C1
Only present if it is different of the

TerminalManager.Identification of this
ManagementPlan.
<TermnlMgrId>
6 [1..1 C11 List of Actions must be grouped by values of
Identification ] this Identification.
<Id>::Max35Text
6 [0..1 <Tp>::PartyType5Code
Type ]
6 [0..1 <Issr>::PartyType6Code
Issuer ]
6 [0..1 <Ctry>::Min2Max3AlphaText
Country ]
6 [0..1 <ShrtNm>::Max35Text
ShortName ]
5 [0..1 C20 TMS protocol to use for performing the
83 Page 39

TMSProtocol ] maintenance action. For instance may
identify a proprietary manufacturer protocol
used for software download
<TMSPrtcol>::Max35Text
5 [0..1 C20 Version of the TMS protocol to use to perform
TMSProtocolVersion ] the maintenance action.
Might be suitable in the following but not
restricted examples:
 POI server managing POI Terminals
with different TMS ProtocolVersion ,
 POI is managed by two TM with
different TMSProtocolVersion
 POI Software Update with legacy
protocol
 …
<TMSPrtcolVrsn>::Max35Text
5 [0..1 C2 Identification of the data set associated to the
DataSetIdentification ] action.
Mandatory for Action.Type "Delete", “Install” ,
“Update”, “Upload”and "Download",
Absent for Action.Type "Restart".
<DataSetId>
6 [0..1 C6 Name of the data set associated to the
Name ] action.
C12
Should be present if needed to identify.
C13
C14
<Nm>::Max256Text
6 [1..1 C3 "AcquirerParameters":If the acquirer
Type ] configuration parameters have
C4
to be deleted (Action.Type =
C5 "Delete"), updated
(Action.Type = "Update") or
C6 replaced (Action.Type =
C7 "Download").
C16 "ApplicationParameters": If only the
C20 application parameters have to
be deleted (Action.Type =
"Delete"), updated
replaced (Action.Type =
"Download").
"ManagementPlan": if management plan
has to be replaced by a new
one to download (Action.Type
= "Download")
85 Page 40
"MerchantParameters": If only the

merchant parameters have to
be deleted (Action.Type =
"Delete"), updated
"Download").
"Parameters": If the parameters that
will be present in the
AcceptorConfiguration sent by
the TM, have to be deleted
(Action.Type = "Delete"),
updated (Action.Type =
"Update") or replaced
(Action.Type = "Download").
“SecurityParameters”: to download
cryptographic keys
(Action.Type = "Download") or
remove cryptographic keys
(Action.Type = "Delete").
"SoftwareModule": For software download
(Action.Type = "Download" or
Action.Type = “Install”).
"StatusReport": if a status report has to
be sent alone without
requesting any data set
(DataSetRequired absent and
Action.Type = "Upload")
"TerminalParameters": If only the
terminal parameters have to be
deleted (Action.Type =
"Delete"), updated
"Download").
“LogFile” if a file is to be uploaded
(Action.Type = "Upload")
“CertificateManagementRequest” if a
certificate has to be generated
(Action.Type = "Upload")
6 [0..1 C6 Version of the data set to be processed by
Version ] the POI
C12
C14
<Vrsn>::Max256Text
6 [0..1 C6 Date time of creation of the data set.
CreationDateTime ]
C12
87 Page 41

C14
5 [0..*] * Type of POI components to send in a status
ComponentType report.
AcquirerProtocolParameters Components
for acquirer interface of
the point of interaction,
including acquirer
hosts.
ApplicationParameters Components of
payment applications
running on the point of
interaction.
MerchantParameters Components for
the merchant using the
Parameters Components for all type of
parameters used the
TerminalParameters Components for
manufacturer
configuration
parameters of the point
of interaction.
SecurityParametersComponents for
security of the point of
interaction.
<CmpntTp>::DataSetCategory12Code
5 [0..1 Identification of the delegation scope
DelegationScope- ] assigned by the MTM.
Identification
<DlgtnScpId>::Max35Text
5 [0..1 Definition of the delegation scope
DelegationScopeDefinition ]
<DlgtnScpDef>::Max3000Binary
5 [0..1 Proof of delegation to be verified by the POI,
DelegationProof ] when performing the delegated actions.
[0..1 Protected proof of delegation.
ProtectedDelegationProof ]
<PrtctdDlgtnProof>
5 Trigger [1..1 Appli * Allowed values:
] C8 "DateTime": the action is triggered by the
information contained in the
Action.TimeCondition data structure
“Host”: the action is triggered through a
response sent by a Host.
89 Page 42
"Manual": An operator has to use an

administrative command on the POI to
contact the related TM, in order to not
interrupt the flow of transactions.
"SaleEvent": the sale system of the
acceptor, driving the POI system, sends
an event to trigger maintenance actions
during an appropriate period.
<Trggr>::TerminalManagementActionTrigger
1Code
5 [0..*] Process to perform before or after the TMS
AdditionalProcess action, allowed values are:
"Reconciliation": the POI has to perform
reconciliation before the action.
"ManualConfirmation": the POI has to ask a
confirmation to the cashier before starting
the action.
“Restart” : the POI has to restart the
application after the successful completion
of the action and other optional external
conditions (e.g acknowledgement of the
ECR).After the completion of the action
and before the restart of the application,
the DataSet identified by
DataSetIdentification must not be used for
transaction processing. The application
may be invalid or may used former
DataSet until the restart of the application.
<AddtlPrc>::TerminalManagementAdditional
Process1Code
5 ReTry [0..1 Condition of a retry if the action is not
] successfully completed.
<ReTry>
6 [1..1 Time period to wait after the last attempt in
Delay ] MMDDhhmm, leading zeros may be omitted.
<Dely>::Max9NumericText
6 [0..1 Maximum number of retries.
MaximumNumber ]
<MaxNb>::Number
5 [0..1 C8 Mandatory for Action.Trigger "DateTime",
TimeCondition ]
Absent for Action.Trigger "HostEvent",
"Manual", "SaleEvent"
<TmCond>
6 [0..1 C9 Must be absent if StartTime is present.
91 Page 43

WaitingTime ] Time to wait before lauching the action.
Format: MMDDhhmm, leading zeros may be
omitted.
<WtgTm>::Max9NumericText
6 [0..1 C9 Must be absent if WaitingTime is present
StartTime ]
Date and time when the action must be
started. If Timezone is not present, POI
timezone is assumed.
<StartTm>::ISODateTime
6 [0..1 Date and time after which the action must not
EndTime ] be started and performed. If Timezone is not
present, POI timezone is assumed.
<EndTm>::ISODateTime
6 [0..1 C10 Time period for a cyclic action, absent
Period ] otherwise.
<Prd>::Max9NumericText
6 [0..1 C10 Maximum number of cycles for a cyclic
MaximumNumber ] action. If the value is 0, the number of cycles
is limitless.
<MaxNb>::Number
5 [0..1 Terminal Manager challenge that the POI has
TMChallenge ] to send in a StatusReport requesting key
download.
[0..*] Certificate chain containing the signed public
KeyEncipherment- key encryption key of the Terminal Manager
Certificate used by the POI to send a session key
encryption key.
The format of the certificate is compliant with
the DER X.509 format.
The certificate chain must ordered by starting
with the higher certificate level and ending
with the leaf.
<KeyNcphrmntCert>::Max10KBinary
5 ErrorAction [0..*] Processing to be performed after the last
action retry fails.
<ErrActn>
6 [1..*] * Result of the last retry of the action. All values
ActionResult are allowed with the exception of "Success".
.If the actual error doesn’t match any
93 Page 44
ActionResult listed in this ErrorAction then

rule 5.8.2 applies
<ActnRslt>::TerminalManagementActionRes
ult4Code
6 [1..1 Processing to be performed for the results
ActionToProcess ] defined by ActionResult, allowed values:
SendStatusReport Send a status report
immediately, reporting the
result of the action and
requesting a
ManagementPlan Then
sending also
POIComponent in the
StatusReport
StopSequence Stop the current sequence
of terminal management
actions without any action,
and do not notice the error
with a status report.
<ActnToPrc>::TerminalManagementErrorActi
on2Code
5 [0..*] Additional information about the maintenance
AdditionalInformation action.
<AddtlInf>::Max3000Binary
5 [0..*] C16 For Action.DatasetIdentification.Type =
MessageItem StatusReport or
CertificateManagementRequest those data
elements can provide information to POI
about expected data in StatusReport or
CertificateManagementRequest
corresponding to this Action
<MsgItm>
6 [1..1 <ItmId>::Max140Text
ItemIdentification ]
6 [1..1 C17 <Cond>::MessageItemCondition1Code
Condition ]
C18
C19
6 [0..*] C17 <Val>::Max140Text
Value
C18
C19
1 SecurityTrailer [0..1 Digital signature or MAC of the message
] body ManagementPlan, including the
delimiters (start and end tags if XML
encoding).
This element is computed as a response
95 Page 45
message.
<SctyTrlr>
534
97 Page 46
535 4.2 Message Preparation

536
537 The TM or MTM sends back a ManagementPlanReplacement as a response to a StatusReport when one of
538 the following conditions is verified:
539  DataSetRequired is absent in the StatusReport message or
540  DataSetRequired is present in the StatusReport message and DataSetRequired.Type has the value
541 "ManagementPlan" or
542  The TM or MTM needs to receive or collect information from the POI or
543  The StatusReport is a valid message and there is no other kind of message to send back to the POI.
544
545 Should the TM or MTM intend to perform a series of new actions or instruct the POI to execute a new
546 management plan, a ManagementPlanReplacement is sent as a response to a StatusReport with a set of
547 new actions detailed in ManagementPlan.DataSet.Content.
548 When the TM or MTM has no intention to modify the current management plan or change the current list of
549 actions, a ManagementPlanReplacement message is sent back as a response to a StatusReport without
550 ManagementPlan.DataSet.Content. The current list of actions remains unchanged.
551
552 The MTM is the only TM able to delegate and to send a management plan for different TM as expressed in
553 Business Rule C1.
554 When a MTM sends Actions to the POI, it must identify for each Action, not related to the MTM, the
555 TerminalManagerId. The Actions must be grouped by TerminalManagerId as expressed in Business Rule
556 C11.
557
558 Using MessageItem in an Action of ManagementPlanReplacement allows TM or MTM to control POI request
559 (StatusReport or CertificateManagementRequest) for this Action only.
560 More details on MessageItem in chapter TMSprotocol.
561
562 For the Action "Upload" a LogFile, a server identified by RemoteAccess and its protocol defined through
563 TMSProtocol and TMSProtocolVersion must be declared in order to receive the LogFile.
564

566 The following steps are performed by the POI when receiving a ManagementPlanReplacement as a
567 response to a StatusReport.
568 1. The POI checks the Header of the received message.
569 1.1. The POI stores the Identification of InitiatingParty.
570 1.2. If DownloadTransfer is set to "False", the action is logged in Event with Result containing
571 "InvalidContent" and AdditionalErrorInformation the text value "DownloadTransfer".
572 1.3. FormatVersion must be identical to the one used in the StatusReport. If the format is not correct:
573  An action is stored in the log of Event with the specific Result "InvalidContent" and
574 AdditionalErrorInformation containing the wrong message element as "FormatVersion”.
575  A TerminalManagementRejection must be sent to the sender.
99 Page 47
576 1.4. ExchangeIdentifier should have the same value as in StatusReport. If not, the action is stored in the
577 log of Event with Result containing "InvalidContent" and AdditionalErrorInformation the text value
578 "ExchangeIdentifier".
579 1.5. CreationDateTime is stored if required.
580 2. If configured the POI checks the signature of the received message as described in [EPAS SECU]. If
581 asymmetric cryptography is used, the POI checks the signature by using the public key contained in the
582 certificate that is present in the security trailer or already defined in the configuration data of the POI. For
583 each terminal manager there is a separate certificate:
584 - certPRMTM_CA(PUMTM_AUTH) if the message was received from the MTM or
585 - certPRMTM_CA(PUTM_AUTH) if the message was received from the TM.
586 If the verification of the signature fails, the error is logged in Event with Result containing
587 "SignatureError" and AdditionalErrorInformation the text value "SecurityTrailer".
588 3. If applicable, the POI checks whether the information in the Certificate Subject correspond to the
589 TerminalManagerIdentification of the message body. If not, the action is logged in Event with Result
590 containing "InvalidContent" and AdditionalErrorInformation the text value "Signer.SignerIdentification".
591 4. The POI checks whether Type of Identification corresponds to "ManagementPlan". If not, the error is
592 logged in Event with Result containing "InvalidContent" and AdditionalErrorInformation the text value
593 "DataSet.Identification.Type".
594 5. The POI checks the completeness, syntax and contents of each action definition grouped by
595 TerminalManagerIdentification present in the received ManagementPlan. In case of an error, the whole
596 management plan is ignored. The list of Action of the previous management plan remains valid. The
597 error is then logged in Event.
598 5.1. The actions are analysed whether the actions are correctly defined. The mandatory data elements
599 have to be present (see ERR3, section 10). All existing data elements have to be correctly formatted
600 (ERR2, section 10).
601 5.2. If an enumeration value of data elements contained in action is unknown, the action may be added
602 to the Event log with Result containing "NotSupported" and AdditionalErrorInformation containing the
603 message component or element.
604 5.3. If the message element Address is not present in the received Action, the POI uses the currently
605 defined address of the TMS (e.g. manually entered at the POI by the user or issued in
606 TMSIdentification of TMSTrigger sent by the acquirer host or intermediary agent in an acquirer
607 protocol response message, or setup up by any another means).
608 5.4. Type or Name in DataSetIdentification is used to identify the category of data to be uploaded,
609 downloaded or deleted:
610 5.4.1. For the Action "Upload",
611 - if DataSetIdentification.Type has the value "StatusReport”, all other elements of
612 DataSetIdentification must be absent
613 - if DataSetIdentification.Type has the value "CertificateManagementRequest”,
614 DataSetIdentification.Name must be present
615 - if DataSetIdentification.Type has the value "LogFile” then DataSetIdentification.Name must
616 be present to identify a logical file. In this case, the POI must use the RemoteAccess,
617 TMSProtocol and TMSProtocolVersion defined within this Action to transfer the LogFile.
618 5.4.2. For the Action "Upload", with DataSetIdentification.Type = "StatusReport” or
619 “CertificateManagementRequest”, one or several Action.MessageItem may be declared that
620 must be taken into account by the POI when generating the StatusReport or
621 CertificateManagementRequest.
622 5.4.3. For the action “Download” if DataSetIdentification.Type contains the value
623 “ManagementPlan”. All other elements must be absent.
101 Page 48
624 5.4.4. For the action “Download” if DataSetIdentification.Type doesn’t contain the value
625 “ManagementPlan”, DataSetIdentification.Type must contain either the values
626 ApplicationParameters, AcquirerParameters, MerchantParameters, TerminalParameters or
627 SecurityParameters; DataSetIdentification.Name must contain the name of the file to be
628 downloaded when file transfer is used and the name of the DataSet to receive for message
629 exchanges. All other elements should be present in DataSetIdentification. If Version is
630 present, the POI must download only this version of the parameters.
631 5.4.5. For the action Delete, DataSetIdentification.Type and DataSetIdentification.Name must be
632 present.
633 If Type contains the value ApplicationParameters, the parameters previously received by an
634 AcceptorConfigurationUpdate contained in Content.ApplicationParameters and identified by
635 Content.ApplicationParameters.ApplicationIdentification equals to
636 DataSetIdentification.Name are deleted.
637 If Type contains the value AcquirerParameters, all parameters previously received by an
638 AcceptorConfigurationUpdate contained in Content are deleted.
639 Delete action can only be applied by the MTM or a TM which issued the data to delete
640
641 5.4.6. If the value of DataSetIdentification.Type is not managed by this POI, the action is ignored.
642 This action must be logged in Event and Result must contain the value "NotSupported" and
643 AdditionalErrorInformation, the wrong message element "Action.DataSetIdentification.Type".
644 5.5. If Trigger is present and valid, the possible types of events that can initiate the current action are
645 taken into account. If the value of the Trigger is not supported by the POI, the action must be
646 ignored. This action must be logged in Event with Result containing "NotSupported" and
647 AdditionalErrorInformation the text value "Action.Trigger".
648 5.6. If AdditionalProcess is present, this pre-condition or post-condition is stored for the current action. If
649 the value is not supported by the POI, the error must be logged in Event with Result containing
650 "NotSupported" and AdditionalErrorInformation containing the wrong message element
651 "Action.AdditionalProcess"; Action must be ignored.
652 5.7. If TimeCondition is present, its content is checked to determine whether the data element are
653 correctly formatted. If the format of a timing parameter in TimeCondition is not correct according to
654 the ISODateTime format or the value of StartTime or EndTime is wrong (e.g. dd > 31; mm-dd = 02-
655 30), the complete management plan of the Terminal Manager Identification is discarded and an error
656 must be added in the log of Event with Result containing "FormatError".
657 If the StartTime or the complete TimeCondition is missing for the first action defined for a
658 TerminalManagerIdentification, the StartTime of this action is set to the current date and time plus
659 WaitingTime if set.
660 If TimeZone is not present in StartTime or EndTime, then the POI local time must be assumed. In the
661 example of 2017-04-06T21:15:00, the terminal will process in its own time.
662 If a TimeZone is provided, the terminal must take in account the Time Zone. The example of 2017-04-
663 06T21:15:00.000-05:00, when the terminal is at UTC-8, the StartTime will be 2017-04-06T18:15:00.
664 2017-04-06T21:15:00.000-05:00 is 2017-04-07T02:15:00Z, and therefore it's 2017-04-
665 06T18:15:00.000-08:00.
666 If a TimeZone is in zulu time, in this StartTime example, 2017-04-06T21:15:00Z, a terminal in UTC-5,
667 will use 2017-04-06T16:15:00.
668 It is recommended that the MTM manages the clock synchronization. There should only be one
669 manager of the clock time. If a POI receives a StartTime or an EndTime with a TimeZone and is not
670 aware of its own TimeZone, the complete management plan of the Terminal Manager Identification is
671 discarded and an error must be added in the log of Event with Result containing "FormatError".
672 If StartTime and WaitingTime or the complete TimeCondition are missing for an action defined for a
673 TerminalManagerIdentification, the action should be started as soon as possible.
103 Page 49
674
675 Subsequently all other present data elements are checked and stored.
676 5.8. The error actions to be performed are stored with the related management plan action. If an error
677 occurs while performing a management plan action, the POI must perform the appropriate error
678 action defined for the ActionResult of the error.
679 5.8.1. For a known ActionResult (defined in the code set) that is not managed in the ErrorAction:
680  If an ActionResult of “AnyError” is defined, then the error action associated to the
681 ActionResult of “AnyError” must be performed.
682  If an ActionResult of “AnyError” is not defined, then the error must be ignored by the POI.
683 5.8.2. For an unknown ActionResult (not defined in the code set) that is not managed in the
684 ErrorAction:
685  If an ActionResult of “UnlistedError” is defined, then the error action associated to the
686 ActionResult of “UnlistedError” must be performed.
687  If an ActionResult of “UnlistedError” is not defined, then the error must be ignored by the
688 POI.
689 Note: A TM should send an ErrorAction with an ActionToProcess of "SendStatusReport" defined for
690 all ActionResults by default for each management plan. This allows the TM to define the sending of a
691 StatusReport as the default behaviour for a POI in the event of an error.
692 6. The downloaded management plan replaces all actions defined for this specific TM (MTM or not).
693 7. The POI erases the contents of the existing log of Event per TM, if the log has been sent to the TM.
694 8. Subsequently, the POI starts the execution of the management plan (see section 4.4).
695
696
105 Page 50
697
698 4.4 Execution of the Management Plan

699 The following rules are defined for the execution of the management plan:
700
701 MNG1: There is one management plan per MTM and one per TM. Each management plan is
702 processed separately.
703
704 Inside a list of Actions sharing the same TerminalManagerIdentification, a sequence of actions is defined as
705 a list of actions with the first action containing a StartTime and each following actions a WaitingTime.
706
707 MNG2: An action including a Retry has to be finished before starting another action or moving to the
708 next management plan (group of Actions with a different TerminalManagerIdentification). So it
709 is not possible to execute two actions in parallel. A sequence of actions has to be finished
710 before starting a subsequent action of the management plan or new management plan.
711 MNG3: If an action of a sequence contains a Period, this action and possible following actions of the
712 sequence (defined with a WaitingTime) are executed periodically. Otherwise the action is
713 executed only once.
714 MNG4: The management plan may contain only one sequence with an action containing a period.
715 MNG5: A sequence may contain only one action with a period.
716 MNG6: When a StartTime is reached the Action must be launched. However, if a StartTime is reached
717 during the execution of a former Action, the action must be executed once all previous actions
718 have finished.
719 MNG7: If several actions of the management plan for a dedicated TerminalManagerIdentification
720 contain a StartTime these actions have to be listed in chronological order.
721 MNG8: For message exchange, a StatusReport must be sent explicitely for each of the
722 DataSetRequired items defined in the ManagementPlan
723 MNG9: If an Action is, whatever the reason (e.g Retry or WaitingTime), outside the time slot dedicated
724 for the maintenance plan defined through the DelegationScopeDefinition, the management
725 plan of this TM must be completed. This case must be logged in Event with Result containing
726 "Success" and AdditionalErrorInformation the text value “Time period exceeded".
727 MNG10: A management plan for a TM must not start before the time slot defined in the
728 DelegationScopeDefinition.
729
730 TMS actions are executed sequentially inside time slot according to StartTime or WaitingTime.
731 1. The timing conditions of each TMS action are analysed:
732 a. If StartTime has expired or WaitingTime is 0, the action must be started after execution of
733 the ManualConfirmation or Reconciliation if they are present in the AdditionalProcess. At the
734 end of the action, the RestartSystem is triggered if present in the AdditionalProcess. The
735 RestartSystem is a reboot which may occured after external conditions (e.g
736 acknowledgement of the ECR). After the execution of the reboot, the POI then moves to the
737 next action.
738 b. If StartTime has been sent and is not reached, the execution of the management plan for
739 this dedicated TerminalManagerIdentification is paused until StartTime is reached and in the
740 meantime POI considers the management plan of the next TerminalManagerIdentification.
107 Page 51
741 c. If WaitingTime has been sent and is not equal to 0, the POI waits for WaitingTime
742 2. If TimeCondition of the started action contains Period, the new StartTime is calculated and stored in
743 the management plan of this Terminal Manager. If Period is missing or the action is not part of a
744 sequence, the action must not be executed anymore.
745 3. After execution of an action the next action is analysed. The next action is executed
746 a. if the StartTime is passed or
747 b. if the WaitingTime is reached.
748
749 4.4.1 One-Time Call to the Maintenance Example

750 In the following management plan example, the POI performs only one message exchange for the
751 StatusReport upload and ManagementPlanReplacement download when the StartTime T0 is reached.
752
StartTim WaitingTime Period Type DataSetIdentification.Name DataSetIdentification.Type
e
T0 - - Download any name ManagementPlan
753 Identification in DataSetRequired of StatusReport is set to "ManagementPlan".

754
755 4.4.2 Cyclic Call and Acquirer Parameters Download Examples

756
757 The first example describes a cyclic call to the maintenance. This is the typical case for a
758 managementPlanReplacement where TMS requires only to be recall periodically.
759
e
T0 - Cycle1 Download any name ManagementPlan
760
761 The first call is started when StartTime T0 is reached. The POI sends a StatusReport message containing
762 DataSetRequired with the same value than DataSetIdentification of the action. The TM or the MTM sends
763 back a ManagementPlanReplacement message.
764
765 In the case where there is nothing new to be downloaded by TMS, the exchange look like this
109 Page 52
766
767 Figure 1 : StatusReport with no change on the ManagementPlan
768
769 In case where new parameters are prepared for downloading (let say Acquirer parameters), a new
770 Management Plan is sent to POI
e
- - - Download -any first name AcquirerParameters
- - Cycle1 Download -any second name ManagementPlan
771
772 And the exchange looks like this
773
774 Figure 2 : StatusReport with change on ManagementPlan and AcceptorConfigurationUpdate.
775
776 The following calls are performed periodically using Period defined by "Cycle1", with the same exchange of
777 messages described in Figure 1 : StatusReport with no change on the ManagementPlan.
778
111 Page 53
779 4.4.3 Cyclic Call after an Acquirer Parameters Download Examples

780 This example presents a sequence of actions with the download of Acquirer parameters followed by a cyclic
781 call.
782 The management plan is processed in the following way:
783 When StartTime T1 is reached, a StatusReport message is sent to request AcquirerParameters. The TM or
784 MTM sends back an AcceptorConfigurationUpdate message containing the whole set of acquirer
785 parameters. The Restart of the POI application with the installed parameters is initiated by the
786 AdditionalProcess.
787 After the waiting time D2, a StatusReport message is sent to request a new management plan.
788 Repeat the last action periodically using Period defined by "Cycle2".
789
e
T1 - - Download - AcquirerParameters
- D2 Cycle2 Download - ManagementPlan
790
791 4.4.4 Sequence of Parameters Downloads Example

792 According to the following example the POI performs the sequence of actions:
793  Delete all acquirer parameters installed for this TMIdentification if the StartTime T0 is reached.
794 Repeat this action after the time period of T0+Cycle1, T0+Cycle1+Cycle1 etc.
795  Download the AcceptorConfigurationUpdate, if the action before is finished with a WaitingTime of
796 D1. Repeat this action accordingly to the first action.
797  Download the AcceptorConfigurationUpdate, if the action before is finished with a WaitingTime of
798 D2. Repeat this action accordingly to the first action.
799  Restart the POI application with the already installed parameters or install parameters during the
800 restart if the action before is finished with a WaitingTime =0. Repeat this action accordingly to the
801 previous action. This function may also be realised with AdditionalProcess equal to Restart in the
802 previous action. Note that a Restart in the AdditionalProcess means a reboot of the terminal..
803  Upload StatusReport if the action before is finished with a WaitingTime of D4 as request message.
804 The response message contains the new management plan.
805
StartTim WaitingTim Period Type DataSetIdentification.Nam DataSetIdentification.Type
e e e
T0 - Cycle1 Delete - AcquirerParameters
D1 - Download - AcquirerParameters
- D2 - Download - ApplicationParameters
- - - Restart - -
- D4 - Download - ManagementPlan
806 4.4.5 Sequence of Upload action Example

807 According to the following example the POI performs the sequence of actions:
808  Generates after T0 a unique CertificateManagementRequest message to the TM, for a
809 SecurityDomain named “MyPKI”,
113 Page 54
810  After T1
811 o Upload a first log file of the terminal named “LifeCounters”
812 o After D1, upload a second log file of the terminal named "Battery"
813 o After D2, send a StatusReport. The response message may contain a new management
814 plan.
815 o If no management plan has been received, the POI repeats this sequence with a “cycle1”
816 periodicity
817
StartTim Waiting Period Action. MessageItem. DataSetIdentification.Type
e Time Type ItemIdentification
T0 - Upload MyPKI CertificateManagementRequest
T1 Cycle1 Upload LifeCounters LogFile
- D1 - Upload Battery LogFile

- D2 - Download - ManagementPlan
818
819 4.5 Error Handling during Management Plan Execution

820 The management plan is executed action by action. If an action has been performed successfully, it is added
821 in the log of Event of the dedicated Terminal Manager Identification and of the Master Terminal Manager if
822 they are different, with Result containing the value "Success" and, if no Period is defined to repeat this
823 action, the action is not performed anymore. The AdditionalErrorInformation that will be sent to the Master
824 Terminal Manager must contain the identification of the TerminalManager.
825 The management plan may contain for each TMS action a list of ErrorAction. If no ErrorAction is defined, all
826 errors during the processing of this action won’t trigger any specific processing on the POI which must go to
827 the next action in sequence.
828 By using ActionResult, the TMS may define which reaction has to be performed for one specific error type or
829 a range of error types. The following subset of the reactions has to be supported as defined in
830 ActionToProcess:
831  "SendStatusReport": Log the result of the action with the related error and upload a StatusReport
832 immediately to the related Terminal Manager, without executing next actions
833  "StopSequence": Stop the current sequence of terminal management actions without any action, and
834 do not notice the error by sending a status report.
835 There are several error conditions possible during the execution of a Management plan.
836 1. If the file to be downloaded does not exist in the file directory, the action is added to the event log
837 with Result containing "MissingFile".
838 2. If the POI is unable to connect to the TMS for a specific action, the action is added to the event log
839 with Result containing "ConnectionError" and AdditionalErrorInformation containing the number of
840 retries.
841 3. If the communication is terminated during an action, the action is added to the event log with Result
842 containing "ConnectionError" and AdditionalErrorInformation containing the text value
843 "Communication terminated".
844 4. If the connection of POI, in order to download a file,is rejected by the TMS due to access rights, the
845 action is added to the event log with Result containing "AccessDenied" and
846 AdditionalErrorInformation containing the text value "File".
115 Page 55
847  In case of error during the upload of the log file, an Event is recorded in the event log with Result
848 containing the relevant value and AdditionalErrorInformation must contain the logical name of the
849 requested file.
850
851

853
855
856
Number
C1 DataSet.Content.Action.TerminalManagerIdentificat  DataSet.Content.Action.TerminalManagerIdentificati
ion must be present if different from on
ManagementPlan.TerminalManagerId.Identification  ManagementPlan.TerminalManagerId.Identification
and ManagementPlan.TerminalManagerId.Type =
MasterTerminalManager, or must be absent
otherwise
C2 DataSetIdentification must be present if Action.Type  DataSet.Content.Action.Type
is Delete, Update, Upload, Install or Download, and  DataSet.Content.Action.DataSetIdentification
must be absent if Action.Type is Restart, Bind,
Rebind, Unbind
C3 If Action.Type is Delete DataSetIdentification.Type  DataSet.Content.Action.Type
must be set amongst AcquirerParameters,  DataSet.Content.Action.DataSetIdentification.Type
ApplicationParameters, MerchantParameters,
Parameters, SecurityParameters,
TerminalParameters
C4 If Action.Type is Update, DataSetIdentification.Type  DataSet.Content.Action.Type
must be set amongst AcquirerParameters,  DataSet.Content.Action.DataSetIdentification.Type
ApplicationParameters, MerchantParameters,
Parameters, TerminalParameters
C5 If Action.Type is Download,  DataSet.Content.Action.Type
DataSetIdentification.Type must be set amongst  DataSet.Content.Action.DataSetIdentification.Type
AcquirerParameters, ApplicationParameters,
ManagementPlan, MerchantParameters,
Parameters, SecurityParameters, SoftwareModule,
TerminalParameters
C6 If Action.Type=Upload and  DataSet.Content.Action.Type
DataSetIdentification.Type different from "LogFile"  DataSet.Content.Action.DataSetIdentification.Name
and "CertificateManagementRequest", the 3
 DataSet.Content.Action.DataSetIdentification.Type
elements DataSetIdentification.Name,
DataSetIdentification.Version,  DataSet.Content.Action.DataSetIdentification.Versio
DataSetIdentification.CreationDateTime must be n
absent,  DataSet.Content.Action.DataSetIdentification.Creati
If Action.Type= Upload and onDateTime
DataSetIdentification.Type = ”LogFile" or
”CertificateManagementRequest", the
DataSetIdentification.Name, must be present
C7 If Action.Type is Install, DataSetIdentification.Type  DataSet.Content.Action.Type
must be set to SoftwareModule  DataSet.Content.Action.DataSetIdentification.Type
C8 TimeCondition must be present, if trigger is Date  DataSet.Content.Action.Trigger
and Time  DataSet.Content.Action.TimeCondition
C9 If WaitingTime is present, then StartTime must be  DataSet.Content.Action.TimeCondition.WaitingTime
absent. If WaitingTime is absent, then StartTime  DataSet.Content.Action.TimeCondition.StartTime
must be present
C10 Period and MaxNumber must be present or absent  DataSet.Content.Action.TimeCondition.Period
together  DataSet;Content.Action.TimeCondition.MaximumNu
117 Page 56
mber
C11 All Actions for a TerminalManagerIdentification must  DataSet.Content.Action.TerminalManagerIdentificati
be grouped by ascending on.Identification
TerminalManagerIdentification
C12 If Action.Type=Download,and  DataSet.Content.Action.Type
DataSetIdentification.Type=”ManagementPlan’, the  DataSet.Content.Action.DataSetIdentification.Name
3 elements DataSetIdentification.Name,
DataSetIdentification.Version,
DataSetIdentification.CreationDateTime must be  DataSet.Content.Action.DataSetIdentification.Versio
absent n
 DataSet.Content.Action.DataSetIdentification.Creati
onDateTime
C13 If Action.Type=Download or Delete, and  DataSet.Content.Action.Type
DataSetIdentification.Type is not equal to  DataSet.Content.Action.DataSetIdentification.Name
'ManagementPlan’, DataSetIdentification.Name
must be present
C14 If Action.Type= Install or Update,and  DataSet.Content.Action.Type
DataSetIdentification.Type is not equal to  DataSet.Content.Action.DataSetIdentification.Name
’ManagementPlan’, one of the
 DataSet.Content.Action.DataSetIdentification.Versio
DataSetIdentification.Name,
n
DataSetIdentification.Version,
DataSetIdentification.CreationDateTime must be  DataSet.Content.Action.DataSetIdentification.Creati
present onDateTime
C15 
C16 If MessageItem is present then Action.Type must  DataSet.Content.Action.Type
equal to Upload, and DataSetIdentification.Type  DataSet.Content.Action.DataSetIdentification.Type
must be equal to ”StatusReport" or
 DataSet.Content.Action.MessageItem
“CertificateManagementRequest”.
C17 A MessageItem.Value must be present if  MessageItem.Condition
MessageItem.Condition is ConfiguredValue or  MessageItem.Value
AllowedValue
C18 More than 1 MessageItem.Value must be present if  MessageItem.Condition
MessageItem.Condition is AllowedValue  MessageItem.Value
C19 If MessageItem.Condition is NotSupported,  MessageItem.Condition
Mandatory or IfAvailable then MessageItem.Value is  MessageItem.Value
absent
C20 If Action.Type is equal to “Upload” and  Action.Type
Action.DataSetIdentification.Type equal “LogFile”  Action.DataSetIdentification.Type
then Action.TMSProtocol,
 Action.TMSProtocol
Action.TMSProtocolVersion and
Action.RemoteAccess must be defined  Action.TMSProtocolVersion
 Action.RemoteAccess
857
858
859
119 Page 57
860 5 AcceptorConfigurationUpdate (catm.003)

861

863
864 The AcceptorConfigurationUpdate message contains the following information:
865
Lvl AcceptorConfigurationUpdate Mult. Rule Cstr Usage
]
2 DownloadTransfer [1..1 * True
]
2 ExchangeIdentification [1..1 Unique identifier for the InitiatingParty to
] detect duplication of the
AcceptorConfigurationUpadet file transfer, or
to assign a AcceptorConfigurationUpdate
response message to the StatusReport
request message.
Cyclic counter that increments by one with
each new transfer between the InitiatingParty
and the RecipientParty.
<XchgId>::Number
]
]
<InitgPty>
]
<Id>::Max35Text
3 Type [0..1 * In case of message exchange the allowed
] value is "OriginatingPOI".
In case of file transfer; allowed values are:
"TerminalManager"
or "MasterTerminalManager" .
]
121 Page 58

]
3 ShortName [0..1 Appli See ManagementReplacement
]
<ShrtNm>::Max35Text
2 RecipientParty [0..1 Appli See StatusReport
]
<RcptPty>
]
<Id>::Max35Text
3 Type [0..1 * Message exchange: allowed values are
] "MasterTerminalManager" and
"TerminalManager".
In case of File transfer: "OriginatingPOI "
]
]
]
<ShrtNm>::Max35Text
3 RemoteAccess [0..1 Access information to reach the target host.
] (see StatusReport).
<RmotAccs>
1 AcceptorConfiguration [1..1 AcceptorConfigurationUpdate message body
]
<AccptrCfgtn>
2 TerminalManagerIdentification [1..1 <TermnlMgrId>
]
]
<Id>::Max35Text
3 Type [0..1 Appli * Allowed values: "MasterTerminalManager" or
] C28 "TerminalManager".
123 Page 59

3 Issuer [0..1 Appli * See ManagementReplacement
]
]
]
<ShrtNm>::Max35Text
2 DataSet [1..*] The POI has to process several data sets, if
present.
<DataSet>
3 Identification [1..1 Identification of the data set
]
<Id>
4 Name [0..1 Name of the data set
]
<Nm>::Max256Text
]
"AcquirerParameters":
AcquirerProtocolParameters,
HostCommunicationParameters,
ApplicationParameters and
MerchantParameters are present if they
need to be created or replaced.
"ApplicationParameters" if only
ApplicationParameters is present.
"MerchantParameters" if only
MerchantParameters is present.
"Parameters" for any combination of
parameters in the message.
"TerminalParameters" if only
TerminalParameters is present.
"SecurityParameters" if only
SecurityParameters is present.
4 Version [0..1 Version of the parameters, this value may be
] used in the data element
Acquirer.ParametersVersion of the Acquirer
protocol if the DataSetIdentification.Type is
AcquirerParameters.
<Vrsn>::Max256Text
125 Page 60

4 CreationDateTime [0..1 * Date and time of the creation of the acceptor
] parameters. Time accuracy has to be in
seconds.
This element must be present
3 SequenceCounter [0..1 * <SeqCntr>::Max9NumericText
]
3 POIIdentification [0..*] Appli Identification of the point of interactions
involved by the configuration data set.
<POIId>
]
4 Type [0..1 <Tp>::PartyType5Code
]
4 Issuer [0..1 <Issr>::PartyType6Code
]
4 Country [0..1 <Ctry>::Min2Max3AlphaText
]
4 ShortName [0..1 <ShrtNm>::Max35Text
]
3 ConfigurationScope [0..1 Scope of the configuration contained in the
] data set.
PSYS POISystem
Configuration to apply to the whole POI
system.
PGRP POIGroup
Configuration to apply to a subset of the
whole POI system.
PSNG SinglePOI
Configuration to apply to a single POI
terminal.
<CfgtnScp>::PartyType15Code
3 Content [1..1 <Cntt>
]
4 [0..1 C23 True if the whole configuration related to this
ReplaceConfiguration ] terminal manager must be deleted prior to
taking this new configuration into account.
False if the configuration related to this

terminal manager has to be updated
accordingly to the configuration included in
the message content.
Default value : False.
127 Page 61
<RplcCfgtn>::TrueFalseIndicator
4 [0..*] Configuration parameters of the TMS protocol
TMSProtocolParameters between a POI and a terminal manager.
Since this configuration is optional, it might
happen that a POI needs to use any
subelement of this configuration but hasn't
received or been configured with any value.
In that case, the POI will have to consider the
value labelled DEFAULT in the subelements
of this configuration. Optional values without
any DEFAULT must be considered as absent
or unknown.
<TMSPrtcolParams>
ActionType [1..1 C23 TerminalManagementAction3Code
]
Type of action for the configuration
parameters.
CREA Create
Request to create or add the element
identified inside the message exchange.
UPDT Update
Request to update the element identified
inside the message exchange.
DELT Delete
Request to delete the element identified
inside the message exchange.
DEFAULT value to consider is CREA.
e
[1..1 Identification of the master terminal manager
TerminalManager- ] or the terminal manager.
Identification
<TermnlMgrId>
6 [1..1 DEFAUT value to consider is a space "." or
Identification ] any other preconfigured value inside the POI
<Id>::Max35Text
6 [0..1 DEFAULT values to consider are
Type ] TerminalManager or
MasterTerminalManager.
6 [0..1 DEFAULT values to consider are
Issuer ] TerminalManager or
129 Page 62

Country ]
ShortName ]
5 [0..1 ProtocolVersion identifies which TMS
ProtocolVersion ] protocol version is supported by the Terminal
Manager identified by
TerminalManagerIdentification. If absent, the
version is the value of FormatVersion.
<PrtcolVrsn>::Max8Text
5 [1..*] Maintenance services provided by the
MaintenanceService terminal manager. Allowed values:
"AcquirerParameters" Acquirer
specific configuration
parameters for the point
of interaction (POI)
system.
"ApplicationParameters" Payment
application specific
configuration
of interaction (POI)
system.
“CertificateParameters” Certificate
provided by a terminal
manager.
"MasterTerminalManager" The terminal
manager is the master.
"MerchantParameters" Merchant
configuration
of interaction (POI).
"Monitoring" Monitoring of the
terminal estate.
"SecurityParameters"Point of interaction
parameters related to
the security of software
application and
application protocol.
"SoftwareModule" Software module
update.
"TerminalParameters" Point of
interaction parameters
attached to the
terminal.
“TMSProtocolParameters” Configuration
131 Page 63
parameters for the TMS

protocol.
DEFAULT values to consider are
"AcquirerParameters"
"ApplicationParameters"
"SecurityParameters"
"TMSProtocolParameters"
"HostCommunicationParamet
ers"
<MntncSvc>::DataSetCategory10Code
5 Version [1..1 Version of the TMS protocol parameters.
]
<Vrsn>::Max256Text
5 [0..*] Identification of applications which may be
ApplicationIdentification managed by the TM, partially or globally.
DEFAULT values to consider are all
ApplicationIdentification of all application
residing inside the POI.
<ApplId>::Max35Text
5 [1..1 Identification of the terminal manager host.
HostIdentification ]
DEFAULT values to consider are
TerminalManager or
<HstId>::Max35Text
5 [0..1 C28 Only the MTM is allowed to set this value.
POIIdentification ] Otherwise the message must be rejected and
processed as a formatting error.
DEFAULT value to consider is in case of
MasterTerminalManager, the POI serial
number or any other preconfigured value. In
case of TerminalManager, the
POIIdentification given by the
<POIId>::Max35Text
[0..1 New identification of the initiating party to set
InitiatingParty- ] in TMS messages with this terminal manager.
Identification
<InitgPtyId>::Max35Text
[0..1 New identification of the recipient party to set
RecipientParty- ] in TMS messages with this terminal manager.
Identification
<RcptPtyId>::Max35Text
5 FileTransfer [0..1 When set to True, configuration parameters
133 Page 64

] are exchanged per file transfer protocol rather
than per message, when set to False
configuration parameters are exchanged per
messages.
Default is False.
<FileTrf>::TrueFalseIndicator
5 [0..*] <MsgItm>
MessageItem
6 [1..1 <Cond>::MessageItemCondition1Code
Condition ]
6 [0..*] <Val>::Max140Text
Value
4 [0..*] Acquirer protocol parameters defined per set
of POI applications.
AcquirerProtocolParameters
<AcqrrPrtcolParams>
5 ActionType [1..1 C23 Type of action for the configuration
] parameters.
e
5 [1..*] * Identification of the acquirer protocol
AcquirerIdentification parameters.
AcquirerIdentification must be restricted to
[1..1]
<AcqrrId>
6 [1..1 <Id>::Max35Text
Identification ]
6 [0..1 Appli <Tp>::PartyType3Code
Type ]
6 [0..1 Appli
Issuer ] <Issr>::PartyType4Code
Country ]
6 [0..1 Appli <ShrtNm>::Max35Text
ShortName ]
5 Version [1..1 Version of the Acquirer protocol parameters.
]
<Vrsn>::Max256Text
5 [0..*] Identification of the applications the acquirer
ApplicationIdentification protocol parameters are valid for.
<ApplId>::Max35Text
5 Host [0..*] Repartition of messages per acquirer host.
135 Page 65

For a terminal with online capabilities the
HostIdentification including the
HostCommunicationParameters have to be
installed once.
if ‘host ‘ data element is absent then the POI
may send any caaa messages to every
acquirer hosts known by the POI.
<Hst>
6 [1..1 Identification of the host used also in
HostIdentification ] HostCommunicationParameters.
<HstId>::Max35Text
6 [0..*] List of MessageFunction to be sent to the
MessageToSend host (the message "DiagnosticRequest" must
be accepted by all hosts, even if not present
in this list). Allowed values:
"AuthorisationRequest": Request for
authorisation without financial capture.
"BatchTransfer": Transfer the financial data
as a collection of transction.
"CancellationRequest": Request for
cancellation.
"CancellationAdvice": Advice for
cancellation.
"CompletionAdvice": Advice for completion
without financial capture.
"CurrencyConversionRequest": Request for
currency conversion.
"DiagnosticRequest": Request for diagnostic.
"FinancialAuthorisationRequest": Request
for authorisation with financial capture.
"FinancialCompletionAdvice": Advice for
completion with financial capture.
"FinancialReversalAdvice": Advice for
reversal with financial capture.
"ReconciliationRequest": Request for
reconciliation.
"ReversalAdvice": Advice for reversal
without financial capture. To workaround
an editorial error, the coding to use for
ReversalAdvice is REVV
If Host is present and MessageToSend is
absent, then no caaa messages except
DiagnosticRequest could be sent to the
Host.
137 Page 66
<MsgToSnd>::MessageFunction15Code
6 [0..1 ProtocolVersion identifies which Acquirer
ProtocolVersion ] protocol version is supported by the Host
identified by HostIdentification. If absent, the
version is the value of FormatVersion.
5 [0..1 Configuration for data capture and completion
OnLineTransaction ] procedure of online authorised transactions
If absent, the financial capture for online
transaction is not performed by the acquirer
protocol
<OnLineTx>
6 [1..1 C1 Definition of capture mechanism for online
FinancialCapture ] C5 authorised transactions, allowed values:
"Authorisation": financial capture performed
with an authorisation exchange.
"Completion": financial capture performed
with a completion exchange.
"Batch": financial capture performed by
batch transfer.
<FinCaptr>::FinancialCapture1Code
6 [0..1 C1 If the Online Transactions are captured
BatchTransfer ] through Batch the structure must be present.
.
<BtchTrf>
7 [1..*] * The following policies for the capture
ExchangePolicy procedure by Batch Transfer are allowed:
C2
"Cyclic": Batch sent periodically according
C3
to TimeCondition ,
C4
"NumberLimit": Batch sent when the number
of non-captured online authorised
transaction reaches MaximumNumber, as
well as
"TotalLimit": Batch sent when the total
amount of non-captured online authorised
transaction reaches MaximumAmount.
"OnDemand": Batch exchange is performed
if requested by the acquirer in the previous
exchange, or manually by the acceptor. If
no other ExchangePolicy is present,
OnDemand must be present. The
ExchangePolicy “OnDemand” must always
139 Page 67
be allowed on the POI even if this policy is

not present.
and all combinations of these policies.
<XchgPlcy>::ExchangePolicy1Code
7 [0..1 C2 Maximum number of online transactions
MaximumNumber ] (debit and credit) used as trigger for batch
transfer. Failed, declined or cancellations are
not included in the number of transactions,
but debit (or credit) which are cancelled are
part of the counting.
Mandatory if at least one ExchangePolicy =
"NumberLimit" exists, otherwise absent.
<MaxNb>::Number
7 [0..1 C3 Maximum cumulative amount of online
MaximumAmount ] transactions (debit and credit) used as
trigger for batch transfer. Failed, declined or
cancellations are not included in the
cumulative amount, but debit (or credit) which
are cancelled are part of the cumulative
amount.
"TotalLimit" exists, otherwise absent.
For instance a credit of 10 € and a debit of 8
€ imply a cumulative amount of 18 €.
<MaxAmt>::ImpliedCurrencyAndAmount
7 [0..1 Retry after a failed batch transfer
ReTry ]
<ReTry>
8 [1..1 Time between two successive attempts after
] a failed batch transfer.
Delay
Format: MMDDhhmm; leading zeros may be
omitted.
[0..1 Maximum number of attempts.
]
MaximumNumber <MaxNb>::Number
7 [0..1 C4 Mandatory if at least one ExchangePolicy =
TimeCondition ] "Cyclic" exists, otherwise absent.
<TmCond>
8 [0..1 C4 Date and time after which Batch transfer is
] allowed
StartTime
8 [0..1 Date and time after which Batch transfer is
141 Page 68

] prohibited.
EndTime
8 [0..1 C4 Period of the cyclic batch transfer.
]
Format: MMDDhhmm; leading zeros may be
Period
omitted.
6 [0..1 C5 Configuration of the completion exchange.
CompletionExchange ]
Mandatory if FinancialCapture equals to
"Completion", otherwise optional. .
<CmpltnXchg>
7 [1..*] * Policies for a completion exchange. Allowed
ExchangePolicy values are:
C6
"AsGroup": All completion messages are
C7
sent as a series of messages if the trigger
C8 in TimeCondition is met.
"Immediately": Exchange starts after the
online transaction
"NumberLimit": Exchange starts after a fixed
number of online transactions is reached.
MaximumNumber must be present
otherwise the exchange starts immediately.
"OnDemand": Exchange only occurs when
CompletionRequired in the
AcceptorAuthorisationResponse message
is set to "True". This value is allowed only if
FinancialCapture is different from
"Completion". If no other ExchangePolicy is
present, OnDemand must be present. The
ExchangePolicy “OnDemand” must always
be allowed on the POI even if this policy is
not present.
"TotalLimit": Exchange starts as a group of
transactions after the online transaction
totals exceed a certain amount limit.
MaximumAmount must be present
Each combination of these policies is
allowed.
7 [0..1 C6 Maximum number of online transactions used
MaximumNumber ] as trigger for completions sent as group of
messages.
143 Page 69

<MaxNb>::Number
7 [0..1 C7 Maximum amount used as trigger for
MaximumAmount ] completions sent as group of messages.
"TotalLimit" exists, otherwise absent. Sum of
the amount of all online transactions (debit
and credit).
7 [0..1 Definition of retransmissions for completion
ReTry ] exchange
<ReTry>
8 [1..1 Time period to wait between two successive
] attempts if the completion sending failed.
Delay
omitted.
[0..1 Maximum number of retransmissions
]
TimeCondition ] "AsGroup" exists, otherwise must be absent.
<TmCond>
8 [0..1 C8 Date and time after which completion
] message is sent.
StartTime
8 [0..1 Date and time after which sending completion
] exchange is prohibited
EndTime
8 [0..1 C8 Period of time between the sending of 2
] completion messages.
Period
omitted.
7 [0..1 default "False"
ExchangeFailed ]
This flag indicates that Completion messages
of failed transactions have to be exchanged (
<XchgFaild>::TrueFalseIndicator
ExchangeDeclined ]
of online declined transactions, or declined
145 Page 70
after the authorisation has to be exchanged.
<XchgDclnd>::TrueFalseIndicator
6 [0..1 default "Advice"
CancellationExchange ]
Configuration of the cancellation exchanges
for online authorised transactions.
“NotAllowed” Card payment transaction
cannot be cancelled by the
acquirer.
“Advice” Card payment transaction may
be cancelled by an advice only.
“Request” Card payment transaction must
be cancelled by a cancellation
request exchange.
<CxlXchg>::CancellationProcess1Code
5 [0..1 Configuration for data capture and completion
OffLineTransaction ] procedure of offline authorised transactions
If absent, the financial capture of offline
transaction is not performed by the acquirer
protocol
<OffLineTx>
6 [1..1 * Definition of capture mechanism for offline
FinancialCapture ] C9 authorised transactions, allowed values:
"Completion": financial capture performed as
part of the completion exchange.
"Batch": financial capture performed by
batch transfer.
<FinCaptr>::FinancialCapture1Code
6 [0..1 C9 If Configuration of FinancialCapture is equal
BatchTransfer ] to "Batch", the structure must be present.
.
<BtchTrf>
7 [1..*] * Policy for a financial capture procedure by
ExchangePolicy batch:
C10
"Cyclic": Batch sent periodically according to
C11
TimeCondition
C12
"NumberLimit": Batch starts after a fixed
number of offline non-captured authorised
transactions reaches MaximumNumber .
"TotalLimit": Batch starts after the total
amount of offline non-captured authorised
transactions reaches MaximumAmount.
147 Page 71
"OnDemand": Batch may be exchanged at

the choice of the Acceptor. If no other
ExchangePolicy is present, OnDemand
must be present.
Each combination of "Cyclic", "NumberLimit",
“OnDemand” and "TotalLimit" is allowed.
The ExchangePolicy “OnDemand” must
always be allowed on the POI even if this
policy is not present.
7 [0..1 C10 Maximum number of offline transactions
MaximumNumber ] (debit and credit) used as trigger for batch
transfer. Failed, declined or cancellations are
not included in the number of transactions,
but debit (or credit) which are cancelled are
part of the counting.
<MaxNb>::Number
7 [0..1 C11 Maximum cumulated amount of offline
MaximumAmount ] transactions (debit and credit) used as trigger
for batch transfer. Failed, declined or
amount.
7 [0..1 Retry after a failed batch transfer
ReTry ]
<ReTry>
8 [1..1 Time to wait between two successive
] attempts after a failed batch transfer.
Delay
omitted.
[0..1 Maximum number of attempts.
]
TimeCondition ] "Cyclic" exists, otherwise absent.
<TmCond>
8 [0..1 C12 Date and time after which Batch transfer
149 Page 72

] should occur..
StartTime
8 [0..1 Date and time after which Batch Rransfer is
] prohibited
EndTime
8 [0..1 C12 Period of time for the cyclic batch transfer.
]
Period
omitted.
6 [0..1 * Configuration of the completion message
CompletionExchange ] exchange.
Mandatory if FinancialCapture is equal to
"Completion", otherwise optional. If the
structure CompletionExchange is absent and
the structure OfflineTransaction is present,
the ExchangePolicy of CompletionExchange
is considered to have the value
"Immediately".
<CmpltnXchg>
7 [1..*] Policies for a completion exchange. Allowed
ExchangePolicy C14 values are:
"Immediately": Exchange starts after the
offline transaction
"AsGroup": All completion messages are
sent as a series of messages if the trigger in
TimeCondition is met.
"AsSoonAsPossible": Exchange starts when
the communication resources become
available (e.g. for the next online
transaction if the connection with the
acquirer is down).
"NumberLimit": Exchange starts after a fixed
number of offline transactions is reached.
MaximumNumber must be present
"TotalLimit": Exchange starts as a group of
transactions after the offline transaction
totals exceed a certain amount limit.
MaximumAmount must be present
Each combination of "AsGroup",
"NumberLimit" and "TotalLimit" is allowed.
7 [0..1 C15 Maximum number of offline transactions to be
151 Page 73

MaximumNumber ] reached before completion messages are
sent as a group of messages.
<MaxNb>::Number
7 [0..1 C16 Maximum amount of offline transactions (sum
MaximumAmount ] of the totals for debit and credit transactions)
to be reached before completion messages
are sent as a group of messages.
7 [0..1 Definition of retransmissions for completion
ReTry ] exchange.
<ReTry>
8 [1..1 Time period between two successive
] attempts if the completion sending has failed.
Delay
omitted.
[0..1 Maximum number of retries.
]
TimeCondition ] "AsGroup" exists, otherwise must be absent.
<TmCond>
8 [0..1 Date and time after wich a completion
] messages should be sent.
StartTime
8 [0..1 Date and Time after which Completion
] Exchange is prohibited
EndTime
8 [0..1 Period between 2 exchanges of messages by
] group.
Period
omitted.
[0..1 default "False"
ExchangeFailed ]
of failed offline transactions have to be
153 Page 74
exchanged.
<XchgFaild>::TrueFalseIndicator
[0..1 default "False"
ExchangeDeclined ]
of offline declined transactions have to be
exchanged.
<XchgDclnd>::TrueFalseIndicator
[0..1 default "Advice"
CancellationExchange ]
Configuration of the cancellation exchanges
for offline authorised transactions.
“NotAllowed” Card payment transaction
cannot be cancelled by the
merchant.
“Advice” Card payment transaction may
be cancelled by an advice only.
“Request” Card payment transaction must
be cancelled by a cancellation
request exchange.
<CxlXchg>::CancellationProcess1Code
5 [0..1 Configuration of reconciliation exchange. If
ReconciliationExchange ] the structure is absent, the ExchangePolicy of
ReconciliationExchange is considered to
have the value "None".
<RcncltnXchg>
6 [1..*] C18 Policies for the reconciliation exchange,
ExchangePolicy allowed values:
“Cyclic": Reconciliation is exchanged
periodically according to the
TimeCondition.
"None": Reconciliation is never exchanged.
"NumberLimit": Reconciliation is exchanged
after a fixed number of transactions. The
element MaximumNumber must be present
to define the maximum number otherwise
the message exchange is started
immediately.
"OnDemand": Reconciliation is exchanged at
the choice of the Acceptor. If no other
ExchangePolicy is present, OnDemand
must be present. The ExchangePolicy
“OnDemand” must always be allowed on
the POI even if this policy is not present.
"TotalLimit": Reconciliation is exchanged if
the total amount of transactions exceeds a
155 Page 75
limit of amount the completions are sent as

group. The message element
MaximumAmount must be present the
reconciliation is not performed.
Each combination of "Cyclic", "NumberLimit",
“OnDemand” and "TotalLimit" is allowed.
6 [0..1 C19 Maximum number of all transactions (debit
MaximumNumber ] and credit) as trigger for reconciliation. Failed,
declined or cancellations are not included in
the number of transactions, but debit (or
credit) which are cancelled are part of the
counting.
<MaxNb>::Number
6 [0..1 C20 Maximum cumulative amount of all
MaximumAmount ] transactions (debit and credit) as trigger for
reconciliation. Failed, declined or
amount.
6 [0..1 Definition of retransmissions for reconciliation
ReTry ] exchange.
<ReTry>
7 [1..1 Time period to wait between two successive
Delay ] attempts if the reconciliation sending has
failed.
omitted.
[0..1 Maximum number of retries.
MaximumNumber ]
<MaxNb>::Number
6 [0..1 C21 Timing conditions for reconciliation exchange.
TimeCondition ]
"Cyclic" exists, otherwise absent.
<TmCond>
7 [0..1 Date and time after which a reconciliation
157 Page 76

StartTime ] exchange should occur. If the transaction
capture is made through completion, this
parameter should be set prior to the POI date
of service to avoid uncaptured transactions.
7 [0..1 Date and time after which a Reconciliation is
EndTime ] prohibited. If the transaction capture is made
through completion, this parameter should
not be set to avoid uncaptured transactions
unless the POI is to be taken out of service.
7 [0..1 Period between 2 reconciliation exchanges.
Period ]
omitted.
5 [0..1 Indicator whether reconciliation period will be
ReconciliationByAcquirer ] defined by the acquirer. In this case the
acquirer protocol response message must
contain the ReconciliationIdentifier.
default “False”
<RcncltnByAcqrr>::TrueFalseIndicator
5 [0..1 Indicator whether reconciliation totals have to
TotalsPerCurrency ] be calculated per currency.
default “False”
<TtlsPerCcy>::TrueFalseIndicator
5 SplitTotals [0..1 default "False"
]
The flag indicates that totals in reconciliation
or batch must be split per POIGroup and
CardProductProfile according to the presence
of these informations in the messages of the
transaction.
<SpltTtls>::TrueFalseIndicator
5 [0..1 After an error in a totals of the Reconciliation,
ReconciliationError ] the POI sends transactions in error in the
BatchTransfer messages.
default “False”
<RcncltnErr>::TrueFalseIndicator
CardDataVerification ]
When True, an AcceptorCompletionAdvice
following an authorisation exchange must
contain either CardProtectedData or
PlainCardData.
159 Page 77
If False, an AcceptorCompletionAdvice
following an authorisation exchange must not
contain CardProtectedData and
PlainCardData.
<CardDataVrfctn>::TrueFalseIndicator
5 [0..1 default: "False"
NotifyOffLineCancellation ]
Send a cancellation advice for offline
transactions not yet captured.
<NtfyOffLineCxl>::TrueFalseIndicator
5 [0..*] C24 Types of transaction to be present in batch
BatchTransferContent transfer, a combination of one or several
following values:
"DebitCredit": Debit and credit transactions
must be included in the batch.
""Cancellation": Cancellation transactions
"Declined": Non financial declined
transactions must be included in the batch
(i.e. not forced by the merchant).
"Failed": Non financial failed transactions
<BtchTrfCntt>::BatchTransactionType1Code
FileTransferBatch ]
BatchTransfer are exchanged per file transfer
protocol rather than per message.
<FileTrfBtch>::TrueFalseIndicator
BatchDigitalSignature ]
BatchTransfer are authenticated by digital
signature rather than a MAC (Message
Authentication Code).
<BtchDgtlSgntr>::TrueFalseIndicator
5 [0..*] List of message elements and components to
MessageItem be present in the acquirer protocol (see
section 5.3).
<MsgItm>
6 [1..1 Identification of the message element present
ItemIdentification ] in one or several messages of the acquirer
protocol. This is an absolute path (i.e. starting
by the message envelope) or a relative path
to the message element with the XML tags
separated by the character '/' (e.g. the
absolute path
161 Page 78

/AccptrAuthstnReq/Hdr/RcptPty and
the relative path Envt/POI/Id/Id).
<ItmId>::Max140Text
6 [1..1 C25 Condition of presence of the related message
Condition ] element, allowed values:
C26
"NotSupported": Message item must be
C27
absent.
*
"Mandatory": Message item must be present
with the POI value.
"ConfiguredValue": Message item must be
present with the content of Value. The
message item must not represent an XML
structure.
.
"AllowedValues": Message item is present
with the content of one of Values. The
message item must not represent an XML
structure.
"IfAvailable": Message item has to be
present if the data is available in the
application.
<Cond>::MessageItemCondition1Code
6 [0..*] C25 Value to be used for the related message
Value element.
C26
C27 Must be absent for the values
"NotSupported", "Mandatory"and "IfAvailable"
of Condition.
Mandatory but not repeated for the value
"ConfiguredValue" of Condition.
Mandatory with possible repetitions for the
value "AllowedValues" of Condition.
<Val>::Max140Text
5 [1..1 "True": Acquirer protocol messages must
ProtectCardData ] protect sensitive card data using the
ProtectedCardData alternative.
"False": Acquirer protocol messages do not
protect sensitive card data using the
PlainCardData alternative.
<PrtctCardData>::TrueFalseIndicator
5 [0..1 <PrvtCardData>::TrueFalseIndicator
PrivateCardData ]
5 [0..1 To set/unset security trailer in acquirer
163 Page 79

MandatorySecurityTrailer ] protocol messages. Defaut value is True to
set security trailer
<MndtrySctyTrlr>::TrueFalseIndicator
4 [0..*] Configuration parameters under the
MerchantParameters responsibility of the merchant.
<MrchntParams>
] parameters.
e
5 [0..1 Identification of the merchant for the MTM, if
MerchantIdentification ] the POI manages several merchants.
<MrchntId>::Max35Text
5 Version [0..1 Version of the merchant parameters.
]
<Vrsn>::Max256Text
5 [0..1 Format of the content of OtherParameters.
ParameterFormatIdentifier ]
<ParamFrmtIdr>::Max8Text
5 Proxy [0..1 Local proxy configuration.
]
<Prxy>
5 [0..1 Merchant parameters.
OtherParameters ]
<OthrParams>::Max10000Binary
4 [0..*] C23 Manufacturer configuration parameters of the
TerminalParameters POI.
<TermnlParams>
5 ActionType [1..1 Type of action for the configuration
] parameters.
e
5 [0..1 Identification of the vendor for the MTM, if the
VendorIdentification ] POI manages various subsets of terminal
parameters.
<VndrId>::Max35Text
5 Version [0..1 Version of the terminal parameters.
]
<Vrsn>::Max256Text
5 [0..1 Format of the content of OtherParameters.
165 Page 80

ParameterFormatIdentifier ]
5 [0..1 Parameters to synchronise the real time clock
ClockSynchronisation ] of the POI
We recommend that only one TM manages
this configuration.
<ClckSynctn>
6 [1..1 Name of the time zone where is located the
POITimeZone ] POI, as definined by the IANA (Internet
Assigned Number Authority) time zone data
base.
<POITmZone>::Max70Text
6 [0..*] Parameters to contact a time server.
SynchronisationServer
<SynctnSvr>
6 [0..1 <Dely>::ISOTime
Delay ]
5 [0..*] Time zone line to update in the time zone
TimeZoneLine data base subset stored in the POI. The
format of the line is conform to the IANA
(Internet Assigned Number Authority) time
zone data base.
<TmZoneLine>::Max70Text
5 [0..*] Local time offset to UTC (Coordinated
LocalDateTime Universal Time).
<LclDtTm>
6 [0..1 Date time of the beginning of the period
FromDateTime ] (inclusive).
<FrDtTm>::ISODateTime
6 [0..1 Date time of the end of the period (exclusive).
ToDateTime ]
<ToDtTm>::ISODateTime
6 [1..1 UTC offset in minutes, of the local time during
UTCOffset ] the period. For instance, 120 for Central
European Time, -720 for Central Standard
Time (North America).
<UTCOffset>::Number
5 [0..1 Others manufacturer configuration
OtherParameters ] parameters of the point of interaction.
<OthrParams>::Max10000Binary
167 Page 81

4 [0..*] Application configuration parameters defined
ApplicationParameters per ApplicationIdentification.
<ApplParams>
] parameters.
e
5 [1..1 Identification of the application defined by the
ApplicationIdentification ] TMS, vendor, merchant or acquirer (e.g. used
for message element POIComponent.Model)
<ApplId>::Max35Text
5 Version [0..1 Appli Version of the application parameters (e.g.
] used for message element
POIComponent.VersionNumber)
<Vrsn>::Max256Text
5 [0..1 Format of the content of Parameters or the
ParameterFormatIdentifier ] deciphered content of EncryptedParameters.
5 Parameters [0..*] C22 Contents of the parameters.
If this data element is absent,
EncryptedParameters must be present.
<Params>::Max100KBinary
5 [0..1 C22 Sensitive parameters (sequence of
EncryptedParameters ] Parameters including the component
identifier) encrypted with a cryptographic key,
using CMS ContentType "EnvelopedData".
If this data element is absent, at least one
occurrence of Parameters must be present.
<NcrptdParams>
[0..*] Configuration parameters related to the
HostCommunication- communication with an acquirer host or a
Parameters terminal manager host.
<HstComParams>
] parameters.
e
5 [1..1 Identification of the host operated by the
HostIdentification ] acquirer or intermediate agent.
169 Page 82

<HstId>::Max35Text
5 Address [0..1 Network parameters of the host.
]
Based on typeNetworkParameters .
<Adr>
5 Key [0..*] Cryptographic key to be used for message
element protection (see section Host
Communication Parameters
<Key>
6 [1..1 Identification of the cryptographic key.
KeyIdentification ]
<KeyId>::Max140Text
6 [1..1 Version of the cryptographic key.
KeyVersion ]
<KeyVrsn>::Max140Text
6 [0..1 Number of usages of the cryptographic key.
SequenceNumber ]
<SeqNb>::Number
6 [0..1 Identification used for derivation of a unique
DerivationIdentification ] key from a master key provided for the data
protection.
<DerivtnId>::Min5Max16Binary
6 [0..1 Type of algorithm used by the cryptographic
Type ] key.
<Tp>::CryptographicKeyType3Code
6 [0..*] Allowed usage of the key.
Function
<Fctn>::KeyUsage1Code
5 [0..1 Access information to reach an intermediate
NetworkServiceProvider ] network service provider.
<NtwkSvcPrvdr>
5 [0..1 <PhysIntrfc>
PhysicalInterface ]
6 [1..1 <IntrfcNm>::Max35Text
InterfaceName ]
6 [0..1 <IntrfcTp>::POICommunicationType2Code
InterfaceType ]
6 [0..1 <UsrNm>::Max35Text
UserName ]
6 [0..1 <AccsCd>::Max35Binary
AccessCode ]
6 [0..1 <SctyPrfl>::Max35Text
171 Page 83

SecurityProfile ]
6 [0..1 <AddtlParams>::Max2KBinary
AdditionalParameters ]
4 [0..*] POI parameters related to the security of
SecurityParameters software application and application protocol.
<SctyParams>
] parameters.
e
5 Version [1..1 Version of the security parameters.
]
<Vrsn>::Max256Text
5 [0..1 Challenge generated by the POI in the
POIChallenge ] StatusReport requesting security parameters
data set.
<POIChllng>::Max140Binary
5 [0..1 Challenge generated by the Terminal
TMChallenge ] Manager to be sent by the POI in the
StatusReport reporting the result of the
security parameters data set download and
installation.
5 [0..*] Based on type CryptographicKey.
SecurityElement
<SctyElmt>
4 [0..*] <SaleToPOIParams>
SaleToPOIParameters
5 ActionType [1..1 <ActnTp>::TerminalManagementAction3Cod
] e
5 [0..1 <MrchntId>
MerchantIdentification ]
6 [1..1 <CmonNm>::Max70Text
CommonName ]
6 [0..1 <Adr>::Max140Text
Address ]
6 [1..1 <CtryCd>::ISO3NumericCountryCode
CountryCode ]
6 [1..1 <MrchntCtgyCd>::Min3Max4Text
MerchantCategoryCode ]
6 [1..1 <RegdIdr>::Max35Text
RegisteredIdentifier ]
]
173 Page 84

5 [1..1 <HstId>::Max35Text
HostIdentification ]
5 [0..1 <MrchntPOIId>::Max35Text
MerchantPOIIdentification ]
5 [0..1 <SaleId>::Max35Text
SaleIdentification ]
1 SecurityTrailer [0..1 Digital signature or MAC of the message
] body AcceptorConfiguration, including the
delimiters (start and end tags if XML
encoding).
message.
<SctyTrlr>
866
175 Page 85

868
869 Inside Acceptor Configuration Update, several elements (e.g MerchantParameters.Version) are named as
870 « version ». In any case, this “version” works as a label to identify parameters, but the element which is
871 processed for knowing if the parameters are to be taken into account or not is the CreationDateTime since it
872 is required to verify than newer version will replace older one. As it is not used for processing, “version” is a
873 free text format where the meaning as to be agreed between producer (TMS) and user (POI).
874
875 The POI System processes the download of the message AcceptorConfigurationUpdate in the following
876 ways:
877 1. If configured the POI checks the signature of the received message. If the signature or the MAC
878 verification fails, the error is stored in the log of Event with Result containing "SignatureError". The
879 AcceptorConfiguration is then deleted from the internal memory of the POI.
880 2. The POI checks whether the dataset category present in Type of Identification sent in the
881 StatusReport corresponds to one of the type received (e.g. AcquirerParameters). If there is no Type
882 corresponding to Identification, the error is stored in the log of Event with the Result containing
883 "InvalidContent" and AdditionalErrorInformation containing the text value "Identification.Type". The
884 AcceptorConfiguration is then deleted from the internal memory of the POI.
885 3. The POI checks CreationDateTime of AcceptorConfigurationUpdate. The POI must only accept a
886 more recent CreationDateTime.
887 Note: The reload of a previous version of a parameter file may be implemented by signing again the
888 file with a new CreationDateTime.
889 4. The structure Content is analysed.
890 a. The content of AcquirerProtocolParameters is described in Section 5.3.
891 b. The content of ApplicationParameters is used to update the data basis for the payment
892 application. If present, ApplicationParameters contain ApplicationIdentification, the Version
893 of the application and Parameters. The content of Parameters is application specific.
894 c. The content of MerchantParameters is used to update the configuration parameters of the
895 POI related to the merchant. The internal structure of the MerchantParameters is merchant
896 specific.
897 d. The HostCommunicationParameters determines Address (NetworkParameters) for each
898 HostIdentification as described in Section Host Communication Parameters.
899 e. The SaleToPOIParameters is used to set all elements required for a connection between the
900 POI and an Electronic Cash Register or an UnAttended Terminal.
901 5. If the POI does not approve any element contained in a DataSet, the POI must log the error in Event
902 with Result containing "InvalidContent". AdditionalErrorInformation indicates the position of the error
903 as a text value. The whole AcceptorConfiguration is then deleted from the internal memory and the
904 former configuration stay valid.
905 If the whole content is correct, the POI replaces or updates the existing parameters by installing and
906 activating the downloaded parameters.
907 Since the POI may receive parameters from different TMs, it should manage these parameters according to
908 the TM Identification, as illustrated by the following figures.
909
177 Page 86
910
911 Figure 3 Parameters management with multiple TM
912
913 So in order to allow multiple TMs to send parameters to POI, the following rules apply:
914 6. If a POI receives a CREATE for a type of Parameter (TMSProtocolParameters,
915 AcquirerProtocolParameters, MerchantParameters, TerminalParameters, ApplicationParameters,
916 HostCommunicvationParameters, SecurityParameters, SaleToPOIParameters) from a TM with
917 previous received parameters of this type, the POI must replace all Parameter of this type coming
918 from this TM. Considering the previous figure as the data structure, previous parameters present in
919 the set identified by the TM identification are deleted and replaced by new ones.
920 7. If a POI receives a CREATE for a type of Parameter (TMSProtocolParameters,
922 HostCommunicvationParameters, SecurityParameters, SaleToPOIParameters) from a TM with no
923 previous received parameters of this type, the POI must create all Parameter of this type coming
924 from this TM. Considering the previous figure as the data structure, a new set of parameter identified
925 by the TM Identification is created.
926 8. If a POI receives an UPDATE for a type of Parameter (TMSProtocolParameters,
928 HostCommunicvationParameters, SecurityParameters, SaleToPOIParameters) from a TM with no
929 previous received parameters of this type, the POI must create all Parameter of this type coming
930 from this TM. Considering the previous figure as the data structure, a new set of parameter identified
931 by the TM Identification is created
935 previous received parameters of this type. If the keyIdentification (MerchantIdentification,
936 VendorIdentification, ApplicationIdentification, HostIdentification) is not known by the POI, the POI
937 must reject the whole set of received Parameters as an “InvalidContent. Considering the previous
938 figure as the data structure, the whole structure is unchanged
942 previous received parameters of this type. If the keyIdentification (MerchantIdentification,
943 VendorIdentification, ApplicationIdentification, HostIdentification) is already known by the POI, ”. the
944 POI must update this Parameter identification of this type with the one coming from this TM.
179 Page 87
945 Considering the previous figure as the data structure, the parameter identified by the key
946 Identification is replaced.
947 11. CREATE and UPDATE are identical for TMSProtocolParameters or SecurityParameters.
948
949 5.3 Acquirer Protocol Parameters

950 AcquirerProtocolParameters may refer to one or more acquirers identified by AcquirerIdentification (acquirer
951 protocol parameters). This set of parameters may also be used for one or a set of POI applications identified
952 by ApplicationIdentification.
953 5.3.1 Configuration of Data Capture and Completion for Online Transactions
954 OnlineTransaction is used for financial data capture, batch transfer and completion exchange configuration.
955 5.3.1.1 Financial Capture

956 FinancialCapture may have one of the following values for online transactions:
957
Value Usage
Authorisation Data capture is part of an authorisation exchange. TransactionCapture is set to True in the related
AcceptorAuthorisationRequest message.
Batch Data capture is part of a batch transfer.
Completion Data capture is part of a completion exchange. TransactionCapture is set to True in the related
AcceptorCompletionAdvice message.
No financial capture or done by other means If OnlineTransaction is absent from the
958
959 If FinancialCapture contains another value than the first three values listed above, the complete DataSet
960 must be ignored and the action may be stored in the log of Event with Result populated with "InvalidContent"
961 and AdditionalErrorInformation containing the text value "OnlineTransaction.FinancialCapture". The value of
962 FinancialCapture before update must be used then if present.
963
964 5.3.1.2 Batch Transfer

965 Should OnlineTransactions.FinancialCapture be equal to "Batch"; BatchTransfer determines the behaviour of
966 the POI for capturing online transactions using ExchangePolicy, MaximumNumber, MaximumAmount and/or
967 TimeCondition. For all other values of OnlineTransactions.FinancialCapture, the element BatchTransfer must
968 be absent.
969 If ExchangePolicy contains a value different from "Cyclic", “OnDemand”, "NumberLimit" or "TotalLimit"; the
970 complete DataSet is ignored and an error may be stored in the log of Event with Result containing
971 "InvalidContent" and AdditionalErrorInformation containing the text value
972 "OnlineTransactions.BatchTransfer.ExchangePolicy".
973 If ExchangePolicy contains either “NumberLimit” or “TotalLimit”, the trigger are evaluated regardless of any
974 other value of ExchangePolicy. Then in case of coexistence, the smaller must trig the ExchangePolicy.
975 If ExchangePolicy contains a time condition, the Batch must be sent without filtering its content. The time
976 condition for OnlineTransaction and OfflineTransaction should be identical.
977
978
181 Page 88
979 ExchangePolicy with "Cyclic" value

980 If ExchangePolicy has the value "Cyclic"; StartTime and Period in TimeCondition are used to define the
981 timing of the cyclic batch transfer. The configuration of BatchTransfer contains an error if one of these
982 elements is missing. The complete DataSet must be ignored and an error may be stored in the log of Event
983 with Result containing "InvalidContent" and AdditionalErrorInformation containing the text value
984 "BatchTransfer.TimeCondition".
985 ReTry is present to define the maximum number and the delay for retries for the batch transfers in case of
986 communication errors. The element EndTime may be used to stop the process of this cyclic batch transfer.
987 MaximumNumber, MaximumAmount and all other elements of TimeCondition must be ignored since these
988 are not used by the “Cyclic” policy but may be relevant for instance for other ExchangePolicy.
989
990 ExchangePolicy with "NumberLimit" value
991 If ExchangePolicy has the value "NumberLimit", MaximumNumber must be present. If this element is missing
992 the configuration of the BatchTransfer contains an error. The complete DataSet must be ignored and the
993 error may be stored in the log of Event with the Result "InvalidContent" with the AdditionalErrorInformation
994 "BatchTransfer.MaximumNumber".
995
996 ExchangePolicy with "TotalLimit" value
997 If ExchangePolicy has the value "TotalLimit", MaximumAmount must be present. If this element is missing
998 the configuration of the BatchTransfer contains an error. The complete DataSet must be ignored and the
999 error may be stored in the log of Event with the Result "InvalidContent" with the AdditionalErrorInformation
1000 "BatchTransfer.MaximumAmount".
1001
1002 ExchangePolicy with "OnDemand" value
1003 If ExchangePolicy has the value "OnDemand", Batch is exchanged at the choice of the Acceptor. If there are
1004 other occurrences with other value than "OnDemand", it means that the Batch may be exchanged at the
1005 choice of the Acceptor, in addition to that other ExchangePolicy.
1006 The ExchangePolicy “OnDemand” must always be allowed on the POI even if this policy is not present.
1007 5.3.1.3 Completion Exchange

1008 CompletionExchange defines the behaviour of the POI for a completion exchange subsequent to an online
1009 transaction using ExchangePolicy, MaximumNumber, MaximumAmount, Retry and TimeCondition.
1010 For the definition of CompletionExchange for online transactions, ExchangePolicy may have one or several
1011 of the following values:
1012
Value Usage
Immediately A completion exchange should start immediately after the online transaction
NumberLimit A completion exchange starts after a fixed number of online transactions. MaximumNumber must
be present.
TotalLimit A completion exchange starts when the online transaction totals exceed a total limit amount.
MaximumAmount must be present.
AsGroup All completion messages are sent as a series of messages when TimeCondition is reached.
OnDemand A completion exchange starts when CompletionRequired in the AcceptorAuthorisationResponse
message is set to "True".
1013
183 Page 89
1014 If ExchangePolicy contains a value different from the values listed above; the configuration must be ignored
1015 and the action may be stored in Event with Result containing "InvalidContent" and AdditionalErrorInformation
1016 containing the text value "CompletionExchange.ExchangePolicy".
1017 If ExchangePolicy contains the value "AsGroup"; StartTime and Period in TimeCondition are used to define
1018 the timing of the cyclic completion exchange. If one of these elements is missing, the configuration of the
1019 completion exchange contains an error. The complete DataSet must be ignored and the error may be stored
1020 in the log of Event with Result containing "InvalidContent" and AdditionalErrorInformation containing the text
1021 value "CompletionExchange.TimeCondition".
1022 ReTry may be present to define the maximum number of and the delay for retransmissions of completion
1023 messages.
1024 All other elements of the component TimeCondition that are not used for the present exchange policies will
1025 be ignored.
1026
1027 5.3.2 Configuration of Data Capture and Completion for Offline Transactions
1028 OfflineTransaction determines the data capture mechanism, batch transfer and completion exchange
1029 configuration for offline transactions.
1030 5.3.2.1 Financial Capture

1031 FinancialCapture may have one of the following values:
1032
Value Usage
Batch Data capture is part of the batch transfer
Completion Data capture is part of the completion exchange
No message is sent. Data capture is performed by other means if OfflineTransaction is absent from
the AcquirerProtocolParameters.
1033
1034 The current value of FinancialCapture is used if it belongs to the above table.
1035 If FinancialCapture contains a different value from the two first ones listed above, the complete DataSet must
1036 be ignored and the action may be logged in Event with Result containing "InvalidContent" and
1037 AdditionalErrorInformation containing the text value "OfflineTransaction.FinancialCapture".
1038
1039 5.3.2.2 Batch Transfer

1040 Should OfflineTransactions.FinancialCapture contain the value "Batch"; BatchTransfer determines the
1041 behaviour of the POI for the capture of offline transactions by using ExchangePolicy, MaximumNumber,
1042 MaximumAmount and/or TimeCondition (see section 5.3.1.2).
1043
1044
185 Page 90
1045
1046 5.3.2.3 Completion Exchange

1047 CompletionExchange determines the behaviour of the POI for a completion exchange subsequent to an
1048 offline transaction using ExchangePolicy, MaximumNumber, MaximumAmount or TimeCondition.
1049 ExchangePolicy may have one or several of the following values:
1050
Value Usage
AsGroup Completion exchange messages are sent as a series of messages when TimeCondition is
reached.
AsSoonAsPossible A completion exchange starts with the next online transaction
Immediately A completion exchange starts after the current offline transaction
NumberLimit A completion exchange starts after a fixed number of transactions defined in
MaximumNumber is reached. MaximumNumber must be present;.
TotalLimit The completion exchange starts when offline transaction totals exceed a total limit amount
defined in MaximumAmount. MaximumAmount must be present;
No completion exchange is required. If OfflineTransaction is absent from the
1051
1052 If ExchangePolicy contains a different value from the values listed above, the configuration must be ignored
1053 and the action may be logged in Event with Result containing "InvalidContent" and
1054 AdditionalErrorInformation containing the text value "OfflineTransactions.ExchangePolicy".
1055
1056 If ExchangePolicy contains the value "AsGroup", the message elements StartTime and Period in
1057 TimeCondition are used to define the timing of the completion exchange.
1058 ReTry may be used to define the maximum number of and the delay for retransmissions of completion
1059 advices.
1060 All other elements of TimeCondition which are not used for the present exchange policies must be ignored.
1061
1062 If ExchangePolicy contains either “NumberLimit” or “TotalLimit”, the trigger are evaluated regardless of any
1063 other value of ExchangePolicy. Then in case of coexistence, the smaller must trig the ExchangePolicy.
1064 If ExchangePolicy contains a time condition, the set of CompletionAdvice must be sent, the time condition for
1065 OnlineTransaction and OfflineTransaction should be identical.
1066
1067 5.3.3 Configuration of Reconciliation

1068 ReconciliationExchange determines the behaviour of the POI for the reconciliation with an acquirer by using
1069 ExchangePolicy and TimeCondition.
1070 ExchangePolicy may contain one or several of the following values:
1071
Value Usage
Cyclic Start time and Period defined by the Acquirer. The element TimeCondition must contain the
elements StartTime and Period
None Reconciliation exchange not performed
187 Page 91
NumberLimit After a fixed number of transactions. The element MaximumNumber must be present to define the
maximum otherwise the reconciliation is not performed.
TotalLimit If transaction totals exceed a limit of amount. The element MaximumAmount must be present
otherwise the reconciliation is not performed.
OnDemand Reconciliation exchange is performed at the choice of the Acceptor.
1072
1073 If one of the occurrences of ExchangePolicy contains a value different from the values listed above, the
1074 configuration must be ignored and the action may be stored in the log of Event with Result containing
1075 "InvalidContent" and AdditionalErrorInformation containing the text value
1076 "ReconciliationExchange.ExchangePolicy".
1077 If the ReconciliationExchange configuration is missing and ExchangePolicy has not been configured before,
1078 ReconciliationExchange.ExchangePolicy has to be considered as "None".
1079 TimeCondition is only present in case of one of the elements ExchangePolicy contains the value "Cyclic".
1080 Otherwise the component TimeCondition must be absent.
1081
1082 5.3.4 Other Acquirer Protocol Configuration Parameters

1083
1084 5.3.4.1 BatchTransferContent

1085
1086 BatchTransferContent contains the following values:
Value Usage
DebitCredit Data capture containing debit and credit transactions. To be captured by the POI (i.e. payment,
payment reservation and refund transactions).
Cancellation When a transaction of the batch is cancelled, the batch contains both the cancelled transaction
and the transaction of cancellation.
Failed Data capture containing failed transactions. Failed or aborted transactions to be captured by the
POI.
Declined Online declined transactions
1087
1088 5.3.4.2 MessageItem

1089 MessageItem determines the condition of presence for the message elements in the nexo Acquirer protocol
1090 messages [CAPE ACQ MDR].
1091 A message component or element that can be populated by configuration is identified by the rule "Config" in
1092 the nexo Acquirer Protocol specifications [CAPE ACQ MUG].
1093 MessageItem.ItemIdentification: A message element in the nexo Acquirer protocol message is identified by
1094 its absolute or relative path from the XML root of the message, using XML tag separated by the character "/".
1095 For instance, the message element RecipientParty in the header of the AcceptorBatchTransfer message has
1096 the absolute path AcceptorBatchTransfer.Header.RecipientParty is identified in ItemIdentification by: the
1097 value "/AccptrBtchTrf/Hdr/RcptPty". The Identification data element of the POI identification in all the
1098 messages has relative path Environment.POI.Identification.Identification is identified in ItemIdentification by
1099 the value "Envt/POI/Id/Id".
189 Page 92
1100 For each message item, Condition defines the behaviour of the message element in the acquirer protocol.
1101 The condition is valid for all relevant messages sent to the acquirer identified in
1102 AcquirerProtocolParameters.AcquirerIdentification. Following values of the Condition are allowed:
1103
Value Usage
AllowedValues Recipient supports only a set of values defined in the value list..
IfAvailable Message element is sent if it is available in the payment application.
Mandatory Message element must be present in the acquirer protocol message.
NotSupported Message element is not supported by the recipient.
ConfiguredValue Message element is mandatory and takes the specific value defined in the element Value. The
POI uses this specific value for each message without any control, after configuration or during
message preparation,on the POI regarding the value. To configure message element which are
not defined as text, the received Value will be converted by the POI as a direct conversion from
text to the format of the message elment (e.g Text to Numeric or Text to IsoDateTime). It's up to
the TMS to manage correct values and format, meaning that no additional process is required
on the POI if the text conversion failed, leading to a possible message creation or reception
failure.
1104
1105 As a genral rule, there is no specific test regarding messageItem. So it's up to the one who set messageItem values to
1106 verify that the resulting message will be a valid one (e.g NotSupported is not consistant with a mandatory message
1107 element).
1108
1109 5.4 Host Communication Parameters

1110 This set of parameters hold all the information elements needed to connect a POI to a host system, a TMS
1111 Server or a Sale System.
1112 The Addresses and PhysicalInterface for connections can be defined per HostIdentification. The Addresses
1113 may be composed of multiple Address, allowing to define several means for a single server.
1114 The structure of the Addresses element is the following one.
1115
Data element Usage
Address Repeatable element to define NetworkType and AdressValue
UserName User name to be issued to the server (e.g. FTP user name)
AccessCode User AccessCode to be issued to the server (e.g. FTP user AccessCode)
ServerCertificate
ServerCertificateIdentifier
ClientCertificate
SecurityProfile
1116
1117 The repeatable element Address contained in the element Address is described as follow.
1118
Data element Usage
NetworkType Type of network used for the connection (e.g. Ethernet, PSTN, GPRS,…)
AddressValue Value which identifiy the access in the given network ( e.g for Ethernet : IP address +
port,…)
191 Page 93
1119
1120 5.5 TMS Protocol Parameters

1121
1122
1123 5.5.1 MessageItem

1124 MessageItem determines the condition of presence for the message elements, listed below, in the nexo TMS
1125 protocol messages. These message elements are also identified with Config in the Rules columns on each
1126 message presentation.
1127 Using MessageItem in the TMSProtocol parameters sets the POI behaviour for all related POI messages.
1128 This is unlike setting MessageItem into one Action of the ManagementPlanReplacement, where the settings
1129 will be applied for this Action only.
1130
1131 MessageItem.ItemIdentification ideintifies the message element in the nexo TMS protocol by its absolute
1132 path from the XML root of the message, using XML tag separated by the character "/".
1133 For each message item, Condition defines the behaviour of the message element in the TMS protocol. The
1134 condition is applicable for all relevant messages sent to the TM identified in
1135 TMSProtocolParameters.TerminalManagerIdentification.
1136
1137 Following values of the Condition are allowed:
1138
Value Usage
AllowedValues The POI must only use values in the received list
IfAvailable The POI must use this message element if available in the payment application.
Mandatory The POI must provide the element and value.
NotSupported The POI must not provide the element.
ConfiguredValue The POI must provide the element and the value as specified.
The TMS is responsible for the configured value. The POI will provide it as is.
1139
1140 There is no specific test regarding messageItem. So it's up to the one who set messageItem values to verify that the
1141 resulting message will be valid.
1142
1143
193 Page 94
1144
ItemIdentification Allowed Config Comments
/StsRpt/StsRpt/InitgTrggr/AddtlInf Configured Values For TMS expecting the
identification of the
StatusReport after a
delegation process
/StsRpt/StsRpt/DataSet/Cntt/POICpblties Mandatory For TMS acting only on
parameter downloading
NotSupported
/StsRpt/StsRpt/DataSet/Cntt/POICmpnt Allowed Values For TMS acting only on
Mandatory
Not Supported
/StsRpt/StsRpt/DataSet/Cntt/POICmpnt/SubTpInf Allowed Values To filter and keep the
size of status report as
Mandatory
short as possible.
Configured Values
Not Supported
/StsRpt/StsRpt/DataSet/Cntt/Evt Allowed Values For TMS acting only on
Mandatory
Not Supported
/StsRpt/StsRpt/DataSet/Cntt/Errs Mandatory For TMS acting only on
NotSupported
/StsRpt/SctyTrlr Mandatory To mandate
SecurityTrailer from a
NotSupported
POI managed by TMS
which don't support
SecurityTrailer.
/CertMgmtReq/CertMgmtReq/CertSvc Allowed Values
Configured Values
/CertMgmtReq/CertMgmtReq/SctyDomn Allowed Values
Mandatory
Not Supported
Configured Values
/CertMgmtReq/CertMgmtReq/BinryCertfctnReq Mandatory Then only one mode
could be supported.
NotSupported
/CertMgmtReq/CertMgmtReq/CertfctnReq Mandatory Then only one mode
could be supported.
NotSupported
/CertMgmtReq/SctyTrlr Mandatory To mandate
SecurityTrailer from a
NotSupported
POI managed by TMS
which don't support
SecurityTrailer.
1145
195 Page 95
1146 5.6 Sale to POI Parameters

1147
1148 This section defines the configuration of the Sale to POI Parameter elements for exchanges between the
1149 POI and one or multiple Electronic Cash Register/UnAttended Terminal. The connection between the POI
1150 and the ECR/UAT is defined per HostIdentification. These elements are not repeatable.
1151 The other elements define how the POI identifies itself to the ECR/UAT (MerchantPOIIdentification), and vice
1152 versa (SaleIdentification), and also identify critical elements to qualify the associated Merchant
1153 (MerchantIdentification).
1154

1156
1158
Number
C1 If the Online Transactions are captured through  OnlineTransaction.FinancialCapture
Batch, the BatchTransfer element must be present,  OnlineTransaction.BatchTransfer
otherwise it must be absent
C2 If the Batch Transfer of Online transaction is  OnlineTransaction.BatchTransfer.ExchangePolicy
managed at least by a NumberLimit of transaction,  OnlineTransaction.BatchTransfer.MaximumNumber
then the element MaximumNumber must be present
managed at least by a TotalLimit of transaction,  OnlineTransaction.BatchTransfer.MaximumAmount
then the element MaximumAmount must be present
managed at least by a Cyclic ExchangePolicy, then  OnlineTransaction.BatchTransfer.TimeCondition
the element TimeCondition must be present with a
 OnlineTransaction.BatchTransfer.TimeCondition.Sta
StartTime and Period, otherwise it must be absent
rtTime
 OnlineTransaction.BatchTransfer.TimeCondition.Per
iod
C5 If the Online Transactions are captured through  OnlineTransaction.FinancialCapture
Completion, the CompletionExchange element must  OnlineTransaction.CompletionExchange
be present
C6 If the Completion of Online transaction is managed  OnlineTransaction.CompletionExchange.ExchangeP
at least by a NumberLimit of transaction, then the olicy
element MaximumNumber must be present  OnlineTransaction.
otherwise it must be absent CompletionExchange.MaximumNumber
C7 If the Completion of Online transaction is managed  OnlineTransaction.
at least by a TotalLimit of transaction, then the CompletionExchange.ExchangePolicy
element MaximumAmount must be present  OnlineTransaction.
otherwise it must be absent CompletionExchange.MaximumAmount
C8 If the Completion of Online transaction is managed  OnlineTransaction.
at least by a AsGroup ExchangePolicy, then the CompletionExchange.ExchangePolicy
element TimeCondition must be present with at  OnlineTransaction.
StartTime and Period otherwise it must be absent CompletionExchange.TimeCondition
 OnlineTransaction.
CompletionExchange.TimeCondition.StartTime
 OnlineTransaction.
CompletionExchange.TimeCondition.Period
C9 If the Offline Transactions are captured through  OfflineTransaction.FinancialCapture
Batch, the BatchTransfer element must be present  OfflineTransaction.BatchTransfer
C10 If the Batch Transfer of Offline transaction is  OfflineTransaction.BatchTransfer.ExchangePolicy
managed at least by a NumberLimit of transaction,  OfflineTransaction.BatchTransfer.MaximumNumber
197 Page 96

managed at least by a TotalLimit of transaction,  OfflineTransaction.BatchTransfer.MaximumAmount
then the element MaximumAmount must be
present otherwise it must be absent
managed at least by a Cyclic ExchangePolicy, then  OfflineTransaction.BatchTransfer.TimeCondition
the element TimeCondition must be present with
 OfflineTransaction.BatchTransfer.TimeCondition.Sta
rtTime
 OfflineTransaction.BatchTransfer.TimeCondition.Per
iod
C13
C14 If the ExchangePolicy of the CompletionExchange  OfflineTransaction.CompletionExchange.ExchangeP
of OfflineTransaction is set to Immediately or olicy
AsSoonAsPossible, there musn’t be another
ExchangePolicy
C15 If the Completion of Offline transaction is managed  OfflineTransaction.CompletionExchange.ExchangeP
at least by a NumberLimit of transaction, then the olicy
element MaximumNumber must be present  OfflineTransaction.
otherwise it must be absent CompletionExchange.MaximumNumber
C16 If the Completion of Offline transaction is managed  OfflineTransaction.
at least by a TotalLimit of transaction, then the CompletionExchange.ExchangePolicy
element MaximumAmount must be present  OfflineTransaction.
otherwise it must be absent CompletionExchange.MaximumAmount
C17 If the Completion of Offline transaction is managed  OfflineTransaction.
at least by a Cyclic ExchangePolicy, then the CompletionExchange.ExchangePolicy
element TimeCondition must be present with  OfflineTransaction.
StartTime and Period, otherwise it must be absent CompletionExchange.TimeCondition
 OfflineTransaction.
CompletionExchange.TimeCondition.StartTime
 OfflineTransaction.
CompletionExchange.TimeCondition.Period
C18 If the ExchangePolicy of the  ReconciliationExchange.ExchangePolicy
ReconciliationExchange is set to None there musn’t
be another ExchangePolicy
C19 If the ExchangePolicy of ReconciliationExchange is  ReconciliationExchange.ExchangePolicy
managed at least by a NumberLimit of transaction,  ReconciliationExchange.MaximumNumber
managed at least by a TotalLimit of transaction,  ReconciliationExchange.MaximumAmount
then the element MaximumAmount must be
present otherwise it must be absent
managed at least by a Cyclic ExchangePolicy, then  ReconciliationExchange.TimeCondition
the element TimeCondition must be present with
 ReconciliationExchange.TimeCondition.StartTime
 ReconciliationExchange.TimeCondition.Period
C22 If there is no Parameters in ApplicationParameters,  ApplicationParameters.Parameters
EncryptedParameters must be present  ApplicationParameters.EncryptedParameters
If there is no EncryptedParameters in
ApplicationParameters, Parameters must be
present
C23 If we ReplaceConfiguration of a Terminal Manager  ReplaceConfiguration
we must only create new parameters,  ActionType
C24 BatchTransferContent must be present if  OnlineTransaction.FinancialCapture
OnlineTransaction.FinancialCapture is Batch or if  OfflineTransaction.FinancialCapture
OfflineTransaction.FinancialCapture is Batch.
 BatchTransferContent
C25 A MessageItem.Value must be present if  MessageItem.Condition
MessageItem.Condition is ConfiguredValue or  MessageItem.Value
AllowedValue
199 Page 97
C26 More than 1 MessageItem.Value must be present if  MessageItem.Condition

MessageItem.Condition is AllowedValue  MessageItem.Value
C27 If MessageItem.Condition is NotSupported,  MessageItem.Condition
Mandatory or IfAvailable then MessageItem.Value  MessageItem.Value
is absent
C28 Only the MTM is allowed to set the POIIdentification  TerminalManagerIdentification.Type
 DataSet.Content.TMSProtocolParameters.POIIdenti
fication
1159
1160 5.8 Nexo parameters states lifecycle

1161 5.8.1 Foreword
1162 Parameter management between TMS and POI rely on some principles which are
1163 - The only value relevant for identifying parameter version between TMS and POI is the
1164 DataSet.Identification.CreationDateTime
1165 - Each parameter set prepared by TMS and used by a POI is identified by its
1166 o DataSet.Identification.Type
1167  TMSProtocolParameters
1168  AcquirerProtocolParameters
1169  MerchantParameters
1170  TerminalParameters
1171  ApplicationParameters
1172  HostCommunicationParameters
1173  SecurityParameters
1174 o DataSet.Identification.Name
1175 o DataSet.Identification.Version : compulsory or not depending on the type
1176 - the POI status report can inform TMS about its parameter set in use, with the POIComponent
1177 description of this report. In that case POIComponent.Identification.Identification should be equal to
1178 the beginning of the DataSet.Identification.Name of the AcceptorConfigurationUpdate.
1179 - A parameter version can exists to define several parameter sets prepared and sent together. This
1180 version does not interfere with the individual parameter set version, but can be used for Acquirer
1181 protocol as AcquirerParametersVersion data.
1182 - All parameter sets have a version, except HostCommunicationParameters which does not require
1183 version as it is used for defining Host configuration.
1184 - Parameters' Version can be defined and used differently depending on the data set. Then it can be
1185 up to the parameter producer and consumer to manage the logic of this data. When no specific
1186 requirement exists for this version, we recommend to use a dateTime format, which can give a
1187 useful information for a human operator.
1188 In the nexo Acquirer Protocol, some messages refer to AcquirerParameters, this message element must be
1189 understood as the group of parameters made by grouping AcquirerProtocolParameters,
1190 HostCommunicationParameters, ApplicationParameters and MerchantParameters received with the same
1191 DataSet.Identification.
1192
1193
201 Page 98
1194 5.8.2 Parameters lifecycle on POI

1195 For a POI, the states are :
1196 - Received : when an AcceptorConfigurationUpdate parameter is received, it have to be checked
1197 before it can be installed
1198 o If the received parameter does not already exists on the POI , it is installed and activated
1199 o If the received parameter already exist on the POI, it is installed in a status equivalent to the
1200 state previously known for those parameters
1201 - Active : parameters in this state can be used by the applications
1202 - Inactive : parameter sets are stored – but not used by any application.
1203 When receiving an AcceptorConfigurationUpdate with an ActionType equals to DELETE, the parameter set
1204 is removed from the POI regardless of its state (active or inactive).
1205 If a received parameter set is not valid, it is not stored, installed or activated.
1206
1207 According to explanations present in various chapter of this document, the way to manage ActionType
1208 CREATE or UPDATE is reminded here after.
1209 For parameters which does not already exist on terminal, Action.Type CREATE or UPDATE are both
1210 accepted and have the same result in creating the parameter set on the terminal.
1211 For parameters which already exist on terminal, Action.Type CREATE or UPDATE are both accepted
1212 CREATE will replace the whole parameter set with the data sent
1213 UPDATE will only change or add parameters received to the existing parameter set on the terminal.
1214
1215 @startuml
1216 [*] --> Received : ACU received
1217 Received --> [*] : ACU checked KO
1218 Received --> Active : ACU checked OK & existing same active parameter
1219 Received --> Active : ACU checked OK & non existing same parameter
1220 Received --> Inactive : ACU checked OK & existing same inactive parameter
1221 Inactive --> [*] : ACU delete
1222 Active --> [*] : ACU delete
1223 Active --> Inactive : ACU deactivate
1224 Inactive --> Active : ACU activate
1225 Received : update status for next Status report
1226 Active : update status for next Status report
1227 Inactive : update status for next Status report
203 Page 99
1229 @enduml
1230
1231 Figure 4 Parameters lifecycle on POI
1232
205 Page 100

1233
1234 5.8.3 Parameters lifecyle on TMS

1235 The following states exist for parameters managed by the TMS for each POI using these parameters:
1236 - Initial: Some data initialization has started on TMS for these parameters. Data of the various
1237 elements of a parameters set had been created – partially or totally.
1238 - Validated: An actor (e.g TMS operator or external entity) decides to make parameters accessible to
1239 POI. A validation and a semantic check is performed on all parameter sets ready to be dispatched in
1240 the field. The time where this operation is performed is recorded as CreationDateTime.
1241 - Planned: once a POI has connected, it receives a new management plan, including the commands
1242 for parameter download.
1243 - Sent: Parameters have been sent during an AcceptorConfigurationUpdate activity. Note that this
1244 state should be transitory, before TMS receives a new StatusReport which confirms the parameter
1245 acceptation.
1246 - Deactivated: StatusReport indicates that parameters have been received by POI but are not in use.
1247 - Activated: StatusReport indicates that parameters are in use.
1248 - Deleted: StatusReport does not mention anymore the parameter set.
1249
1250
1251 @startuml
1252 [*] --> Initial
1253 Initial : parameter set declaration
1254 Initial : parameter input
1255 Initial --> Validated : Actor validation
1256 Validated : result = parameter validity check
1257 Validated : version = CreationDateTime
1258 Validated : update ManagementPlanReplacement
1259 Validated --> Planned : ManagementPlanReplacement
1260 note right on link
1261 Note : change in managementPlan Replacement occurs
1262 when the StatusReport received from POI shows a CreationDateTime
1263 of the parameter set which is less than the one recorded in TMS
1264 end note
1265 Planned : POI status = notified
1266 Planned --> Sent : AcceptorConfigurationUpdate
1267 Sent : POI status = downloaded
1268 Activated: POI status = activated
1269 Activated --> Initial : parameter set changes\
1270 by TMS operator
1271 Sent --> [*] : removed from StatusReport \
1272 after deletion command
1273 Sent --> Deactivated : StatusReport = deactivated
207 Page 101

1274 Deactivated : POI status = deactivated

1275 Deactivated --> Initial : parameter set changes\
1276 by TMS operator
1277 Sent --> Activated: StatusReport = activated
1279 @enduml
209 Page 102

1280
1281 Figure 5 Parameters lifecycle on TMS
1282
211 Page 103

1283 6 TerminalManagementRejection (catm.004)

1284
1285 6.1 Introduction

1286 The TerminalManagementRejection allows the rejection of any TMS messages from a POI, a MTM or a TM.
1287
1288 A RecipientParty sends a TerminalManagementRejection message to an InitiatingParty to indicate that the
1289 RecipientParty could not process the received message.
1290
1291
1292 Figure 6: Rejection of a TMS message
1293
1294 The TerminalManagementRejection message contains the reason of the rejection (RejectReason), some
1295 additional information on the rejection (AdditionalInformation) for further analysis, and the rejected message
1296 itself (MessageInError) which may be compared to the message sent.
1297
1298 The TerminalManagementRejection message must be sent in the following cases:
1299
1300 1. The envelope of the received message is incorrect.
1301 RejectReason contains the value InvalidMessage. It is recommended to include the optional fields
1302 AdditionalInformation to provide the details of the error. MessageInError contains the received message
1303 with the error.
1304
1305 2. The rejected message cannot be decoded properly; the syntax or the semantic is
1306 invalid.
1307 RejectReason contains the value ParsingError. It is recommended to include the optional fields
1308 AdditionalInformation to provide the details of the decoding error. MessageInError contains the received
1309 message with the coding error.
1310
1311 3. The identification of the rejected message is invalid.
1312 RejectReason contains the value InitiatingParty or RecipientParty. No other field is required.
1313 AdditionalInformation may contain the invalid identifier.
1314
1315 4. The verification of the security of the rejected message fails.
213 Page 104

1316 RejectReason contains the value Security. It is recommended to include the optional fields
1317 AdditionalInformation to provide the details of the security error. MessageInError contains the received
1318 message with the security error.
1319
1320 5. The rejected type of message is not supported by the RecipientParty, and then the
1321 RecipientParty is not able to send a message response to the InitiatingParty.
1322 RejectReason contains the value MessageType. No other field is required. AdditionalInformation may
1323 contain the invalid MessageFunction value.
1324
1325 6. The version of the protocol used for the message (Header.FormatVersion) is not
1326 supported by the RecipientParty which is not able to send a message response of this version to the
1327 InitiatingParty.
1328 RejectReason contains the value ProtocolVersion and AdditionalInformation the invalid protocol version.
1329
1330 7. The RecipientParty is not able to process the message for lack of resources. For
1331 that reason, a message response could not be built and the message is not processed.
1332 RejectReason has the value UnableToProcess. AdditionalInformation contains the reason for which the
1333 message could not be processed.
1334
1335 8. The RecipientParty must not respond to a received TerminalManagementRejection.
1336
1337 The reaction of the InitiatingParty to a TerminalManagementRejection message depends on the
1338 RejectReason and the type of rejected message.
1339
1340

1342 The TerminalManagementRejection message contains the following information:
1343
Lvl TerminalManagementRejection Mult. Rule Cstr Usage
]
2 DownloadTransfer [1..1 * False
]
2 ExchangeIdentification [0..1 Copy from the request if successfully
] extracted
<XchgId>::Number
]
215 Page 105


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>
]
2 RejectReason [1..1 High level information allowing the sender to
] know the class of error, and to have different
processing.
InitiatingParty: Invalid identification data for
the sender InitiatingParty.
InvalidMessage: Invalid envelope
message.
MessageType: Type of message the
recipient receives is unknow or
unsupported.
ParsingError: Invalid message: At least
one of the data element or data structure
217 Page 106

is not present, the format, or the content

of one data element or one data structure
is not correct.
ProtocolVersion: Version of the protocol
couldn't be supported by the recipient.
RecipientParty: Invalid identification data
for the the receiver RecipientParty.
Security: Security error (for example an
invalid key or an incorrect MAC value).
UnableToProcess: Not possible to process
the message, for instance the security
module is unavailable, the hardware is
unavailable, or there is a problem of
resource.
<RjctRsn>::RejectReason2Code
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 (without transport header) received
] by the recipient which has been rejected and
produced this TerminalManagementRejection
message
<MsgInErr>::Max100KBinary
1344
219 Page 107

1345 7 MaintenanceDelegation
1346

1348
1349 Depending on use cases, the Master Terminal Manager (MTM) might be operated by an estate owner who
1350 may not be responsible for the whole set of parameters. In such a case, part of the parameters could be
1351 managed by a delegated Terminal Manager (TM).
1352 There are 2 possibilities for the TM to send parameters to the POI
1353  The TM may send its parameters to the MTM in order to add it in the next
1354 AcceptorConfigurationUpdate managed by the MTM
1355  For security or confidentiality reasons, the TM may not send its parameters to the MTM. In such a
1356 case, the MTM may control the delegation and exchange with its estate element of information to
1357 verify the delegation scope – we will qualify it as Closed Delegation – or may give free access to the
1358 TM – the delegation will then be qualified as Open Delegation
1359
1360 This document will focus on Closed Delegation.
1361
1362 The set of terminals which is targeted by a delegation may be flexible, depending on the use case. Basicaly,
1363 one can have the following situation
1364 1. Targeted Delegation
1365 a. The set of terminals concerned by a delegation is known by the MTM:
1366 A formal definition of the set of terminal targeted by one specific delegation can be handled
1367 on MTM. Then MTM can issue a management plan with information for delegation to this
1368 specific set of terminals. Note that the case where ALL terminals from the MTM are targeted
1369 is a particular case of this use case. Nevertheless, the intention of targeting all terminals
1370 must be clearly expressed to distinguish from the third use case (untargeted delegation).
1371 b. The set of terminals concerned by a delegation is known by the TM:
1372 Creation of terminals concerned by delegation can be done on the TM. The TM must then
1373 create a delegation request with a definition of the terminals POIidentification for which a
1374 delegation is requested. As in the previous case, MTM can originate Management Plan with
1375 information for delegation to the TM.
1376 2. Untargeted Delegation : The set of terminals concerned is unknown at the time of creation of
1377 delegation.
1378 If the set of terminals concerned by delegation is not known by the MTM and TM (see note 1.a),
1379 then the Management Plan with instruction for delegation must not be initiated by the MTM.
1380 Then we expect a specific operation to be initiated on the terminal to trigger the transmission of
1381 management Plan including delegation instructions to this terminal.
1382
1383 In order to control, verify or restrict the delegation to a subset of an estate, the solution is mainly based on
1384 three important data elements, which are:
1385
1386  DelegationScopeIdentification: a label identifying the delegation
1387  DelegationScopeDefinition: a container to record all necessary information to control the delegation
221 Page 108

1388  DelegationProof (or ProtectedDelegationProof if secured by a CMS structure): a kind of pass to

1389 exchange between actors in order to legitimate the reason of message exchanges.
1390
1391 Even if the internal structure of DelegationScopeDefinition and DelegationProof are not necessary to define
1392 this protocol, their definition is primordial to ensure interoperability of solutions based on this protocol. Then
1393 the definition of these element must be the following ones.
1394 These two elements, defined below, are structured and encoded with the same encoding format of the
1395 exchanged messages.
1396
Element Mult Usage
.
DelegationScopeDefinition
DelegationScopeIdentification [1..1
]
DataSet [1..*]
Type [1..1 Allowed values are:
] AcquirerParameters,
ApplicationParameters
MerchantParameters
SecurityParameters
TerminalParameters
TMSProtocolParameters
CertificateParameters
SaleToPOIParameters
HostCommunicationParameters is always granted
Destinations [1..*] To identify the recipient of the parameters. Should be an
ApplicationName in case of ApplicationParameters or a
Manufacturer Name in case of TerminalParameters.
ProviderName [1..1 To identify the issuer of parameters
]
DataSetElement [0..*]
ParamName [1..1 Identifier that must be understood by receivers identified in the Destinations
]
ParamType [0..1 Type that must be understood by the receivers identified in the Destinations.
] Mainly used for SecurityParameters in order to identify type of the key to
exchange;
ParamPresence [0..1 To mandate or not the presence of a parameter in a delegated configuration
]
ParamValue [0..1 To set the value of an identifier
]
1397
Element Mult. Usage
DelegationProof
TMIdentification [1..1] Identifier of the TM given by the MTM
POISubset [0..*] Identification of a group of POI shared by the TM and the MTM
DelegationType [1..1] Allowed values are
Create
Delete
Update
StartDate [0..1] Activation date of the delegation
Default is the reception date
223 Page 109

Element Mult. Usage

EndDate [0..1] Expiry date of the delegation
If absent there is no expiry date
DelegationScopeIdentification [1..1]
DigestOfDelegationScopeDefinition [1..1]
Algorithm [1..1] Allowed values are
SHA256,
SHA384
SHA512
Digest [1..1]
MaintenanceTimeSlot [0..*]
StartTime [1..1] ISOTime
Duration [1..1] ISOTime
1398
1399
1400 7.2 Delegation actors

1401 This chapter lists all the stakeholders for the POI configuration which may interact with the parameters
1402 setting or usage
1403
1404 Terminal manufacturer : in charge with Terminal production. For this purpose it may be concerned
1405 by the initial keys introduction and by TerminalParameters
1406
1407 Terminal supplier : put the terminal in the field, operate it in the fied, maintain the terminal. It may be
1408 the more concerned user of TMS solution for setting the parameters.
1409
1410 Terminal owner (estate owner) : the one who may want to have the MTM for controlling its estate
1411 and broadcasting the parameters
1412
1413 Repair center/ call center : need to know what is running in the terminal . It has the same concerns
1414 as a Teminal supplier
1415
1416 Application developper : deal with the parameters to be received from all parties – and specifically
1417 the ones agreed with the acquirers or standardization (such as OSCar) for the Application Parameters
1418
1419 Acquirers : is originator of most of the parameters managed by the application for the business part of
1420 it
1421 Loyalties provider : originator of the application parameter needed by a loyalty application. It can be
1422 assimilated to an acquirer
1423
1424 Merchant : is originator of the MerchantParameter, and may have some prerogative on some of the
1425 others parameters
1426
1427
225 Page 110

1428 Intermediate agent (processor) : management of some of the parameters on behalf of the acquirer
1429 (PIN encryption, communication)
1430 Service provider : create and operate certificates used for transport, be aware of POI managed
1431 (white lists)
1432
1433 POI terminal : receives all parameters related to its activity, checks delegation
1434
1435 Concentrator (POI server) : receives all parameters related to all equipments under its responsibility
1436 in a retail solution and dispatches parameters when needed to individual equipment
1437
1438 Scheme (issuer) : under the responsibility of acquirer => not to be part of TMS actors
1439
1440
1441
1442
1443 7.3 Delegation use cases

1444
1445 The following use cases will be devoted to use cases where a delegated TM doesn’t provide the MTM with
1446 its parameters. Otherwise, the ParameterDataSet of the MaintenanceDelegationRequest must embed all the
1447 parameters coming from the TM.
1448
1449 7.3.1 POI Identifications

1450 A POI terminal has 3 types of identifications:
1451 The identification of the terminal for the Merchant.
1452 This is useful when the shop of the merchant has several POI terminals, clustered or not, to identify
1453 the POI terminal for the Sale system.
1454 The identification of the terminal for the Acquirer.
1455 This is used when the Acquirer want to manage the POI terminal on its side. The Acquirer may
1456 choose to use the identification of the Merchant.
1457 There is potentially one identifier per Acquirer.
1458 For standalone terminals, which are unique at the acceptor side, the identification is always 1.
1459 For e-commerce, there is only one identifier.
1460 The identification of the terminal for TMS. This is useful when the shop of the merchant has several POI
1461 terminals to identify the POI terminal for the Sale system.
1462
1463 @startuml
1464 class MTM
1465 class “POI\nTerminal” as POITerminal
1466 class “Sale\nSystem” as SaleSystem
1467 class « Acquirer A » as AcquirerA
227 Page 111

1468 class « Acquirer B » as AcquirerB

1469 hide empty members
1470 hide circle
1471 MTM –down- POITerminal : TMS\nIdentifiction
1472 SaleSystem -right- POITerminal : Merchant\nIdentification
1473 POITerminal –right- AcquirerA : Acquirer\nIdentification
1474 POITerminal -- AcquirerB : Acquirer\nIdentification
1476 @enduml
1477 Figure 7 One POI multiple Identifications
1478
1479 7.3.2 Setup of Delegation

1480
1481 Before exchanging MaintenanceDelegationRequest and MaintenanceDelegationResponse, some actors
1482 have to agree on definition of some elements.
1483
1484 The acquirer and the estate owner must agree on the following elements:
1485  On the couple (MTMIdentification, TMIdentification). As explained before, a TM or a MTM must be
1486 able to identify a delegation from these values. Then this couple of values must uniquely identify a
1487 TM from the MTM point of view, but also a MTM from a TM point of view.
1488  On the DelegationScopeIdentification
1489  On the list of DataSet to delegate
1490  On the POISubset
1491  On the timeslot available for the TM management plan.
1492  On the need or not to protect Delegation information and how to exchange CA root keys.
1493
229 Page 112

1494 The merchant may have to subscribe a contract with the acquirer. During this subscription the following
1495 element may be exchanged.
1496  Identification of the Terminal Estate Manager. Then the acquirer is able to check if it could reuse an
1497 existing delegation or if a new one has to be setup with the Terminal Estate Manager.
1498  Identification of the POIID and/or POISubset. To allow the acquirer to control the broadcast of its
1499 parameter and acess to its services.
1500
1501 7.3.3 Stopping a Delegation

1502
1503 A delegation may be stopped by a MTM or a TM, but it should be stop by a TM. In this case, it should Delete
1504 all its parameters and management plan inside POI (terminal or system) and then should send a
1505 MaintenanceDelegationRequest with a DelegationType set to DELETE to the MTM.
1506
1507 7.3.4 General rules for Delegation

1508
1509 Rule 1: A POI Terminal must belong to one and only one MTM (i.e. to one terminal estate only).
1510
1511 Rule 2: TM identifications (i.e. TMIdentification values) used during the delegation must be agreements
1512 between the MTM and the TM.
1513 The TMIdentification value is assigned by the MTM before any delegation process.
1514 The TMIdentification respects the unicity of the TM identifications at the POI, and at the MTM.
1515 The MTM must verify the TMIdentification is not assigned to another delegated TM of the terminal estate.
1516 The TM has to verify that the same TMIdentification is not assigned by two different MTM, for those he get
1517 delegations.
1518
1519 Rule 3: A POI Terminal must keep the same identification, whatever the TM (i.e. the delegated TM uses the
1520 POIdentification value defined by the MTM).
1521 The unicity of the POIdentification at the TM must be ensured, using the TM identification coupled with the
1522 POIIdentification.
1523
1524 For instance, in the drawing below, there are 2 terminal estates sharing the same delegated TM:
1525 Both MTM have the identification 1
1526 POI Terminal, identified by 1, keeps the same POI identification for the shared TM.
1527 The shared delegated TM has a different identification for the 2 MTM.
231 Page 113

Terminal Estate A Terminal Estate B
MTM A MTM B
TMid 1 TMid 1
TM 1 TM 1
TM 2 TM 3
TMA TMB
TMid 2 TMid 3
TM 1 TM 1
POI 1 POI 1
TM 2 TM 3
POI POI 1 POI 1 POI
Terminal Terminal
POIid 1 POIid 1
1528
1529 Figure 8 POI identification with delegation
1530
1531 Corollary 3-1: The TMSPOIIdentification must be unique inside the MTM realm
1532
1533 Rule 4: A given delegation is performed on a subset of the POI terminals belonging to the MTM.
1534 This subset is delimited and controlled by the MTM.
1535 This subset can be negotiated between the MTM and the TM that will perform the maintenance delegation.
1536 This subset can also be determined by some feature of the POI as the application.
1537
1538 The MTM control any delegation by allowing the creation, the update, or the removal of a delegation, with a
1539 specific action on the management plan of a POI:
1540 The MTM provides in the action the delegation proof in DelegationProof or ProtectedDelegationProof.
1541 This delegation proof must contain both the POIdentification and TMIdentification, with other elements
1542 related to the scope of the delegation.
1543 The POI forwards the delegation proof in the first Status Report to the delegated TM. The delegated TM is
1544 then able to verify that the POI belongs to the delegation subset.
1545
1546 Rule 5: DelegationProof is mandatory if there is no security between POI and TM and security is necessary
1547
1548 7.3.5 Status Report triggered by an Acquirer message

1549
1550 In some cases, an Acquirer may request to a POI to contact a TM. In a system where a POI is in touch with
1551 multiple TMs, the POI has to identify which TM to contact.
1552 The aim of this section is to highlight this identification process.
1553
1554 The trigger is obviously part of a message exchange between the POI and the Acquirer, and the way to
1555 request this call is out of the scope of this document.
1556
1557 In any case, it is the responsibility of the acquirer to send the correct TMIdentifier to the POI.
233 Page 114

1558
1559
1560
1561 7.3.6 Rules for Key Download Delegation

1562
1563 Rule 1: The scope of the key exchange delegation must contain the identification of the keys to download.
1564 The identification of the keys to download must be defined in agreement with the MTM, with applications, or
1565 with protocols’ type to used.
1566 The identification of the keys to download may be a prefix of the identification.
1567 The identifications of the keys to download may be updated by a delegation update.
1568
1569 In case of OpenDelegation, the TM is free to exchange any key, and collision in key identification could
1570 occur. In CloseDelegation TM may exchange key if and only if SecurityParameters is defined in
1571 DelegationScopeDefinition. In this latter case, collision shouldn’t occur since the name of keys must be
1572 present in DelegationScopeDefinition in section paramName.
1573
1574 7.3.7 Create a Key Download Delegation

1575 The process to create a delegation of the key download is summarised in the message flow below.
POI M TM TM
D elegation N ego tiation
tion R equ est

M aint ena nce D el ega
M ain ten an ceD

Stat usR epo rt el eg ati on R esp
on se
delegation actio n
ent
M anag em entP la nR epla cem
delegation actio n Statu sR epor t
epla cem ent

M ana gem ent P la nR
1576
1577 Figure 9 Creation of Key Download delegation
1578
1579 The TM and the MTM negotiate the identification of the TM, the subset of the POI, and the identification of
1580 the keys.
1581
1582 The TM sends first a MaintenanceDelegationRequest to the MTM containing:
1583  The TM identification provided by the MTM.
1584  DelegationType = Create
1585  MaintenanceService = KeyDownload
1586  TMRemoteAccess = TM Host address
1587  DelegationScopeIdentification (useful to identify the delegated maintenance function)
1588  SymmetricKey = the identification of the keys for which the management is delegated.
235 Page 115

1589 The identification of the keys must be included in the DelegationScopeDefinition.

1590 Certificate, if necessary for digital signature
1591
1592
237 Page 116

1593
1594 Then the MTM sends a MaintenanceDelegationResponse to the TM containing:
1595 Response = Approved/Declined.
1596 A copy of the following data element received in the request:
1597  DelegationType,
1598  MaintenanceService,
1599  DelegationScopeIdentification
1600
1601 In the following management plan of the subset of POI terminals part of the delegation, the MTM sends a
1602 ManagementPlanReplacement to the POI containing an Action using:
1603  Type = Download
1604  RemoteAccess = TM Host address where to send a StatusReport and get the management plan of
1605 the delegated TM.
1606  ComponentType = SecurityParameters (in the StatusReport)
1607  DelegationScopeIdentification
1608  DelegationScopeDefinition containing:
1609  The identification of the keys to manage
1610  ProtectedDelegationProof containing:
1611  The POI identification for the MTM.
1612  The TM identification provided by the MTM.
1613  Delegation type: Create
1614  MaintenanceService = KeyManagement
1615  DelegationScopeDefinition
1616  A digital signature of the proof
1617
1618 The POI receives the management plan with the delegation action:
1619 The POI stores the delegated action if the digital signature is valid.
1620 The POI performs the action, sending a StatusReport to the RemoteAccess using:
1621  The same POI identification as the MTM POIIdentification
1622  The identification of the TM in TerminalManagerIdentification
1623  The ProtectedDelegationProof received in the delegation action.
1624  A protection with a digital signature.
1625
1626 The delegated TM receives the StatusReport of the POI:
1627  Validates the delegation proof,
1628  May verify that the POI is part of the POI subset which has been delegated.
1629
1630 Then the POI:
239 Page 117

1631  Receives the management plan of the TM, which is managed independently from the MTM
1632 management plan.
1633  Exchanges the keys identified in the scope of the delegation: the POI has to verify that the
1634 keys belong to this scope.
1635
1636
241 Page 118

1637
1638 7.3.8 Update a Key Download Delegation

1639 The TM sends a MaintenanceDelegationRequest to the MTM containing:
1640  DelegationType = Update
1641  The same MaintenanceService, DelegationScopeIdentification,
1642  The updated DelegationScopeDefinition.
1643
1644 The MTM sends a ManagementPlanReplacement to the POIs containing an Action using:
1645  Type = Update
1646  The same ComponentType, DelegationScopeIdentification
1648  An updated ProtectedDelegationProof, containing
1649  The POI identification for the MTM.
1651  Delegation type: Update
1652  MaintenanceService = KeyManagement
1653  The updated DelegationScopeDefinition
1655
1656 The POI receives the management plan with the delegation action.
1657 The POI updates the delegated action if the digital signature is valid.
1658
1659 When the delegated TM receives the StatusReport of the POI:
1662
1663 7.3.9 Remove a Key Download Delegation

1664 The MTM decides to remove the delegation.
1666  DelegationType = Delete
1667  The same DelegationScopeIdentification,
1668
1670  Type = Delete
1672
1673 The POI receives the management plan with the delegation action, and removes:
243 Page 119

1674  The keys managed by the delegated TM,

1675  The delegated TM management plan,
1676  The delegation.
1677
245 Page 120

1678
1679 7.3.10 Rules for Parameters Download Delegation

1680
1681 Rule 1: The delegation scope of the parameter exchange must contain the identification of the parameters to
1682 download.
1683 The identification of the parameters to download must be defined in agreement with the MTM, with
1684 applications, or with protocols’ type to used.
1685 The identification of the parameters to download may be a prefix of the identification.
1686 The identifications of the parameters to download may be updated by a delegation update.
1687
1688 Rule 2: Management rules to ensure consistency of global set of parameters are defined at application level
1689
1690 Rule 3: For application parameters delegation, acquirer identification must be present in the delegation
1691 scope
1692
1693 Corollary 3-1: Even if a TM manages multiple acquirers, TM must request to MTM one Delegation per
1694 Acquirer
1695
1696 Rule 4: Delegation for ApplicationParameters is only possible when AcquirerProtocolParameters is also
1697 delegated to the TM.
1698
1699 Note: When the MTM sends a management plan for a delegated TM, it may contain calls to status report
1700 for both the delegated TM and the MTM.
1701
1702 7.3.11 Create a Parameters Download Delegation

1703
1704 The process to create a delegation of the Parameters download is summarised in the message flow below.
POI MTM TM
Delegation Negotiation
nRequest
Ma inte nan ceDeleg atio
Mainten an
StatusR eport ce Delega tio nR
espo nse
delegation action
t
ManagementPlanReplacemen
delegation action StatusReport
lacemen t
Ma nag ementPlanRep
1705
1706 Figure 10 Creation of Parameters Download delegation
1707
247 Page 121

1708 The TM and the MTM negotiate the identification of the TM, the subset of the POI, and the identification of
1709 the parameters.
1710
1713  DelegationType = Create
1714  MaintenanceService : one or more occurrences in (AcquirerProtocolParameters,
1715 ApplicationParameters, ApplicationParametersSubsetCreation, MerchantParameters,
1716 TerminalParameters, CertificateParameters)
1717  TMRemoteAccess = TM Host address
1718  DelegationScopeIdentification to identify the delegated maintenance function
1719 The identification of the parameters may be included in the DelegationScopeDefinition. In case of
1720 OpenDelegation , the delegation applies to any parameters of the delegated services.
1721  Certificate, if necessary for digital signature
1722
1724  Response = Approved/Declined.
1725  A copy of the following data element received in the request:
1729
1730 In the following management plan of the subset of POI terminals part of the delegation, the MTM sends a
1732  Type = Download
1733  RemoteAccess = TM Host address where to send a StatusReport and get the management
1734 plan of the delegated TM.
1735  ComponentType must be consistant with
1736 MaintenanceDelegationRequest.MaintenanceService
1738  DelegationScopeDefinition containing:
1739  The identification of the parameters to manage
1740  ProtectedDelegationProof containing:
1744  MaintenanceService =applicationParameters
1747
249 Page 122

1753  The ProtectedDelegationProof received in the delegation action.
1754  A protection with a digital signature.
1755
1759
1760 Then the POI:
1761  Receives the management plan of the TM, which is managed independently from the MTM
1763  Exchanges the parameters identified in the scope of the delegation: the POI has to verify
1764 that the parameters belong to this scope.
1765
1766 7.3.12 Update of Parameter Download Delegation

1768  DelegationType = Update
1770  MaintenanceService with one or more occurrences (AcquirerProtocolParameters,
1771 ApplicationParameters, ApplicationParametersSubsetCreation, MerchantParameters,
1772 TerminalParameters, CertificateParameters)
1774
1776  Type = Update
1779  DataSet with one or more occurrences (AcquirerProtocolParameters,
1780 ApplicationParameters, ApplicationParametersSubsetCreation,
1781 MerchantParameters, TerminalParameters, CertificateParameters)
1782  An updated ProtectedDelegationProof, containing
1785  Delegation type: Update
1786  The updated DelegationScopeDefinition
251 Page 123


1788
1790 The POI updates the delegated action if the digital signature is valid.
1791
1792 When the delegated TM receives the StatusReport of the POI:
1794  May verify that the POI is part of the POI subset which has been delegated
1795
1796
253 Page 124

1797
1798 7.3.13 Remove of Parameter Download Delegation

1799 The MTM decides to remove the delegation, or:
1801  DelegationType = Delete
1803
1805  Type = Delete
1807
1808 The POI receives the management plan with the delegation action, and removes:
1809  The parameters managed by the delegated TM,
1810  The delegated TM management plan,
1811  The delegation.
1812
1813 7.4 Delegation examples

1814
1815 7.4.1 Example: AcquirerParameters Download Delegation

1816
1817 This example describes a successful delegation for one specific acquirer through one TM.
1818 The process to create a delegation of the AcquirerProtocolParameters download is summarised in the
1819 message flow below.
POI M TM TM
D elegation N ego tiation
tion R equ est

M aint ena nce D el ega
M aint ena nceD el ega tion

Sta tusR epo rt R espo nse
delegation actio n
ent
delegation actio n Statu sR epor t
ent
1820
1821 Figure 11 AcquirerParameters download delegation
1822
1823 Assumptions:
255 Page 125

1824  Security trailer is configured for any messages

1825  The TM is able to check the POI certificate that is used to sign messages
1826
1827 Workflow:
1828
1831  The POISubset contains the POI Identification assigned by the MTM (if known by the TM)
1833  MaintenanceService : contains “AcquirerProtocolParameters”
1835  AcquirerProtocolParameters.Acquirerdentification.Identification for a given Acquirer.
1836  Version may contain the version of Acquirer protocol parameters, since the version is not relevant
1837 any dummy value can be sent
1838
1839 Certificate of the TM for digital signature is verified by the MTM
1840
1842  Response = Approved
1846
1847 Certificate of the MTM for digital signature is verified by the TM
1848 In the following management plan for the POI, the MTM sends a ManagementPlanReplacement to the POI
1849 containing an Action using:
1850  Type = Download
1851  RemoteAccess = TM Host address where to send a StatusReport and get the management
1852 plan of the delegated TM.
1853  ComponentType = ManagementPlan
1854  A DelegationProof protected or not containing:
1857  MaintenanceService =AcquirerProtocolParameters
1858  AcquirerProtocolParameters.Acquirerdentification.Identification
1859  A digital signature of the proof generated by the MTM (optional)
1860
257 Page 126

1866  The DelegationProof protected or not received in the delegation action.
1867  A protection with a digital signature of the MTM (if present)
1868
1870  Validates the signature of the message using the POI certificate
1871  May verify that StatusReport.POIIdentification is part of the POI subset sent in the
1872 MaintenanceDelegationRequest.
1873  Validates the delegation proof,
1874
1875 Then the POI:
1876  Receives the management plan of the TM, which is managed independently from the MTM
1878  Exchanges the AcquirerProtocolParameters (e.g. the host address for the acquirer).
1879 7.4.2 Example: ApplicationParameters Download Delegation

1880
1881 This example describes a successful delegation for two acquirers through two TM.
1882 The process to create a delegation of the ApplicationParameters download is summarised in the message
1883 flow below.
259 Page 127

POI MTM TM1 TM2

Delegation Negotiation 1
Request
MaintenanceDelegation
MaintenanceDelegationResp
onse
Delegation Negotiation 2
delegation action MaintenanceDelegationRequest
MaintenanceDelegationResp
onse
StatusReport
t
ManagementPlanReplacemen
StatusReport
delegation action
ent
ManagementPlanReplacem
StatusReport
delegation action
ManagementPlanReplacement
1884
1885 Figure 12 ApplicationParameters download delegation
1886
1887 Assumptions:
1889  Both TM are able to check the relevant POI certificate
1890
1891 Workflow:
1892
1893 The TM1 sends a MaintenanceDelegationRequest to the MTM containing:
1894  The TM1 identification provided by the MTM.
1895  The POISubset contains the POI Identification assigned by the MTM (if known by TM1)
1897  MaintenanceService : contains “ApplicationParametersSubsetCreation”
1898  TMRemoteAccess = TM1 Host address
1899  DelegationScopeIdentification to identify the delegated maintenance function (e.g. ‘TM1 set of
1900 tables’)
1901  The identification of the parameters is included in the DelegationScopeDefinition. e.g. Table1,
1902 Table2, Table6)
1903
261 Page 128

1904 Certificate of the TM1 for digital signature is verified by the MTM
1905
1906 Then the MTM sends a MaintenanceDelegationResponse to the TM1 containing:
1913
1914 Certificate of the MTM for digital signature is verified by the TM1
1921  DelegationScopeIdentification to identify the delegated maintenance function (e.g. ‘TM2 set of
1922 tables’)
1923  The identification of the parameters is included in the DelegationScopeDefinition. e.g. Table1,
1924 Table2, Table6)
1925
1934
1936 In the following management plan for the POI, the MTM sends a ManagementPlanReplacement to the POI
1937 containing two Action using:
1938  Action 1
1940  RemoteAccess = TM1 Host address where to send a StatusReport and get the management plan
1941 of the delegated TM1.
1942  ComponentType = ManagementPlan
263 Page 129

1943  A DelegationProof protected or not containing:

1944  The TM1 identification provided by the MTM.
1946  MaintenanceService = ApplicationParametersSubsetCreation
1947  AcquirerProtocolParameters.Acquirerdentification.Identification= Acquirer1
1950
1951  Action 2
1963
1964
1965 The POI receives the management plan with the delegation actions.
1966 The POI stores the delegated actions if the digital signature is valid.
1967
1968 Exchange between POI and TM1
1969 The POI performs action1, sending a StatusReport to the RemoteAccess of TM1 using:
1971  The identification of the TM1 in TerminalManagerIdentification
1972  The DelegationProof received in the delegation action1.
1974
1975 TM1 receives the StatusReport of the POI:
1980
1981 Then the POI:
265 Page 130

1982  Receives the management plan of the TM1, which is managed independently from the MTM
1984  Exchanges the ApplicationParameters.
1985
1992
1993
1994
2000
2001 Then the POI:
2005
2006
267 Page 131

2007
2008 7.4.3 Example: Untargeted Delegation

2009
2010 This example describes a successful delegation for a specific POI through one TM.
2011 In this example the POI may not yet known by the TM
2012 Delegation is initiated by the POI operator.
2013 The process to create a delegation of the parameters download is summarised in the sequence diagram
2014 below.
Operator POI 1 POI 2 MTM TM1
Nominal
case before
delegation
Initiated
periodically
after
delegation
Manually
after
delegation
TM1 accepts
or not POI 1
2015
2016 Figure 13 Untargeted delegation
2017
2018 Assumptions:
2019  Security trailer is configured for all messages
2020  The TM is able to check the POI certificate
2021  DelegationScopeIdentification is defined and known by all the parties prior to any message
2022 exchange
2023
269 Page 132

2024
2025 Workflow:
2026
2032  DelegationScopeIdentification to identify the delegated maintenance function (e.g. ‘TM set of tables’)
2033  PartialDelegation = True and POISubset is absent
2034
2035 Digital signature and Certificate of the TM for digital signature are verified by the MTM
2036
2044
2045 Digital signature and Certificate of the MTM for digital signature are verified by the TM
2046
2047 To be granted access to the delegated services, the POI sends a StatusReport to the MTM using:
2048  DataSetRequired.Identification.Name = DelegationScopeIdentification (entered by the operator)
2049  DataSetRequired.Identification.Type = ManagementPlan
2050
2051 According to its estate management policy, the MTM may either:
2052  Grant the access to the services with a following additional management plan for the POI, sending a
2055  RemoteAccess = TM Host address where to send a StatusReport and get the management plan
2056 of the delegated TM.
2058  TerminalManagerIdentification = TMIDentification provided by MTM
271 Page 133


2066  Decline the access to the services with a following additional management plan for the POI, sending
2067 an empty ManagementPlanReplacement to the POI:
2068
2069 The POI receives the management plan with the delegation actions:
2071
2072 Exchange between POI and TM
2073 The POI performs action1, sending a StatusReport to the RemoteAccess of TM using:
2076  The DelegationProof received in the delegation action.
2078
2079 TM receives the StatusReport of the POI:
2082 MaintenanceDelegationRequest,
2083  Validates the delegation proof.
2084
2085 Then the POI:
2086  Receives the management plan of the TM, which is managed independently from the MTM
2088  Exchanges the parameters identified in the scope of the delegation: the POI has to verify that the
2089 parameters belong to this scope.
2090
2091
273 Page 134

2092
2093 7.4.4 Distributed Delegation

2094
2095 In this example the MTM shares its estate between two TM according to specific criteria (acquiring bank,
2096 geographic area, type of merchant …)
2097
POI
POI su
subset2
bset 2 PO
POII su
subse
bsett1
1 MTM
MTM TM1
TM1 TM2
TM2
1
2098
2099 Figure 14 Distributed delegation
2100
2101 Assumptions:
2103  Both TM are able to check the relevant POI certificate
2104  The MTM defines two POISubstets and knows which POI belongs to each of the subset
2105
2106 Workflow:
2107
2110  The POISubset contains the POISubset Identifier assigned by the MTM and known by TM1
275 Page 135

2112  MaintenanceService : contains “ApplicationParameters”

2114  DelegationScopeIdentification to identify the delegated maintenance function (e.g. ‘POISubset1
2115 application parameters’)
2116
2118
2126
2128
2133  MaintenanceService : contains “ApplicationParameters”
2135  DelegationScopeIdentification to identify the delegated maintenance function (e.g. ‘POISubset2
2136 application parameters’)
2137
2139
2147
2149
277 Page 136

2150 In the following management plan for each of the POI belonging to POISubset1, the MTM sends a
2151 ManagementPlanReplacement to the POI containing one Action using:
2152
2160  POISubset Identification
2161  MaintenanceService = ApplicationParameters
2164
2167
2168 In the following management plan for each of the POI belonging to POISubset2, the MTM sends a
2169 ManagementPlanReplacement to the POI containing one Action using:
2170
2172  RemoteAccess = TM2 Host address where to send a StatusReport and get the management plan of
2173 the delegated TM2.
2178  POISubset Identification
2179  MaintenanceService = ApplicationParameters
2182
2185
2186
2187
279 Page 137

2190
2195
2199 MaintenanceDelegationRequest. or validates the POISubset contains in the delegation proof
2201
2202 Then the POI:
2206
2213
2217 MaintenanceDelegationRequest.or validates the POISubset contains in the delegation proof
2219
2220 Then the POI:
2224
281 Page 138

2225
2226 7.5 Delegated services and corresponding configuration message

2227 components
2228
2229 The table below indicates the message components which can be downloaded by a TM for each of the
2230 delegated service
2231
Delegated Maintenance service Message components usable
AcquirerProtocolParameters AcceptorConfigurationUpdate.Dataset.Content.Acquirer-
ProtocolParameters
ApplicationParameters AcceptorConfigurationUpdate.Dataset.Content.Application-
Parameters
ApplicationParametersSubsetCreation AcceptorConfigurationUpdate.Dataset.Content.Application-
Parameters
KeyDownload AcceptorConfigurationUpdate.Dataset.Content.Security-Parameters
KeyManagement AcceptorConfigurationUpdate.Dataset.Content.Security-Parameters
Reporting None
SoftwareModule None
TMSProtocolParameters AcceptorConfigurationUpdate.Dataset.Content.TMSProtocol-
Parameters
MerchantParameters AcceptorConfigurationUpdate.Dataset.Content.Merchant-Parameters
TerminalParameters AcceptorConfigurationUpdate.Dataset.Content.Terminal-Parameters
CertificateParameters CertificateManagementResponse.ServerCertificate
CertificateManagementResponse.ServerCertificateIdentifier
CertificateManagementResponse.ClientCertificate
SaleToPOIParameters AcceptorConfigurationUpdate.Dataset.Content.SaleToPOI-
Parameters
2232
2233 7.6 MaintenanceDelegationRequest (catm.005)

2234
2235 The MaintenanceDelegationRequest message contains the following information:
2236
Lvl MaintenanceDelegationRequest Mult. Rule Cstr Usage
1 Header [0..1 Information related to the protocol
] management.
<Hdr>
2 ProtocolVersion [1..1 * The version compliant with this release of the
2 ExchangeIdentification [0..1 * Identification of the exchange (request,
] response).
Must be present.
<XchgId>::Number
283 Page 139


2 CreationDateTime [1..1 Date and time at which the message was
] sent.
]
<InitgPty>
]
]
]
]
2 RecipientParty [0..1 See StatusReport
]
<RcptPty>
]
]
]
]
3 RemoteAccess [0..1 * Access information to reach the target host.
]
Must be present in case of
MaintenanceDelegationRequest.
<RmotAccs>
1 MaintenanceDelegationRequest [1..1 Information related to the request of
] maintenance delegations.
<MntncDlgtnReq>
2 TMIdentification [1..1 Identification of the Terminal Manager
] requesting the delegation.
See StatusReport
<TMId>
]
]
]
285 Page 140


]
2 MasterTMIdentification [0..1 Identification of the Master Terminal Manager
] managing the terminal estate.
See StatusReport
<MstrTMId>
]
]
]
]
2 RequestedDelegation [1..*] Information on the delegation of a
maintenance action or maintenance function.
<ReqdDlgtn>
3 DelegationType [1..1 Type of delegation action.
]
CREACreate.
UPDT Update.
DELT Delete.
<DlgtnTp>::TerminalManagementAction3Cod
e
3 MaintenanceService [1..*] C1 Maintenance service to be delegated.
AcquirerParameters: Configuration
parameters of the
payment acquirer
protocol.
ApplicationParameters: Configuration
parameters of an
application.
ApplicationParametersSubsetCreation:
Creation of a subset of
the configuration
parameters of an
application.
CertficateParamleters: Certificate
provided by a terminal
manager
KeyDownload: Download of
cryptographic keys with
the related information.
KeyManagement: Activate, deactivate or
revoke loaded
287 Page 141

cryptographic keys.
MerchantParameters: hant
configuration
of interaction (POI).
Reporting: Reporting on activity,
status and error of a
SoftwareModule: Software module
update.
TerminalParameters: Point of interaction
parameters attached to
the terminal as serial
number or physical
capabilities.
TMSProtocolParameters Configuration
parameters for the TMS
protocol.
SaleToPOIProtocolParameters
Configuration
parameters for the
connection to the ECR
or UAT
If DelegationType equals DELETE the
MaintenanceService value is not relevant
3 PartialDelegation [0..1 Flag to indicate that the delegated
] maintenance must be performed on a subset
of the terminal estate.
Default False
If PartialDelegation is True and POISubset is
absent then the Delegation may apply to any
POI belonging to the MTM.
If PartialDelegation is False and POISubset is
absent then the Delegation applies to any
POI belonging to the MTM.
<PrtlDlgtn>::TrueFalseIndicator
3 POISubset [0..*] Subset of the terminal estate for the
delegation.
The subset may be expressed as a list of POI
or terminal estate subset identifier.
<POISubset>::Max35Text
3 DelegatedAction [0..1 Information for the MTM to build or include
] delegated actions in the management plan of
the POI.
289 Page 142

<DlgtdActn>
4 PeriodicAction [0..1 Flag to indicate that the delegated actions
] have to be included in a periodic sequence of
actions.
Default False
<PrdcActn>::TrueFalseIndicator
4 TMRemoteAccess [0..1 Network address and parameters of the
] terminal manager host which will perform the
delegated actions.
<TMRmotAccs>
4 TMSProtocol [0..1 TMS protocol to use to perform the
] maintenance action.
<TMSPrtcol>::Max35Text
4 [0..1 Version of the TMS protocol to use to perform
TMSProtocolVersion ] the maintenance action.
<TMSPrtcolVrsn>::Max35Text
4 [0..1 Data set on which the delegated action has to
DataSetIdentification ] be performed.
<DataSetId>
5 Name [0..1 <Nm>::Max256Text
]
]
"AcquirerParameters":
AcquirerProtocolParameters,
HostCommunicationParameters,
ApplicationParameters and
MerchantParameters are present if they
need to be created or replaced.
"ApplicationParameters" if only
ApplicationParameters is present.
"MerchantParameters" if only
MerchantParameters is present.
"Parameters" for any combination of
parameters in the message.
"TerminalParameters" if only
TerminalParameters is present.
"SecurityParameters" if only
SecurityParameters is present.
291 Page 143


]
5 [0..1 <CreDtTm>::ISODateTime
CreationDateTime ]
4 ReTry [0..1 Definition of retry process when activation of
] the action fails.
<ReTry>
5 Delay [1..1 <Dely>::Max9NumericText
]
5 [0..1 <MaxNb>::Number
MaximumNumber ]
4 [0..*] Additional information to include in the
AdditionalInformation maintenance action.
<AddtlInf>::Max3000Binary
4 Action [0..*] Sequence of action to include in the next
MTM management plan.
see ManagementPlanReplacement
<Actn>
5 Type [1..1 <Tp>::TerminalManagementAction4Code
]
5 [0..1 Based on type NetworkParameters.
RemoteAccess ]
<RmotAccs>
5 Key [0..*] Identification of Key to use to perform the
Action.
<Key>
6 [1..1 <KeyId>::Max140Text
KeyIdentification ]
6 [1..1 <KeyVrsn>::Max140Text
KeyVersion ]
6 [0..1 <SeqNb>::Number
SequenceNumber ]
6 [0..1 <Tp>::CryptographicKeyType3Code
Type ]
6 [0..*] <Fctn>::KeyUsage1Code
Function
[0..1 Appli <TermnlMgrId>
TerminalManager- ]
Identification
6 [1..1 <Id>::Max35Text
Identification ]
6 [0..1 <Tp>::PartyType5Code
293 Page 144


Type ]
6 [0..1 <Issr>::PartyType6Code
Issuer ]
Country ]
ShortName ]
5 [0..1 <TMSPrtcol>::Max35Text
TMSProtocol ]
5 [0..1 <TMSPrtcolVrsn>::Max35Text
TMSProtocolVersion ]
5 [0..1 Appli <DataSetId>
DataSetIdentification ]
6 [0..1 Appli C2 At least one DataSetIdentification must be
Name ] present with Name and Type equals to
ManagementPlan
<Nm>::Max256Text
6 [1..1 C2 At least one DataSetIdentification must be
Type ] present with Name and Type equals to
ManagementPlan
6 [0..1 <Vrsn>::Max256Text
Version ]
6 [0..1 Appli <CreDtTm>::ISODateTime
CreationDateTime ]
5 [0..*] <CmpntTp>::DataSetCategory12Code
ComponentType
DelegationScope- ] assigned by the MTM.
Identification
5 [0..1 Definition of the delegation scope, for
DelegationScopeDefinition ] instance inside the payment application
parameters the range of application profiles,
the RID (Registered application provider
IDentification).
5 [0..1 <DlgtnProof>::Max5000Binary
DelegationProof ]
5 [0..1 <PrtctdDlgtnProof>
ProtectedDelegationProof ]
5 Trigger [1..1 <Trggr>::TerminalManagementActionTrigger
] 1Code
5 [0..*] <AddtlPrc>::TerminalManagementAdditional
AdditionalProcess Process1Code
295 Page 145


5 ReTry [0..1 Should be present with the default value
] expected by the TM
<ReTry>
6 [1..1 <Dely>::Max9NumericText
Delay ]
6 [0..1 <MaxNb>::Number
MaximumNumber ]
5 [0..1 Should be present with the default value
TimeCondition ] expected by the TM
<TmCond>
6 [0..1 <WtgTm>::Max9NumericText
WaitingTime ]
6 [0..1 <StartTm>::ISODateTime
StartTime ]
6 [0..1 <EndTm>::ISODateTime
EndTime ]
6 [0..1 Should not be present
Period ]
6 [0..1 Should not be present
MaximumNumber ]
<MaxNb>::Number
5 [0..1 <TMChllng>::Max140Binary
TMChallenge ]
[0..*] <KeyNcphrmntCert>::Max10KBinary
KeyEncipherment-
Certificate
5 ErrorAction [0..*] <ErrActn>
6 [1..*] <ActnRslt>::TerminalManagementActionRes
ActionResult ult4Code
6 [1..1 <ActnToPrc>::TerminalManagementErrorActi
ActionToProcess ] on2Code
5 [0..*] <AddtlInf>::Max3000Binary
AdditionalInformation
5 [0..*] <MsgItm>
MessageItem
6 [1..1 <Cond>::MessageItemCondition1Code
Condition ]
6 [0..*] <Val>::Max140Text
Value
] assigned by the MTM.
DelegationScopeIdentification
297 Page 146


3 DelegationScopeDefinition [0..1 Definition of the delegation scope, for
] instance inside the payment application
the RID (registered application provider
identification).
3 Certificate [0..*] Certificate path of the terminal manager.
<Cert>::Max10KBinary
3 [0..*] Association of the TM identifier and the MTM
identifier of a POI.
POIIdentificationAssociation
<POIIdAssoctn>
4 [1..1 Identifier for the master terminal manager.
MasterTMIdentification ]
<MstrTMId>::Max35Text
4 TMIdentification [1..1 Identifier for the terminal manager requesting
] the delegation.
<TMId>::Max35Text
3 SymmetricKey [0..*] Identification of the key to manage or to
download.
see ManagementPlanReplacement
<SmmtrcKey>
4 KeyIdentification [1..1 <KeyId>::Max140Text
]
4 KeyVersion [1..1 <KeyVrsn>::Max140Text
]
4 SequenceNumber [0..1 <SeqNb>::Number
]
4 Type [0..1 <Tp>::CryptographicKeyType3Code
]
4 Function [0..*] <Fctn>::KeyUsage1Code
3 ParameterDataSet [0..1 * Configuration parameters of the Terminal
] Manager to be sent by the MTM.
see AcceptorConfigurationUpdate/dataset
Same constraints than
AcceptorConfigurationUpdate applies here
also
<ParamDataSet>
299 Page 147


1 SecurityTrailer [1..1 This element is computed as a request
] message.
<SctyTrlr>
2237

2239
2240 This chapter lists all business rules regarding the MaintenanceDelegationRequest.
2241
2242
Number
C1 If a MaintenanceService is required on  RequestedDelegation.MaintenanceServi
ApplicationParameters, a ce.
MaintenanceService on
AcquirerParameters must also be
expected
C2 In a MaintenanceDelegationRequest at  DataSetIdentification.Name
least one DataSetIdentification must
 DataSetIdentification.Type
be present with a Name and Type
equals to ManagementPlan
2243
301 Page 148

2244 7.7 MaintenanceDelegationResponse (catm.006)

2245 The master terminal manager provides the outcome of a maintenance delegation request to a terminal
2246 manager.
2247 The MaintenanceDelegationResponse message contains the following information:
2248
Lvl MaintenanceDelegationResponse Mult. Rule Cstr Usage
1 Header [1..1 Maintenance delegation response message
] management information.
<Hdr>
2 ProtocolVersion [1..1 Copy * The version compliant with this release of the
2 ExchangeIdentification [0..1 Copy * Must be present.
]
<XchgId>::Number
] sent.
2 InitiatingParty [1..1 Copy <InitgPty>
]
]
]
]
]
2 RecipientParty [0..1 <RcptPty>
]
3 Identification [1..1 Copy from the request
]
<Id>::Max35Text
3 Issuer [0..1 Copy from the request
]
3 Country [0..1 Copy from the request
]
]
]
303 Page 149

<RmotAccs>
1 MaintenanceDelegationResponse [1..1 Information related to the request of
] maintenance delegations.
<MntncDlgtnRspn>
2 TMIdentification [1..1 Copy Identification of the Terminal Manager
] requesting the delegation.
See StatusReport
<TMId>
]
]
]
]
2 MasterTMIdentification [0..1 Copy Identification of the Master Terminal Manager
] managing the terminal estate.
See StatusReport
<MstrTMId>
]
]
]
]
2 DelegationResponse [1..*] Information on the delegation of a
maintenance action or maintenance function.
<DlgtnRspn>
3 MaintenanceService [1..*] Copy Requested maintenance service to be
delegated.
3 Response [1..1 Response of the MTM to the delegation of the
] maintenance service.
Approved: Service has been successfuly
provided.
Declined: Service is declined.
<Rspn>::Response2Code
305 Page 150


3 ResponseReason [0..1 Reason of the response of the MTM.
]
<RspnRsn>::Max35Text
3 DelegationType [1..1 Type of delegation action.
]
CREACreate.
UPDT Update.
DELT Delete.
<DlgtnTp>::TerminalManagementAction3Cod
e
3 POISubset [0..*] <POISubset>::Max35Text
] assigned by the MTM.
DelegationScopeIdentification
3 DelegationScopeDefinition [0..1 Definition of the delegation scope, for
] instance inside the payment application
the RID (registered application provider
identification).
3 DelegationProof [0..1 Proof of delegation to be verified by the POI,
] when performing the delegated actions.
3 ProtectedDelegationProof [0..1 Protected proof of delegation.
]
<PrtctdDlgtnProof>
3 [0..*] <POIIdAssoctn>
POIIdentificationAssociation
4 [1..1 Identifier for the master terminal manager.
MasterTMIdentification ]
<MstrTMId>::Max35Text
4 TMIdentification [1..1 Identifier for the terminal manager requesting
] the delegation.
<TMId>::Max35Text
1 SecurityTrailer [0..1 * Must be present
]
message.
<SctyTrlr>
2249
307 Page 151

2250 8 Certificate Management

2251

2253 The CertificateManagementRequest message is sent by a POI terminal or any intermediary entity:
2254  to the terminal manager acting as a Certificate Authority for managing X.509 certificate of a public
2255 key owned by the initiating party, or
2256  for requesting the inclusion or the removal of the POI to a white list of the terminal manager.
2257 This message can be triggered through a ManagementPlanReplacement requesting an Action with Type
2258 equals as "Upload" and DataSetIdentification.Type equals to “CertificateManagementRequest”.
2259
2260 The CertificateManagementResponse is sent by a terminal manager in response to a
2261 CertificateManagementRequest to provide the outcome of the requested service.
2262
2263 8.1.1 Certificate Creation

2264 A POI terminal or any intermediary entity request the creation of an X.509 certificate with the public key and
2265 the information of the owner of the asymmetric key provided by the requestor.
2266
2267 The CertificateManagementRequest message body contains:
2268  POIIdentification, containing the identification assigned by the Master Terminal Manager as defined
2269 in 7.3.4.
2270  Optionally TMIdentification (which is mandatory in the response)
2271  CertificateService with the value CreateCertificate,
2272 The public key of the asymmetric key and the information of the owner are provided
2273 - Either (cf Constraints C5 and C1):
2274  In BinaryCertificationRequest, which is the DER or PEM of the PKCS#10 Certificate Signing
2275 Request.
2276  Or in the CertificateRequestInformation data structure.
2277 The CertificateRequestInformation data structure, and partially BinaryCertificationRequest, contains:
2278  The attributes to included in the X.509 certificate to build which may contain at least:
2279  OrganisationName with the name of the manufacturer,
2280  OrganisationUnitName with the model of POI terminal
2281  CommonName with the serial number of the POI terminal
2282 - Optionally other attributes to put as extension of the certificate to create.
2283 - The public key PublicKeyValue, which is an RSA key (Algorithm) in the data structure
2284 SubjectPublicKeyInformation.
2285 These information must be signed with a digital signature:
2286 - In the BinaryCertificationRequest PKCS#10 structure, using the asymmetric key to certified.
2287 - In the SecurityTrailer/SignedData, using the identification of the key provided inside
2288 CertificateRequestInformation (KeyIdentification and KeyVersion), with the asymmetric key to certified
2289 or any other key recognised by the TM (Cf. Constraint C4).
2290
309 Page 152

2291 The CertificateManagementResponse message body contains:

2292 - A copy of POIIdentification.
2293 - TMIdentification.
2294 - Result containing the outcome of the performed service.
2295 - SecurityProfile (to be better defined)
2296 - The created certificate in ClientCertificate.
2297 - The sequence of X.509 certificates from the CA signing the client certificate to the root certificate in
2298 CertificatePath.
2299
2300 In order to manage errors occurring during the communication of the CertificateManagementResponse
2301 message, the TM must provide an approved response, even if the certificate has been already created.
2302
2303 8.1.2 Certificate Renewal

2304 The POI terminal or the intermediary entity request the renewal of an X.509 certificate with the public key of
2305 the asymmetric key provided by the requestor.
2306
2308 - POIIdentification, containing the identification assigned by the Master Terminal Manager as defined in
2309 7.3.4.
2310 - Optionally TMIdentification
2311 - CertificateService with the value RenewCertificate,
2312 - The certificate to renew in ClientCertificate.
2313 The public key of the asymmetric key and the information of the owner are provided either:
2314 - In BinaryCertificationRequest, which is the DER or PEM of the PKCS#10 Certificate Signing Request.
2315 - In the CertificateRequestInformation data structure.
2316 The CertificateRequestInformation data structure, and partially BinaryCertificationRequest, contains:
2317 - The public key PublicKeyValue of the new certificate to create, which is an RSA key (Algorithm) in the
2318 data structure SubjectPublicKeyInformation.
2319 This information must be signed with a digital signature:
2320 - In the BinaryCertificationRequest PKCS#10 structure,
2322 CertificateRequestInformation (KeyIdentification and KeyVersion), with the asymmetric key of the
2323 certificate to renew or any other key recognised by the TM (Cf Constraint C4).
2324
311 Page 153

2325
2326
2331 - SecurityProfile
2332 - The renewed certificate in ClientCertificate.
2333 - Optionally, the sequence of X.509 certificates from the CA signing the client certificate to the root
2334 certificate in CertificatePath.
2335
2336 In order to manage errors occurring during the communication of the CertificateManagementResponse
2337 message, the TM must provide an approved response, even if the certificate has been already renewed.
2338
2339
2340
2341 8.1.3 Certificate Revocation

2342 The POI terminal or the intermediary entity request the revocation of an already created X.509 certificate.
2343
2346 7.3.4.
2348 - CertificateService with the value RevokeCertificate,
2349 - The certificate to revoke in ClientCertificate.
2350 This information must be signed with a digital signature:
2352 CertificateRequestInformation (KeyIdentification and KeyVersion), with the asymmetric key of the
2353 certificate to revoke or any other key recognised by the TM (Cf constraint C4).
2354
2359
2360
313 Page 154

2361
2362 8.1.4 White List Insertion

2363 The POI terminal or the intermediary entity request the insertion of the POI on a white list of the Terminal
2364 Manager.
2365
2368 7.3.4.
2370 - CertificateService with the value AddWhiteList,
2371 - The identification of the POI terminal in WhiteListIdentification:
2372  The identifier of the terminal manufacturer in ManufacturerIdentifier,
2373  The identifier of the model in Model,
2374  The serial number of the the POI terminal in SerialNumber.
2375
2380
2381
2382 8.1.5 White List Removal

2383 The POI terminal or the intermediary entity request the removal of the POI on a white list of the Terminal
2384 Manager.
2385
2388 7.3.4.
2390 - CertificateService with the value RemoveWhiteList,
2391 - The identification of the POI terminal in WhiteListIdentification:
2392  The identifier of the terminal manufacturer in ManufacturerIdentifier,
2393  The identifier of the model in Model,
2394  The serial number of the the POI terminal in SerialNumber.
2395
315 Page 155

2400
2401 8.2 CertificateManagementRequest (catm.007)

2402
Lvl CertificateManagementRequest Mult. Rule Cstr Usage
] management.
<Hdr>
2 ProtocolVersion [1..1 * The version compliant with this release of the
2 ExchangeIdentification [0..1 * Identification of the exchange (request,
] response).
Must be present.
<XchgId>::Number
] sent.
]
<InitgPty>
3 Identification [1..1 C6 <Id>::Max35Text
]
]
]
]
]
<RcptPty>
]
]
]
]
]
<RmotAccs>
317 Page 156


1 CertificateManagementRequest [1..1 Information related to the request of
] certificate managements.
<CertMgmtReq>
2 POIIdentification [1..1 Identification of the terminal or system using
] the certificate management service.
<POIId>
3 Identification [1..1 C6 <Id>::Max35Text
]
]
]
]
2 TMIdentification [0..1 Identification of the TM or the MTM providing
] the Certificate Authority service.
See StatusReport
<TMId>
]
]
]
]
2 CertificateService [1..1 Confi C1 Requested certificate management service.
] g
C2 WLSA AddWhiteList
C3 Add a POI in the white list of the
terminal manager.
CRTC CreateCertificate
Creation of an X.509 certificate
with the public key and the
information of the owner of the
asymmetric key provided by the
requestor.
WLSR RemoveWhiteList
Remove a POI from the white
list of the terminal manager.
CRTR RenewCerificate
Renewal of an X.509 certificate,
protected by the certificate to
renew.
CRTK RevokeCertificate
Revocation of an active X.509
319 Page 157

certificate.
<CertSvc>::CardPaymentServiceType10Cod
e
2 SecurityDomain [0..1 Confi Identification of the client and server public
] g key infrastructures containing the certificate.
In addition, it may identify specific
requirements of the customer.
<SctyDomn>::Max70Text
2 BinaryCertificationRequest [0..1 Appli C1 PKCS#10 (Public Key Certificate Standard
] Confi 10) certification request coded in base64
C5
g ASN.1/DER (Abstract Syntax Notation 1,
C4 Distinguished Encoding Rules) or PEM
(Privacy Enhanced Message) format.
<BinryCertfctnReq>::Max20000Text
2 CertificationRequest [0..1 Appli C1 Certification request data structure with
] Confi PKCS#10 (Public Key Certificate Standard
C5
g 10) information for creation or renewal of an
C4 X.509 certificate.
<CertfctnReq>
3 [1..1 Information of the certificate to create.
]
CertificateRequestInformation <CertReqInf>
4 Version [0..1 Version of the certificate request information
] data structure.
<Vrsn>::Number
4 SubjectName [0..1 Distinguished name of the certificate subject,
] the entity whose public key is to be certified.
<SbjtNm>
5 [1..*] <RltvDstngshdNm>
RelativeDistinguishedName
6 [1..1 C2 <AttrTp>::AttributeType1Code
AttributeType ]
6 [1..1 <AttrVal>::Max140Text
AttributeValue ]
4 SubjectPublicKey- [1..1 Information about the public key being
Information ] certified.
<SbjtPblcKeyInf>
5 Algorithm [0..1 Asymmetric cryptographic algorithm.ERSA
] RSAEncryption
<Algo>::Algorithm7Code
321 Page 158


5 [1..1 Public key value.
PublicKeyValue ]
<PblcKeyVal>
6 [1..1 <Mdlus>::Max5000Binary
Modulus ]
6 [1..1 <Expnt>::Max5000Binary
Exponent ]
4 Attribute [1..*] Attribute of the certificate service to be put in
the certificate extensions, or to be used for
the request.
<Attr>
5 [1..1 X509 attribute.
AttributeType ]
CHLG ChallengePassword
Password by which an entity
may request certificate
revocation
EMAL EmailAddress
Email address of the certificate
subject.
<AttrTp>::AttributeType2Code
5 [1..1 Value of the X500 attribute.
AttributeValue ]
<AttrVal>::Max140Text
3 KeyIdentification [0..1 Identification of the key.
]
<KeyId>::Max140Text
3 KeyVersion [0..1 Version of the key.
]
<KeyVrsn>::Max140Text
2 ClientCertificate [0..1 C3 Created certificate. The certificate is
] ASN.1/DER encoded, for renewal or
revocation of certificate.
<ClntCert>::Max10KBinary
2 WhiteListIdentification [0..1 Appli Identification of the white list element, for
] white list addition or removal.
<WhtListId>
3 ManufacturerIdentifier [1..1 Identifier of the terminal manufacturer.
]
<ManfctrIdr>::Max35Text
3 Model [1..1 Identifier of the terminal model.
]
<Mdl>::Max35Text
323 Page 159


3 SerialNumber [1..1 Serial number of the terminal manufacturer.
]
<SrlNb>::Max35Text
1 SecurityTrailer [0..1 Confi * Must be present
] g C4 This element is computed as a request
message.
<SctyTrlr>
2403
2404
325 Page 160

2405

2407
2409
2410
Number
C1 In case of Certificate Creation or Renewal, the  CertificateManagement.CertificateService
BinaryCertificationRequest or the  CertificateManagement.BinaryCertificationRequest
CertificateRequest must be present
 CertificateManagement.CertificateRequest
C2 In case of Certificate Creation or Renewal, and if  CertificateManagement.CertificateService
the CertificateRequest is present, the following  CertificateManagement.CertificateRequest.
AttributeType must be present OrganisationName,
 CertificateManagement.CertificateRequest.Certificat
OrganisationUnitName and CommonName
eRequestInformation.Attribute.
C3 In case of Certificate Renewal or Revocation, the  CertificateManagement.CertificateService
ClientCertificate must be present, otherwise it must  CertificateManagement.ClientCertificate
be absent
C4 If the CertificateManagementRequest contains a  CertificateRequestInformationBinaryCertificationReq
CertificateRequest, the SecurityTrailer.ContentType uest
must be SignedData  CertificationRequest
 SecurityTrailer.ContentType
C5 BinaryCertificationRequest and CertificateRequest  CertificateManagement.BinaryCertificationRequest
must not be present simultaneously  CertificateManagement.CertificateRequest
C6 Identification of InitiatingParty must be the same  Header.InitiatingParty.Identification
 CertificationManagementRequest.POIID.
Identification
2411
2412 8.3 CertificateManagementResponse (catm.008)

2413
Lvl CertificateManagementResponse Mult. Rule Cstr Usage
] management.
<Hdr>
2 ProtocolVersion [1..1 Copy * The version compliant with this release of the
2 ExchangeIdentification [0..1 Copy * Identification of the exchange (request,
] response).
Must be present.
<XchgId>::Number
] sent.
327 Page 161


2 InitiatingParty [1..1 Copy See StatusReport
]
<InitgPty>
]
]
]
]
]
<RcptPty>
]
]
]
]
]
<RmotAccs>
1 CertificateManagementResponse [1..1 Information related to response to the request
] of Certificate management.
<CertMgmtRspn>
2 POIIdentification [1..1 Identification of the terminal or system using
] the certificate management service.
<POIId>
]
]
]
]
329 Page 162


2 TMIdentification [0..1 * Identification of the TM or the MTM providing
] the Certificate Authority service.
See StatusReport
Must be present
<TMId>
]
]
]
]
2 CertificateService [1..1 Requested certificate management service.
]
<CertSvc>::CardPaymentServiceType10Cod
e
2 Result [1..1 Outcome of the certificate service processing.
]
<Rslt>
3 Response [1..1 C4 Response of the terminal manager.
]
<Rspn>::Response2Code
3 ResponseDetail [0..1 Detail of the response.
]
CRTU UnknownCertificate
The certificate is unknown.
SVSU UnsupportedService
Requested service not
supported.
<RspnDtl>::ResultDetail3Code
3 AdditionalResponse [0..1 Additional information about the result.
]
<AddtlRspn>::Max140Text
2 SecurityProfile [0..1 Identification of the security profile, for
] creation, renewal or revocation of certificate.
<SctyPrfl>::Max35Text
2 ClientCertificate [0..1 C4 Created certificate. The certificate is
] ASN.1/DER encoded, for renewal or
revocation of certificate.
<ClntCert>::Max3000Binary
331 Page 163


2 ClientCertificatePath [0..*] C4 Certificate of the client certificate path, from
the CA (Certificate Authority) certificate, to
the root certificate, for renewal or revocation
of certificate.
<ClntCertPth>::Max10KBinary
2 ServerCertificatePath [0..*] C4 Certificate of the server certificate path, from
the CA (Certificate Authority) certificate, to
the root certificate, for renewal or revocation
of certificate.
<SvrCertPth>::Max10KBinary
1 SecurityTrailer [0..1 * Must be present if present in the request
]
message.
<SctyTrlr>
2414
2415

2417
2419
2420
Number
C4 In case of Approved result on certificate, the  CertificateManagementResponse.CertificateService
ClientCertificate, ClientCertificatePath and  CertificateManagementResponse.ClientCertificate
ServerCertificatePath must be present, and must be
 CertificateManagementResponse.Result
absent otherwise
 CertificateManagementResponse.ClientCertificateP
ath
 CertificateManagementResponse.ServerCertificateP
ath
2421
333 Page 164

2422 9 Alternative Message Exchanges

2423 The Message Definition Report of the TMS protocol is describing the TMS messages without mentioning the
2424 transport mechanism used to exchange the data.
2425 The transport mechanism used may vary for each message but only the following alternatives are described
2426 in the document:
2427 1. Message Exchange only (see section 9.1):
2428 o StatusReport as request and ManagementPlanReplacement as response message
2429 o StatusReport as request and AcceptorConfigurationUpdate as response message
2430 2. File Transfer only (see section 9.2):
2431 o StatusReport uploaded per file transfer protocol
2432 o ManagementPlanReplacement downloaded per file transfer protocol
2433 o AcceptorConfigurationUpdate downloaded per file transfer protocol
2434 3. Message Exchange and File Transfer (see section 9.4):
2435 o StatusReport as request and ManagementPlanReplacement as response message
2436 o AcceptorConfigurationUpdate downloaded per file transfer protocol
2437 Depending on the applied transport protocol the contents of some message element may differ (e.g.
2438 DataSetRequired in the StatusReport, Action.DataSetIdentification.Name in the
2439 ManagementPlanReplacement and the cryptographic mechanism used in the SecurityTrailer).
2440
2441 Currently, the following messages are Message Exchange only.
2442  MaintenanceDelegationRequest
2443  MaintenanceDelegationResponse
2444  CertificateManagement
2445  CertificateManagementResponse,
2446  TerminalManagementRejection.
2447
2448 9.1 Message Exchange only

2449 This section describes the TMS protocol and the handling of the messages by the POI and TMS if the
2450 StatusReport, the ManagementPlanReplacement and the AcceptorConfigurationUpdate are exchanged as
2451 messages only.
2452 The StatusReport message is used to request either the response messages
2453  ManagementPlanReplacement or
2454  AcceptorConfigurationUpdate.
2455 The ManagementPlanReplacement response message is requested by the POI using the StatusReport
2456 message containing the message element DataSetRequired. The type of message in the
2457 DataSetIdentification is "ManagementPlan" then.
2458 The AcceptorConfigurationUpdate response message is requested by the POI using the StatusReport
2459 message containing the message element DataSetRequired. The Type of dataset in the
2460 DataSetIdentification is e.g "AcquirerParameters" or "ApplicationParameters".
335 Page 165

2461 The diagram in figure 15 shows the scenario described above. The card acceptor establishes a
2462 communication session manually.
2463 The POI sends the StatusReport to inform the MTM about the parameter versions already installed and
2464 receives in the response the management plan generated by the MTM. The new management plan contains
2465 a list of actions to be performed:
2466 1. The StatusReport as request for AcceptorConfigurationUpdate containing the new acquirer
2467 parameters.
2468 2. The StatusReport as request for a new management plan.
2469 If the trigger of the first action is reached the POI sends the StatusReport and receives the new acquirer
2470 parameters in the response. Afterwards the POI sends a StatusReport as request message with the result of
2471 the parameter update and gets back the new management plan in the response.
2472
2473
2474
POI MTM
POI initiates terminal 1
StatusReport
management
2
nReplacement
ManagementPla
StatusReport
3
4
ationUpdate
AcceptorConfigur
StatusReport
5
6
Replacement
ManagementPlan
2475
2476 Figure 15: TMS messages transferred as message exchanges
2477
2478 9.1.1 Upload StatusReport

2479 A StatusReport is sent when:
2480 The action Upload StatusReport is initiated when the StartTime in the message element TimeCondition is
2481 reached.
2482 The action requests the download of a management plan or a parameters download.
2483 The POI processing for sending a StatusReport to a Terminal Manager is the following one:
2484 1. The timing conditions of all outstanding TMS actions are analysed.
2485 2. If a StartTime is reached for the upload of the StatusReport, this action is initiated.
2486 3. The POI builds MessageBody, optionally the SecurityTrailer and MessageHeader of the
2487 StatusReport file as described in section 3.2.
2488 4. The POI sends the message to the TMS using the address defined in the TMS action or the local
2489 configuration of the POI.
337 Page 166

2490
2491 9.1.2 ManagementPlanReplacement

2492 The response message contains the new management plan. The POI replaces the current management plan
2493 and analyses the new one.
2494 The new Management plan may contain several actions:
2495  actions to request new parameters with an absolute start time.
2496  the sending of a status report after WaitingTime
2497  the sending of a status report at a given StartTime
2498  the last action instructs to request a new management plan
2499 9.1.2.1 Processing of the ManagementPlanReplacement

2500
2501 1. The POI checks the optional signature of the received message.
2502 2. The POI stores the version of the management plan in the log of Event.
2503 3. CreationDate is used to identify the management plan.
2504 4. The list of TMS actions in Action is analysed:
2505  The actions are analysed for correctness
2506  The presence of mandatory data elements is checked
2507  All existing data elements have to be correctly formatted.
2508  The validation of the dataset is performed according to section 4.2 but the data element
2509 Identification.Name must exist for each download.
2510
2511 9.1.2.2 Excecution of the ManagementPlanReplacement

2512 The ManagementPlanReplacement contents complies with the contents described in section 4.
2513
2514 ManagementPlanReplacement (example 1)
2515
StartTime WaitingTime Period Type Identification.Name Identification.Type
T0 - - Download AcquirerParameters
D1 Download ManagementPlan
2516
2517 1. The POI requests acquirer parameters when the StartTime T0 is reached.
2518 2. If the response message containing the acquirer parameters is processed by the POI the POI sends the
2519 result of the parameter update to the TMS after a waiting time D1 and receives a new management plan
2520 in the response message.
2521
2522
339 Page 167

2523
2524 ManagementPlanReplacement (example 2).
2525
T0 - Cycle1 Download - AcquirerParameters
D1 - Download - MerchantParameters
D2 - Download - ManagementPlan
2526
2527 1. The POI requests acquirer parameters when the StartTime T0 is reached.
2528 2. If the response message containing the acquirer parameters is processed the POI requests merchant
2529 parameters after a waiting time D1.
2530 3. If the response message containing the merchant parameters is processed by the POI the POI sends
2531 the result of the parameter update to the TMS after a waiting time D2 and receives a new management
2532 plan in the response message.
2533
2534 9.2 File Transfer only

2535 This section describes the differences of the TMS protocol and the handling of the messages by the POI and
2536 TMS if the StatusReport and the ManagementPlanReplacement are exchanged as files using FTP.
2537 If the ManagementPlanReplacement file is requested by the POI by the StatusReport the message element
2538 DataSetRequired has to be present to inform the TMS to provide the new ManagementPlanReplacement file
2539 on the corresponding file directory.
2540 If the ManagementPlanReplacement file is downloaded by a file transfer to the POI there is no request
2541 necessary. The message element DataSetRequired is not needed then.
2542 The diagram in figure 16 shows the scenario described above.
2543 The card acceptor establishes a FTP session with the MTM. The POI uploads the StatusReport and
2544 downloads a new management plan.
2545 The new management plan of the MTM contains a list of actions to be performed:
2546 1. The download of several AcceptorConfigurationUpdate files (illustrated as loop of actions)
2547 containing new vendor parameters. The acceptor parameters issued by the vendor are identified
2548 by their file name in the definition of the TMS action.
2549 2. The upload of the StatusReport to the MTM for sending the status of the new parameters.
2550 3. The upload of the StatusReport to one TM for sending the status of the new parameters.
2551 4. The download of the management plan of the TM after a period.
2552 If the trigger of the first action is reached the POI downloads several files containing new acquirer
2553 parameters. Afterwards the POI uploads a StatusReport to the MTM with the result of the download including
2554 the actual version of the acquirer parameter set.
2555 If the trigger of the third action is reached the POI establishes a FTP session with the TM, uploads a
2556 StatusReport and downloads a management plan generated by the TM. The management plan of the TM
2557 contains a list of actions to be performed:
2558 1. The download of several AcceptorConfigurationUpdate files (illustrated as loop of actions)
2559 containing new acquirer parameters. The acceptor parameters issued by the Acquirer are
2560 identified by their file name in the definition of the TMS action.
341 Page 168

2561 2. The upload of the StatusReport to the TM for sending the status of the new parameters.
POI MTM TM
POI initiates terminal 1
StatusReport
management session
2
nReplacement
ManagementPla
Loop (1,*) 1
rationUpdate
AcceptorConfigu
StatusReport
3
POI initiates terminal

management session using 4 StatusReport
TMS action defined byMTM
5
ManagementPlanReplacement
Loop (1,*) 1
te
AcceptorConfigurationUpda
StatusReport
6
2562
2563 Figure 16: TMS messages transferred as files
2564 9.3 Upload of a StatusReport

2565 The action Upload StatusReport is initiated when StartTime in TimeCondition is reached (StartTime =
2566 dd.mm.yyyy hh.mm.ss).
2567 The POI processing for sending a StatusReport to a Terminal Manager is the following one:
2568 1. The timing conditions of all outstanding TMS actions are analysed.
2569 2. If a StartTime is reached for the upload of the "StatusReport" this action must be started. The
2570 StatusReport contains the log of Event containing at least the last twenty events (Last in, first out) if
2571 already existing. The log must never be erased completely.
2572 3. The POI builds the MessageBody and the optional SecurityTrailer of the StatusReport file as
2573 described in section 3.2.
2574 4. The POI builds the header of the file and generates the file name of the report as follows: "SR"
2575 concatenated with the counter converted to six characters (range '0'-'F') and ".XML".
2576 5. The POI performs the login into the TMS FTP server.
2577 a) If the POI is not able to establish the FTP session, it tries it again according to the definition
2578 in ReTry or saves the error directly in the log of Event with the Result "ConnectionError", if
2579 no retry is defined.
2580 b) If a username and AccessCode is needed to login, the POI uses the corresponding data in
2581 the component Address of the TMS action. If the FTP server denies the access the POI
2582 saves the error in the log of Event with the Result "AccessDenied".
2583 c) If the login was successful the POI changes the directory to Rep. This directory may be
2584 presented by the FTP server as a physical or virtual directory dedicated for this POI.
2585 6. The POI uploads the StatusReport to this directory.
343 Page 169

2586 7. If the StartTime or WaitingTime of the next action is shorter than in internally defined period for the
2587 session the FTP session is kept open for the next action.
2588 8. The timing conditions of the remaining actions are analysed. If a StartTime is expired or the delay to
2589 the previous action is reached the action must be started if allowed.
2590 9. If the TimeCondition of the action done contains a Period, the new StartTime is calculated (New
2591 StartTime = StartTime + Period) and stored in the management plan.
2592 10. If no other StartTime is reached the session must be closed.
2593
2594 9.3.1 Download of a ManagementPlanReplacement

2595 The action Download the management plan is initiated when the WaitingTime after the previous action is
2596 reached. The POI analyses the new management plan and replaces the current one if no error has been found.
2597 The new management plan contains several actions:
2598  Actions to download the parameter files with an absolute start time. Usually the parameter files
2599 are downloaded immediately.
2600  Upload of the status report after WaitingTime
2601  Upload of the status report at a given StartTime
2602  The last action instructs to download a new management Plan
2603 9.3.1.1 Processing of a ManagementPlanReplacement

2604
2605 1. The POI performs a login to the TMS FTP server and changes the directory to MgtPlan. The error
2606 handling is performed according to section 9.3.
2607 2. The POI downloads the management plan with the file name taken from the specific action or the default
2608 management plan named MP000000.XML if existing and the file to be downloaded does not exist. If
2609 neither the default management plan nor the specific one exists the POI logs the error in the log of Event
2610 with the Result "MissingFile".
2611 3. The POI checks the optional signature of the received message.
2612 4. The POI checks whether the dataset category present in the Type in the identification corresponds to the
2613 type of file name.
2614 5. The POI stores the version of the management plan in the log of Event.
2615 6. CreationDate is used to identify the management plan.
2616 7. SequenceCounter is used by the TMS to identify all dataset structures with the same CreationDate. It is
2617 used if the dataset is split into several files. SequenceCounter starts with `1`. The last dataset of the
2618 series is identified by the maximum value of the SequenceCounter `9999`.
2619 8. Subsequently the list of Action is analysed.
2620  The actions are analysed for correctness
2621  The presence of mandatory data elements is checked
2622  All existing data elements have to be correctly formatted.
2623  The validation of the files is performed according to section 4.2 but the data element
2624 Identification.Name must exist for each download.
2625
2626
345 Page 170

2627
2628 9.3.1.2 Execution of a ManagementPlanReplacement

2629 A ManagementPlanReplacement complies to the contents described in section 4 with two exceptions:
2630 Rule 7 The Upload of the StatusReport and the Download of the ManagementPlanReplacement are
2631 separate actions, so that the ManagementPlanReplacement is not downloaded after each
2632 StatusReport upload.
2633 Rule 8 The message element Identification.Name must always contain the filename to be downloaded.
2635
2636
T0 - - Upload - StatusReport
D1 - Download PA345678.XML AcquirerParameters
D2 - Download MP123456.XML ManagementPlan
2637 The delays D1 and D2 are set according to the reaction time of the TMS for building the files
2638 AcceptorConfigurationUpdate and ManagementReplacement if the content of these files depend on the
2639 StatusReport.
2640
2641
2643
2644
2645
2646
T0 - Cycle1 Upload - StatusReport
D2 - Download PA567890.XML MerchantParameters
2648
347 Page 171

2649
T0 - Download PA345678.XML MerchantParameters
- D1 Download PA567890.XML AcquirerParameters
- D2 Upload - StatusReport
T1=T0+D4 - Cycle1 Upload - StatusReport
2651
2652 9.4 Message Exchange and File Transfer

2653 The POI may also use different transport protocols for the exchange of the TMS messages.
2654 Figure 17: TMS messages transferred as both messages and fileshows a scenario where the POI sends a
2655 StatusReport as requested and receives a ManagementPlanReplacement as a response. The
2656 AcceptorConfigurationUpdate is downloaded by the POI as a file using the File Transport Protocol. This TMS
2657 session is initiated by the card acceptor since a TMSTrigger in the response message of the acquirer has
2658 been received.
2659
2660 In this scenario the rules for building a management plan by the MTM - as described in section 9.1 for the
2661 StatusReport and ManagementPlanReplacement apply. The rules of section 5.2 for
2662 AcceptorConfigurationUpdate apply as well.
POI MTM Acquirer
AcceptorAuthorisationReques
1 t
AcquirerParameters
2 version expired
AcceptorAuthorisationResponse
TMSTrigger sent
StatusReport
3
4
ent
Download of thenew 5
nUpdate
acquirer parameters is AcceptorConfiguratio
initiated byPOI using an
FTP session
StatusReport
( If defined 1
as final
2
action) ent
2663
2664 Figure 17: TMS messages transferred as both messages and file
2665
349 Page 172

2666 10 Error Handling

2667 Below are some basic rules for handling errors:
2668 ERR1: Ignored if the recipient cannot interpret the message components or elements (actually, not to be
2669 considered as an error).
2670 ERR2: The complete message to be discarded and the event to be logged as "FormatError" (e.g.
2671 alphanumeric or binary instead of numeric) if a component or a message element has the wrong format.
2672 ERR3: The complete message to be discarded and the event to be logged as "SyntaxError" (e.g. missing
2673 ending Tag, missing mandatory element, unexpected attributes) if a parsing error occurs.
2674 ERR4: The complete message to be discarded and the event to be logged as "LengthError" if the message
2675 element or the complete message does not respect the defined length (element or component exceeding the
2676 length or being to short).
2677 ERR5: If a message is requested by the POI and the response is not received after a defined period the
2678 event is logged as "Timeout".
2679
2680
351 Page 173

2681 11 Transport Protocol Services

2682 For the nexo TMS Protocol the transport protocol TCP (Transmission Control Protocol, specified in the RFC
2683 793) or the File Transfer Protocol (FTP) must be used for the transfer of data between the POI and the TMS.
2684 A secure layer on top of these protocols should be used.
2685 FTP is used as download and upload mechanism of the messages described in this document. The POI
2686 System represents the FTP client. The TMS represents the FTP server.
2687 The same filename conventions and structures should be used for other file transport mechanisms (e.g. for a
2688 local update using a USB memory stick).
2689
2690 11.1 File Transfer Protocol

2691 The File Transfer Protocol (FTP4) is the protocol used by the nexo application protocols to transfer files.
2692 This chapter contains the specification of the services of FTP to be implemented by the nexo application
2693 protocols using file transfers.
2694
2695 11.1.1 The FTP Model

2696 FTP is a typical client/server protocol, where the client is the POI and the server the TMS host. The FTP
2697 specifications call the client the user in relation to the person who gets file transfer services.
2698 FTP uses two types of transport connections to provide the file transfer services:
2699 1. The Control Connection, which is established at the creation of the FTP session, and carry on the
2700 command request by the client and the response from the server after the processing of the service.
2701 2. The Data Connection, which is established each time a file has to be exchanged or any data like the
2702 content of a directory. The data connection is release at the end of the transfer.
2703 The set of components of the FTP client and of the FTP server are respectively called User-FTP Process
2704 and Server-FTP Process.
FTP Client
User-FTP Process
User
User Interface
FTP Server
Server-FTP Process
User Protocol Control Connection Server Protocol

Interpreter Interpreter
(User-PI) (Server-PI)
User Data Server Data

File Data Connection File
Transfer Process Transfer Process
System (User-DTP) (Server-DTP) System
2705
2706 Figure 18: The FTP Model
2707
353 4 RFC 959, October 1985, by Jon Postel and Joyce Reynolds
354 Page 174

2708 11.1.1.1 FTP Client Components

2709 The User-FTP Process contains the following components:
2710 The User Interface, which provides an interface to the application protocol. An interface to a human user is
2711 not required.
2712 The User Protocol Interpreter (User-PI), which manages the control connection. After the establishment of
2713 the connection, it processes the command requested by the User Interface and send them to the Server
2714 Protocol Interpreter. In addition, it manages the User Data Transfer Process.
2715 The User Data Transfer Process (User-DTP), which establishes or listens to the data connection at the
2716 request of the User Protocol Interpreter. It sends or receive data using the local file transfer where is
2717 implanted the User-FTP Process.
2718
2719 11.1.1.2 FTP Server Components

2720 The Server-FTP Process contains the following components:
2721 The Server Protocol Interpreter (Server-PI), which manages the control connection. It listens to the FTP
2722 reserved port for incoming connection requests coming from clients. It processes the command requested by
2723 the Client, send response on the control connection, and manages the Server Data Transfer Process.
2724 The Server Data Transfer Process (Server -DTP), which establishes or listens to the data connection at the
2725 request of the Server Protocol Interpreter. It sends or receive data using the local file transfer where is
2726 implanted the Server-FTP Process.
2727
2728 11.2 File Transfer Services

2729 11.2.1 Access Commands
2730 11.2.1.1 Login Sequence

2731 The command USER UserName is the first command transmitted by the client after the establishment of the
2732 control connection.
2733 This UserName must uniquely identify a POI. For instance, UserName may be based on the identification of
2734 the POI as described in the organisation unit and common name (OU used as Modelname concatenated
2735 with CN used as serial number with a possible separator) of the POI certificate subject name also used in the
2736 message header element InitiatingParty.ShortName.
2737
2738 The command PASS Password is not mandatory, other and more appropriate authentication method has to
2739 be employed. Usually the password is equal to the username (e.g. the password is built by the serial number
2740 of the POI terminal concatenated with the merchant identifier).
2741
2742 The command ACCT Account is not used.
2743
2744 11.2.1.2 FTP Session Termination

2745 The command QUIT is used to close the FTP session and is followed by the release of the control
2746 connection by the client after reception of the response.
2747
356 Page 175

2748 The command REIN reinitialises the FTP session without closing it. This command is used when a POI
2749 Server managing several POI, needs to exchange different types of files on the behalf of these POI
2750 Terminals.
2751
2752 11.2.1.3 Directory Positioning

2753 The command CWD DirName is the command the client use to go to the directory where a file has to be
2754 downloaded or uploaded. The directory structure shown below is presented by the TM to POI. The presented
2755 directories may be physical or virtual.
2756 DirName is the path name of the target directory to go to. The structure of an example of the file directory
2757 reachable is presented in the figure below.
UserRoot
/
Acqu TMS
Auth Capt Soft MgtPlan Param Rep

Authorisations Captures Software Management Plan Report
Vendor Mer Acq

Vendor Merchant Acquirer
2758
2759 Figure 19: FTP Server Directory Structure for TMS
2760
2761
2762 11.2.2 FTP Transfer Parameter Commands
2763 11.2.2.1 Data Connection

2764 The command PASV to pass the server in a passive data connection mode is used by default to avoid the
2765 problem of firewall, Network Address Translation, and port change by the client 5. The response at the
2766 command informs to the client the server port to connect to.
2767
2768 The command PORT DataPort and the active data mode is not used.
2769
2770 11.2.2.2 File Type

2771 The binary file type is used for the transfer. The command TYPE is not used.
2772
2773 11.2.2.3 Transfer Mode

2774 The file transfer mode which might be used are:
358 5 See RFC 1579, Firewall-Friendly FTP
359 Page 176

2775  The stream mode if the exchange of data does not require restart of the transfer after the beginning of
2776 the file.
2777  The block mode, if restart might be used if the file transfer does not terminate correctly.
2778 The POI must support the stream mode. The block mode may be used in addition for the file transfer.
2779 The command MODE TransferMode is sent by the Client to inform the stream or block mode to use for the
2780 next transfer.
2781 There is no recommendation for the position of the marker. The stream mode is the preferred solution.
2782
2783 11.2.2.4 File Structure

2784 The file (no record structure) structure is used for the transfer, so the command STRU is not used.
2785
2786 11.2.2.5 File Naming Conventions

2787 The file names contain the following information that are concatenated (min. 8 and max. 32 characters):
2788 - File Type
2789 o "SR" for Status report
2790 o "MP" for Management Plan
2791 o "SW" for Software Modules
2792 o "PA" for Acceptor Configuration (e.g. Vendor, Merchant or Acquirer Parameter)
2793 o "DD" for Delegation Data (e.g. TM certificate)
2794 - Value for the SequenceNumber (Default "00…00")
2795 - ".ASN" for ASN.1 coded and ".XML" for XML coded files.
2796 The sequence number is used to check if a file has to be downloaded:
2797 1. If the sequence number is higher than the existing one the file has to be downloaded.
2798 2. If the sequence number is equal or lower than the last number stored by the POI this sequence
2799 number is not acceptable.
2800 If there is no file with an acceptable sequence number the POI looks for a file with the default
2801 sequence number that can be downloaded instead of.
2802 Therefore the default value for the SequenceNumber is used to synchronise the sequence numbers
2803 present in the POI and TMS (This means that the default sequence number must reset the sequence
2804 number to "00…00"). If the maximum number is reached the TMS system resets the sequence
2805 number also with the default value.
361 Page 177

2806
2807 The following example illustrates the naming convention for a sequence of files if always the default name for
2808 the Management Plan is used:
2809
2810  Download first Management Plan MP000000 containing the Cyclic Call with two TMS actions:
2811 o Upload StatusReport and
2812 o Download Management Plan MP000000 (StartTime plus Period defined).
2813  For a foreseen download of a parameter set the TMS server generates a new Management Plan
2814 MP000000 containing three actions:
2815 1. Upload StatusReport
2816 2. Download Acceptor configuration PA000001
2817 3. Download new Management Plan MP00000 containing only the default actions Upload
2818 StatusReport and Download Management Plan MP000000
2819  For the next download of a new parameter set the TMS server generates a new Management Plan
2820 MP000000 containing three actions:
2821 1. Upload StatusReport
2822 2. Download parameter set PA000002
2823 3. Download new Management Plan MP00000 containing only the default actions Upload
2824 StatusReport and Download Management Plan MP000000
2825 11.2.3 FTP Protocol Service Commands
2826 11.2.3.1 File Transfer

2827 The commands RETR and STOR are used to download and upload files.
2828
2829 The command ALLO is necessary to allocate storage at the server before the transfer of files.
2830
2831 The command REST Mark is used to restart the transfer from the specific marker Mark. This command has
2832 to be immediately followed by a RETR or a STOR command. For the stream mode the restart is not possible.
2833
2834 The command ABOR is used to abort a transfer or a command.
2835
2836 11.2.3.2 Directory Management

2837 The command LIST is used to get the content of a directory.
2838
2839
2840
2841
2842
2843
363 Page 178

2844
2845
365 Page 179

Cape Card Payments Terminal Management Message Usage Guide: 8.0 2nd March 2020

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

Cape Card Payments Terminal Management Message Usage Guide: 8.0 2nd March 2020

Uploaded by

Copyright:

Available Formats

1

1 © 2020 nexo AISBL All rights reserved.

56 5.1 Message Usage................................................................................................................................... 50

96 7.4.4 Distributed Delegation............................................................................................................. 121

159 1.2 References

168 1.3 Terms and Definitions

191 1.4 Conventions.

219 1.5 What’s new in the edition 8.

Encoding of Boolean 1.6.5 Creation

Annex A Examples Updated

224 1.6 Principles.

226 1.6.1 Number encoding

235 1.6.2 Initiating Party.

243 1.6.3 DateAndTime.

247 1.6.4 Encoding of Certificate

359 1.6.5 Encoding of Boolean value.

368 2 Common nexo TMS message principles

383 2.1 CryptographicKey

391 2.2 NetworkParameters

ServerCertificate [0..*] X.509 Certificate required to authenticate the

400 2.3 PointOfInteractionComponent

407 2.3.1 Structure

ProviderIdentification [0..1 Appli Identifies the provider of the software,

37 1 replaces ManufacturerIdentification in version 1.0

Status [0..1 Current status of the component:

Unit [1..1 Unit of the memory size, allowed values:

410 2.3.2 Business Rules Validation

419 3 StatusReport (catm.001)

421 3.1 Message Usage

Lvl StatusReport Mult. Rule Cstr Usage

3 Value is bilaterally agreed between

Lvl StatusReport Mult. Rule Cstr Usage

Based on type NetworkParameters.

Lvl StatusReport Mult. Rule Cstr Usage

Lvl StatusReport Mult. Rule Cstr Usage

Lvl StatusReport Mult. Rule Cstr Usage

Based on type PointOfInteractionComponent

Lvl StatusReport Mult. Rule Cstr Usage

4 If absent when the StatusReport is sent by

Lvl StatusReport Mult. Rule Cstr Usage

Lvl StatusReport Mult. Rule Cstr Usage

Based on type CryptographicKey

4 Events have to be listed in chronological

Lvl StatusReport Mult. Rule Cstr Usage

Lvl StatusReport Mult. Rule Cstr Usage

449 3.2 Message Preparation

491 3.3 Message Processing

514 3.4 Business Rules Validation

521 4 ManagementPlanReplacement (catm.002)

523 4.1 Message Usage

Lvl ManagementPlanReplacement Mult. Rule Cstr Usage

Lvl ManagementPlanReplacement Mult. Rule Cstr Usage

Lvl ManagementPlanReplacement Mult. Rule Cstr Usage

Lvl ManagementPlanReplacement Mult. Rule Cstr Usage

C12 "Bind", "Rebind", "Unbind".

Only present if it is different of the

Lvl ManagementPlanReplacement Mult. Rule Cstr Usage

Lvl ManagementPlanReplacement Mult. Rule Cstr Usage

"MerchantParameters": If only the

Lvl ManagementPlanReplacement Mult. Rule Cstr Usage

Lvl ManagementPlanReplacement Mult. Rule Cstr Usage

"Manual": An operator has to use an

Lvl ManagementPlanReplacement Mult. Rule Cstr Usage