idnits 2.17.1 draft-ietf-trade-iotp-v1.0-papi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Bad filename characters: the document name given in the document, 'draft-ietf-trade-iotp-v1.0-papi-00', contains other characters than digits, lowercase letters and dash. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 141 longer pages, the longest (page 1) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 143 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 6595: '... However, all REQUIRED attributes fr...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 543 has weird spacing: '...s layer e.g. ...' == Line 547 has weird spacing: '... system loc...' == Line 551 has weird spacing: '...inement fut...' == Line 555 has weird spacing: '...ication prov...' == Line 748 has weird spacing: '...m layer user...' == (12 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 2000) is 8802 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PS1' is mentioned on line 3049, but not defined == Missing Reference: 'PSn' is mentioned on line 2858, but not defined == Missing Reference: 'PS2' is mentioned on line 3050, but not defined == Missing Reference: 'RFC1738' is mentioned on line 4242, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'SSL' is mentioned on line 4238, but not defined == Missing Reference: 'XSL' is mentioned on line 6795, but not defined == Unused Reference: 'HTML' is defined on line 6761, but no explicit reference was found in the text == Unused Reference: 'HTTP' is defined on line 6766, but no explicit reference was found in the text == Unused Reference: 'ISO4217' is defined on line 6772, but no explicit reference was found in the text == Unused Reference: 'MIME' is defined on line 6775, but no explicit reference was found in the text == Unused Reference: 'SET' is defined on line 6778, but no explicit reference was found in the text == Unused Reference: 'UTC' is defined on line 6788, but no explicit reference was found in the text -- No information found for draft-ietf-trade-iotp-v1 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RFC XXXX' ** Obsolete normative reference: RFC 1866 (ref. 'HTML') (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO4217' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTC' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 10 errors (**), 0 flaws (~~), 23 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRADE Working Group Werner Hans 2 INTERNET-DRAFT Hans-Bernhard.Beykirch 3 SIZ 4 Masaaki Hiroya 5 Yoshiaki Kawatsura 6 Hitachi 7 Expires: September 2000 March 2000 9 Architecture and Payment API for Internet Open Trading Protocol (IOTP) 10 ------------ --- ------- --- --- -------- ---- ------- -------- ------ 11 13 Status of this Memo 15 This document is intended to become an Internet-Draft and will be in 16 full conformance with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Distribution of this document is unlimited. Please send comments to 35 the TRADE working group at , which may 36 be joined by sending a message with subject "subscribe" to . 39 Discussions of the TRADE working group are archived at 40 http://www.elistx.com/archives/ietf-trade. 42 Abstract 44 The Trading Architecture proposes an abstract layered model of the 45 IOTP based trading environment. Its description sketches the 46 essential functional and data modules and their interfaces at each 47 trading role's installation. This abstract view deals as a guideline 48 for the modules' mapping to actual software modules. 50 The second part of this document focuses on the Payment API that 51 improves the essential interface that relates to payment 52 transactions. Such interface exists at the Consumers', the Merchants' 53 and the Payment Handlers' installations connecting the actual payment 54 software components/legacy systems and the generic IOTP aware front 55 end application. 57 Copyright 59 Copyright (C) The Internet Society 2000. 61 Table of Contents 63 Status of this Memo........................................1 64 Abstract...................................................1 65 Copyright..................................................2 67 Table of Contents..........................................3 68 1. Introduction............................................6 69 1.1 Intended Readership...................................8 70 GENERAL TRADING ARCHITECTURE...............................8 71 2. Trading Architecture....................................8 72 2.1 Overview...............................................8 73 2.1.1 Layers and Components................................9 74 2.1.1.1 Consumer Access - End System Layer................10 75 2.1.1.2 Network Layer.....................................11 76 2.1.1.3 Access Layer......................................11 77 2.1.1.4 Refinement Layer - Integration with IOTP..........11 78 2.1.1.5...................................................12 79 2.1.1.6 Data Layer........................................12 80 2.1.2 Implementation Variants.............................12 81 2.1.3 Component Distribution..............................12 82 2.2 Requirements and Commitments..........................12 83 2.2.1 Basic Requirements..................................13 84 2.2.1.1 Electronic Commerce Provider (Server).............13 85 2.2.2 Security Requirements and Commitments..............13 86 2.2.2.1 Overview about the Security Levels...............13 87 2.2.3 Security Mechanism.................................14 88 2.2.3.1 Transmission Security............................14 89 2.2.3.2 Authentication....................................15 90 2.2.3.3 Document Security.................................15 91 2.2.3.4 Authorization.....................................16 92 2.2.4 Protection against Attacks.........................16 93 2.2.4.1 Consumer System..................................17 94 2.2.4.2 Transmission Line................................17 95 2.2.4.3 Provider's Computing Center......................18 96 3. Layers and Functional Components......................18 97 3.1 End System Layer.....................................19 98 3.1.1 Presentation Software...............................20 99 3.1.2 Document Formatting................................20 100 3.1.3 Document Security..................................21 101 3.1.4 Transport Coupling.................................21 102 3.1.5 Maintenance........................................21 103 3.2 Network Layer........................................21 104 3.3 Access Layer.........................................22 105 3.3.1 Transport Coupling.................................23 106 3.3.1.1 Network Protocols................................23 107 3.3.1.2 Transmission Security............................24 108 3.3.1.3 Access Protection................................24 109 3.3.1.4 Presentation Control Monitor.....................24 110 3.3.1.5 Parameterized Subsystem Distribution.............25 111 3.3.1.6 Frame Dialogs....................................25 112 3.3.2 Presentation Services..............................26 113 3.3.2.1 Native presentation (standard)...................27 114 3.3.2.2 Optimization.....................................27 115 3.3.2.3 Transport Information............................27 116 3.3.2.4 Native Programs..................................28 117 3.4 Refinement Layer.....................................28 118 3.4.1 Format Conversion..................................29 119 3.4.2 Document Security..................................30 120 3.4.3 Format Optimization................................30 121 4. Recapitulation........................................30 122 4.1 Example Justification................................33 123 5. Progress Example......................................35 124 6. TCP/IP - WWW, Java Implementation Variant.............40 125 6.1 Consumer's Sphere....................................42 126 6.2 Provider's sphere....................................43 127 IOTP Payment API..........................................43 128 7. Payment API...........................................43 129 7.1 Introduction.........................................44 130 7.2 Assumptions..........................................45 131 8. Message Flows.........................................50 132 8.1 Authentication Documentation Exchange................54 133 8.2 Brand Compilation....................................55 134 8.3 Brand Selection......................................58 135 8.4 Successful Payment ..................................61 136 8.5 Payment Inquiry......................................65 137 8.6 Abnormal Transaction Processing......................67 138 8.6.1 Failures and Cancellations.........................67 139 8.6.2 Resumption.........................................69 140 8.7 IOTP Wallet Initialization...........................69 141 8.8 Payment Software Management..........................70 142 9. Mutuality.............................................70 143 9.1 Error Codes..........................................73 144 9.2 Attributes and Elements..............................82 145 10. Payment API Calls....................................94 146 10.1 Brand Compilation Related API Calls.................94 147 10.1.1 Find Accepted Payment Brand.......................94 148 10.1.2 Find Accepted Payment Protocol....................95 149 10.1.3 Get Payment Initialization Data...................97 150 10.1.4 Inquire Authentication Challenge..................99 151 10.1.5 Authenticate.....................................100 152 10.1.6 Check Authentication Response....................101 153 10.1.7 Cancel Payment...................................102 154 10.2 Brand Selection Related API Calls..................103 155 10.2.1 Find Payment Instrument".........................103 156 10.2.2 Find Payment Protocol............................105 157 10.2.3 Check Payment Possibility........................107 158 10.2.4 Quit Payment Instrument..........................109 159 10.3 Payment Transaction Related API calls..............110 160 10.3.1 Start Payment Consumer...........................110 161 10.3.2 Start Payment Payment Handler....................112 162 10.3.3 Resume Payment Consumer..........................115 163 10.3.4 Resume Payment Payment Handler...................116 164 10.3.5 Continue Process ................................117 165 10.4 General Inquiry API Calls..........................120 166 10.4.1 Inquire Payment Log..............................120 167 10.4.3 Payment Instrument Inquiry.......................124 168 10.4.4 Inquire Pending Payment..........................126 169 10.5 Payment Related Inquiry API Calls..................127 170 10.5.1 Check Payment Receipt............................127 171 10.5.2 Expand Payment Receipt...........................128 172 10.5.3 Inquire Process State............................129 173 10.5.4 Start Payment Inquiry............................131 174 10.5.5 Inquire Payment Status...........................131 175 11. Called Functions....................................134 176 11.1 Call Back Function.................................135 177 11.2 Work and Payment Log Database Function.............136 178 12. Security Consideration...............................141 179 Full Copyright Statement.................................141 180 References...............................................141 181 Author's Address.........................................142 182 Expiration and File Name.................................143 184 1. Introduction 186 Common network technologies base on standardized and established 187 Internet technologies. The Internet technologies provide mechanisms 188 and tools for presentation, application development, network 189 infrastructure, security, and basic data exchange. 191 The Internet Open Trading Protocol (IOTP) [RFC XXXX] is such an 192 Internet technology that specifies a generic protocol for Internet 193 trading. IOTP founds upon a client server model. It defines six 194 different trading roles (Consumer, Merchant, Payment Handler, 195 Delivery Handler, Merchant Customer Care Provider, and Payment 196 Instrument Customer Care Provider) and nine trading transaction types 197 (Deposit, Purchase, Refund, Withdrawal, Value Exchange, Inquiry, 198 Payment Instrument Customer Care, Authentication, and Ping). But it 199 does not depend on any payment method, e.g., SET, CyberCash/Coin, 200 Mondex, or GeldKarte. 202 The general IOTP objectives are to o provide the basic trading 203 transactions, o be an interoperable solution, o be payment system 204 independent, o be extensible and flexible, o meet immediate 205 business needs, o be an application level protocol, o be transport 206 level independent, and o be client / server architecture 207 independent. 209 Each trading role uses an IOTP aware application. The client, i.e., 210 Consumer, initiates each type of transaction request while the 211 server, i.e., other trading roles, responds to the Consumers' 212 requests. 214 Due to the presence of already installed trading roles' systems with 215 their own interfaces (Internet shop, order management, payment, 216 billing, and delivery management systems, or financial institute's 217 legacy systems), IOTP defines the common external (Internet) 218 interface between these systems. Initially, this consideration leads 219 to the two-level layered view of the IOTP software for each role, 220 consisting of the generic IOTP frontend part providing IOTP based 221 gateway services and the trading roles' specific backend systems 222 implementing the actual trading transaction types' functionality. 223 These software components communicate with each other and might have 224 been even provided by different software suppliers. 226 As IOTP extends payment schemes to a trading protocol, the IOTP 227 application glues different payment software components. However, the 228 Consumers' requirements can be lowered to the sole support of 229 multiple payment methods. Therefore, the IOTP application splits into 230 three main component types: 232 o the IOTP Application Core processes the generic parts of the IOTP 233 transaction and connects to the Internet, 234 o the Existing Legacy System resp. Existing Payment Software 235 processes the actual transaction type resp. payment transaction, 237 o the IOTP Middleware resp. IOTP Payment Bridge connects the other 238 two components. It extends the Existing Legacy System with an 239 interface compatible with the one offered by the IOTP Application 240 Core. The latter maps the Payment API calls to the payment software's 241 specific calls. 243 Actually, the trading architecture splits into five logical layers 244 that reflect the aspects of external Internet and user interfaces, 245 internal generic IOTP message processing, backend preparation of the 246 transaction's content, their processing at the actual application 247 layer, and the transaction data management. 249 The trading architecture being motivated and introduced in Chapters 2 250 to 6 elaborates the essential functional and data modules, maps them 251 to the five layers, and sketches their (internal) interfaces. 252 Generally, some of these interfaces are specified in public (product) 253 documents while others are confidential developer's only interfaces. 254 However, the Trading Architecture defines the first step towards an 255 actual implementation of an IOTP aware application. 257 The typical Payment Handlers, i.e., financial institutes or near- 258 bank organizations, require an IOTP aware application that easily 259 fits into their existing financial infrastructure. The Payment 260 Handler may even insist on the reuse of special in-house solutions 261 for some subtasks of the IOTP aware application, e.g., reflecting 262 their cryptography modules, gateway interfaces, or physical 263 environment. Therefore, their IOTP aware application really needs 264 both well defined external and internal interfaces. 266 However, the significance of such an architecture depends on the 267 product's target group. Generally, Payment Handlers have stronger 268 products requirements with respect to modularization and clear 269 internal interfaces than Consumers. But even the Consumer's IOTP 270 application aims at the support of multiple payment methods. 271 Particularly, Consumers prefer the flexible use of different seamless 272 integrating payment methods within one trading application with 273 nearly identical behavior and user interfaces. 275 The second part of the document (Chapters 7 to 11) refines one 276 specific internal interface to an actual Application Programming 277 Interface (API), i.e., Payment API, that bases on the functional 278 specification of Baseline IOTP [RFC XXXX]. This API aims at the 279 realization of a plug-in mechanism for payment specific software. 280 Currently, several payment software components from different 281 suppliers exist. Due to the payment method independence of IOTP, the 282 IOTP application must deal with and should provide a mostly common 283 interface for them. Therefore, this Payment API proposes an interface 284 between the generic IOTP Application Core and the Existing Payment 285 Software. Although, the highest significance of this API is 286 recognized at the Consumer, Payment Handlers offering multiple 287 transactions will also benefit, because such an API reduces the 288 overhead of integration, customization etc. of the IOTP aware 289 application. 291 1.1 Intended Readership 293 Software and hardware developers; development analysts, and users of 294 payment protocols. 296 GENERAL TRADING ARCHITECTURE 298 2. Trading Architecture 300 The general architecture suits for a broad range of applications, and 301 several abstract interfaces are identified between the architecture 302 components. Of course, such an architecture defines only the initial 303 starting point for an incremental process of refinements that ends in 304 an actual implementation. This incremental process hides superfluous 305 details very long and clarifies the roles of the components and their 306 interfaces very early. 308 2.1 Overview 310 The Trading Architecture consists of several layers and components 311 providing specific functionality. There exist well- defined 312 interfaces between the layers that are introduced in this section. 314 Implementation variants are derived from this abstract description. 315 For electronic commerce on the Internet, the implementation obviously 316 bases on HTML, HTTP, and TCP/IP. However, mobiles and set top boxes 317 may introduce other techniques. 319 The components can be distributed over different platforms, e.g., 320 main server and server stations. The combination of implementation 321 variants and component distribution leads to actual scenarios, e.g., 322 TCP/IP, WWW, and Java on a server station at the merchant or 323 financial institute. But these actual scenarios are out of the scope 324 of this proposal. 326 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 327 ------------------ Trading Architecture --------- 328 | components that may spread | 329 | across layers | 330 V V 331 Implementation variants <------------> Component Distribution 332 tcp/ip - www, java main server 333 other server station 334 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 335 Figure 1: Relationship between Architecture, Implementation 336 Variant, and Component Distribution 338 2.1.1 Layers and Components 340 An electronic commerce application should support different 341 implementation variants. Although WWW obtains the main focus, the 342 technologies may change in the future. A separation of the 343 application according to current and upcoming technologies must be 344 prevented. 346 The specification of the Trading Architecture starts with the general 347 logical partition of the layers. 349 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 350 End system layer 351 o Web browser or standard software interacting with the user 353 network layer 354 o tcp/ip, other 356 access layer 357 o Internet IOTP demon 358 o Internet transport information 359 o frame dialog, presentation services 360 o subsystem distribution 361 o monitor for presentation control 363 refinement layer 364 o document security 365 o format conversion 367 application layer 368 o electronic commerce application 369 o application monitor 370 o middleware 372 data layer 373 o data access 374 o integrity 375 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 376 Figure 2: Architecture Layers and Implementation Examples 378 2.1.1.1 Consumer Access - End System Layer 380 The end system uses the World Wide Web for presentation purposes 381 supporting graphical mechanisms for interaction, animated 382 graphical objects, photos, audio, and video tracks. In this 383 moment, these technologies are already implemented in highly 384 available web browsers. These software components are bundled 385 with newer releases of operating systems for the consumers' 386 personal computers, e.g., Microsoft Internet Explorer with 387 Microsoft Windows 95/NT, they come for free (Netscape 388 Navigator/Communicator), or can be licensed for a nominal license 389 fee. In the future, other networks and devices like set-top boxes 390 for Pay-TV will be the target of IOTP implementations, too. 392 The Internet features an open network infrastructure between the 393 consumer and the service provider for electronic commerce. An 394 electronic commerce application must be able to generate the 395 complete transaction data, to sign it, and to ensure the 396 transmission security. Currently, this demands can not be 397 fulfilled by the Web-browser, solely. Instead special helper 398 applications have to be installed at the consumer's side. 400 Actually, the client-sided end system layer consists also of the 401 last three server-sided layers (see below) but they have been 402 collapsed for simplicity. For short: 404 o Operating system offered network services belong to the access 405 layer. 406 o Web browsers' capabilities spread across the access to the data 407 layer. 408 o The functionality of helper applications may spread across 409 refinement to data layer. 410 o The IOTP wallet mainly belongs to the refinement layer. 411 o The actual payment software, e.g. SET wallet, inclusive its 412 helper applications like chip card reader drivers belongs to 413 the application/data layer. 415 However, the following discussion of these layers assumes their 416 location at the server side. 418 2.1.1.2 Network Layer 420 The network layer is operated by network providers and online 421 service providers. Not only the network provider may offer these 422 services, they can also be offered by merchants, mall providers, 423 financial service providers, and even financial institutes. 425 This layer aims at the abstraction from particular network 426 services like TCP/IP, HTTP, or Pay-TV networks. Application data, 427 i.e., IOTP message content and payment specific data, is 428 transparently passed to the refinement layer. 430 2.1.1.3 Access Layer 432 This layer subsumes the standard mechanisms for (Inter)net(work) 433 access, i.e., 435 o operating system offered network access services, 436 o peripherals like modem, packet filter, or firewall, 437 o partial capabilities of Web browsers and HTTP servers, e.g., 438 transmission security, visualisation, logging. 440 This layer does not offer any trading services and transparently 441 carries IOTP formatted data. 443 2.1.1.4 Refinement Layer - Integration with IOTP 445 Standardized protocols promise strong flexibility for the choice 446 of application suppliers, prevent the dependence on a particular 447 one, and yield compliance and interoperability. Often, the 448 server-located systems have quite long life cycles, despite the 449 short development cycles of hardware and software. 451 These two cycles lead to two concurrent goals. The first goal 452 intends long-termed stability and security of investments. The 453 second requires the accurate consideration of new developments. 455 The IOTP Application Core represents the generic part of an IOTP 456 aware trading environment that provides IOTP specific document 457 formatting and security mechanisms. It connects to the 458 transaction specific backend systems. 460 2.1.1.5 462 The processing of the actual transaction data is performed by the 463 Existing Legacy Systems resp. Existing Payment Software being 464 reused for IOTP based (Internet) trading. They may even apply 465 their own document formatting and security mechanisms on the 466 application data being transparently embedded in IOTP messages. 468 2.1.1.6 Data Layer 470 The Existing Legacy Systems provide their specific data 471 management systems for data storage, security, or backup. 472 However, the internal structure of the Application and Data Layer 473 is out of the scope of this document. 475 2.1.2 Implementation Variants 477 The implementation variant defines the concrete realization of 478 these layers. Although this proposal focuses on the WWW 479 environment, any concrete realization is omitted. 481 2.1.3 Component Distribution 483 Component distribution means that the architecture needs to be 484 mapped onto different infrastructures and that different 485 realizations become necessary. While this mapping is quite 486 trivial on current consumers' personal computers, it is more 487 complicated on the server's side. Complexity may even increase on 488 the consumer's side with the upcoming of intelligent payment 489 periphery, e.g., intelligent chip card reader. E.g., the 490 architecture may be implemented at the Payment Handler on a 491 single main server or may be distributed between multiple server 492 stations. 494 The architecture should be considered from two different points 495 of view, i.e., from the server's and from the consumer's point of 496 view. 498 2.2 Requirements and Commitments 499 2.2.1 Basic Requirements 501 In addition to the aforementioned IOTP objectives, the user's 502 prospective must be considered. 504 2.2.1.1 Electronic Commerce Provider (Server) 506 o The Trading Architecture must be scaleable. 508 o The implementation must support the 24h/7d service. The online 509 dialog system should be always available. Precautions are 510 necessary that support changes, e.g., maintenance, during the 511 operating hours. 513 o The architecture must provide functions that can be used by 514 most of the providers. Therefore, the architecture clearly 515 describes its core components and the interface to the provider 516 specific services. 518 - The architecture addresses all layers inclusive the 519 refinement layer. The application and data layer may be 520 realized by the providers. Payment Handlers and big merchants 521 may implement these capabilities on behalf of their existing 522 installations. 524 - For example, the interface to the Existing Payment Software 525 located at the application layer bases on the XML format. 527 2.2.2 Security Requirements and Commitments 529 Security Requirements have strong influences on the design of the 530 architecture. I.e., several concrete security mechanisms for the 531 transmission and requirements for the operating environments at 532 the consumer's and provider's side reflect distinct security 533 levels. Baseline IOTP provides integrity protection but future 534 versions of IOTP will incorporate more sophisticated mechanisms 535 for confidentiality, authenticity, and integrity. 537 2.2.2.1 Overview about the Security Levels 539 Several security levels protect the application data. 541 Security Level Architecture Method 542 Layer 543 {1} transmission access layer e.g. SSL 544 (inclusive 545 authentication 546 provider -> consumer) 547 {2} authentication end system local pass phrase 548 (consumer -> certificate, layer verification through 549 chip card) software or the 550 consumer's chip card 551 {3} document refinement future versions of 552 (inclusive layer IOTP of specific 553 authentication e.g. payment methods 554 chip card <-> provider) 555 {4} authorization application provider's 556 layer application 558 The security levels can be classified as follows: 560 o The Transmission Security for Transport Purposes {1} implements 561 the secure transmission between two parties (HTTP server and Web 562 browser) without any interpretation of the content. E.g., the 563 transmission of the Java applets belongs to this class. In addition, 564 products, information announcements, and trading offers that may lead 565 to an IOTP transaction require transmission security. 567 o The Application Security {2-4} provides the strongest protection 568 for the financial and trading transactions. The remaining security 569 levels fall into this category. 571 2.2.3 Security Mechanism 573 2.2.3.1 Transmission Security 575 Socket security components like SSL implement the transmission 576 security. Both instances of the access layer at the consumer's and 577 provider's side may exchange their data SSL secured. This implies 578 that the international versions of the common Web browsers deliver 579 only weak security, except the provider is a financial institute. 580 This provider needs a special certificate and has to use particular 581 HTTP servers. The consumer has to use the newer releases of Web 582 browsers. Particular European browser add-ons close the security hole 583 outside the USA and Canada and offer world wide strong security with 584 full sized symmetric session keys. 586 SSL supports both server and consumer authentication. From the 587 worldwide prospective, US browser integrated SSL V2 offers both weak 588 confidentiality and weak integrity while SSL V3 offers weak 589 confidentiality but strong integrity. However, the usual RSA key size 590 is limited to 512 bits, in contrast to the normal key sizes of SET , 591 CyberCash , eCash ( all 1024), and HBCI (768). 593 The server's private authentication key may be stored in a special 594 hardware device. 596 Server authentication offered by both versions of SSL suffices in 597 most cases. It supports the secure transmission of Java applets etc. 598 and the verification of its origin by the consumer. And it provides 599 the base for HTTP Basic Authentication or (mutual) authentication at 600 the application layer. 602 2.2.3.2 Authentication 604 ID / pass phrase pairs or certificates can prove the claimed 605 consumer's identity. When using chip cards, these cards should enable 606 their transaction sensitive mechanisms only after successful local 607 authentication. 609 2.2.3.3 Document Security 611 The security services of the refinement layer process the IOTP level 612 document security. This includes: 614 o document integrity 615 Digital signatures or message authentication codes permit this. 617 o authentication 618 Mutual authentication may happen at startup each time a new 619 communication channel is established between two trading roles, i.e., 620 Consumer - Merchant / Payment Handler / Delivery Handler. 622 o confidentiality 623 The data stream may be optionally encrypted in addition to the 624 transmission protocol. However, Baseline IOTP provides 625 confidentiality only by the use of transmission security mechanisms. 627 o validity 628 Counters, nonces, or unique transaction identifiers ensure message 629 freshness and prevent replay attacks. 631 o defense of attacks 632 Failed signatures may be controlled and defended (brute force 633 attacks). 635 A unique crypto application programming interface offers the services 636 for document security processing. Beneath the software based 637 implementation, this API may offer services for accessing some 638 central crypto hardware, too. This hardware stores the crypto keys 639 and performs the cryptographic operations. Such a device is expected 640 to be implemented by a chip card at the Consumer's side and by tamper 641 resistant security modules at the Payment Handler's side. The 642 equipment at the Merchant and Customer Care Providers may depend on 643 their expected load. 645 The refinement layer may require additional data for key management 646 purposes, i.e., certificates or private keys. 648 The result of this security verification is reported to the 649 application layer. Security warnings, e.g., replay attacks detected 650 at the refinement layer, may be forwarded to other application 651 modules, e.g., card or user management systems. 653 However, the refinement layer does not manage any security of 654 transparently embedded data like payment scheme specific data. Its 655 security needs to be handled by the application layer. 657 2.2.3.4 Authorization 659 The application layer implements the authorization procedures and 660 different procedures may be offered by the providers. The following 661 information influences the counterparty's verification: 663 o result of the authentication 664 derived from the document integrity reported by the refinement layer. 666 o result of the document integrity 667 evaluated information reported by the refinement layer. 669 o authorization 670 - user, account, or chip card status Verification of user, 671 account, or chip card presence and status. 673 - competence verification counterparty's, mainly consumer's, 674 authorization of the requested transaction type at the application 675 layer. 677 2.2.4 Protection against Attacks 679 In principle, multiple points of attacks exist that need accurate 680 protection: 682 o consumer's system, 683 o providers' systems respective their computing centers, and 684 o transmission line. 686 Generally, several providers are involved during each IOTP 687 transaction - even during the individual steps - while basically only 688 one consumer participates (consumer to business). This scenario may 689 be extended for business to business transactions in future versions 690 of IOTP. 692 2.2.4.1 Consumer System 694 The protection of the consumer's system, i.e., vulnerable personal 695 computer with unsecured applications, is quite difficult. Better 696 security is obtained by specialized consumer electronic components 697 that integrate chip cards implementing the important security 698 procedures in tamper resistant hardware. The following requirements 699 need to be satisfied by a PC based system. 701 o On the Internet, the transmission security should be ensured by an 702 SSL instance. Very sensible transactions should be secured by an SSL 703 implementation with full cryptographic strength. 705 o Additionally, the transaction data may be symmetrically or 706 asymmetrically secured by software or chip cards. 708 o Best security is obtained by the use of intelligent chip card 709 readers with an integrated keyboard and display. This allows the 710 secure input of pass phrases, the safe display of transaction data, 711 and the signature outside the personal computer. Viruses and Trojan 712 horses are not able to attack the chip card reader. 714 o The environment for the input of the transaction data needs to be 715 secured. Current implementations of Web browsers for personal 716 computers and workstations have many security holes, e.g., Java 717 virtual machine, ActiveX. 719 2.2.4.2 Transmission Line 721 The network providers control the security of the transmission line. 722 There is no additional danger, if strong cryptographic mechanisms for 723 end to end security are used. All end points are located at the 724 consumer's respective provider's sphere. 726 2.2.4.3 Provider's Computing Center 728 The providers' end points for the transmission and document security 729 are located at their computing centers. Important secret/private keys 730 may be stored in hardware. Separate hardware components should be 731 used according to the different quality of both security levels. 733 Additional protection against illegal access, e.g., a firewall, is 734 necessary. This does not secure the application data but addresses 735 system attacks from the public Internet. 737 3. Layers and Functional Components 739 A flexible architecture requires its partition into multiple logical 740 layers. These layers incorporate the functional components. Changes 741 at one layer may not necessarily imply changes at other layers. And, 742 the introduction of additional implementation variants does not 743 necessarily imply changes on all layers. The architecture consists of 744 the following layers whereby the communication between the access and 745 the refinement layer bases on IOTP: 747 Notation Duties 748 1 end system layer user interface and off-line functionality 749 of the consumer's system (personal 750 computer or other intelligent end device 751 2 network layer communication between consumer and 752 provider 753 3 access layer transport coupling and presentation 754 control 755 4 refinement layer processing of the transaction message 757 5 application layer electronic commerce functionality and 758 control 759 6 data layer data management 761 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 762 End system layer 763 presentation software 764 document formatting, document security, transport coupling 765 |service specific formats 766 network layer v 767 network access procedure 768 network participant management 769 network services ^ 770 | service specific formats 771 access layer v 772 presentation services 773 presentation control monitor 774 transport coupling ^ 775 | document format IOTP 776 refinement layer v 777 document security 778 document formatting ^ 779 | content data format 780 application layer v 781 electronic commerce application 782 application monitor (authorization) 783 | provider specific format 784 data layer v 785 data access 786 integrity 787 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 788 Figure 3: Layer Components of the Architecture 790 The architecture describes the layers inclusive the refinement layer 791 and their interfaces to the specific implementations of the 792 provider's applications. 794 3.1 End System Layer 796 The end system layer is localized at the consumer's side. The 797 architecture defines the components for electronic commerce. It 798 considers the use of standard software and browser based applications 799 as well as client based and server based implementation alternatives. 801 An (optionally certified) IOTP aware application implements the data 802 format parser and the security services. This application may bolt on 803 standard software or browser based applications. The implementation 804 should reflect the depicted architecture: 806 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 807 End system layer 808 presentation software 809 o standard software 810 o web browser based 811 document security 812 o document authenticity 813 o document encryption 814 o validity 815 document formatting 816 o conversion between IOTP and application formats 817 o format syntax checks of the IOTP structure (segments, 818 lengts, elements, attributes etc.) 819 o logical compression 820 transport coupling 821 o network protocols 822 o transmission security 823 o access protection 824 IOTP kernel maintenance 825 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 826 Figure 4: Components and Functions of the End System Layer 828 3.1.1 Presentation Software 830 The presentation software performs the actual electronic commerce 831 processing at the consumer's side. It is responsible for the data 832 presentation, too. This applies both to personal computers and other 833 consumer electronic end devices. 835 There are no requirements how to provide this functionality. 836 Generally, two classes can be distinguished: 838 o program parts base on intelligent browser extensions like Java 839 applets, plug-ins or helper applications. 840 o standard products for electronic commerce. 842 3.1.2 Document Formatting 844 This component includes functions for the generation and analysis of 845 IOTP messages as well as mechanisms for initialization and 846 termination of IOTP transactions. They correspond to those of the 847 provider's refinement layer. 849 The IOTP aware application implements these functions in browser 850 based applications and standard products. This application has 851 further interfaces to the components presentation software, document 852 security, transport coupling, and IOTP kernel maintenance. It 853 controls their behavior. 855 This general concept of the IOTP aware application for browser based 856 electronic commerce supports its usage in PC based kiosk system in 857 public self service areas, too. 859 Note that IOTP defines only one instance of the very general 860 refinement layer. The architecture may remain unchanged if another 861 protocol or some future IOTP version replaces Baseline IOTP. However, 862 the consumer's system generates complete transaction messages and 863 transfers them to the provider considering all security aspects. 865 3.1.3 Document Security 867 This component provides (chip card based) document security services 868 that correspond to the respective services of the refinement layer. 870 3.1.4 Transport Coupling 872 This component manages communication channels in cooperation with the 873 respective components of the access layer at the counterparty. It 874 supports socket security mechanisms like SSL and XML message 875 processing. 877 3.1.5 Maintenance 879 The end system layer should provide functions for maintenance of the 880 IOTP aware application. This may be ordinary software maintenance as 881 well as application specific extensions. Also an organizational 882 concept including access protection to the application components is 883 needed. 885 3.2 Network Layer 887 The network layer of the architecture connects the consumer's system 888 with the provider's system. The network provider implements this 889 layer and promises its reliability. The offered services base on 890 standardized communication protocols. 892 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 893 Network layer 894 network access procedure 895 o access procedure and identification 896 o end device characteristics 897 network participant management 898 network services 899 o Internet 900 o other 901 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 902 Figure 5: Components and Functions of the Network Layer 904 The network provider realizes the network access procedure and 905 implements the participant management with respect to the consumer's 906 identification. The result of this verification may be reported to 907 the access layer's component transport coupling together with the 908 determined characteristics of the end device. 910 Currently, Baseline IOTP neglects this option due to the lack of any 911 standardized clarification of the reportable data. 913 3.3 Access Layer 915 The access layer defines the entry point to the provider's sphere and 916 controls the presentation dialogs with the consumer's end device. 917 This layer does no processing on the transaction data exchanged 918 between the provider and the consumer. All documents are processed 919 transparently. 921 Particular applications, so-called native programs, may serve as 922 consumer attractors. Consumer attractors are games, advertisements, 923 information, and calculation examples and they may be offered by the 924 merchant trading role. 926 The presentation controls and their dialog steps are realized in so- 927 called frame dialogs. The capabilities are defined by concrete 928 presentation services, e.g., WWW. Herewith, frame dialogs are 929 adjusted to the specific presentation service. In addition to the 930 control of the presentation service, the frame dialog controls the 931 document transport. 933 The presentation control monitor realizes the superior control, i.e., 934 initialization and termination of the channels to the frame dialogs, 935 connections to the application subsystems, their distribution, 936 supervision, and statistics. 938 The access layer consists of the following components and 939 subcomponents: 941 o transport coupling 942 - network protocols 943 - transmission security 944 - access protection 946 o presentation control monitor 947 - frame dialogs 948 - presentation services 949 - subsystem distribution 951 o frame dialogs 953 o native programs 955 3.3.1 Transport Coupling 957 The transport coupling provides an interface to the network layer and 958 contains the following subcomponents: 960 o network protocols o tcp/ip, pay tv, mobile 962 o transmission security o socket protection component 964 o access management o packet filter o firewall 966 3.3.1.1 Network Protocols 968 The transport access depends on the actual presentation services and 969 their standard mechanisms. Currently, this access is determined by 970 the WWW. This coupling of presentation services is called standard 971 coupling. In the case of WWW, the socket standard defines the 972 coupling for both transmission channels. 974 Both the implementation of the access layer and the standard coupling 975 should be transparent to the provider's and the consumer's sphere 976 because the presentation service, being selected for a particular 977 consumer connection, must implement the standard coupling internally. 979 The next figure presents an example for standard coupling at the 980 access layer: 982 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 983 Consumer's sphere WWW/Java resp. IOTP 984 ^ 985 Access layer |sockets 986 | 987 tcp/ip 988 (network protocols) | 989 |sockets 990 v 991 Provider's sphere WWW/Java resp. IOTP 992 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 993 Figure 6: Access Layer's Standard Coupling 995 Note that the access layer usually lacks any conversion services, 996 i.e., the selected consumer connection requires the same standard 997 coupling at both parties. 999 Maybe, some provider operated IOTP aware application may accept 1000 document formats without an intermediate presentation service. But 1001 this is not expected for Baseline IOTP over HTTP or native TCP/IP. 1003 3.3.1.2 Transmission Security 1005 The socket protection component implements the transmission security 1006 on the public network. On the Internet, SSL may implement this 1007 service at IOTP message level while the Existing Legacy Systems and 1008 Existing Payment Software may secure their specific transaction data 1009 on their own at the application layer in advance to its encapsulation 1010 in IOTP. 1012 3.3.1.3 Access Protection 1014 Components are needed that limit the remote access and protect the 1015 provider's infrastructure against attacks from the public network. 1016 Firewalls and packet filters do this for TCP/IP based network 1017 protocols. However these component prevent illegal access to the 1018 providers' system but they can not protect the data that they 1019 transparently process. 1021 3.3.1.4 Presentation Control Monitor 1023 The presentation control monitor provides basic features being 1024 independent from the underlying system architecture, loosely couples 1025 the application and the presentation systems, and supports the 1026 professional operation. 1028 The presentation control monitor contains the following 1029 subcomponents: 1031 o frame dialogs Each frame dialog relates to and controls the 1032 respective presentation service. The presentation control monitor 1033 manages the connections (channels) to the individual frame dialogs. 1035 The monitor provides the following functionality: 1037 - selection of the frame dialogs components and their presentation 1038 services 1039 - initialization, termination and channel supervision for 1040 transport coupling 1041 - requesting and forwarding of transport profiles for control 1042 purposes of the network layer 1044 o parameterized subsystem distribution provides functionality 1045 complementary to the application monitor: 1046 - mapping of the frame dialog's sessions to the application layer 1047 - supervision and transport parameterization of the subsystems 1049 Further functions are: 1051 o load supervision 1053 o statistic and diagnosis functions 1055 These functions subsume 1056 - logging 1057 System processes must remain transparent to the support personal in 1058 order to provide consumer support. The monitor must be able to log 1059 the history of the dialog steps and the progress of IOTP message 1060 exchanges for each session, hereby delivering the raw data for 1061 subsequent analyses. o statistics and reporting functions Online 1062 statistics about the maximal and current number of connections and 1063 the states of the electronic commerce environment are necessary. 1064 They enable the detection of bottle necks and system adjustments. 1065 - error processing 1066 The monitor must be able to report specific error messages to the 1067 consumer's system and to the provider's applications. These 1068 messages can be used by the user help desk for error localization, 1069 too. 1070 - trace function 1071 The monitor's dialog control should be traceable, i.e., the monitor 1072 should provide a logging function for its own actions. This trace 1073 function should be able to trace subsets of connections. 1075 3.3.1.5 Parameterized Subsystem Distribution 1077 This function complements the subsystem distribution of the 1078 application monitor. Based on information of the network layer, the 1079 presentation control monitor initiates the connection to the 1080 requested application monitor or application subsystem and supervises 1081 these connections. Both single and multiplexed connections may be 1082 supported. 1084 3.3.1.6 Frame Dialogs 1086 The further partition of the frame dialog's functionality yields: 1088 o presentation services 1089 They implement the actual online dialog with the consumer. Native 1090 presentation methods are used to implement the transaction dependent 1091 parts of the electronic commerce offer, e.g., determination of 1092 acceptable payment methods, offer generation, payment, digital data 1093 delivery. Native presentation methods of the Internet are HTML pages; 1094 scripts, applets, and pre-installed applications. The main functions 1095 are: 1097 - management of provider specific data, individual presentation 1098 possibilities 1099 Often, the provider requires a specific look & feel (logos, 1100 colors). This should be controlled by tables whereby each service 1101 uses its own table. 1103 - dialog control 1104 The fundamental connection control should base on tables. They 1105 specify which dialogs need to be activated after a specific user 1106 input. The frame dialog coincides with a table automaton. These 1107 tables must be customizable and maintainable. The dialog controller 1108 must support tracing in order to prevent the presence of a removed 1109 objects in the table. This log documents the dialog process and can 1110 be used for review purposes. 1112 o document transport 1113 IOTP realizes the document transport for electronic commerce. The 1114 provider's Web server or the IOTP aware application represents the 1115 corresponding implementation. It is based on standard TCP/IP 1116 protocols with the usage of an intermediate presentation protocol 1117 (HTTP). The socket protection component may be disabled, if the IOTP 1118 protocol provides its own document security - this does not apply to 1119 Baseline IOTP. The frame dialog uses the protocols of the 1120 presentation service and controls herewith this application. The 1121 application requests data from the presentation service or responds 1122 data to it until an IOTP message has been generated or processed. 1124 Baseline IOTP over the Internet assumes pre-installed consumer 1125 applications. Although the IOTP application manages the visualization 1126 and dialog appearance, the provider generates and formats the 1127 visualized transaction specific data, e.g., payment brand, logo, 1128 purchase amount, (organizational) descriptions. Furthermore, he has 1129 to trace the message exchanges in order to synchronize his own 1130 transaction progress with the consumer's transaction progress. 1132 3.3.2 Presentation Services 1134 The presentation services base on established, standardized, and 1135 extensible description services. Therefore, only fundamental 1136 requirements are noted that need to be fulfilled by these services. 1138 The established implementations of presentation services of the 1139 Internet are Web servers. 1141 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1142 Presentation Services 1143 o native presentation 1144 - basic presentation protocols (HTML, ...) 1145 - graphical user interface (style guides) 1146 - character set conversion (ASCII <-> EBCDIC) 1147 o optimization 1148 - compression 1149 - local object cashing 1150 - refresh 1151 o transport information 1152 - inquiry and parameterization services of the transport 1153 coupling (security, configuration, performance, quality) 1154 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1155 Figure 7: Components and Functions of the presentation services 1157 3.3.2.1 Native presentation (standard) 1159 The standard presentation protocols apply to the presentation modus, 1160 i.e., HTML is used on the Internet optionally enriched with Java or 1161 ActiveX applets, JavaScript or VisualBasic scripts. The IOTP protocol 1162 contains also some data being visualized during the transaction. 1163 Considering Baseline IOTP, the preceding browsing and shopping steps 1164 base on the standard presentation protocol. Afterwards the 1165 transaction switches to IOTP. The implementation of the user 1166 interface considers the requirements of the provider. 1168 3.3.2.2 Optimization 1170 The transmission of the presentation data using the Internet is 1171 recommended and advantageous due to performance considerations and 1172 costs. Nevertheless, optimization should be independent from the 1173 network. Example operations are logical compression, local object 1174 caching, and slim data transmission. 1176 The HTTP cache management and the packaging of several Java classes 1177 in one archive are two Internet specific optimizations. 1179 Logical compression deals with the omission of empty or superfluous 1180 data elements. 1182 3.3.2.3 Transport Information 1184 Presentation services are network independent. But it is pithy and 1185 necessary to receive information from the network layer or to control 1186 this layer through parameters. The presentation service may provide 1187 the mechanisms for accessing and forwarding such information. 1189 The network provider may provide the following information: 1191 o network type (TCP/IP, ...) 1192 o participant identification 1193 o end device identification 1195 This information could be used for security purposes, statistics, 1196 configuration, performance and quality of service. 1198 3.3.2.4 Native Programs 1200 Optionally, the access layer may contain application services. It may 1201 be more advantageous to implement simple calculations, e.g., ATM 1202 locators or zip code determinations, immediate in the access layer, 1203 without the usage of any subsystem, relieving the application 1204 systems. 1206 Particularly, scripts and applets offer new perspectives because they 1207 transmit program parts to the consumer's system and execute them on 1208 the remote system. This allows the server side supplement of raw data 1209 and their consumer sided refinement, i.e., processing and 1210 visualization. This relieves the central systems because the 1211 consumers' systems perform the main part of the computation. More 1212 complex applications are possible with remote data base access (JDBC, 1213 RMI). The potential increases further if complete applications are 1214 distributed on CDROMs etc. instead of dynamic transmissions of 1215 network accurate (down-)scaled scripts and applets. 1217 3.4 Refinement Layer 1219 Ideally, the refinement layer separates the application layer from 1220 the actual access layer. Mainly, it establishes a stable interface. 1221 The refinement layer communicates with IOTP formatted messages 1222 towards the access layer and with application specific formatted 1223 messages towards the application layer, e.g., providers' existing 1224 legacy systems. It converts the messages between the respective 1225 formats. 1227 The IOTP aware application, i.e., IOTP Application Core, belongs to 1228 this layer. 1230 The refinement layer supplies services that can be accessed by the 1231 application layer: 1233 o format conversion: task of the IOTP services 1234 o security (document): task of the security and stock data 1235 services 1236 o format optimization: task of the security services 1238 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1239 Refinement layer 1240 o document security 1241 - document authenticity (authentication, signing, etc.) 1242 - stock data management (RSA key management, wrong 1243 signatures) 1244 o document formatting 1245 - conversion between IOTP and application format 1246 - formal syntax checks 1247 - character set conversion (ASCII <-> EBCDIC) 1248 - logical compression and decompression 1249 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1250 Figure 8: Refinement Layer's Components and Functions 1252 3.4.1 Format Conversion 1254 The format conversion guarantees the access layer's independence from 1255 the application and provider specific data formats and yields the 1256 portability of the presentation control monitor between different 1257 installations. This is of particular importance for bank or near-bank 1258 Payment Handlers with their broad range of proprietary existing 1259 installations. 1261 The IOTP service performs the following tasks 1263 o formal syntax check and semantic analysis of the IOTP message 1264 (correct protocol building blocks, elements, lengths, 1265 attributes, matches of descriptive header attributes and 1266 elements, and dangling cross references) 1268 o verification of the document security referencing the security 1269 services 1271 o generation and supervision of IOTP dialog sequences 1273 >From the provider's prospective it should be considered that the 1274 received messages may be generated both by the consumers' home 1275 electronic commerce applications and public self service terminals. 1277 Furthermore, the format conversion handles character set conversions. 1278 This conversion depends on the installation platforms. 1280 3.4.2 Document Security 1282 The secure (confidential, authentic, integer) data exchange between 1283 the consumer and the provider is one important requirement for 1284 electronic commerce. The consumer leaves the sphere of the provider 1285 (merchant, financial institute etc.), in contrast to the traditional 1286 face-to-face business. Instead, the data is generated in the 1287 consumers' private environment, by trusted servers, or at public 1288 terminals and transmitted over the public network. Therefore, the 1289 document security seems to be worthwhile despite Baseline IOTP's 1290 focus on message integrity. 1292 The verification of the document authenticity requires either a stock 1293 data management for the key and signature management without any 1294 contribution of the data layer. Alternatively, a certification 1295 hierarchy may be established. Stock data may be Certificate 1296 Authority, provider (, and consumer) certificates as well as 1297 otherwise encoded cryptographic keys. It may include further 1298 information about the consumer. This data is intended only for key 1299 management. Any authorization of a transaction is deferred to the 1300 application layer. 1302 The refinement layer should support the anonymous access - at least 1303 for registration purposes - if the provider offers the actual service 1304 to registered consumers, only. 1306 3.4.3 Format Optimization 1308 The security services optimize the data format by compression and 1309 decompression operations. 1311 4. Recapitulation 1313 The following discussion focuses on the Consumer and Payment Handler 1314 and simplifies the provider's IOTP Middleware / Existing Legacy 1315 System to the IOTP Payment Bridge / Existing Payment Software. 1317 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1318 End System Layer 1320 Network Layer 1322 Access Layer 1323 o Transport Coupling 1324 - access protection: packet filter, firewall 1325 - transmission security: SSL, TLS 1326 - network protocol: TCP/IP, HTTP, XML 1327 o Presentation Service 1328 - graphical user interface 1329 - HTML 1330 - character set conversion 1332 Refinement Layer IOTP 1333 o Document Formatting APPLICATION 1334 - IOTP level semantical analysis CORE 1335 - transaction reference analysis 1336 - cross reference management 1337 - character set conversion 1338 o Document security 1339 - Hash 1340 - canonical form transformation 1341 - signature capabilities 1342 o Cache Management 1343 - idempotency checks 1344 - logging capabilities 1345 o Transaction Database 1346 - storage of IOTP messages, blocks, and elements indexed by 1347 transids or blockids 1348 - transaction status memory 1349 o Dispatcher 1350 - routing 1351 - session management 1352 o Transaction Type Processors 1353 - IOTP transaction types 1354 - user inquiries 1355 - policy, configuration data base 1357 Application Layer IOTP 1358 o Device Driver MIDDLEWARE / 1359 - chip card, PIN PAD PAYMENT BRIDGE 1360 - tamper resistent security module ------------------- 1361 o Payment Protocol Driver EXISTING LEGACY SYSTEM / 1362 - Secure Electronic Transaction EXISTING PAYMENT SOFTWARE 1363 - Secure Channel Credit and Debit 1364 - ... 1366 Data Layer 1367 o Transaction Database 1368 - storage of transaction data 1369 - transaction status memory 1370 - stock data 1371 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1372 Figure 9: Architecture Recapitulation 1374 Figure 14 entails a more compact view of the Trading Architecture. 1375 Implementations may consider additional middleware or the more 1376 detailed view on the IOTP / Payment Bridge being omitted from the 1377 following description. This figure names the important functional 1378 modules of an IOTP application and maps them to the identified 1379 architecture layers. Example modules are: 1381 o TCP/IP stacks, 1382 o SSL security packages, 1383 o HTTP wrapper, 1384 o XML parser / validator and generator, 1385 o IOTP semantic analyzer, 1386 o security modules for document security, 1387 o cache manager, 1388 o internal database system, 1389 o format converter, 1390 o display and dialog management, 1391 o session management: Transaction, Message, Element Identifier 1392 Management, 1393 o dispatcher, 1394 o transaction specific processing modules, 1395 o . . . 1397 IOTP defines the interface between the access and the refinement 1398 layer. The HTTP and the XML processors, which parse and validate IOTP 1399 messages, are assigned to the access layer. 1401 The transaction database is the central component of the IOTP 1402 application. It stores the transaction data (IOTP messages, 1403 components, and blocks) and realizes the persistent memory of the 1404 internal transaction state automaton. The specific transaction type 1405 processors interrogate the database for internal state update / 1406 verification and transaction data. Nevertheless, the IOTP Payment 1407 Bridge and Existing Payment Software may use their own databases or 1408 they may refer to this database through call back functions. 1410 The figure indicates further interfaces between the other layers and 1411 their internal modules. They have not been fixed yet due to their 1412 variance between the different roles, systems, vendors, ... 1413 Furthermore, the figure describes the transaction type processors 1414 very coarsely. Obviously, the Payment Handler's Payment Bridge 1415 cooperates with the Existing Legacy Systems. Therefore the 1416 transaction type processors may indirectly request further 1417 installation specific communication and application specific 1418 services, e.g., some CORBA middleware, SNA transport protocol, or 1419 external transaction approval. 1421 4.1 Example Justification 1423 TCP/Internet Protocol (TCP/IP): 1424 TCP/IP is the basic network protocol used for information exchange 1425 on the Internet with increasing success even in business 1426 environments. It provides sole transport services and does not 1427 depend on any application data. The TCP/IP module is assigned to 1428 the Transport Coupling module of the access layer. 1430 Secure Socket Layer (SSL), Transport Layer Security (TLS): 1431 SSL and TLS add sole channel security services to the basically 1432 open unsecured TCP/IP. Consequently, they encrypt transparently 1433 application data before transmission and remove the security 1434 envelope after receipt. Although SSL and TLS build upon TCP/IP they 1435 offer sole access services. 1437 Hypertext Transfer Protocol (HTTP) Wrapper: 1438 >From the application's or IOTP's point of view, HTTP is a generic 1439 wrapper used for pre-transmission conversion, such that 1440 transmission could be easily realized by the reuse of current 1441 software components (Web browsers and HTTP servers). Furthermore, 1442 HTTP wrapped messages pass firewalls with the highest probability - 1443 HTTP provides only access services. 1445 Extensible Markup Language (XML): 1446 The actual IOTP message content is encoded in XML and the Document 1447 Type Declaration (DTD) defines the syntax of IOTP messages. The XML 1448 parser checks received XML messages on syntactical well-formedness 1449 and IOTP-DTD validity. Even the powerful XML parser remains an 1450 access utility from the application's point of view. 1452 The transmission of data uses specific formats and conversions of low 1453 level data entities. E.g., byte order of characters, character sets. 1454 Some of these presentations services may be optionally handled by the 1455 HTTP parser or the XML parser. However, the abstract view assigns 1456 their subservices to the presentation services. 1458 Graphical User Interface (GUI): 1459 Furthermore, these services subsume the dialog service with the 1460 consumer, e.g., pop-up of notification/alert windows or input forms 1461 and low level input processing. 1463 Hypertext Markup Language (HTML): 1464 The presentation service includes any HTML processor - the HTML 1465 engine of the Web browser - that visualizes any HTML encoded data. 1466 It includes also style sheet processors and visualization engines 1467 for XML. The operating system (MS Windows, ...), the window system 1468 (X11, ...), or the reused tools prescribe the interface. Any 1469 further refinement of this interface or the introduction of a 1470 portable intermediate layer is out of the scope of this document. 1472 All of the aforementioned capabilities belong to the access layer. 1473 The next items describe the refinement layer. 1475 Document Formatting: 1476 The incoming IOTP messages - nevertheless encoded in XML but now 1477 verified w.r.t. well-formedness and validity- reach the refinement 1478 layer. This layer provides modules from IOTP level document 1479 verification (use of unique transaction id, use of other ids, valid 1480 cross references, analysis of interior structures, e.g., syntax of 1481 net locations, descriptions, embedded data). It transforms XML 1482 encoded IOTP messages to an internal structured representation. 1483 These functions belong to the architecture component "document 1484 formatting" because they deal with the internal application 1485 specific structure of IOTP messages. Vice versa, the document 1486 formatter enriches the internal representation of IOTP messages and 1487 encodes them to IOTP specific XML before transmission. 1489 Document Security: 1490 Baseline IOTP provides some security mechanisms that build an extra 1491 architecture component. This increases the flexibility of the 1492 architecture. E.g., vendors could plug in several security modules 1493 without affecting the remaining application. Furthermore, Payment 1494 Handlers may prescribe high security requirements that affect only 1495 an isolated topic of the architecture and therefore an isolated 1496 module of the application. 1498 Cache Management: 1499 The cache manager implements a hardly application dependent 1500 mechanism for idempotency checks of messages. The cache manager 1501 does not belong to the access layer because IOTP defines the rules 1502 for idempotency checking. 1504 Dispatcher: 1505 The dispatcher is the master module of the IOTP Application Core. 1506 It receives all events - both from the user and the remote party - 1507 and determines the respective slaves, i.e., transaction type 1508 processors. The dispatcher manages session related requests and 1509 responses. The dispatcher and the transaction type processors 1510 depend on the IOTP application. 1512 Transaction Database: 1513 The transaction database stores both the message content and the 1514 internal state information. 1516 Existing Payment Software: 1517 The Existing Payment Software together with the suitable IOTP 1518 Payment Bridge define the Application Layer. Their internal 1519 structure is not described. However, a more elaborated discussion 1520 would result in a structure comparable with the IOTP Application 1521 Core. 1523 5. Progress Example 1525 This section describes the progress of an IOTP transaction within the 1526 Trading Architecture step by step and uses an example consumer dialog 1527 for the brand independent payment with a provider combining the 1528 Merchant and Payment Handler trading roles. The implementation 1529 variant "TCP/IP - WWW, Java, SSL" with an online distributed Java 1530 applet is assumed that implements the IOTP aware application. Secure 1531 Channel Credit and Debit (SCCD) based payments may be implemented by 1532 Java applets. SSL implements the secure data transmission. The 1533 description focuses on the participation of the individual layers and 1534 clarifies their roles. 1536 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1537 Client (Consumer) IOTP request 1 Server 1538 -------------------------> 1539 IOTP response 2 1540 <------------------------- 1542 IOTP request n 1543 -------------------------> 1544 IOTP response n 1545 <------------------------- 1546 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1548 End System Layer 1550 Pre IOTP progress: 1551 1. The consumer dials into the Internet using his (arbitrary) 1552 network provider and establishes the physical Internet connection. 1553 2. The consumer uses the pre-installed Web browser for the 1554 visualization of HTML pages that have been fetched from the 1555 Internet. 1556 The consumer interacts only with the component presentation 1557 software, i.e., the Web browser. The other components of the end 1558 system layer cooperate with the browser transparently. 1560 Network Layer 1561 3. The network provider identifies the participants and supplies 1562 the service access points for WWW and Email. 1563 4. The network provider may offer his own WWW content. Usually, 1564 the HTTP protocol is offered on port 80. 1566 End System Layer 1567 5. The consumer connects to some merchant site, browses through 1568 the merchant's offer, and fills his shopping cart. The initial URL 1569 may be accessed by user input or links from other pages (home 1570 page, result page of a Web search engine. Then the consumer 1571 decides to check out the shopping cart and agrees to the 1572 subsequent payment. 1574 Access Layer 1575 7. By assumption, the requested page is SSL secured, indicated by 1576 the protocol HTTPS in its URL. This page is used to initiate the 1577 secure download of the Java applet. 1578 8. The socket protection entity of the transport coupling 1579 component responds with the encrypted session key material. 1581 End System Layer 1582 Remark: 1583 The browser has been configured with the public key needed for the 1584 authentication of the page's origin. The key may be configured by 1585 the consumer, manually (neither safe nor recommended). The key can 1586 be sent to the consumer by standard mail or it can be downloaded 1587 from another site. The latter requires another browser built-in 1588 public certification key. 1590 8. The consumer's (and provider's) socket protection components 1591 exchange the encrypted session key material (certificates and 1592 encrypted pre-master keys). The browser (or SSL helper 1593 application) verifies the key material using the configured public 1594 keys, derives the actual session keys, and accepts or rejects the 1595 upcoming transmission of the requested page. 1596 9. The consumer gets an indication - e.g. icon change - about the 1597 successful SSL connection. Manually, he may pop up the received 1598 certificate and verify the authenticity of the server. 1599 10. Now the browser initiates the actual request of the page. The 1600 transport coupling receives the encrypted page. The browser 1601 decrypts this page using the session key and forwards the 1602 decrypted page to its visualization engine. The Java applet is 1603 securely downloaded and activated as part of the page processing. 1604 Alternatively, a local pre-installed Java applet may be referenced 1605 and activated. In addition, either the downloaded page contains 1606 the IOTP based initialization data for the Java applet or the Java 1607 applet requests this from a special URL. 1608 11. The consumer provides some input data, e.g., for payment 1609 instrument selection, which is driven by the Java applet. 1610 12. Finally the consumer agrees to the payment of the selected 1611 goods with the chosen payment instrument and clicks on the pay now 1612 button. At this point all user input needs to be verified, e.g., 1613 supplement of all required payment data. 1614 13. On successful verification, the Java applet forwards the user 1615 data to its IOTP dialog services. 1616 14. The IOTP dialog services generate the IOTP (Payment) request 1617 message using the IOTP message services. 1618 15. The IOTP message is forwarded to the transport coupling, 1619 which may establish a new SSL secured connection with the Payment 1620 Handler (cf. 8 & 9) and sends the message to his IOTP aware 1621 application, using the current network connection and the socket 1622 API. Note that the Merchant and Payment Handler collapse by 1623 assumption. 1625 Access Layer 1626 16. The network layer transmits the (encrypted) data. 1627 17. The frame dialog ensures the complete and consistent 1628 transmission between the consumer's end system and the provider's 1629 computing center. The message may be used to set up some control 1630 mechanisms. 1632 Refinement Layer 1633 18. The refinement layer performs formal verification. It 1634 transforms the IOTP formatted message into the application 1635 specific format, verifies the document formatting, validity, and 1636 security, and extends the application data with the results. 1637 19. The application data is forwarded to the application 1638 services. 1640 The following insertion gives an example description of the 1641 application and data layers. They vary between the trading roles and 1642 even between providers of the same type. The description does not 1643 belong to the architecture. 1645 Application Layer 1647 The application layer implements the functionality of the actual 1648 electronic commerce applications which vary between the providers. In 1649 addition, a parameterized application monitor may be contained in the 1650 application. 1652 The application layer contains the following components: 1654 o application monitor 1655 o electronic commerce application 1657 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1658 Application Layer 1659 o application monitor 1660 - security (verification, authorization) 1661 - verification result of document authenticity 1662 - customer authorization 1663 - anonymous access 1664 - subsystem distribution (parameterized) 1665 o electronic commerce applications 1666 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1667 Figure 10: Application Layer's Components 1669 o Application Monitor 1670 One component of the application monitor routes the initiated 1671 application connections to the application subsystems, supervises 1672 them, and deals with the application specific security and 1673 authorization. The presentation control monitor of the access 1674 layer triggers the application monitor. 1676 o Subsystem Distribution 1677 This control function initiates and supervises the application 1678 connection to the application system (consumer account manager, 1679 order, payment, or billing system, etc.). It contains the 1680 following functionality: 1682 - parameterized session memory 1683 stores the current (shopping/payment 1684 negotiation/payment/delivery) context, e.g., the relationship 1685 between goods, payments and consumers. 1687 - routing of application connections and their supervision 1688 Partial functions may be realized by different application 1689 subsystems or they may run on different servers at different 1690 locations. The component manages the controlled initialization, 1691 termination, and supervision of application connections derived 1692 from the information of the initial IOTP request and final IOTP 1693 response. 1695 - statistics and diagnosis 1696 The tasks are described in the previous section about the 1697 presentation control monitor. The respective components log the 1698 actions of the application monitor (logging of application 1699 progress and application errors) 1701 o Application Specific Security 1703 This function includes the routing of successful authorized dialogs. 1704 Security modes are: 1706 - authorized 1707 The application services can reference the verification result 1708 of the document security (signature, authentication). But they 1709 handle the application specific consumer authorization by 1710 themselves. This may involve the validity check of the 1711 consumer's account or of a payment chip card. 1712 - without authorization 1713 There is no user information necessary because the service 1714 requires no security attribute (guest account). But the 1715 component may perform some checks on user supplied data, e.g., 1716 syntax of email address and validity of the given domain name. 1718 o Electronic Commerce Applications 1720 They comprise the provider specific functionality. The Existing 1721 Legacy System resp. Existing Payment Software and IOTP Middleware 1722 resp. IOTP Payment Bridge belong to this class. 1724 Data Layer 1726 The data layer consists of the following components: 1728 o data access 1729 Routines for database access and data manipulation. 1731 o data integrity 1732 The data integrity contains a transaction monitor and integrity 1733 verifications. 1735 o data administration 1736 The functions storage, balance, update, and distribution belong to 1737 the administration class. 1739 The above progress example is continued: 1741 Refinement Layer 1742 20. The refinement layer reports technical errors to the 1743 presentation control monitor, e.g., time-outs. 1744 21. The refinement layer generates an IOTP response if it has 1745 received the correct response from the application services. Its 1746 security services sign (and encrypt) the IOTP response. 1748 End System Layer 1749 22. The applet's IOTP message services request the data 1750 encryption and signature verification for the response from its 1751 security services. 1752 23. The applet's IOTP dialog services enable IOTP dialogs and 1753 verify any optional authentication and initialization data. 1754 24. The IOTP message services generate the next request (IOTP 1755 Payment Exchange). 1757 Access Layer 1758 25. The frame dialog receives the message, verifies its relation 1759 with the current dialog, and forwards the data. 1761 Refinement Layer, Application Layer, Data Layer 1762 26. The process coincides with the processing of the first IOTP 1763 message. 1765 Access Layer 1766 27. The IOTP aware application sends the response and closes the 1767 IOTP dialog on payment completion or failure. The physical 1768 connection remains open. 1770 End System Layer 1771 28. The Java applet processes the transaction response. 1773 29. It takes the control and display the final payment status. 1774 30. It passes the control back to the browser, redirects it to 1775 the respective net location, and terminates. 1777 6. TCP/IP - WWW, Java Implementation Variant 1779 The WWW variant of the Trading Architecture has specific requirements 1780 for the implementation that are implied by the open structure and 1781 established standards and tools of the Internet. The following table 1782 depicts the non-trivial relationship of these structures with the 1783 Trading Architecture. The table describes the components, standards, 1784 and products of the implementation variant. 1786 Layer Component Standard Product 1787 End System Presentation IOTP IOTP Wallet, Payment 1788 Layer Software Extension 1789 XML IOTP Wallet, e.g., Web 1790 browser extension 1791 (e.g. Java applet) 1792 Java IOTP Wallet, e.g., Web 1793 browser extension 1794 (e.g. Java applet) 1795 Document Format IOTP IOTP Wallet, Payment 1796 Extension (and 1797 smartcard) 1798 Document IOTP IOTP Wallet, security 1799 Security (smartcard) services (of financial 1800 service providers) 1801 inclusive chip card 1802 support 1803 Transport 1804 Services 1805 Network TCP/IP TCP/IP socket support 1806 Protocol Socket for the Windows & OS/2 1807 family, Macintosh 1808 system, and UNIX 1809 derivatives, e.g., 1810 Windows WINSOCK.DLL 1811 HTTP Web browser, IOTP 1812 Wallet 1813 HTML, XML Web browser, IOTP 1814 Wallet 1815 IOTP IOTP Wallet 1816 Transmission SSL browser implemented SSL 1817 Security functionality, SSL 1818 client solution for 1819 world wide full 1820 strength cryptography 1821 Network Network Internet Internet/Online 1822 Layer Services service provider 1823 Network Access Requirement Internet/Online 1824 Procedure and of the service provider 1825 User Management Internet 1826 Service 1827 Provider 1828 Access Layer Transport 1829 Services 1830 Network TCP/IP TCP/IP support by 1831 Protocol - packet filter 1832 - web server 1833 - ... 1834 Transmission SSL web server integrated 1835 Security SSL functionality, 1836 specific SSL server 1837 solutions 1838 Access Firewall 1839 Security 1840 Packet router of firewall 1841 Filter 1842 (exterior) 1843 Application firewall 1844 Level 1845 Gateway 1846 Packet router of firewall 1847 Filter 1848 (interior) 1849 Presentation 1850 Control Monitor web server 1851 Subsystem 1852 Distribution 1853 Frame HTML, Java web server 1854 Dialog ActiveX, 1855 JavaScript, 1856 Visual Basic 1857 Presentation HTML, XML web server 1858 Native HTML, XML web server 1859 Presentation 1860 Optimization HTTP Cache web server, http proxy 1861 Transport System requirements for the 1862 Information Information web server 1863 Native Programs Java self developed / 1864 JavaScript, customized programs / 1865 ActiveX, applets 1866 Visual Basic 1867 Refinement Document Format IOTP IOTP aware application 1868 Layer 1869 Document IOTP IOTP aware application 1870 Security security services: 1871 - digital signature 1872 - crypto API for RSA, 1873 - (certification / 1874 registration 1875 authority) 1876 Table 1: Implementation Variant TCP/IP - WWW, Java, Server 1877 Station Solution 1879 The IOTP implementation variant does not recommend any specific Web 1880 server. Its implementation requires the distinction between the 1881 consumer's and the merchant's / deliverer's / Payment Handler's 1882 sphere. 1884 6.1 Consumer's Sphere 1886 The following discussion distinguishes between two different types of 1887 end systems. 1889 A standard application may implement all services on its own. Solely, 1890 it has to fulfill the requirements of the IOTP protocol. 1891 Alternatively, it may use the functionality of a so-called IOTP 1892 kernel, in order to relieve the actual front-end application from the 1893 complex process of the parsing, analysis, verification, generation, 1894 and protection of IOTP messages. Parameters supplied by (preceding) 1895 IOTP messages influence the consumer's system behavior and 1896 appearance. 1898 A Web browser extension may also require an IOTP kernel, e.g., in 1899 order to provide full SSL security outside of USA and Canada. The 1900 usage of a local IOTP kernel is recommended even if an online loaded 1901 component - e.g., Java applet - may encode this extension. This 1902 decreases the size of the application dependent Java applet. 1903 Parameters supplied by (preceding) IOTP messages may customize such 1904 an applet, too. Alternatively, a fully customized applet may be 1905 supplied to the consumer. 1907 The detailed description of the IOTP kernel is outside of this 1908 discussion and needs to be formalized in an subsequent document. The 1909 specification of the IOTP kernel aims at the subsequent 1910 implementation. Such an implementation may be distributed as an IOTP 1911 development kit using the Internet service providers in order to 1912 enable the rapid development of consumer products. Furthermore, the 1913 IOTP kernel may incorporate a Crypto API encapsulating the security 1914 services. 1916 6.2 Provider's sphere 1918 A powerful server station with a decentralized operating system like 1919 UNIX may implement the access layer. Such a server station may be 1920 located at a computing center, at the Internet services provider, 1921 etc. It runs the following jobs: 1923 - Web server 1924 - SSL server 1925 - IOTP Application Core 1927 The general cooperation of the IOTP Application Core and the Existing 1928 Legacy System is outside the scope of this document. However, the 1929 connection to particular Existing Payment Software is discussed in 1930 the next chapter. The IOTP Application Core may be a slim IOTP 1931 monitor (IOTP application level gateway) that forwards the IOTP 1932 documents to the actual IOTP Application Core located anywhere else 1933 in the demilitarized zone or interior network. 1935 Additional components may protect the server station against attacks 1936 from the Internet. Such products as well as the respective 1937 (consultation) services are highly available. Therefore, this 1938 document does not address these traditional network security risks. 1940 Any gateway in the interior net may convert the traffic between 1941 TCP/IP and other protocols. Herewith, IOTP documents can be 1942 transmitted to arbitrary IOTP systems. 1944 IOTP Payment API 1946 7. Payment API 1948 The Internet Open Trading Protocol extends pure payment schemes like 1949 SET, SSL based payments, or CyberCash to a trading protocol, that 1950 deals with purchase orders, payment receipts, and delivery responses 1951 but does not replace of any payment method. Instead, it provides a 1952 wrapper for these payment specific protocols. Consequently, the IOTP 1953 aware application may reuse Existing Payment Software or may minimize 1954 the changes to these components. Therefore, the IOTP Application Core 1955 implements the IOTP transaction platform, IOTP transaction data 1956 management system, and user interface. But it defers the actual 1957 payment processing to the Existing Payment Software. 1959 7.1 Introduction 1961 The following table sketches the four logical steps of many payment 1962 transactions. The preceding agreement about the goods, payment method 1963 and purchase amount is omitted. 1965 Payment State Party Behavior 1966 Mutual Payment Handler E.g., generation of 1967 Authentication identification request, solvency 1968 request, and some nonce 1969 Consumer E.g., responses to the requests, 1970 and generation of the own nonce 1971 Authorization Payment Handler Opening of the transaction, 1972 generation of the authorization 1973 request 1974 Consumer Reservation of the Consumer's 1975 e-money 1976 Payment Handler Acceptance or rejection of the 1977 authorization response 1978 Capture generation of the capture 1979 request 1980 Consumer Charge 1981 Payment Handler Acceptance or rejection of the 1982 e-money, closing of the payment 1983 transaction 1984 Reversal On rejection: general of the 1985 reversal data 1986 Consumer Receipt of the refund 1988 Some payment methods do not distinguish between authorization and 1989 capture. The optional transaction reversal applies on payment 1990 rejection / revocation. This model applies also to refunds, deposits, 1991 withdrawals, electronic cheque, direct debit, and money transfer. 1993 It seems to be important for the consumers' acceptance, that the same 1994 IOTP wallet supports different payment methods and the registration 1995 of new payment methods which might be achieved by a common Payment 1996 API. Payment Handlers will also benefit from such a Payment API that 1997 standardizes the connection to their legacy systems, if they offer 1998 payment services for multiple payment methods. 2000 The Payment API provides a standard method for exchanging payment 2001 protocol messages between the parties involved in a payment 2002 (resolution). The existence of a well defined Payment API enables 2003 payment software developers to bolt on their components to other 2004 developer's general IOTP Application Core. The former have to 2005 implement the IOTP Payment Bridge, too. 2007 In outline, the Payment API accepts as an input parameter the 2008 transformed payment protocol message received from the remote party 2009 and returns another payment protocol message to be sent back to the 2010 remote party. This continues between the two parties until the 2011 Payment Handler's Payment API signals the payment termination. 2013 The relationship between the API and a typical software architecture 2014 is illustrated in the following figure. The relationship between 2015 these components are arbitrary: One IOTP Application Core may manage 2016 multiple IOTP Payment Bridges, which may manage multiple Existing 2017 Payment Software components, which may manage multiple payment 2018 methods. Finally, each payment method may support multiple payment 2019 instruments. Vice versa, several IOTP Payment Bridges may share 2020 Existing Payment Software and even share payment methods. 2022 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 2023 IOTP client (consumer) <---------------> IOTP server (merchant) 2024 ^ Internet ^ 2025 | IOTP Payment | IOTP Payment 2026 | API | API 2027 v v 2028 IOTP/Payment Bridge IOTP/Payment Bridge 2029 ^ ^ 2030 | Existing Payment APIs, e.g., | 2031 | SET, Mondex, etc. | 2032 v v 2033 Existing Payment Software Existing Payment Software 2034 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 2035 Figure 11: Relationship of the Components 2037 The next section lists several assumptions about the different 2038 software components. The next chapter illustrates the payment 2039 transaction progress and message flow for different kinds of 2040 transaction behavior. Chapters 9 to 11 contain the detailed 2041 description of the API calls and Chapter 12 elaborates the call back 2042 interface. 2044 When dealing with Merchants' or Delivery Handlers' IOTP aware 2045 applications, the payment related components are replaced by their 2046 Existing Legacy Systems and the IOTP Middleware. However, the 2047 discussion of non-payment interfaces (order management etc.) is 2048 deferred to future versions of this document. 2050 7.2 Assumptions 2052 Any Payment API has to suit for a broad range of payment methods both 2053 software based like Credit Card SET or CyberCoin and chip card based 2054 like Mondex or GeldKarte. Furthermore, it should suit for mimicries 2055 of typical and traditional payment methods like money transfer, 2056 direct debit, deposit, withdrawal, and money exchange, however they 2057 are realized. It should support both payments with explicit consumer 2058 acknowledge and automatic (micro)payments, which have been consumer 2059 approved in advance. 2061 The Payment API considers the following transaction types of Baseline 2062 IOTP [RFC XXXX]: 2064 o Baseline Purchase, 2065 o Baseline Refund, 2066 o Baseline Value Exchange, 2067 o Baseline Withdrawal, and 2068 o Baseline (Payment) Inquiry. 2070 First, the vision of the IOTP aware application's and its main 2071 components' capabilities are clarified. On the one hand, the Payment 2072 API should be powerful and flexible such that the IOTP Application 2073 Core really benefits from it. On the other hand, it should not be 2074 overloaded with stuff that is not supported by Existing Payment 2075 Software. Furthermore, the requirements of Consumers and Payment 2076 Handlers differ extremely on failure resolution and inquiry 2077 capabilities. Therefore, it is envisioned that the IOTP Application 2078 Core supports only basic inquiry mechanism while complex and payment 2079 method specific inquiries are deferred to the actual Existing Payment 2080 Software. Finally, the complete payment processing inclusive failure 2081 resolution support is deferred to the Existing Payment Software. 2083 The IOTP Application Core implements the generic and payment method 2084 independent part of the IOTP transaction processing and provides the 2085 suitable user interface. Focusing on the payment, it 2087 o manages the registered IOTP Payment Bridges, inclusive their 2088 registration process, 2090 o supports the Consumer's payment instrument selection preceding the 2091 payment request, 2093 o invokes and requests additional payment specific support from the 2094 selected and registered Existing Payment Software through the IOTP 2095 Payment Bridge, 2097 o initializes and terminates the Existing Payment Software through 2098 the IOTP Payment Bridge, 2100 o requests authentication data from the Consumer, 2102 o supervises the online transaction process and traces its progress, 2104 o implements any payment transaction progress indicator, 2106 o offers generic dialogs to the Existing Payment Software, e.g. pass 2107 phrase input, basic transaction inquiry, balance inquiry, brand 2108 selection payment acknowledge, payment instrument insertion, payment 2109 suspension / cancellation, 2111 o validates (previously) received payment receipts and the status of 2112 (terminated) payment transactions, 2114 o stores the transaction data and offers basic data base facilities 2115 and basic inquiry mechanisms for payment transactions, 2117 o supports the invocation of the existing software modules in an 2118 interactive mode for further payment method specific transaction 2119 post-processing, and 2121 o exports call back functions for use by the IOTP Payment Bridge or 2122 Existing Payment Software for progress indication or database access. 2124 In addition, the IOTP Application Core 2126 o enables the inquiry of pending and completed payment transactions, 2128 o manages the IOTP components and IOTP blocks exchanged during the 2129 transaction which may be referenced and accessed for the processing 2130 of subsequent messages, e.g., for signature verification. In 2131 particular, it stores named Packaged Content elements exchanged 2132 during payments. 2134 o associates each IOTP transaction type with payment transaction(s) 2135 and each payment transaction with multiple payment parameters (IOTP 2136 Transaction Identifier, Trading Protocol Options, Payment Instrument, 2137 Offer Response, IOTP Payment Bridge, and Wallet Identifier). The 2138 latter association can be lowered to the Consumer Payment Identifier, 2139 IOTP Payment Bridge, and Wallet Identifier when the payment 2140 transaction has been successfully started. 2142 o manages several kinds of identifiers, i.e., transaction, message, 2143 component, and block identifiers, 2145 o provides a message caching mechanism, 2147 o neglects failures at lower protocol layers except time-outs 2148 because they are handled by the appropriate protocol mechanisms, 2149 e.g., TCP/IP handles transmission errors. 2151 o detects time-outs at the protocol and API level reflecting the 2152 communication with both the remote party and the local periphery, 2153 e.g., chip card (reader) may raise time-outs. 2155 o defers payment specific error resolution to the Existing Payment 2156 Software. Mostly, they are solved from the IOTP Application Core's 2157 prospective by the extended exchange of Payment Exchange messages. 2158 The most significant failures arise from sudden unavailability or 2159 lapses of the local or opposing payment component. 2161 o assumes that the IOTP Payment Bridge is a passive component of the 2162 payment system, i.e., it awaits any input data and generates one 2163 response to each request. In particular, it does neither recognize 2164 nor notify time-outs, necessarily. 2166 However, the IOTP Payment Bridge and Existing Payment Software do not 2167 have to rely on the IOTP Application Core's capabilities. E.g., they 2168 may implement several dialogs on their own or they may refuse the 2169 export of specific payment instruments at brand selection time and 2170 may defer this selection to the Check Payment Possibility step using 2171 their own user interface. 2173 The IOTP Payment Bridge's capabilities deal not only with actual 2174 payments from the Consumer to the Payment Handler but extend to the 2175 following: 2177 o translation of messages between the formats of the IOTP 2178 Application Core and the Existing Payment Software. If one IOTP 2179 payment API call splits into multiple Existing Payment Software 2180 calls, it has to assemble their output to one IOTP payment API 2181 response. 2183 o Consumer's payment instrument selection by the means of an 2184 unsecured export of the relationship of payment brands, payment 2185 protocols, and payment instruments (identifiers). Generally, this 2186 includes not just the brand (Mondex, GeldKarte, etc.) but also which 2187 specific instance of the instrument and currency to use (e.g. which 2188 specific Mondex card and which currency of all those available). 2189 However, some payment methods may defer the selection of the payment 2190 instrument to the actual payment carrying-out or they may even lack 2191 any management of payment instruments. E.g., chip card based payment 2192 methods may offer - Point of Sale like - implicit selection of the 2193 payment instrument through simple insertion of the respective chip 2194 card into the chip card reader or they interrogate the inserted card 2195 and request an acknowledge (or selection) of the detected payment 2196 instrument(s). 2198 o payment progress checks, e.g., is there enough funds available to 2199 carry out the purchase, 2201 o balance inquiry, e.g. consumers may interrogate their chip card 2202 based payment instrument or remotely administered account in advance 2203 of a payment transaction acknowledge, 2205 o IOTP Payment Receipt - more precisely its Packaged Content - 2206 checks. Furthermore, it may support payment method specific Payment 2207 Receipt checks that are typically exchanged in IOTP Payment Scheme 2208 Components rather than in IOTP Payment Response Blocks or generated 2209 by chip cards. 2211 o decoding of data contained within a brand or protocol specific 2212 IOTP Payment Receipt or actual payment method specific Payment 2213 Receipt into a format which can be displayed to the user or printed, 2215 o cancellation of payment, even though it is not complete, 2217 o suspension and resumption of payment transactions. One source of 2218 failure the Existing Payment Software has to deal with is the time- 2219 out of the network connection. For resolution, the IOTP Application 2220 Core may try the suspension with a view to later possible resumption. 2221 Alternatively, the IOTP Application Core may signal the transaction's 2222 cancellation. However, the existing software can not rely on correct 2223 suspensions / cancellations, e.g., when it shuts down, it has to 2224 consider any exceptions and to resolve inconsistencies. 2226 Another source of failure is lack of funds in which case the IOTP 2227 Application Core may signal the suspension of the current payment 2228 transaction. The consumer may download money and may resume the 2229 previous transaction. 2231 o payment transaction status inquiry, so that the inquirer can 2232 determine the appropriate next step. 2234 o inquiry on payment transactions. Particularly, the inquiry of 2235 transactions with specific transaction states should be supported. 2236 The IOTP Application Core may inquire and resolve pending 2237 transactions at startup. E.g., the computer system may crash due to 2238 power failure. 2240 The determination details of the inquired transaction data is up to 2241 the IOTP Payment Bridge. It may evaluate local databases, log files, 2242 chip cards, or remote account manager. 2244 o recording the payment progress and status on a database. E.g., 2245 information about pending payments can be used to assist their 2246 continuation when the next payment protocol message is received. 2248 o payment progress indication. This could be used to inform the end 2249 user of details on what is happening with the payment. 2251 o payment method specific authentication methods. 2253 Existing Payment Software may not provide full support of these 2254 capabilities. E.g., some payment protocols may not support or even 2255 prevent the explicit transaction cancellation at arbitrary phases of 2256 the payment process. Therefore, the IOTP Payment Bridge has to 2257 implement at least skeletons that signal any lack of support back to 2258 the caller by the use of error codes (see below). The Existing 2259 Payment Software's capabilities vary extremely. It 2261 o supports the actual online payment transaction, 2263 o resolves most types of payment specific failures, 2265 o provides hints for out-of-band failure resolution on failed 2266 immediate resolution, 2268 o may implement transaction data management and inquiry mechanisms 2269 ranging from no transaction recording, last transaction recording, 2270 chip card deferred transaction recording, simple transaction history 2271 to very sophisticated implementations with flexible user inquiry 2272 capabilities. The latter is required by Payment Handlers for easy and 2273 cost effective failure resolution. 2275 o may rely on the generic dialogs of the IOTP Application Core. 2276 However, particular (business) rules or payment aspects may require 2277 additional dialog boxes or their dedicated appearance / structure / 2278 content, may prohibit the unsecured export of payment instruments, or 2279 may prescribe the pass phrase input under its own control. 2281 The API must consider both successful and failed payments. On time- 2282 out failure, each party requires a reliable analysis of the current 2283 payment transaction status and hints about the possible resolution 2284 alternatives. Common payment revocation by (e)mail, fax, or voice 2285 telephone becomes useless if the content of any chip card needs to be 2286 modified. 2288 8. Message Flows 2290 The Payment API calls are distinguished between general and payment 2291 transaction related inquiry calls, brand selection and payment 2292 transaction related calls, payment instrument customer care related 2293 and other calls. 2295 o Brand Compilation Related API Calls 2297 "Find Accepted Payment Brand" identifies the accepted payment brands 2298 for the indicated currency amount. 2300 "Find Accepted Payment Protocol" identifies the accepted payment 2301 protocols and returns payment scheme specific packaged content for 2302 brand selection purposes. 2304 "Get Payment Initialization Data" returns additional payment scheme 2305 specific packaged content for payment processing by the payment 2306 handler. 2308 "Inquire Authentication Challenge" returns the payment scheme 2309 specific authentication challenge value. 2311 "Authenticate" forwards any payment scheme specific authentication 2312 data to the IOTP Payment Bridge for processing. 2314 "Check Authentication Response" verifies the returned payment scheme 2315 specific authentication response value. 2317 "Cancel Payment" terminates the payment transaction immediately. This 2318 API function is a short cut to some specific "Change Process State" 2319 call. 2321 o Brand Selection Related API Calls 2323 "Find Payment Instrument" identifies which instances of a payment 2324 instrument of a particular payment brand are available for use in a 2325 payment. 2327 "Find Payment Protocol" identifies which payment protocols are 2328 supported by a specific payment instrument, resp. payment brand. 2330 "Check Payment Possibility" checks whether a payment instrument is 2331 able to perform a payment. 2333 "Quit Payment Instrument" terminates a payment transaction, even 2334 before the transaction has been initiated towards the Payment Handler 2335 (short cut for "Change Process State"). 2337 "Authenticate" (cf. Brand Compilation Related API Calls) 2339 o Payment Transaction Related API Calls 2341 "Start or Resume Payment Consumer/Payment Handler" initiate or resume 2342 a payment transaction. There exist specific API calls for the two 2343 trading roles Consumer and Payment Handler. 2345 "Continue Process" forwards payment scheme data to the Existing 2346 Payment Software and returns more payment scheme data for 2347 transmission to the counterparty. 2349 "Change Process State" changes the current status of payment 2350 transactions. Typically, this call is used for successful/less 2351 termination of suspension. 2353 oGeneral Inquiry API Calls 2355 "Inquire Payment Log" interrogates the payment log for different 2356 kinds of payments. The interrogation is adjustable by multiple 2357 parameters. 2359 "Remove Payment Log" removes one specific entry from the Payment Log. 2361 "Payment Instrument Inquiry" retrieves the properties of Payment 2362 Instruments. 2364 "Inquire Pending Payment" reports whether the IOTP Payment Bridge has 2365 pending transactions. 2367 o Payment Transaction Related Inquiry API Calls 2369 "Check Payment Receipt" checks the validity of IOTP Payment Receipts, 2370 returned by an "Inquire Process State" API call. It is used to check 2371 that the payment receipt is consistent and/or matches the respective 2372 payment transaction. Typically, it is used by the Consumer during the 2373 final processing of payment transactions. However, this check might 2374 be advantageous both for Consumers and Payment Handlers on failure 2375 resolution. 2377 "Expand Payment Receipt" expands IOTP Payment Receipt Packaged 2378 Contents and payment specific payment receipts into a form which can 2379 be used for display or printing purposes. 2381 "Inquire Process State" responds with the payment status and the IOTP 2382 Payment Receipt Component. Normally, it is called by the Payment 2383 Handler for final processing of the payment transaction. 2385 "Start Payment Inquiry" prepares the remote inquiry of the payment 2386 transaction status and responds with payment scheme specific data 2387 that might be needed by the Payment Handler for the Consumer 2388 initiated inquiry processing. 2390 "Inquire Payment Status" is called on Consumer initiated inquiry 2391 requests by the Payment Handler. It provides the payment scheme 2392 specific content of the Inquiry Response Block. 2394 "Continue Process" and Change Process State" (cf. Payment Transaction 2395 Related API Calls) 2397 o Other API Calls 2399 "Manage Payment Software" enables the immediate activation of the 2400 Existing Payment Software. Further user input is under control of the 2401 Existing Payment Software. 2403 "Access Data Base" provide a general data base interface to the IOTP 2404 Payment Bridge. They can rely on the IOTP Application Core 2405 capabilities for reliable data management. 2407 "Call Back" Function provides a general interface for visualization 2408 of transaction progress by the IOTP Application Core. 2410 The following table shows which API functions must (+), should (#), 2411 or might (?) be implemented by which Trading Roles. 2413 API function Consumer Payment Handler Merchant 2414 Find Accepted Payment Brand + 2415 Find Accepted Payment Protocol + 2416 Find Payment Instrument + 2417 Find Payment Protocol + 2418 Get Payment Initialization Data + 2419 Cancel Payment # 2420 Check Payment Possibility + 2421 Quit Payment Instrument # 2422 Start Payment Consumer + 2423 Start Payment Payment Handler + 2424 Continue Process + + 2425 Inquire Process State + + 2426 Change Process State + + ? 2427 Check Payment Receipt + ? 2428 Inquire Authentication Challenge # 2429 Remove Payment Log # # # 2430 Authenticate + 2431 Check Authentication Response # 2432 Resume Payment Consumer + 2433 Resume Payment Payment Handler + 2434 Expand Payment Receipt # ? 2435 Inquire Payment Log # # 2436 Payment Instrument Inquiry ? 2437 Inquire Pending Payment # # 2438 Start Payment Inquiry ? 2439 Inquire Payment Status ? 2440 Manage Payment Software # o ? 2441 Access Database # # # 2442 Table 2: Mapping between API Functions and Trading Roles 2444 The next sections sketch the relationships and the dependencies of 2445 the API calls. They provide the informal description of the progress 2446 alternatives and describe the communication and synchronization 2447 between the general IOTP Application Core and the payment scheme 2448 specific modules. 2450 8.1 Authentication Documentation Exchange 2452 This section describes how the functions in this document are used 2453 together to process authentication. 2455 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 2456 Authenticator Inquire Authentication Challenge(Alg1*) -> IPB 2457 Inq. Auth. Challenge Response(Alg1,Ch1) <- IPB 2458 . . . 2459 Inquire Authentication Challenge(Algn*) -> IPB 2460 Inq. Auth. Challenge Response(Algn,Chn) <- IPB 2461 Create and transmit Authentication Request Block 2462 Authenticatee Authenticate(Alg1, Ch1) -> IPB 2463 AuthenticateResponse(...) <- IPB 2464 . . . 2465 Authenticate(Algm, Chm) -> IPB 2466 AuthenticateResponse(Res) <- IPB 2467 Create and transmit Authentication Response Block 2468 Authenticator Check Authentication Response(Algm,Chm,Res)->IPB 2469 Check Auth. Resp. Response() <-IPB 2470 Create and transmit Authentication Status Block 2471 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 2472 Figure 12 Authentication Message Flows 2474 1. (Authenticator Process) The IOTP Payment Bridge (IPB) is asked 2475 for one or multiple authentication challenge values ("Inquire 2476 Authentication Challenge"). Each value is encapsulated in an 2477 Authentication Request Component which forms the final Authentication 2478 Request Block. If the authenticator intends to submit a choice of 2479 authentication algorithms to the authenticatee, it has to issue 2480 several API call to the IOTP Payment Bridge. 2482 Note that the interface is limited to the response of one algorithm 2483 per call. If the IOTP Application Core provides a choice algorithm, 2484 this choice should be reduced successively by the returned algorithm. 2485 The IOTP Payment Bridge notifies the IOTP Application Core with each 2486 newly registered Payment Instrument about the supported 2487 authentication algorithms by their names. 2489 2. The Authenticatee's IOTP Application Core checks whether the IOTP 2490 transaction type actually supports the authentication process. If 2491 Authentication Request Components have been provided, they are 2492 checked in some order. The IOTP Application Core analyzes the 2493 algorithms' names, the transaction context, and optionally user 2494 preferences in order to determine the system components which are 2495 capable to process the authentication request items. Such system 2496 components might be the IOTP Application itself or some of the 2497 registered IOTP Payment Bridges. These system components might be 2498 requested for the responses to the supplied challenges, sequentially. 2499 The search stops with the first successful response. 2501 Alternatively, the IOTP Application might ask for a user selection. 2502 This might be appropriate, if two or more authentication algorithms 2503 are received that require explicit user interaction, like PIN or chip 2504 card insertion. 2506 The Authenticatee's organizational data is requested by 2507 Authentication Request Blocks without any content element. On 2508 failure, the authentication request may be retried, or the whole 2509 transaction might be suspended or cancelled. 2511 3. (Authenticator Process) The IOTP Application Core checks the 2512 presence of the Authentication Response Component in the 2513 Authentication Response Block and forwards its content to the 2514 "selected" IOTP Payment Bridge for verification ("Check 2515 Authentication Response"). Otherwise, the presence of the 2516 Authenticatee's organisational data is checked. Any verification must 2517 succeed in order to continue the transaction. 2519 8.2 Brand Compilation 2521 An example of how the functions in this document are used together so 2522 that the Merchant can compile the Brand List Component, generate the 2523 Payment Component, and adjust the Order Component with payment scheme 2524 specific packaged content. 2526 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 2527 Merchant For each registered IOTP Payment Bridge 2528 | Find Accepted Payment Brand() -> IPB 2529 | Find Accepted Payment Brand Response (B*) <- IPB 2530 | Find Accepted Payment Protocol(B1) -> IPB 2531 | Find Accepted Payment Protocol Res.(P1*) <- IPB 2532 | . . . 2533 | Find Accepted Payment Protocol(Bn) -> IPB 2534 | Find Accepted Payment Protocol Res.(Pn*) <- IPB 2535 Create one Brand List Component, ideally sharing 2536 common Brand, Protocol Amount, Currency Amount, 2537 and Pay Protocol Elements 2538 Create Trading Protocol Options Block 2539 On brand independent transactions 2540 | Create Brand Selection Component, implicitly 2541 | Get Payment Initialization Data() -> IPB 2542 | Get Payment Initialization Data Res.() <- IPB 2543 | Optionally 2544 | | Inquire Process State() -> IPB 2545 | | Inquire Process State Response(State) <- IPB 2546 | Create Offer Response Block 2547 Transmit newly created Block(s) 2548 Consumer Consumer selects Brand/Currency from those 2549 that will work and generates Brand Selection 2550 Component - at least implicitly 2551 On brand dependent transaction 2552 | Transmit Brand Selection Component 2553 Merchant On brand dependent transaction 2554 | Get Payment Initialization Data() -> IPB 2555 | Get Payment Initialization Data Res.() <- IPB 2556 | Optionally 2557 | | Inquire Process State() -> IPB 2558 | | Inquire Process State Response(State) <- IPB 2559 | Create Offer Response Block 2560 | Transmit newly created Block 2561 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 2562 Figure 13 Brand Compilation Message Flows 2564 1. The Merchant's commerce server controls the shopping dialog with 2565 its own mechanisms until the Consumer checks out the shopping cart 2566 and indicates the payment intention. The notion shopping subsumes any 2567 non-IOTP based visit of the Merchant Trading Role's (which subsumes 2568 Financial Institutes) web site in order to negotiate the content of 2569 the IOTP Order Component. The subsequent processing switches to the 2570 IOTP based form by the activation of the Merchant's IOTP aware 2571 application. 2573 2. The IOTP Application Core inquires the IOTP level trading 2574 parameters (Consumer's shopping identifier, payment direction, 2575 initial currency amounts, discount rates, Merchant's and Delivery 2576 Handler's Net Locations, Non-Payment Handler's Organisational Data, 2577 initial order information, ....). 2579 3. The registered IOTP Payment Bridges are inquired by the IOTP 2580 Application Core about the accepted payment brands ("Find Accepted 2581 Payment Brand"). Their responses provide most of the attribute values 2582 for the compilation of the Brand List Component's Brand Elements. The 2583 IOTP Application Core might optionally match the returned payment 2584 brands with Merchant's general preferences. 2586 The IOTP Application Core must provide any wallet identifiers, if 2587 they are required by the IOTP Payment Bridges which signal their need 2588 by specific error codes (see below). Any signaled error that could 2589 not immediately solved by the IOTP Application Core should be logged 2590 - this applies also to the subsequent API calls of this section. In 2591 this case, the IOTP Application Core creates an IOTP Error Block 2592 (hard error), transmits it to the Consumer, and terminates the 2593 current transaction. 2595 4. The IOTP Application Core interrogates the IOTP Payment Bridges 2596 for each accepted payment brand about the supported payment protocols 2597 ("Find Accepted Payment Protocol"). These responses provide the 2598 remaining attribute values of the Brand Elements as well as all 2599 attribute values for the compilation of the Brand List Component's 2600 Protocol Amount and Pay Protocol Elements. Furthermore, the 2601 organisational data about the Payment Handler is returned. The IOTP 2602 Application Core might optionally match the returned payment brands 2603 with Merchant's general preferences. 2605 Note that this complex process might be optimized by any pre- 2606 compilation of Brand Lists. At startup the IOTP Application Core 2607 might 2609 o perform multiple dummy inquiries on the registered IOTP 2610 Payment Bridges, 2612 o exclude some IOTP Payment Bridges from subsequent inquiries, 2614 o analyze the relationships between the items, and 2616 o create patterns of the Brand Lists. 2618 For this purpose it is assumed that the items either vary on each 2619 inquiry or are static. 2621 5. The steps 3 and 4 are repeated during IOTP Value Exchange 2622 transactions - these steps are omitted in the previous figure. 2624 6. The IOTP Application Core compiles the Brand List Component(s) 2625 and the IOTP Trading Protocol Options Block. It is recommended that 2626 "equal" items returned by IOTP Payment Bridge function calls are 2627 shared due to the extensive linking capabilities within the Brand 2628 List Component. However, the compilation must consider several 2629 aspects in order to prevent conflicts - sharing detection might be 2630 textual matching: 2632 o Packaged Content Elements contained in the Brand List Component 2633 (and subsequently generated Payment and Order Components) might be 2634 payment scheme specific and might depend on each other. 2636 o Transaction/Brand/Protocol/Currency Amount (in)dependent data 2637 might share the same Packaged Content. 2639 o The Consumer's IOTP Application Core transparently passes the 2640 packaged contents to the IOTP Payment Bridges which might not be 2641 able to handle payment scheme data of other payment schemes 2642 accurately. 2644 The details about the rules and mechanisms, how this could be 2645 accomplished is out of the scope of this document. With other words, 2646 this document does not define further restrictions to the IOTP 2647 specification. 2649 7. The IOTP Application Core determines whether the IOTP message can 2650 be enriched with an Offer Response Block. This is valid under the 2651 following conditions: 2653 o All payment alternatives share the attribute values and 2654 contents of the subsequently generated Payment and Order 2655 Component. 2657 o The subsequently generated data does not depend on any 2658 BrandSelXInfo Elements that might be reported by the consumer 2659 within the TPO Selection Block in the brand dependent variant. 2661 If both conditions are fulfilled, the IOTP Application Core might 2662 request the remaining payment scheme specific payment initialization 2663 data from the IOTP Payment Bridge ("Get Payment Initialization Data") 2664 and compile the Offer Response Block. Optionally, the IOTP 2665 Application Core might request the current process state of the IOTP 2666 Payment Bridge and use the returned status to infer the order status 2667 which is added to the Offer Response Block. Alternatively, IOTP 2668 Application should determine the order status on its own. 2670 As in step 6, the details about the rules and mechanisms, how this 2671 could be accomplished is out of the scope of this document. 2673 8. The IOTP Application Core compiles the IOTP TPO message adding 2674 all compiled blocks and transmits the message to the Consumer. The 2675 IOTP Application Core terminates if an Offer Response Block has been 2676 created. 2678 9. The Consumer performs the Brand Selection Steps (see below) and 2679 responds with a TPO Selection Block if no Offer Response Block has 2680 been received. Otherwise, the following step is skipped. 2682 10. On brand dependent transactions, the IOTP Application Core 2683 requests the remaining payment scheme specific payment initialization 2684 data from the IOTP Payment Bridge ("Get Payment Initialization 2685 Data"), compiles the Offer Response Block, transmits it to the 2686 Consumer, and terminates. Like Step 7, the IOTP Application Core 2687 might access the current process state of the IOTP Payment Bridge for 2688 the compilation of the order status. 2690 Any error during this process raises an IOTP Error Block. 2692 8.3 Brand Selection 2694 This section describes the steps that happen mainly after the 2695 Merchant's Brand Compilation (in a brand independent transaction). 2696 However, these steps might partially interlace the previous process 2697 (in a brand dependent transaction). An example of how the functions 2698 in this document are used together so that the Consumer can determine 2699 which Brand/Currency to use is illustrated in the figure below. 2701 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 2702 Merchant Merchant generates Brand List(s) containing 2703 Brands, Payment Protocols and Currency Amounts 2704 On brand independent transactions 2705 | Merchant generates Offer Response Block 2706 Consumer For each accepted Payment Brand 2707 | Find Payment Instrument(B,C) -> IPB 2708 | Find Payment Instrument Response (PI*) <- IPB 2709 For each returned Payment Instrument/Brand 2710 | Find Payment Protocol(B,PI,C) -> IPB 2711 | Find Payment Protocol Response(P*) <- IPB 2712 Consumer selects Brand/Currency/Payment Instrument 2713 from those that will work and generates Brand 2714 Selection Component 2715 For the Selection 2716 | Get Payment Initialization Data(B,C,PI,P) -> IPB 2717 | Get Payment Initialization Data Response()<- IPB 2718 On brand dependent transaction 2719 | Generate and transmit TPO Selection Block 2720 Merchant On brand dependent transaction 2721 | Merchant checks Brand Selection and generates 2722 | and transmits Offer Response Block 2723 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 2724 Figure 14 Brand Selection Message Flows 2726 Note that the figure and the following description show one of two 2727 variants of the inquiry of valid payment instruments. Alternatively, 2728 the IOTP Application Core might enrich the "Find Payment Instrument" 2729 input parameter list with the payment protocols that are accepted by 2730 the Merchant. In this case all calls to "Find Payment Protocol" 2731 become superfluous and might be skipped. However, the IOTP 2732 Application Core must call "Find Payment Instrument" for every valid 2733 combination of payment brands, payment protocols, and IOTP Payment 2734 Bridges. 2736 1. The Merchant's commerce server controls the shopping dialog with 2737 its own mechanisms until the Consumer checks out the shopping cart 2738 and indicates the payment intention. The subsequent processing 2739 switches to the IOTP based form by the activation of the Merchant's 2740 IOTP aware application. 2742 2. The IOTP Application Core compiles the Trading Protocol Options 2743 Block which contains the Brand List Component(s) enumerating 2744 Merchant's accepted payment brands and payment protocols and 2745 initiates the Brand Selection process. 2747 3. This first IOTP message activates the Consumer's IOTP aware 2748 application, e.g., the Web browser invokes a helper application 2749 (e.g., Java applet or external application). The Consumer's IOTP 2750 Application Core 2752 o infers the accepted payment brands, payment protocols, payment 2753 direction, currencies, payment amounts, any descriptions etc., and 2754 their relationships from the IOTP message, 2756 o determines the registered IOTP Payment Bridges, 2757 o inquires general payment brand support and the known payment 2758 instruments from each registered IOTP Payment Bridge for each 2759 accepted payment brand and currency ("Find Payment Instrument"). 2760 However, some IOTP Payment Bridges may refuse payment instrument 2761 distinction. 2762 o inquires payment protocol support from each registered IOTP 2763 Payment Bridge that has acknowledged any of the accepted payment 2764 brands ("Find Payment Protocol"). The payment protocol support may 2765 differ between payment instruments if the IOTP Payment Bridge 2766 supports payment instrument distinction. 2768 The IOTP Application Core must provide wallet identifiers, if they 2769 are required by the IOTP Payment Bridges which signal their need by 2770 specific error codes (see below). These API calls are used to infer 2771 the payment alternatives at the startup of any payment transaction 2772 (without user unfriendly explicit user interaction). 2774 It is recommended that the IOTP Application Core manages wallet 2775 identifiers. But for security reasons, it should manage pass phrases 2776 in plain text only in runtime memory. Developers of IOTP Payment 2777 Bridges and payment software modules should provide a thin and fast 2778 implementation - without lengthy initialization processes- for this 2779 initial inquiry step. 2781 4. The IOTP Application Core 2783 o intersects the Consumer's payment capabilities with the 2784 Merchant's accepted payment brands and currencies, 2785 o displays the valid payment instruments and payment instrument 2786 independent payment brands (brand and protocol) together with 2787 their purchase parameters (payment direction, currency, amount), 2788 and 2789 o requests the Consumer's choice or derives it automatically from 2790 the configured preferences. 2792 The management / resolution of unavailable IOTP Payment Bridges 2793 during the previous inquiry process is up to the IOTP Application 2794 Core. It may skip these IOTP Payment Bridges or may allow user 2795 supported resolution. It may also offer the registration of new 2796 payment instruments. 2798 5. The Consumer's payment instrument / brand selection ties one IOTP 2799 Payment Bridge with the subsequent payment transaction. The IOTP 2800 Application Core interrogates this IOTP Payment Bridge, whether the 2801 payment can proceed with success ("Check Payment Possibility"). At 2802 this step, the IOTP Payment Bridge may issue several signals, e.g., 2804 o payment can proceed immediately, 2805 o required peripheral inclusive some required physical payment 2806 instrument (chip card) is unavailable, 2807 o remote party is not available, 2808 o wallet identifier or pass phrase is required, 2809 o expired payment instrument (or certificate), insufficient 2810 funds, and 2811 o physical payment instrument unreadable. 2813 In any case except the first one, the user should be notified and 2814 offered accurate alternatives. Most probably, the user might be 2815 requested 2817 o to resolve the problem, e.g. insertion of another payment 2818 instrument, verification of periphery, 2819 o to skip this check and to proceed (assuming its success), 2820 o to cancel the whole transaction, or 2821 o to suspend the transaction, e.g., initiating a nested 2822 transaction. 2824 If the payment software implements payment instrument selection on 2825 its own, it may request the Consumer's choice at this step. 2827 If the check succeeds, it returns several Brand Selection Info 2828 Elements. 2830 6. The steps 2 to 5 are repeated and possibly interlaced for the 2831 selection of the second payment instrument during IOTP Value Exchange 2832 transactions - this is neglected in the figure above. 2834 7. The IOTP Brand Selection Component is generated and enriched with 2835 the Brand Selection Info elements. This component is transmitted to 2836 the Merchant inside a TPO Selection Block if the received IOTP 2837 message lacks the Offer Response Block. The Merchant will then 2838 respond with an Offer Response Block (following the aforementioned 2839 compilation rules). 2841 8.4 Successful Payment 2843 An example of how the functions in this document are used together to 2844 effect a successful payment is illustrated in the figure below. 2845 Technically, two payments happen during IOTP Value Exchange 2846 transactions. 2848 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 2849 Consumer Start Payment Consumer(Amount,[PS0]...) -> IPB 2850 Start Payment Cons. Res.([PS1], CS=Cont.) <- IPB 2851 Create and transmit Payment Request Block 2852 Payment Handler Start Payment Pay. Handler(Amount, [PS1]) -> IPB 2853 Start Payment PH Response(PS2, CS=Cont.) <- IPB 2854 Create and transmit Payment Exchange Block 2855 Consumer Continue Process(PS2) -> IPB 2856 Continue Process Response(PS3, CS=Cont.) <- IPB 2857 ... CONTINUE SWAPPING PAYMENT EXCHANGES UNTIL ... 2858 Payment Handler Continue Process Response([PSn], CS=End) <- IPB 2859 Inquire Process State() -> IPB 2860 Inquire Proc. State Resp.(State, Receipt) <- IPB 2861 Create and transmit Payment Response Block 2862 Terminate transaction, actively 2863 | Change Process State(State) -> IPB 2864 | Change PS Response(State=CompletedOK) <- IPB 2865 Consumer On receipt of final payment scheme data 2866 | Continue Process(PSn) -> IPB 2867 | Continue Process Response(CS=End) <- IPB 2868 Check Payment Receipt(Receipt) -> IPB 2869 Check Payment Receipt Response() <- IPB 2870 Change Process State(State) -> IPB 2871 Change PS Response(State=CompletedOk) <- IPB 2872 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 2873 Figure 15 Example Payment Message Flows 2875 1. After Brand Selection and receipt of the IOTP Offer Response 2876 Block, the Consumer has to agree to the payment transaction's 2877 continuation. The agreement may be explicit per transaction or may 2878 base on configured preferences or pre-authorizations for specific 2879 payment limits. The Consumer may also decide to suspend or cancel the 2880 continuation of the IOTP transaction. However, this suspension has to 2881 be managed by the IOTP Application Core on its own because no payment 2882 transaction has been actually opened. No IOTP messages are sent to 2883 the counterparty if the payment stops. 2885 It is assumed, that generally the following payment process 2886 continues with minimal user (Consumer and Payment Handler) 2887 interaction and that it is controlled by the IOTP Application Core 2888 and IOTP Payment Bridge. 2890 2. In order to open the actual payment transaction, the IOTP 2891 Application Core issues the "Start Payment Consumer" request towards 2892 the IOTP Payment Bridge. This request carries the whole 2893 initialization data of the payment transaction being referred to by 2894 the IOTP Payment Bridge for subsequent consistency 2895 checks: 2897 o payment brand and its description from the selected Brand 2898 Element of the Brand List Component, 2899 o payment instrument from preceding inquiry step, 2900 o further payment parameters (currency, amount, direction, 2901 expiration) from the selected Currency Amount element, Brand List 2902 Component, and Payment Component of the IOTP Offer Response Block, 2903 o payment protocol from the selected Pay Protocol Element, 2904 o order details contained in the Order Component which might be 2905 payment scheme specific, 2906 o payment scheme specific data inclusive payment protocol 2907 descriptions from the Protocol Amount Element, and Pay Protocol 2908 Element, and 2909 o payment scheme specific data inclusive payment protocol 2910 descriptions, in which the name attribute includes the prefix as 2911 "Payment:" from the Trading Role Data Component. 2913 Generally, this request repeats most checks of the "Check Payment 2914 Possibility" request due to lack of dependencies between both 2915 requests, e.g. availability check of periphery, pass phrase 2916 supplement. There might be a significant delay between both API 2917 requests. The function may return further payment scheme specific 2918 data being considered as payment specific initialization data for the 2919 Payment Handler's IOTP Payment Bridge. If the payment software 2920 implements payment instrument selection on its own, it may request 2921 the Consumer's choice at this step. 2923 The IOTP Payment Bridge reports lack of capability quite similar to 2924 the "Check Payment Possibility" request to the IOTP Application Core. 2925 The Consumer may decide to resolve the problem, to suspend, or to 2926 cancel the transaction, but he must not skip this API request. The 2927 IOTP Application Core might reissue the API request on user 2928 indication. 2930 Developers of payment modules may decide to omit payment instrument 2931 related checks like expiration date or refunds sufficiency, if they 2932 are part of the specific payment protocol. 2934 If the IOTP Payment Bridge requests wallet identifiers or pass 2935 phrases anywhere during the payment process, they should be requested 2936 by this API call, too. The IOTP Application Core should store these 2937 values. The IOTP Payment Bridge may also store these values and 2938 dispense with their supplement on subsequent payment related API 2939 calls. The IOTP Application Core may issue the following API calls 2940 without these values, but it has to supply them on IOTP Payment 2941 Bridge request and to reissue the API call. It is recommended that 2942 the IOTP Application Core stores plain text pass phrases only in 2943 runtime memory and that IOTP Payment Bridges renew their requests for 2944 pass phrases after "Change Process State" API calls. 2946 The IOTP Application Core generates the IOTP Payment Request Block, 2948 inserts any returned payment scheme data, and submits it to the 2949 Payment Handler's system. 2951 3. The Payment Handler's IOTP Application Core opens the payment 2952 transaction using the "Start Payment Payment Handler" API call. The 2953 payment brand, its description, payment protocol, payment specific 2954 data, payment direction, currency and payment amount are determined 2955 quite similar to the Consumer's IOTP Application Core. Furthermore, 2956 the content of the Payment Scheme Data component and the Brand 2957 Selection Info Elements are passed to the API function. 2959 On success, the Payment Handler's IOTP Payment Bridge responds with 2960 payment scheme data. On failures, it has to resolve any problems on 2961 its own or to give up aborting the payment transaction because the 2962 Payment Handler operates a non- interactive server application. 2963 However, the Consumer may restart the whole payment transaction. But 2964 the payment log file should reflect any trials of a payments. 2966 In any case, the Payment Handler informs the Consumer about the 2967 current Process State using the IOTP Payment Response or IOTP Error 2968 Block. 2970 The "Start Payment Payment Handler" call might return the 2971 Continuation Status "End" which leads to the continuation with Step 2972 7. 2974 4. The IOTP Application Core verifies the presence of the Payment 2975 Exchange Block in the IOTP message and passes the contained payment 2976 scheme specific data to the active IOTP Payment Bridge ("Continue 2977 Process") which returns the next Payment Scheme Component. 2979 The Payment Scheme Component is encapsulated in a Payment Exchange 2980 Block and transmitted to the Payment Handler. 2982 5. The Payment Handler's IOTP Application Core verifies the presence 2983 of the Payment Exchange Block and passes the contained payment scheme 2984 specific data to the active IOTP Payment Bridge ("Continue Process") 2985 which returns the next Payment Scheme Component for encapsulation and 2986 transmission to the Consumer. 2988 6. The payment process continues with IOTP Payment Exchange Block 2989 exchanges, carrying the specific payment scheme data. Each party 2990 submits the embedded payment scheme data transparently to the active 2991 IOTP Payment Bridge by the Continue Process API call, wraps the 2992 returned payment scheme data into an IOTP Payment Exchange Block, and 2993 transmits it to the counterparty. 2995 However, the processing of the payment scheme data may fail for 2996 several reasons signaled by specific error codes which are 2997 transformed to IOTP Payment Response Blocks (generated by Payment 2998 Handler) or IOTP Error Blocks (both parties may generate them) and 2999 transmitted to the counterparty. 3001 7. Eventually, the Payment Handler's IOTP Payment Bridge recognizes 3002 the termination of the payment transaction and reports this by the 3003 continuation status "End". Then the IOTP Application Core issues the 3004 "Inquire Process State" API call and verifies whether an IOTP Payment 3005 Receipt Component has been returned. The IOTP Application Core wraps 3006 the payment receipt, the status response, and the optional payment 3007 scheme data in an IOTP Payment Response Block and transmits this 3008 block to the Consumer. 3010 However, these API calls may fail or any API response might be 3011 incomplete (lack of payment receipt). Then the Consumer has to be 3012 notified about the failed processing by an IOTP Error Block. 3014 Finally, the Payment Handler terminates the payment transaction 3015 with the "Change Process State" API call without awaiting any 3016 response from the Consumer. Further failures are not reported to the 3017 Consumer. 3019 It might be possible that the Consumer's IOTP Payment Bridge has 3020 returned the previous payment scheme data with the continuation 3021 status "End". In this case, the Payment Handler must not supply any 3022 further payment scheme data, because it will be rejected by the 3023 Consumer's IOTP Payment Bridge. Note that the genuine continuation 3024 status is not exchanged between the Consumer and the Payment Handler. 3026 8. The Consumer passes the optional payment scheme data and the 3027 payment receipt to the appropriate IOTP Payment Bridge by "Continue 3028 Process" and "Check Payment Receipt" API calls. Finally, the 3029 transaction is terminated with the "Change Process State" API call 3030 which verifies the reported payment status with the local one and 3031 signals any inconsistencies. Inconsistencies and the status text 3032 should be displayed to the Consumer. 3034 At this point, payment transactions have been closed by the Payment 3035 Handler. Therefore, failures have to be resolved locally or outside 3036 the payment transaction. 3038 8.5 Payment Inquiry 3040 In Baseline IOTP, Payment inquiries are initiated by the Consumer in 3041 order to verify the current payment progress and process state at the 3042 remote Payment Handler. The next figure shows the message flow of a 3043 Consumer initiated payment inquiry. 3045 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3046 Consumer Start Payment Inquiry() -> IPB 3047 Start Payment Inquiry Response([PS1]) <- IPB 3048 Create and transmit Inquiry Request Trading Block 3049 Payment Handler Inquire Payment Status([PS1]) -> IPB 3050 Inquire Payment Status Res.(State, [PS2]) -> IPB 3051 Create and transmit Inquiry Response Trading 3052 Block 3053 Consumer If Payment Scheme Data present 3054 | Continue Process(PS2) -> IPB 3055 | Continue Process Response(CS=End) <- IPB 3056 Change Process State(State) -> IPB 3057 Change Process State Response(State') <- IPB 3058 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3059 Figure 16 Remote Process State Inquiry 3061 1. The Consumer might initiate a payment inquiry once the payment 3062 transaction has been opened by the IOTP Application Core, i.e., any 3063 time after the initial submission of the IOTP Payment Request Block. 3064 The IOTP Application Core requests any additional specific payment 3065 scheme data from the respective IOTP Payment Bridge using the "Start 3066 Payment Inquiry" API request. Erroneous API responses should be 3067 reported to the Consumer and valid alternatives (typically retry and 3068 cancellation) should be presented by the IOTP Application Core. 3070 Generally, this request performs the complete initialization, e.g. 3071 availability check of periphery or pass phrase supplement. The IOTP 3072 Payment Bridge reports lack of capability quite similar to the "Check 3073 Payment Possibility" request to the IOTP Application Core. 3075 If the IOTP Payment Bridge requests wallet identifiers or pass 3076 phrases anywhere during the inquiry process, they should be requested 3077 by this API call, too. The IOTP Application Core should store these 3078 values. The IOTP Payment Bridge may also store these values and 3079 dispense with their supplement on subsequent inquiry related API 3080 calls. The IOTP Application Core may issue the following API calls 3081 without these values, but it has to supply them on IOTP Payment 3082 Bridge request and to reissue the API call. For security reasons, the 3083 IOTP Application Core should store plain text pass phrases only in 3084 runtime memory and the IOTP Payment Bridges should renew their 3085 requests for pass phrases after any "Change Process State" API call. 3087 The IOTP Application Core encapsulates any Payment Scheme Component 3088 in an IOTP Inquiry Request Block and submits it to the Payment 3089 Handler. 3091 2. The Payment Handler analyses the Inquire Request Block, maps the 3092 Transaction Identifier to payment related attributes (Brand, Consumer 3093 and Payment Handler Payment Identifiers), and forwards the request to 3094 the appropriate IOTP Payment Bridge ("Inquire Payment Status"). The 3095 IOTP Application Core transforms the response to an Inquiry Response 3096 Block and transmits it to the Consumer. 3098 3. On receipt of the respective IOTP Inquiry Response Block the 3099 Consumer's IOTP Application Core submits any encapsulated payment 3100 scheme specific data to the IOTP Payment Bridge for verification 3101 ("Continue Process"). 3103 4. The IOTP Application Core passes the reported payment status 3104 (except textual descriptions) to the IOTP Payment Bridge ("Change 3105 Process State") for verification purposes and payment status change. 3106 The IOTP Payment Bridge reports any inconsistencies as well as the 3107 final payment status to the IOTP Application Core. Any additional 3108 information that may be of interest for the Consumer has to be 3109 displayed by the IOTP Payment Bridge or Existing Payment Software on 3110 their own. 3112 8.6 Abnormal Transaction Processing 3114 8.6.1 Failures and Cancellations 3116 The IOTP specification distinguishes between several classes of 3117 failures: 3119 o Business and technical errors 3120 o Error depth on transport, message and block level 3121 o Transient errors, warnings, and hard errors. 3123 Any (Payment) API has to deal with the receipt of failure 3124 notifications from and failure responses to the IOTP Application 3125 Core. The interface between the IOTP Application Core and the IOTP 3126 Payment Bridge is mostly inherited from the genuine protocol. I.e., 3127 business errors are reported by status components in normal response 3128 blocks while technical errors are signaled by error components in 3129 dedicated error blocks. 3131 Cancellations are specific business errors might be initiated by each 3132 trading party. 3134 In preference to slim interfaces, the payment API introduces one 3135 additional error flag for business error indication - errors can be 3136 returned by every API function. On receipt of this flag, the IOTP 3137 Application Core has to infer the details of the business error using 3138 the API function "Inquire Process State". 3140 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3141 Any Party Issue some API request -> IPB 3142 Error Response(Error Code) <- IPB 3143 On "Business Error" response 3144 | Inquire Process State() -> IPB 3145 | Inquire P.S. Resp.(State, Receipt) <- IPB 3146 Determine Local Behavior 3147 If Status Change needed 3148 | Change Process State (State) -> IPB 3149 | Change Process State Response(State') <- IPB 3150 If Counterparty notification required 3151 | Create Error or Cancel Block (, add to next 3152 message, ) and transmit it to counterparty 3153 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3154 Figure 17 Error Response from IPB 3156 The specific Completion Codes "ConsCancelled", "MerchCancelled", and 3157 "PaymCancelled" - returned by "Inquire Process State" - determine 3158 that the Cancel Block has to be created instead of an Error Block. 3159 The rules for the determination of the behavior of the IOTP 3160 Application Core, particularly the response to the counterparty is 3161 given in the IOTP specification. 3163 Vice versa, failures, cancellations, and even success's are always 3164 reported to the IOTP Payment Bridge by the API function "Change 3165 Process State". This API function is used both for status change and 3166 consistency checking. Any suspicion of inconsistency should be 3167 reported by the IOTP Payment Bridge for display by the IOTP 3168 Application Core. 3170 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3171 Any Party Error Block or Cancel Block Received 3172 If Status Change required 3173 | Change Process State (State) -> IPB 3174 | Change Process State Response(State') <- IPB 3175 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3176 Figure 18 Error Notification to IPB 3178 The processing of payment transactions might temporarily be hampered 3179 by intermediate failures without significant influence to the IOTP 3180 layer. Internal failures might be resolved within the genuine payment 3181 scheme. However, final failures or cancellations have to be reported 3182 at the IOTP layer. 3184 Finally, communication time-out and heavily faulty communication 3185 channels may disable the transaction. Any components may implement 3186 time-out recognition and use the aforementioned API mechanisms for 3187 the notification of any status change. However, time-outs do not only 3188 appear on communication with the remote party. Even local components, 3189 like chip card readers or IOTP Payment Bridges, may raise time-outs 3190 that need to be resolved. The Consumer's IOTP Application Core should 3191 notify the Consumer about the resolution alternatives, i.e., retry, 3192 suspension, and cancellation. 3194 8.6.2 Resumption 3196 Payment transaction resumption may apply at different steps of a 3197 payment transaction: 3199 o Due to different time-out values the payment transaction may not 3200 have been suspended by the counterparty. Therefore, the API callee 3201 has to deal with pending and suspended payment transactions. 3203 o IOTP Payment Exchange and IOTP Payment Request Blocks may be 3204 received by the Payment Handler on resumption. Additionally, the 3205 payment transaction may not have been created at the Payment Handler. 3206 In that case, the "Resume Payment Payment Handler" API function 3207 responds with a hard error indicating the required "Start Payment 3208 Payment Handler" API call. 3210 o The IOTP Application Core may defer any payment tracing 3211 responsibilities to the IOTP Payment Bridge and may not be able to 3212 distinguish between the continuation and resumption of payment 3213 transactions. Either, the IOTP Payment Bridge API functions "Start 3214 Payment Payment Handler" and "Continue Process" implement both cases 3215 or they signal the required explicit payment resumption by error code 3216 responses ("Business Error"). Further analysis of the current payment 3217 state ("Inquire Process State") should return the value Suspended. 3219 If the Consumer does not reconnect within an acceptable amount of 3220 time, the Payment Handler's system may perform local failure 3221 resolution in order to close the transaction and to retain resources 3222 for other transactions ("Change Process State"). If the Consumer 3223 reconnect afterwards, a Payment Response or Error Block could be 3224 generated. 3226 It is expected, that Payment Handlers implement the main control of 3227 the payment transaction. Therefore, the Payment Handler's 3228 responsibility for driving the payment transaction to a consistent 3229 status is very high. 3231 8.7 IOTP Wallet Initialization 3233 At startup or on explicit user request the IOTP Application Core 3234 should check its IOTP Payment Bridges' internal status by searching 3235 for pending payment transactions. 3237 1. The IOTP Application Core interrogates the registered IOTP 3238 Payment Bridges about pending payment transactions. The IOTP 3239 Application Core may store indicators for pending transactions and 3240 use them for driving any subsequent inquiry ("Inquire Pending 3241 Payment"). 3243 2. If one IOTP Payment Bridge reports the presence of pending 3244 transactions, the IOTP Application Core has to inquire more 3245 information about each pending transaction ("Inquire Payment Log"). 3246 This inquiry API call may be pass phrase protected which has to be 3247 requested from the Consumer. 3249 3. The IOTP Application Core may try to suspend ("Change Process 3250 State") or resume ("Resume Payment Consumer") the pending transaction 3251 (on user request). The IOTP Payment Bridge may deny any processing of 3252 new payment transactions until the pending transactions have been 3253 processed. These denials are signaled by the error code "Business 3254 Error". 3256 8.8 Payment Software Management 3258 The IOTP Application Core provides only a simple and generic 3259 interface for the registration of new payment methods / instruments 3260 ("Manage Payment Software"). It receives the initial user request and 3261 defers the actual registration to the corresponding IOTP Payment 3262 Bridge. Other IOTP Application Core specific registration procedures 3263 deal with the registration of new IOTP Payment Bridges and payment 3264 brands. The registration of a new payment instrument may even be 3265 useful in the initial step of a payment transaction, when the 3266 Merchant transmits new brand identifiers to the Consumer. The IOTP 3267 Application Core has to renew any inquiry of payment instruments - at 3268 least partially, if registration happens afterwards. The IOTP 3269 Application Core may also activate the Existing Payment Software for 3270 further payment instrument and wallet administration. 3272 9. Mutuality 3274 The input and output arguments are annotated using the Extensible 3275 Markup Language (XML) notation. The called API function responds with 3276 a generic wrapper, that provides error codes and error descriptions. 3277 It is anticipated that this description reflects the logical 3278 structure of the API parameter. It may be used to derive 3279 implementation language specific API definitions. 3281 XML definition: 3283 3314 3318 3319 3329 Most of the attribute items are intended for immediate insertion in 3330 the IOTP Error Block. The values of the Name attribute have to 3331 transformed into Error Location Elements of the Error Component (cf. 3332 IOTP Specification). 3334 Attributes: 3336 xml:lang Defines the language used by the Error 3337 Description attribute (cf. IOTP 3338 Specification). 3340 ContentSoftwareId This contains information which identifies the 3341 software which generated the IOTP Message. Its 3342 purpose is to help resolve interoperability 3343 problems that might occur as a result of 3344 incompatibilities between messages produced by 3345 different software. It is a single text string 3346 in the language defined by "xml:lang". It must 3347 contain, as a minimum 3349 o the name of the software manufacturer, 3350 o the name of the software, 3351 o the version of the software, and 3352 o the build of the software. 3354 ErrorCode Contains an error code which indicates the 3355 nature of the error in the message in error. 3356 Valid values for the Error Code are given in 3357 the following section. This mnemonic enables 3358 the automatic failure resolution of the IOTP 3359 Application Core which analyzes the error code 3360 value in order to determine the continuation 3361 alternatives. 3363 ErrorDesc An optional textual description of the current 3364 error in the language identified by 3365 "xml:lang". It is intended for user display 3366 and provides detailed explanations about the 3367 failure and its (out-of-band) resolution 3368 alternatives. 3370 Severity Indicates the severity of the error. Valid 3371 values are: 3373 o Warning. This indicates that although there 3374 is a message in error the IOTP Transaction 3375 can still continue. 3377 o TransientError. This indicates that the 3378 error in the message in error may be 3379 recovered if the message in error that is 3380 referred to by the "Names" attribute is 3381 resent. 3383 o HardError. This indicates that there is an 3384 unrecoverable error in the message in error 3385 and the IOTP Transaction must stop. 3387 MinRetrySecs This attribute should be present if Severity 3388 is set to "TransientError". It is the minimum 3389 number of whole seconds which the IOTP aware 3390 application which received the message 3391 reporting the error should wait before re- 3392 sending the message in error identified by the 3393 "Names" attribute. 3395 If Severity is not set to 3396 "TransientError" then the value of this 3397 attribute is ignored. 3399 Names This attribute indicates the name(s) of the 3400 attribute or element to which the error code 3401 refers. 3403 Content: 3405 PaySchemePackagedContent cf. Table 5 3407 9.1 Error Codes 3409 The following table contains the valid values for the ErrorCode 3410 attribute of the Error Response. The first sentence of the 3411 description contains the default text that can be used to describe 3412 the error when displayed or otherwise reported. Individual 3413 implementations may translate this into alternative languages at 3414 their discretion. However, not every error code may apply to every 3415 API call. An Error Code must not be more than 14 characters long. The 3416 Error Codes have been taken from the IOTP Specification and extended 3417 by some additional codes which are highlighted by a preceding 3418 asterisk. 3420 Generally, if the corrupt values have been user supplied, the IOTP 3421 Application Core might prompt for their correction. If the renewal 3422 fails or if the IOTP Application Core skips any renewals and some 3423 notification has to be send to the counter-party, the error code is 3424 encapsulated within an IOTP Error Block. However, the IOTP server 3425 application reports business errors by the Status Component of the 3426 respective Response Block. 3428 References which are enumerated in the Names attribute have to be 3429 transformed to Error Location Elements. The IOTP Application Core 3430 must consider the elements' origin in the received IOTP message. 3431 Particularly, references to packaged content elements have to be 3432 transformed to references of the surrounding XML element. The same 3433 rule applies to any reported attribute. Then, the AttName attribute 3434 has to be set in the Error Location element, too. 3436 The following table mentions any modification from this general 3437 processing for particular error values. Furthermore, it contains 3438 hints for developers of IOTP Application Core software components 3439 about the processing of error codes. Conversely, developers of IOTP 3440 Payment Bridges get impressions about the expected behavior of the 3441 IOTP Application Core. The IOTP Payment API assumes that the IOTP 3442 Application Core implements the dialog boxes needed for error 3443 resolution. But it does not assume, that the IOTP Payment Bridge 3444 actually relies on them. Instead, the IOTP Payment Bridge may try 3445 resolution on its own, implement specific dialog boxes, and signal 3446 only final failures. 3448 Note: This abstract document assumes that the API parameters are 3449 exchanged in XML encoding. Therefore, several error values might 3450 disappear in lower level language specific derivations. 3452 Error Value Error Description 3454 Reserved Reserved. This error is reserved by the 3455 vendor/developer of the software. Contact 3456 the vendor/developer of the software for 3457 more information (see the SoftwareId 3458 attribute of the Message Id element in the 3459 Transaction Reference Block [RFC XXXX]). 3461 The Names attribute might refer some 3462 attributes or elements of the input 3463 parameter list. 3465 XmlNotWellFrmd XML not well formed. The XML document is not 3466 well formed. See [XML] for the meaning of 3467 "well formed". 3469 The Names attribute might refer to some 3470 attributes and elements of the input 3471 parameter list. 3473 XmlNotValid XML not valid. The XML document is well 3474 formed but the document is not valid. See 3475 [XML] for the meaning of "valid". 3476 Specifically: 3478 o the XML document does not comply with the 3479 constraints defined in the IOTP document 3480 type declaration, and 3481 o the XML document does not comply with the 3482 constraints defined in the document type 3483 declaration of any additional [XML 3484 Namespace] that are declared. 3486 The Names attribute might refer some 3487 attributes and elements of the input 3488 parameter list. 3490 (*)ElNotValid Element not valid. Invalid element in terms 3491 of prescribed syntactical characteristics. 3492 The Names attribute refers to the 3493 corresponding element tags. 3495 The IOTP Application Core has to replace the 3496 error code with "XmlNotValid" before 3497 transmission to the counterparty. 3499 ElUnexpected Unexpected element. Although the XML 3500 document is well formed and valid, an 3501 element is present that is not expected in 3502 the particular context according to the 3503 rules and constraints contained in this 3504 specification. 3506 The Names attribute refers to the 3507 corresponding element tags. The IOTP 3508 Application Core has to replace the error 3509 code with "EncapProtErr" or 3510 "ElContIllegal" before transmission to the 3511 counterparty, if the Names attribute refers 3512 to inner elements without a Block or 3513 Component Identifier. 3515 ElNotSupp Element not supported. Although the document 3516 is well formed and valid, an element is 3517 present that 3519 o is consistent with the rules and 3520 constraints contained in this 3521 specification, but 3522 o is not supported by the IOTP Aware 3523 Application which is processing the IOTP 3524 Message. 3526 The Names attribute refers to the 3527 corresponding element tags. The IOTP 3528 Application Core has to replace the error 3529 code with "EncapProtErr" or 3530 "ElContIllegal" before transmission to the 3531 counterparty, if the Names attribute refers 3532 to inner elements without a Block or 3533 Component Identifier. 3535 ElMissing Element missing. Although the document is 3536 well formed and valid, an element is missing 3537 that should have been present if the rules 3538 and constraints contained in this 3539 specification are followed. 3541 The Names attribute refers to the 3542 corresponding element tags. The IOTP 3543 Application Core has to replace the error 3544 code with "EncapProtErr" or 3545 "ElContIllegal" before transmission to the 3546 counterparty, if the Names attribute refers 3547 to inner elements without a Block or 3548 Component Identifier. 3550 ElContIllegal Element content illegal. Although the 3551 document is well formed and valid, the 3552 element contains values which do not conform 3553 the rules and constraints contained in this 3554 specification. The Names attribute refers to 3555 the corresponding element tags. 3557 The IOTP Application Core has to replace the 3558 error code with "EncapProtErr" or 3559 "ElContIllegal" before transmission to the 3560 counterparty, if the Names attribute refers 3561 to inner elements without a Block or 3562 Component Identifier. 3564 EncapProtErr Encapsulated protocol error. Although the 3565 document is well formed and valid, the 3566 Packaged Content of an element contains data 3567 from an encapsulated protocol which contains 3568 errors. 3570 The Names attribute refers to the 3571 corresponding element tags. 3573 AttUnexpected Unexpected attribute. Although the XML 3574 document is well formed and valid, the 3575 presence of the attribute is not expected in 3576 the particular context according to the 3577 rules and constraints contained in this 3578 specification. 3580 The Names attribute refers to the 3581 corresponding attribute tags. 3583 (*)AttNotValid Attribute not valid. Invalid attribute value 3584 in terms of prescribed syntactical 3585 characteristics. The Names attribute refers 3586 to the corresponding attribute tags. 3588 The IOTP Application Core has to replace the 3589 error code with "XmlNotValid" before 3590 transmission to the counterparty. 3592 AttNotSupp Attribute not supported. Although the XML 3593 document is well formed and valid, and the 3594 presence of the attribute in an element is 3595 consistent with the rules and constraints 3596 contained in this specification, it is not 3597 supported by the IOTP Aware Application 3598 which is processing the IOTP Message. 3600 The Names attribute refers to the 3601 corresponding attribute tags. 3603 Furthermore, the inquiry API function 3604 ("Inquire Payment Log") might report lack of 3605 selection criteria. If a selector has been 3606 user supplied, the IOTP Application Core may 3607 offer a dialog for its adjustment. However, 3608 errors generated in this case, are never 3609 passed to the counterparty's IOTP 3610 Application Core. 3612 AttMissing Attribute missing. Although the document is 3613 well formed and valid, an attribute is 3614 missing that should have been present if the 3615 rules and constraints contained in this 3616 specification are followed. The Names 3617 attribute refers to the corresponding 3618 attribute tags. 3620 If the attribute is required by the IOTP 3621 Document Type Declaration (#REQUIRED) the 3622 hints for non valid attributes should be 3623 adopted, otherwise these for illegal 3624 attribute values. 3626 AttValIllegal Attribute value illegal. The attribute 3627 contains a value which does not conform to 3628 the rules and constraints contained in this 3629 specification. 3631 The Names attribute refers to the 3632 corresponding attribute tags - valid values 3633 are: 3635 BrandId: illegal/unknown Brand Identifier - 3636 If the brand is not recognized/known by any 3637 IOTP Payment Bridge, the IOTP Application 3638 Core may offer the registration of a new 3639 Payment Instrument. 3641 PaymentInstrumentId: illegal/unknown 3642 Payment Instrument Identifier - This 3643 indicates a serious communication problem if 3644 the attribute value has been reported by the 3645 same "wallet" on a previous inquiry 3646 requests. The IOTP Application Core has to 3647 replace the error code with 3648 "TransportError" before transmission to the 3649 counterparty. 3651 WalletId: illegal/unknown Wallet Identifier 3652 - It is assumed that the wallet identifier 3653 is checked before the pass phrase. On 3654 invalid wallet identifiers, the IOTP 3655 Application Core may open the dialog in 3656 order to request the correct wallet 3657 identifier. In addition, any pass phrase may 3658 be supplied by the user. The dialog should 3659 indicate the respective payment brand(s). 3660 The IOTP Application Core has to replace the 3661 error code with "TransportError" before 3662 transmission to the counterparty. 3664 Passphrase: illegal/unknown Pass Phrase - 3665 The IOTP Application Core may open the 3666 dialog in order to request the correct pass 3667 phrase. If the pass phrase is wallet 3668 identifier specific the dialog should 3669 display the wallet identifier. The IOTP 3670 Application Core has to replace the error 3671 code with "TransportError" before 3672 transmission to the counterparty. 3674 Action: illegal / unknown / unsupported 3675 Action 3677 PropertyTypeList: lists contains illegal / 3678 unknown / unsupported Property Types - The 3679 IOTP Application Core tries only the local 3680 resolution but does never transmit any IOTP 3681 Error Block to the counterparty. 3683 CurrCode: illegal/unknown/unsupported 3684 Currency Code 3686 CurrCodeType: illegal/unknown/unsupported 3687 Currency Code Type 3689 Amount: illegal/unknown/unsupported Payment 3690 Amount 3692 PayDirection: illegal/unknown/unsupported 3693 Payment Direction 3695 ProtocolId: illegal/unknown/unsupported 3696 Protocol Identifier 3698 OkFrom: illegal/unknown/unsupported OkFrom 3699 Timestamp 3701 OkTo: illegal/unknown/unsupported OkTo 3702 Timestamp 3704 ConsumerPayId: illegal/unknown Consumer 3705 Payment Identifier 3707 PaymentHandlerPayId: illegal/unknown Payment 3708 Handler Payment Identifier 3710 AttValNotRecog Attribute Value Not Recognized. The 3711 attribute contains a value which the IOTP 3712 Aware Application generating the message 3713 reporting the error could not recognize. 3715 The Names attribute refers to the 3716 corresponding attribute tags. 3718 MsgTooLarge Message too large. The message is too large 3719 to be processed by the IOTP Payment Bridge 3720 (resp. IOTP Application Core). 3722 ElTooLarge Element too large. The element is too large 3723 to be processed by the IOTP Payment Bridge 3724 (resp. IOTP Application Core). 3726 The Names attribute refers to the 3727 corresponding attribute tags. 3729 ValueTooSmall Value too small or early. The value of all 3730 or part of an element content or an 3731 attribute, although valid, is too small. 3733 The Name attribute refers to the 3734 corresponding attribute or element name. 3736 ValueTooLarge Value too large or in the future. The value 3737 of all or part of an element content or an 3738 attribute, although valid, is too large. 3740 The Name attribute refers to the 3741 corresponding attribute or element name. 3743 ElInconsistent Element Inconsistent. Although the document 3744 is well formed and valid, according to the 3745 rules and constraints contained in this 3746 specification: 3748 o the content of an element is inconsistent 3749 with the content of other elements or 3750 their attributes, or 3751 o the value of an attribute is inconsistent 3752 with the value of one or more other 3753 attributes. 3755 The error description may contain further 3756 explanations. 3758 The Names attribute refers to the 3759 inconsistent attribute or element tags. 3761 TransportError Transport Error. The connection to some 3762 periphery or the counterparty could not be 3763 established, is erroneous, or has been lost. 3765 The error description may contain further 3766 narrative explanations, e.g., "chip card 3767 does not respond", "remote account manager 3768 unreachable", "Internet connection to xyz 3769 lost", "no Internet connection available", 3770 "no modem connected", or "serial port to 3771 modem used by another application". This 3772 text should be shown to the end user. If 3773 timeout has occurred at the Consumer this 3774 text should be shown and the Consumer may 3775 decide how to proceed - alternatives are 3776 retry, payment transaction suspension, and 3777 cancellation. 3779 MsgBeingProc Message Being Processed. This error code is 3780 only used with a Severity of Transient 3781 Error. It indicates that the previous 3782 message, which may be an exchange message or 3783 a request message, is being processed. 3785 SystemBusy System Busy. This error code is only used 3786 with a Severity of Transient Error. It 3787 indicates that the IOTP Payment Bridge or 3788 Existing Payment Software that received the 3789 API request is currently too busy to handle 3790 it. 3792 UnknownError Unknown Error. Indicates that the 3793 transaction cannot complete for some reason 3794 that is not covered explicitly by any of the 3795 other errors. The Error description 3796 attribute should be used to indicate the 3797 nature of the problem. 3799 The Names attribute might refer to some 3800 attribute or element tags. 3802 (*)SyntaxError Syntax Error. An (unknown) syntax error has 3803 occurred. 3805 The Names attribute might refer to some 3806 attribute or element tags. 3808 The IOTP Application Core has to replace the 3809 error code with "XmlNotValid" or 3810 "UnknownError" before transmission to the 3811 counterparty. 3813 (*)ReqRefused Request refused. The API request is 3814 (currently) refused by the IOTP Payment 3815 Bridge. The error description may provide 3816 further explanations, e.g., "wallet / chip 3817 card reader is unavailable or locked by 3818 another payment transaction", "payment 3819 gateway is overloaded", "unknown chip card 3820 reader", or "unrecognized chip card 3821 inserted, change chip card". 3823 The Consumer's IOTP Application Core may 3824 visualize the error description and ask the 3825 Consumer about the continuation - 3826 alternatives are retry, payment transaction 3827 suspension, and cancellation. Denials due to 3828 invalid Process States should be signaled by 3829 "BusinessError". Typically, this kind of 3830 error is not passed to the counterparty's 3831 IOTP Application Core. Otherwise, it maps to 3832 "TransportError" or "UnknownError". 3834 (*)ReqNotSupp Request not supported. The API 3835 function(ality) has not been implemented in 3836 the IOTP Payment Bridge. Typically, this 3837 kind of error is not passed to the 3838 counterparty's IOTP Application Core. 3839 Otherwise, it maps to "TransportError" or 3840 "UnknownError". 3842 (*)BusError Business Error. The API request has been 3843 rejected because some payment transaction 3844 has an illegal payment status. 3846 The Names attribute may contain references 3847 to payment transactions using the party's 3848 Payment Identifier - it defaults to the 3849 current transaction or might contain the 3850 current payment transaction party's Payment 3851 Identifier. Particularly, this error code is 3852 used to signal any raise of payment business 3853 layer failures. 3855 The IOTP Application Core must inquire the 3856 IOTP Payment Bridge about the actual Process 3857 State which actually encodes the business 3858 error ("Inquire Process State" or "Inquire 3859 Payment Log"). This error code is never 3860 passed to the counterparty's IOTP 3861 Application Core. 3863 Table 3: Common Error Codes 3865 The IOTP Payment Bridge may also use the error description in order 3866 to notify the Consumer about further necessary steps for failure 3867 resolution, e.g., "sorry, your payment transaction failed. 3868 Unfortunately, you have been charged, please contact your issuer." 3870 9.2 Attributes and Elements 3872 The following table explains the XML attributes in alphabetical order 3873 - any parenthesized number behind the attribute tag recommends the 3874 maximal length of the attribute value in characters: 3876 Attribute Description 3878 Amount (11) Indicates the payment amount to be paid in 3879 AmountFrom(11) whole and fractional units of the currency. 3881 AmountTo (11) For example $245.35 would be expressed 3882 "245.35". Note that values smaller than the 3883 smallest denomination are allowed. For 3884 example one tenth of a cent would be 3885 "0.001". 3887 AuthenticationId An identifier specified by the 3888 authenticator which, if returned by the 3889 organization that receives the 3890 authentication request, will enable the 3891 authenticator to identify which 3892 authentication is being referred to. 3894 BrandId (128) This contains a unique identifier for the 3895 brand (or promotional brand). It is used to 3896 match against a list of Payment Instruments 3897 which the Consumer holds to determine 3898 whether or not the Consumer can pay with the 3899 Brand. 3901 Values of BrandId are managed under 3902 procedure being described in the IOTP 3903 protocol specification. 3905 BrandLogoNetLocn The net location which can be used to 3906 download the logo for the organization (cf. 3907 IOTP Specification). 3909 The content of this attribute must conform 3910 to [RFC1738]. 3912 BrandName This contains the name of the brand, for 3913 example "MasterCard Credit". This is the 3914 description of the Brand which is displayed 3915 to the consumer in the Consumer's language 3916 defined by "xml:lang". For example it might 3917 be "American Airlines Advantage Visa". Note 3918 that this attribute is not used for matching 3919 against the payment instruments held by the 3920 Consumer. 3922 BrandNarrative This optional attribute is designed to be 3923 used by the Merchant to indicate some 3924 special conditions or benefit which would 3925 apply if the Consumer selected that brand. 3926 For example "5% discount", "free shipping 3927 and handling", "free breakage insurance for 3928 1 year", "double air miles apply", etc. 3930 CallBackFunction A function which is called whenever there is 3931 a change of Process State or payment 3932 progress, e.g. for display updates. However, 3933 the IOTP Payment Bridge may use its own 3934 mechanisms and dialog boxes. 3936 CallBackLanguageLis A list of language codes which contain, in 3937 t order of preference, the languages in which 3938 the text passed to the Call Back function 3939 will be encoded. 3941 CompletionCode (14) Indicates the nature of the payment failure. 3942 It is required if ProcessState is set to 3943 "Failed" otherwise it is ignored. Valid 3944 values as well as recovery options are given 3945 in the IOTP specification. 3947 The IOTP Payment Bridge may also use the 3948 Status Description to notify the Consumer 3949 about further necessary steps in order to 3950 resolve some kind of business failures, 3951 e.g., 3953 o "sorry, your payment transaction failed. 3954 Unfortunately, you have been charged, 3955 please contact your issuer." 3956 o "insufficient capacity left (on your card) 3957 for refund", 3958 o "payment failed/chip card error/internal 3959 error, please contact your payment 3960 instrument's issuer" 3962 ConsumerDesc A narrative description of the Consumer. 3964 ConsumerPayId (14) An identifier specified by the Consumer 3965 which, if returned by the Payment Handler in 3966 another Payment Scheme Component or by other 3967 means, will enable the Consumer to identify 3968 which payment is being referred to. Its 3969 value uniquely identifies the payment 3970 transaction on the Consumer's system. It is 3971 provided by the IOTP Payment Bridge on 3972 initialization of the payment transaction. 3973 It may equal to the Payment Handler Payment 3974 Identifiers but need not necessarily be so. 3976 It is recommended that uniqueness extends to 3977 multiple payment instruments, payment 3978 brands, payment protocols, wallet 3979 identifiers, and even multiple IOTP Payment 3980 Bridges, if they (might) share the support 3981 of specific payment brands. 3983 ContStatus During payment progress, this status value 3984 indicates whether the payment needs to be 3985 continued with further IOTP Payment Scheme 3986 Component exchanges with the remote party. 3987 "End" indicates that the reported payment 3988 scheme data is the last data to be exchanged 3989 with the counterparty. 3991 ContentSoftwareId This contains information which identifies 3992 the software which generated the element. 3993 Its purpose is to help resolve 3994 interoperability problems that might occur 3995 as a result of incompatibilities between 3996 messages produced by different software. It 3997 must contain, as a minimum: 3999 o the name of the software manufacturer, 4000 o the name of the software, 4001 o the version of the software, and 4002 o the build of the software. 4004 CurrCodeType (14) Indicates the domain of the CurrCode. Its 4005 value defaults to ISO4217-A. 4007 CurrCode (14) A code which identifies the currency to be 4008 used in the payment. The domain of valid 4009 currency codes is defined by "CurrCodeType" 4011 DataBaseFunction This callback functions may be called by the 4012 IOTP Payment Bridge resp. Existing Payment 4013 Software whenever data about transactions 4014 needs to be stored or retrieved. However, 4015 the IOTP Payment Bridge may use its own 4016 mechanisms. 4018 MerchantPayId (14) An private identifier specified by the 4019 Merchant which will enable the Merchant to 4020 identify which payment is being referred to. 4021 It is a pure private item and is never sent 4022 to any other party. It is provided by the 4023 IOTP Payment Bridge on payment preparation 4024 during brand compilation. 4026 Cf. To "ConsumerPayId" for note about 4027 uniqueness. 4029 MerchantOrgId (64) A private item that might refer to some 4030 specific shop in a multi shop environment. 4031 This item is optional and might enrich the 4032 Wallet Identifier which itself can be used 4033 for the same purpose. 4035 Name Distinguishes between multiple occurrences 4036 of Packaged Content Elements at the same 4037 point in IOTP. For example: 4039 4040 4041 snroasdfnas934k 4042 4043 4044 dvdsjnl5poidsdsflkjnw45 4045 4046 4048 The "Name" attribute may be omitted, for 4049 example if there is only one Packaged 4050 Content element. 4052 NumberofPayments The numerical attribute is used to limit the 4053 items in inquiry responses. 4055 OkFrom (30) The date and time in UTC Format range 4056 OkTo (30) indicated by the merchant in which the 4057 Payment Handler may accept the payment. 4059 Passphrase (32) Payment wallets may use pass phrase 4060 protection for transaction data and payment 4061 instruments' data. However, it is assumed 4062 that there exists a public and customizable 4063 payment instrument identifier such that 4064 these identifiers together with their 4065 relationship to payment brands, payment 4066 protocols, payment directions, and currency 4067 amounts can be inquired by the IOTP 4068 application without any pass phrase 4069 knowledge. 4071 PayDirection Indicates the direction in which the 4072 payment for which a Brand is being selected 4073 is to be made. Its values may be: 4075 o Debit: The sender of the Payment Request 4076 Block (e.g. the Consumer) to which this 4077 Brand List relates will make the payment 4078 to the Payment Handler, or 4079 o Credit: The sender of the Payment Request 4080 Block to which this Brand List relates 4081 will receive a payment from the Payment 4082 Handler. 4084 PayInstName This contains the user-defined name of the 4085 payment instrument. There exist no 4086 (technical) constraints like uniqueness. The 4087 "xml:lang" attribute denotes the language 4088 encoding of its value. 4090 PaymentHandlerDesc A narrative description of the Payment 4091 Handler. 4093 PaymentHandlerPayId An identifier specified by the Payment 4094 (14) Handler which, if returned by the Consumer 4095 in another Payment Scheme Component, or by 4096 other means, will enable the Payment Handler 4097 to identify which payment is being referred 4098 to. It is required whenever it is known. Its 4099 value uniquely identifies the payment 4100 transaction on the Payment Handler's system. 4101 It is provided by the IOTP Payment Bridge on 4102 initialization of the payment transaction. 4103 It may equal to the Consumer Payment 4104 Identifiers but need not necessarily be so. 4106 Cf. To "ConsumerPayId" for note about 4107 uniqueness. 4109 PaymentInstrumentId An identifier for a specific payment 4110 (32) instrument, e.g. "credit card", "Mondex card 4111 for English Pounds". This identifier is 4112 fully customizable. It is assumed, that it 4113 does not contain confidential information or 4114 even an indication to it. The payment 4115 instrument identifier is unique within each 4116 payment brand. It is displayed to the 4117 Consumer during brand selection. 4119 PayReceiptNameRefs Optionally contains a list of the values of 4120 the Name attributes of Packaged Content 4121 elements that together make up the receipt. 4122 The Packaged Content elements are container 4123 either within: 4125 o Payment Scheme Data components exchanged 4126 between the Payment Handler and the 4127 Consumer roles during the Payment, and/or 4128 o the Payment Receipt component itself. 4130 Each payment scheme defines in its 4131 supplement the Names of the Packaged Content 4132 elements that must be listed in this 4133 attribute. 4135 PayReqNetLocn The Net Location indicating where an 4136 unsecured Payment Request message should be 4137 sent if this protocol choice is used. 4139 The content of this attribute depends on the 4140 Transport Mechanism (such must conform to 4141 [RFC1738]. 4143 PercentComplete (3) A number between 0 and 100 which indicates 4144 the progress of the payment transaction. The 4145 values range between 0 and 99 for pending 4146 and suspended transactions. 4148 ProcessState Contains a Process State Code which 4149 indicates the current state of the business 4150 success or failure of the processing of the 4151 payment transactions. Valid values are: 4153 o NotYetStarted. The Payment Request Block 4154 has been received but processing of the 4155 Payment Request has not yet started 4157 o InProgress. The payment transaction is 4158 pending. The processing of the Payment 4159 Request Block and any subsequent Payment 4160 Exchange Blocks has started but it is not 4161 yet complete. 4163 o Suspended: The payment transaction has 4164 been suspended and can be resumed. 4166 This process state is mapped to 4167 "InProgress", if it is passed to the 4168 counterparty's IOTP Application Core. 4170 o CompletedOk. Processing of the Payment 4171 Request Block and any following Payment 4172 Exchange Blocks has completed 4173 successfully. 4175 o Failed. The payment has finally failed for 4176 some reason. 4178 o ProcessError. This value is only exchanged 4179 when the Status Component is being used in 4180 connection with an Inquiry Request Trading 4181 Block. It indicates there was a Technical 4182 Error in the Request Block which is being 4183 processed or some internal processing 4184 error. Each party's IOTP Payment Bridge 4185 uses this value in order to notify the 4186 IOTP Application Core about the presence 4187 of technical errors. 4189 PropertyType (14) The property type defines codes used for 4190 interrogation of specific properties about a 4191 payment instrument. They are unique for each 4192 payment brand. The predefined property "all" 4193 is used on general inquiries. However, these 4194 property types are not used during normal 4195 payment processing. E.g., they may apply to 4196 payment brand specific transactions or out- 4197 of-band failure resolution. 4199 PropertyDesc The property description carries the 4200 respective human readable property (value)'s 4201 description. 4203 PropertyValue The actual property value intends automatic 4204 post processing. 4206 ProtocolBrandId (64)This is an identifier to be used with a 4207 particular payment protocol. For example, 4208 SET and EMV have their own well defined, yet 4209 different, values for the Brand identifier 4210 to be used with each protocol. One Brand 4211 Identifier maps to at most one Protocol 4212 Brand Identifier. 4214 ProtocolId (64) An identifier for a specific payment 4215 protocol and version, e.g. "SETv1.0", 4216 "ecash". Valid values are defined by 4217 supplements to the IOTP specification and 4218 they are unique within each payment brand. 4220 ProtocolIds A sequence of Protocol Identifiers 4222 ProtocolName A narrative description of the payment 4223 protocol and its version in the language 4224 identified by "xml:lang". For example 4225 "Secure Electronic Transaction Version 1.0". 4226 Its purpose is to help provide information 4227 on the payment protocol being used if 4228 problems arise. 4230 ResponseCode This attribute encodes a binary flag with 4231 the value "Yes" and "No". 4233 SecPayReqNetLocn The Net Location indicating where a secured 4234 Payment Request message should be sent if 4235 this protocol choice is used. 4237 A secured payment involves the use of a 4238 secure channel such as [SSL] in order to 4239 communicate with the Payment Handler. 4241 The content of this attribute must conform 4242 to [RFC1738]. 4244 ReceiverOrgId The Organization Identification which 4245 receives the payment bridge processing 4246 Trading Role Data PackagedContent. 4248 StatusDesc (256) An optional textual description of the 4249 current process state in the language 4250 identified by "xml:lang" that should be 4251 displayed to the Consumer. The usage of this 4252 attribute is defined in the payment 4253 supplement for the payment method being 4254 used. Particularly, it provides hints for 4255 out-of-band failure resolution. Its length 4256 is limited to 256 characters. 4258 StyleSheetNetLocn This contains the net location to a style 4259 sheet with visualisation rules for XML 4260 encoded data. 4262 TimeStamp (30) The date and time in UTC Format when the 4263 TimeStampFrom (30) payment transaction has been started. 4264 TimeStampTo (30) 4266 WalletId (32) Many existing payment wallet software are 4267 multiple wallet capable. The Wallet 4268 Identifier selects the actual wallet. It is 4269 assumed, that the wallet identifier is a 4270 public item, that might be stored by the 4271 IOTP Application Core. 4273 xml:lang Defines the language used by the Process 4274 State Description attribute (cf. IOTP 4275 Specification) 4277 Table 4: Attributes 4279 The following table explains the XML elements in alphabetical 4280 order: 4282 Element Description 4284 Algorithm This contains information which describes 4285 an Algorithm that may be used to generate 4286 the Authentication response. The 4287 algorithm that may be used is identified 4288 by the Name attribute (cf. IOTP 4289 Specification). 4291 AuthReqPackagedContent The Authentication Request Packaged 4292 Content originates from a Authentication 4293 (Data/Response) Component's content 4294 whereby the outermost element tags are 4295 prefixed with "AuthReq". Its declaration 4296 coincides with the Packaged Content's 4297 declaration (cf. IOTP Specification). It 4298 encapsulates the authentication challenge 4299 value. The content of this information is 4300 defined in the supplement for a payment 4301 protocol. 4303 AuthResPackagedContent The Authentication Response Packaged 4304 Content originates from a Authentication 4305 (Data/Response) Component's content 4306 whereby the outermost element tags are 4307 prefixed with "AuthRes". Its declaration 4308 coincides with the Packaged Content's 4309 declaration (cf. IOTP Specification). It 4310 encapsulates the authentication response 4311 value. The content of this information is 4312 defined in the supplement for a payment 4313 protocol. 4315 BrandPackagedContent Container for further payment brand 4316 description. Its content originates from 4317 a Brand Element content whose outermost 4318 element tags are prefixed with "Brand". 4319 Its declaration coincides with the 4320 Packaged Content's declaration (cf. IOTP 4321 Specification). 4323 BrandSelBrandInfoPacka This contains any additional data that 4324 gedContent may be required by a particular payment 4325 brand. It forms the content of the Brand 4326 Selection Brand Info Element. 4328 BrandSelProtocolAmount This contains any additional data that 4329 InfoPackagedContent may be required by a particular payment 4330 brand in the format. It forms the content 4331 of the Brand Selection Protocol Amount 4332 Info Element. 4334 BrandSelCurrencyAmount This contains any additional data that 4335 InfoPackagedContent payment brand and currency specific in 4336 the format. It forms the content of the 4337 Brand Selection Currency Amount Info 4338 Element. 4340 ChallengePackagedConte Container for authentication challenge 4341 nt data. Its content originates from a 4342 Authentication Data Component's Packaged 4343 Content element whose outermost element 4344 tags are prefixed with "Challenge". Its 4345 declaration coincides with the Packaged 4346 Content's declaration (cf. IOTP 4347 Specification). 4349 MerchantData Any merchant related data that might be 4350 used by the IOTP Payment Bridge for 4351 different purposes, e.g., it might 4352 contain access keys to some mall keys. 4353 Its declaration coincides with the 4354 Packaged Content's declaration (cf. IOTP 4355 Specification). 4357 PackagedContent Generic Container for non-IOTP data (cf. 4358 IOTP Specification). 4360 PayReceiptPackagedCont Its content originates from a Payment 4361 ent Receipt Component's Packaged Content 4362 whose outermost element tags are prefixed 4363 with "PayReceipt". Its declaration 4364 coincides with the Packaged Content's 4365 declaration (cf. IOTP Specification). 4367 PaySchemePackagedConte The PayScheme Packaged Content originates 4368 nt from a Payment Scheme Component's content 4369 whereby the outermost element tags are 4370 prefixed with "PayScheme". Its 4371 declaration coincides with the Packaged 4372 Content's declaration (cf. IOTP 4373 Specification). It carries the payment 4374 specific data. The content of this 4375 information is defined in the supplement 4376 for a payment protocol. 4378 ProtocolAmountPackaged The Protocol Amount Packaged Content 4379 Content originates from a Protocol Amount 4380 Element's content whereby the outermost 4381 element tags are prefixed with "Amount". 4382 Its declaration coincides with the 4383 Packaged Content's declaration (cf. IOTP 4384 Specification). It contains information 4385 about the protocol which is used by the 4386 payment protocol. The content of this 4387 information is defined in the supplement 4388 for a payment protocol. 4390 ProtocolBrandPackagedC The Protocol Brand Packaged Content 4391 ontent originates from a Protocol Brand 4392 Element's content whereby the outermost 4393 element tags are prefixed with 4394 "ProtocolBrand". Its declaration 4395 coincides with the Packaged Content's 4396 declaration (cf. IOTP Specification). It 4397 contains information about the brand 4398 which might be used by the payment 4399 protocol. The content of this information 4400 is defined in the supplement for a 4401 payment protocol. 4403 ResponsePackagedConten Container for authentication response 4404 t data. Its content originates from a 4405 Authentication Response Component's 4406 Packaged Content whose outermost element 4407 tags are prefixed with "Response". Its 4408 declaration coincides with the Packaged 4409 Content's declaration (cf. IOTP 4410 Specification). 4412 TradingRoleDataPackage The TradingRoleData Packaged Content 4413 dContent originates from a TradingRoleData 4414 Component's content whereby the outermost 4415 element tags are prefixed with 4416 "TradingRoleData". Its declaration 4417 coincides with the Packaged Content's 4418 declaration (cf. IOTP Specification). It 4419 contains information from Merchant to 4420 Payment Handler via Consumer about the 4421 protocol which is used by the payment. 4422 The content of this information is 4423 defined in the supplement for a payment 4424 protocol. The Name attribute in this 4425 packaged contents must include prefix as 4426 "Payment:" to indicate that the payment 4427 bridge processes this, for example 4428 "Payment:SET-OD" 4429 Table 5: Elements 4431 10. Payment API Calls 4433 10.1 Brand Compilation Related API Calls 4435 10.1.1 Find Accepted Payment Brand 4437 This function determines which payment brands could be accepted by 4438 the Payment Handler on behalf of the Merchant. 4440 Input Parameters 4442 o Payment Direction - provided by the IOTP Application Core 4443 o Currency Code and Currency - provided by the IOTP Application 4444 Core 4445 o Payment Amount - provided by the IOTP Application Core 4446 o Merchant Payment Identifier - Merchant's unique private 4447 reference to the payment transaction 4448 o Merchant Organisation Identifier - used for distinction between 4449 multiple merchants that share the some IOTP merchant system 4450 o Wallet Identifier - managed by the IOTP Application Core 4451 o Merchant Data - specific data used by the IOTP Payment Bridge 4452 which is managed in the IOTP Application Core. 4454 XML definition: 4456 4457 4466 Output Parameters 4468 o Payment Brand Identifier - for insertion in the Brand List 4469 Component's Brand Element 4470 o Payment Brand Name and language annotation - for insertion in 4471 the Brand List Component's Brand Element 4472 o Payment Brand Logo Net Location - for insertion in the Brand 4473 List Component's Brand Element 4474 o Payment Brand Narrative Description - for insertion in the 4475 Brand List Component's Brand Element 4476 o (Brand) Packaged Content - further payment brand description 4477 for insertion in the Brand List Component's Brand Element 4479 The Existing Payment Software returns an empty list of brand items, 4480 if it does not support any payment brand/payment protocol combination 4481 for the given payment parameters. 4483 XML definition: 4485 4486 4487 4488 4495 Tables 4 and 5 explain the attributes and elements; Table 3 4496 introduces the Error Codes. 4498 10.1.2 Find Accepted Payment Protocol 4500 Determines which instances of payment protocols are accepted by the 4501 Payment Handler on behalf of the Merchant. 4503 Input Parameters 4505 o Brand Identifier - returned by "Find Accepted Payment Brand" 4506 o Payment Direction 4507 o Currency Code and Currency 4508 o Payment Amount 4509 o Merchant Payment Identifier - Merchant's unique private 4510 reference to the payment transaction 4511 o Merchant Organisation Identifier - used for distinction between 4512 multiple merchants that share the some IOTP merchant system 4513 o Wallet Identifier - managed by the IOTP Application Core 4514 o (Brand) Packaged Content - further payment brand description; 4515 returned by "Find Accepted Payment Brand" 4516 o Merchant Data - specific data used by the IOTP Payment Bridge 4517 which is managed in the IOTP Application Core. 4519 XML definition: 4521 4523 4533 Output Parameters 4535 o Merchant Organisation Identifier - used for distinction between 4536 multiple merchants that share the some IOTP merchant system 4537 o Refined Currency Code and Currency - for insertion in the Brand 4538 List Component's Currency Amount Element 4539 o Refined Payment Amount - for insertion in the Brand List 4540 Component's Currency Amount Element 4541 o Payment Protocol Identifier - for insertion in the Brand List 4542 Component's Pay Protocol Element 4543 o Protocol Brand Identifier - for insertion in the Protocol Brand 4544 Element of the Brand List Component's Brand Element 4545 o Payment Protocol Name and language annotation- for insertion in 4546 the Brand List Component's Pay Protocol Element 4547 o Payment Request Net Location - for insertion in the Brand List 4548 Component's Pay Protocol Element 4549 o Secured Payment Request Net Location - for insertion in the 4550 Brand List Component's Pay Protocol Element 4551 o (Protocol Brand) Packaged Content - for insertion in the 4552 Protocol Brand Element of the Brand List Component's Brand 4553 Element 4554 o (Protocol Amount) Packaged Content - for insertion in the Brand 4555 List Component's Protocol Amount Element 4556 o (Protocol) Packaged Content - for insertion in the Brand List 4557 Component's Pay Protocol Element 4559 XML definition: 4561 4562 4563 4566 4577 Tables 4 and 5 explain the attributes and elements; Table 3 4578 introduces the Error Codes. 4580 10.1.3 Get Payment Initialization Data 4582 This API function provides the remaining initialization data being 4583 required by the Consumer's or Payment Handler's Existing Payment 4584 Software. This function might be called both for "brand dependent" 4585 and "brand independent" transaction types. 4587 Input Parameters 4589 o Brand Identifier - returned by "Find Accepted Payment Brand" 4590 o Merchant Payment Identifier - Merchant's unique private 4591 reference to the payment transaction 4592 o Payment Direction 4593 o Currency Code and Currency - from the Brand List Component's 4594 Currency Amount Element 4595 o Payment Amount - from the Brand List Component's Currency 4596 Amount Element 4597 o Payment Protocol Identifier - from the Brand List Component's 4598 Pay Protocol Element 4599 o Protocol Brand Identifier - from the Protocol Brand Element 4600 which relates to the selected Brand Element, if any 4601 o (TradingRoleData) Receiver Organization Identifier 4602 o OkFrom, OkTo - identical to the entries of the Order Component 4603 o Merchant Organisation Identifier - used for distinction between 4604 multiple merchants that share the some IOTP merchant system 4605 o Wallet Identifier and/or Pass Phrase 4606 o (Brand) Packaged Content - further payment brand description, 4607 from the Brand List Component's Brand Element 4608 o (Protocol Amount) Packaged Content - further payment protocol 4609 description, from the Brand List Component's Protocol Amount 4610 Element 4611 o (Protocol) Packaged Content - further payment protocol 4612 description, from the Brand List Component's Pay Protocol 4613 Element 4614 o (Protocol Brand) Packaged Content - further brand information, 4615 from the Protocol Brand Element of the Brand List Component 4616 which relates to the selected Brand Element, if any 4617 o (Order) Packaged Content - further order description, from the 4618 Order Element 4620 o three Brand Selection Info Packaged Content elements - copied 4621 from the Brand Selection Component on brand dependent purchases 4622 o Brand - additional data about the payment brand 4623 o Protocol Amount - additional data about the payment protocol 4624 o Currency Amount - additional payment brand and currency 4625 specific data 4626 o Merchant Data - specific data used by the IOTP Payment Bridge 4627 which is managed in the IOTP Application Core. 4629 XML definition: 4631 4640 4656 Output Parameters 4658 o OkFrom, OkTo - for insertion in the Payment Component 4659 o (TradingRoleData) Packaged Content - further payment protocol 4660 description; the Name Attribute of the packaged contents must 4661 include "Payment:" as the prefix, for example "Payment:SET-OD". 4662 o (Order) Packaged Content - defaults to the supplied order 4663 packaged data on omission 4665 The Merchant might 4667 o overwrite the previously returned Merchant Payment Identifier 4668 with a new value, 4669 o return just now the Merchant Payment Identifier, or 4670 o may skip the generation of any Merchant Payment Identifier. 4672 XML definition: 4674 4677 4681 Tables 4 and 5 explain the attributes and elements; Table 3 4682 introduces the Error Codes. 4684 10.1.4 Inquire Authentication Challenge 4686 This API function inquires any payment protocol specific 4687 authentication challenge value from the IOTP Payment Bridge. In 4688 Baseline IOTP this API function is called by the Merchant or 4689 Financial Institution, typically. The IOTP Application Core may 4690 propose a choice of algorithms to the IOTP Payment Bridge. However, 4691 the IOTP Payment Bridge may ignore the proposal and select some other 4692 algorithm. The inquiry is assumed to be stateless. E.g., the IOTP 4693 Application Core may check the returned algorithm and stop 4694 transaction processing without notifying the IOTP Payment Bridge. 4696 The IOTP Application Core may submit several API calls to the IOTP 4697 Payment Bridge to build up the Authentication Request Block. Any 4698 choice of algorithms should be reduced by the accepted algorithms 4699 from earlier API responses. 4701 Input Parameters 4703 o Authentication Identifier - the authenticator may provide its 4704 payment identifier, i.e., Payment Handler or Merchant Payment 4705 Identifier. 4706 o Wallet Identifier and/or Pass Phrase 4707 o set of pre-selected algorithms for authentication 4709 XML definition: 4711 4712 4717 Output Parameters 4718 o list of Authentication Challenge Packaged Contents - for 4719 insertion into the IOTP Authentication Request Component 4720 o Algorithm Element - for insertion into the IOTP Authentication 4721 Request Component 4723 XML definition: 4725 4727 4729 Tables 4 and 5 explain the attributes and elements; Table 3 4730 introduces the Error Codes. 4732 10.1.5 Authenticate 4734 The Consumer's IOTP Application Core defers payment protocol specific 4735 authentication processing and the current challenge value to the 4736 active IOTP Payment Bridge. Alternative authentication algorithms 4737 might be tried sequentially or offered to the user for selection. 4739 Note that the IOTP Application Core has to consider both the current 4740 context and the algorithm in order to determine the responsible IOTP 4741 Payment Bridge. 4743 Failed authentication is reported by the Business Error Code which 4744 might trigger the inquiry of the details ("Inquire Process State"). 4746 Input Parameters 4748 o Authentication Identifier 4749 o Wallet Identifier and/or Pass Phrase 4750 o Authentication Challenge Packaged Content - copied from the 4751 IOTP Authentication Request Component 4752 o Algorithm Element - copied from the IOTP Authentication Request 4753 Component 4755 XML definition: 4757 4758 4763 Output Parameters 4765 o Authentication Response Packaged Content - for insertion into 4766 the IOTP Authentication Response Component 4768 XML definition: 4770 4771 4773 Tables 4 and 5 explain the attributes and elements; Table 3 4774 introduces the Error Codes. 4776 10.1.6 Check Authentication Response 4778 This API function verifies the Consumer's payment protocol specific 4779 authentication response. In Baseline IOTP this API function is called 4780 by the Merchant or the Financial Institution. This API call happens 4781 only if the counterparty has responded with an Authentication 4782 Response Component within the Authentication Response Block. 4784 Due to the authentication's statelessness, all parameters are 4785 returned to the IOTP Payment Bridge. Authentication failure is 4786 reported by a Process State different from "CompletedOK". 4788 Input Parameters 4790 o Authentication Identifier 4791 o Wallet Identifier and/or Pass Phrase 4792 o Authentication Challenge Packaged Content - generated by the 4793 Inquire Authentication Challenge (1st content element) 4794 o Algorithm Element 4795 o Authentication Response Packaged Content - copied from the 4796 Authentication Response Component (2nd content element) 4798 XML definition: 4800 4802 4807 Output Parameters 4809 o Current Process (Authentication) State 4810 o Completion Code 4811 o Status Description and its language annotation 4813 XML definition: 4815 4816 4827 Tables 4 and 5 explain the attributes and elements; Table 3 4828 introduces the Error Codes. 4830 10.1.7 Cancel Payment 4832 This API function is used by the merchant to notify the local IOTP 4833 Payment Bridge resp. the payment modules about the immediate 4834 termination of a payment transaction during the compilation of a 4835 brand list. 4837 All the involved components may execute shut down operations on 4838 internal components and data structures. 4840 This call might happen anytime during the Brand List Compilation 4841 process, i.e., before the Offer Response Block has been send to the 4842 Consumer. Normally, no response code is returned. 4844 Input Parameters 4846 o Merchant Payment Identifier - Merchant's unique reference to 4847 the current payment transaction 4848 o intended Payment Status 4849 o intended Completion Code 4850 o Wallet Identifier and/or Pass Phrase 4852 XML definition: 4854 4855 4868 Output Parameters 4870 XML definition: 4872 4873 4875 Tables 4 and 5 explain the attributes and elements; Table 3 4876 introduces the Error Codes. 4878 Essentially, this API function implements a short cut to the API 4879 function "Change Process State" (see below) with specific input 4880 parameters and skips the returned attribute values, i.e. any call of 4881 the form 4883 4890 mimics the call 4892 . 4900 Note that the Merchant Payment Identifier is mapped to the Payment 4901 Handler Payment Identifier. This is valid because the Payment Handler 4902 has not been involved, so far. 4904 10.2 Brand Selection Related API Calls 4906 10.2.1 Find Payment Instrument" 4908 This API function determines which instances of a Payment Brand, 4909 e.g., two Mondex cards, are present. The same physical card may even 4910 represent multiple payment instruments. 4912 Essentially, the function supports two kinds of payment instrument 4913 inquiries. Either, the Protocol Identifier and the optional Brand 4914 Protocol Identifier might be specified on the input parameter list, 4915 or they might be unspecified. In the former case, the IOTP 4916 Application Core should also provide any necessary Protocol (Amount) 4917 Packaged Contents. By this the IOTP Application Core might check for 4918 valid Payment Instruments for each of the alternatives that have been 4919 offered by the Merchant. 4921 In the latter case, the API function returns the superset of 4922 potentially supported payment instruments (for some Payment 4923 Protocol). For each of this Payment Instrument, the valid Payment 4924 Protocols have to be inquired by the API function "Find Payment 4925 Protocol" and matched by the IOTP Application Core against the 4926 Payment Protocols that has been reported by the Merchant. 4928 Input Parameters 4930 o Brand Identifier - copied from the Brand List Component's Brand 4931 Element 4932 o payment Protocol Identifier and associated Protocol Brand 4933 Identifier 4934 o Payment Direction - copied from the Brand List Component 4935 o Currency Code and Currency - copied from the Currency Amount 4936 Element 4937 o Payment Amount - copied from the Currency Amount Element 4938 o Consumer Payment Identifier - Consumer's unique reference to 4939 the current payment transaction 4940 o Wallet Identifier - managed by the IOTP Application Core 4941 o (Brand) Packaged Content - further payment brand description; 4942 copied from the Brand List Component's Brand Element 4943 o (Protocol Brand) Packaged Content - further brand information, 4944 from the Protocol Brand Element of the Brand List Component 4945 which relates to the selected Brand Element, if any 4946 o (Protocol Amount) Packaged Content - further payment protocol 4947 description, copied from the Brand List Component's Protocol 4948 Amount Element 4949 o Element (Protocol) Packaged Content - further payment protocol 4950 description, copied from the Brand List Component's Pay 4951 Protocol Element 4953 XML definition: 4955 4959 4970 Output Parameters 4972 o The known Payment Instrument Identifiers, these are internal 4973 values 4974 o The user-defined names of the payment instrument and their 4975 language encoding 4977 The Existing Payment Software responds with an empty list of 4978 identifiers, either if it does not distinguish between different 4979 payment instruments or if there are no registered payment instruments 4980 available despite brand support for at least one (unspecified) 4981 payment protocol. In the latter case, the IOTP Payment Bridge has to 4982 request the registration of a suitable payment instrument at a 4983 subsequent step of the payment process. 4985 XML definition: 4987 4988 4989 4990 4995 Tables 4 and 5 explain the attributes and elements; Table 3 4996 introduces the Error Codes. 4998 10.2.2 Find Payment Protocol 5000 Determines which instances of payment protocols are supported by a 5001 particular payment instrument. On omission of the payment instrument, 5002 the IOTP Payment Bridge responds with the superset of payment 5003 protocols, supported by all known payment instruments. 5005 Input Parameters 5007 o Brand Identifier - copied from the Brand List Component's Brand 5008 Element 5009 o Payment Instrument Identifier - derived from the Find Payment 5010 Instrument responses 5011 o Payment Direction - copied from the Brand List Component 5012 o Currency Code and Currency - copied from the Currency Amount 5013 Element 5014 o Payment Amount - copied from the Currency Amount Element 5015 o Consumer Payment Identifier - Consumer's unique reference to 5016 the current payment transaction 5017 o Wallet Identifier - managed by the IOTP Application Core 5018 o (Brand) Packaged Content - further payment brand description; 5019 copied from the Brand List Component's Brand Element 5020 o (Protocol Brand) Packaged Content - further brand information, 5021 from the Protocol Brand Element of the Brand List Component 5022 which relates to the selected Brand Element, if any 5023 o (Protocol Amount) Packaged Content - further payment protocol 5024 description, copied from the Brand List Component's Protocol 5025 Amount Element 5026 o (Protocol) Packaged Content - further payment protocol 5027 description, copied from the Brand List Component's Pay 5028 Protocol Element 5030 XML definition: 5032 5036 5046 Output Parameters 5048 o The supported payment protocol identifiers and associated 5049 protocol brand identifiers 5051 XML definition: 5053 5054 5055 5056 5060 Tables 4 and 5 explain the attributes and elements; Table 3 5061 introduces the Error Codes. 5063 10.2.3 Check Payment Possibility 5065 This API function checks whether a payment (both debit and credit) 5066 can go ahead. It can be used, for example, to check 5068 o if there are sufficient funds available in a particular 5069 currency for an electronic cash payment brand, 5070 o whether there is sufficient value space left on the payment 5071 instrument for payment refund, 5072 o whether required system resources are available and properly 5073 configured, e.g., serial ports or baud rate, 5074 o whether environment requirements are fulfilled, e.g., chip card 5075 reader presence or Internet connection. 5077 In addition, it may be used to remind the Consumer to register a 5078 suitable payment instrument if an IOTP Payment Bridge has been 5079 selected that contains no valid payment instrument. 5081 If the payment method bases on external components, e.g., magnetic 5082 stripe or chip cards, and the check accesses the medium, the existing 5083 payment method should not mutually exclusive lock system resources, 5084 e.g., serial port or modem, that may also be required by other 5085 Existing Payment Software, e.g., multiple payment software components 5086 may share the same card reader. If this happens for API internal 5087 request processing, the function has to unlock these components on 5088 return. Otherwise, the payment may not proceed if the Consumer 5089 cancels immediately and decides to use another payment instrument. In 5090 this event the previous IOTP Payment Bridge is not notified about the 5091 change. 5093 This call happens immediately after the Consumer's payment instrument 5094 selection. For example, if the payment instrument is a chip card, 5095 that is not inserted in the chip card reader, the Consumer may be 5096 prompted for its insertion. However, the Consumer should be able to 5097 hit some 'skip' button, if the payment check is part of the actual 5098 payment protocol, too. Finally, the IOTP Payment Bridge may provide 5099 only a subset of these capabilities or may even directly generate a 5100 successful response without any checks. Alternatively, the callee 5101 might respond with the ReqNotSupport error code. 5103 Input Parameters 5105 o Brand Identifier - user selection 5106 o Payment Instrument Identifier - user selection 5107 o Currency Code and Currency Code Type - copied from the selected 5108 Currency Amount Element 5109 o Payment Amount - copied from the selected Currency Amount 5110 Element 5111 o Payment Direction - copied from the selected Trading Protocol 5112 Option Block 5113 o Protocol Identifier - copied from the selected Pay Protocol 5114 Element 5115 o Protocol Brand Identifier - copied from the selected Protocol 5116 Brand Element of the Brand List Component which relates to the 5117 selected Brand Element, if any 5118 o Consumer Payment Identifier - Consumer's unique reference to 5119 the current payment transaction 5120 o Wallet Identifier and/or Pass Phrase 5121 o (Brand) Packaged Content - copied from the selected Brand 5122 Element 5123 o (Protocol Amount) Packaged Content - copied from the selected 5124 Protocol Amount Element 5125 o (Protocol) Packaged Content - copied from the selected Pay 5126 Protocol Element 5127 o (Protocol Brand) Packaged Content - copied from the selected 5128 Protocol Brand Element of the Brand List Component which 5129 relates to the selected Brand Element, if any 5131 XML definition: 5133 5137 5150 Output Parameters 5152 o three Brand Selection Info Packaged Content elements - for 5153 insertion into the Brand Selection component 5154 o Brand - additional data about the payment brand 5155 o Protocol Amount - additional data about the payment protocol 5156 o Currency Amount - additional payment brand and currency 5157 specific data 5159 XML definition: 5161 5165 5167 Tables 4 and 5 explain the attributes and elements; Table 3 5168 introduces the Error Codes. 5170 10.2.4 Quit Payment Instrument 5172 This API function is used by the card holder to notify the local IOTP 5173 Payment Bridge resp. the payment modules about the immediate 5174 termination of a payment transaction during the selection of a 5175 Payment Instrument. 5177 All the involved components may execute shut down operations on 5178 internal components and data structures. 5180 This call might happen anytime during the Payment Instrument 5181 Selection process, i.e., before the "Start Payment Consumer" call has 5182 been issued. Normally, no response code is returned. 5184 Input Parameters 5186 o Consumer Payment Identifier - Consumer's unique reference to 5187 the current payment transaction 5188 o Wallet Identifier and/or Pass Phrase 5190 XML definition: 5192 5193 5198 Output Parameters 5200 XML definition: 5202 5203 5204 Tables 4 and 5 explain the attributes and elements; Table 3 5205 introduces the Error Codes. 5207 Essentially, this API function implements a short cut to the API 5208 function "Change Process State" (see below) with specific input 5209 parameters and skips the returned attribute values, i.e. any call of 5210 the form 5212 5217 mimics the call 5219 . 5226 10.3 Payment Transaction Related API calls 5228 These Payment API calls may be made either by the Consumer's or 5229 Payment Handler's IOTP Application Core. 5231 10.3.1 Start Payment Consumer 5233 Initiates a payment at the Consumer side. The IOTP Payment Bridge and 5234 the Existing Payment Software perform all necessary initialization 5235 and preparation for payment transaction processing. This includes the 5236 reservation of external periphery. E.g., the Consumer's chip card 5237 reader needs to be protected against access from other software 5238 components, the insertion of the chip card may be requested, the 5239 Internet connection may be re-established, or the Payment Handler may 5240 open a mutual exclusive session to the security hardware. 5242 The IOTP Payment Bridge monitors the payment progress and stores the 5243 current payment states such that resumption - even after power 5244 failures - remains possible. The resumption API call provides only a 5245 subset of the input parameters of the start payment call and refers 5246 to the payment transaction through the individual party's payment 5247 identifier. 5249 The IOTP Payment Bridge may remain accessible for payment processing 5250 without any further supplement of wallet identifiers and pass phrases 5251 until the transaction's payment status changes to some status 5252 different from 'InProgress'. Nevertheless, the IOTP Application Core 5253 has to remember both attribute values for further API call issuance 5254 and might be requested to supply this information on subsequent API 5255 calls. But it is recommended that the IOTP Application Core forgets 5256 these values after any payment transaction status change (Change 5257 Process State) and removes at least their plain text representations. 5259 Input Parameters 5261 o Brand Identifier - copied from the selected Brand Element 5262 o Payment Instrument Identifier - the user selection 5263 o Currency Code and Currency - copied from the selected Currency 5264 Amount Element 5265 o Payment Amount - copied from the selected Currency Amount 5266 Element 5267 o Payment Direction - copied from the Brand List Component 5268 o Protocol Identifier - copied from the selected Payment Protocol 5269 Element 5270 o Protocol Brand Identifier - copied from the Brand Protocol 5271 Element of the Brand List Component which relates to the 5272 selected Brand Element, if any 5273 o OkFrom, OkTo - copied from the Payment Component 5274 o Consumer Payment Identifier - Consumer's unique reference to 5275 the current payment transaction 5276 o Wallet Identifier and/or Pass Phrase 5277 o Call Back Function - used for end user notification/logging 5278 purposes 5279 o Call Back Language List. This list is required if the Call Back 5280 Function is set 5281 o Database Function - the IOTP Payment bridge may refer to this 5282 API function for data management purposes 5283 o (Brand) Packaged Content - further payment brand description; 5284 copied from the selected Brand Element's content 5285 o (Protocol Brand) Packaged Content - further information; copied 5286 from the Protocol Brand Element of the Brand List Component 5287 which relates to the selected Brand Element, if any 5288 o (Protocol Amount) Packaged Content - further payment protocol 5289 description; copied from the selected Protocol Amount Element's 5290 content 5291 o (Protocol) Packaged Content - further payment protocol 5292 description; copied from the selected Pay Protocol Element's 5293 ncontent 5294 o (Order) Packaged Content - further order description, copied 5295 from the Order Component 5297 XML definition: 5299 5304 5322 Output Parameters 5324 o Time Stamp 5325 o Continuation Status 5326 o (Payment Scheme) Packaged Content - for insertion into the 5327 Payment Scheme Component of the IOTP Payment Request Block 5329 The IOTP Application Core is allowed to reissue this request several 5330 times on failed analyses of the response. 5332 XML definition: 5334 5336 5340 Tables 4 and 5 explain the attributes and elements; Table 3 5341 introduces the Error Codes. 5343 10.3.2 Start Payment Payment Handler 5345 Initiates a payment at the Payment Handler's side. Similar to the 5346 Consumer's system, the IOTP Payment Bridge and the Existing Payment 5347 Software perform all necessary initialization and preparation for 5348 payment transaction processing. 5350 The IOTP Payment Bridge may remain accessible for payment processing 5351 without any further supplement of wallet/till identifiers and pass 5352 phrases until the transaction's payment status changes to some status 5353 different from 'InProgress'. Nevertheless, the IOTP Application Core 5354 has to remember both attribute values for further API call issuances 5355 and might be requested to supply this information on subsequent API 5356 calls. But it is recommended, that the IOTP Application Core forgets 5357 these values after any payment transaction status change (Change 5358 Process State) and removes at least their plain text representations. 5360 Input Parameters 5362 o Brand Identifier - copied from the Consumer selected Brand 5363 Element 5364 o Consumer Payment Identifier - copied from the Payment Scheme 5365 Component 5366 o Currency Code and Currency - copied from the Consumer selected 5367 Currency Amount Element 5368 o Payment Amount - copied from the Consumer selected Currency 5369 Amount Element 5370 o Payment Direction - copied from the Brand List Component 5371 o Protocol Identifier - copied from the Consumer selected 5372 Payment Protocol Element 5373 o Protocol Brand Identifier - copied from the Brand Protocol 5374 Element of the Brand List Component which relates to the 5375 Consumer selected Brand Element, if any 5376 o OkFrom, OkTo - copied from the Payment Component 5377 o Payment Handler Payment Identifier - Payment Handler's unique 5378 reference to the current payment transaction 5379 o Merchant Organisation Identifier - copied from the Merchant's 5380 Organisation Element 5381 o Wallet Identifier - renaming to till identifier neglected - 5382 and/or Pass Phrase 5383 o Call Back Function - used for end user notification/logging 5384 purposes 5385 o Call Back Language List. This list is required if the call back 5386 function is set 5387 o Database Function - the IOTP Payment bridge may refer to this 5388 API function for data management purposes 5389 o (Brand) Packaged Content - further payment brand description; 5390 copied from the Consumer selected Brand Element's content 5391 o (Protocol Brand) Packaged Content - further information; copied 5392 from the Protocol Brand Element of the Brand List Component 5393 which relates to the Consumer selected Brand Element, if any. 5394 o (Protocol Amount) Packaged Content - further payment protocol 5395 description; copied from the Consumer selected Protocol Amount 5396 Element's content 5397 o (Protocol) Packaged Content - further payment protocol 5398 description; copied from the Consumer selected Pay Protocol 5399 Element's content 5400 o (TradingRoleData) Packaged Content - further payment protocol 5401 description; the Name Attribute of the packaged contents must 5402 include "Payment:" as the prefix, for example "Payment:SET-OD". 5403 o Three Brand Selection Info Packaged Content Elements - copied 5404 from the Brand Selection Component 5405 o Brand - additional data about the payment brand 5406 o Protocol Amount - additional data about the payment protocol 5407 o Currency Amount - additional payment brand and currency 5408 specific data 5409 o (Payment Scheme) Packaged Content. 5411 XML definition: 5413 5422 5441 Output Parameters 5443 o Time Stamp 5444 o Continuation Status 5445 o (Payment Scheme) Packaged Content - for insertion into the 5446 Payment Scheme Component of the IOTP Payment Exchange Block 5448 The response message must contain payment schema data if the 5449 continuation status signals "Continue". The IOTP Application Core is 5450 allowed to reissue this request several times on failed analyses of 5451 the response. 5453 XML definition: 5455 5457 5461 Tables 4 and 5 explain the attributes and elements; Table 3 5462 introduces the Error Codes. 5464 10.3.3 Resume Payment Consumer 5466 This API function resumes a previously suspended payment at the 5467 Consumer side. Resumption includes the internal inquiry of the 5468 payment transaction data, e.g., payment amount, protocol identifier, 5469 and the whole initialization as it has been applied on the Start 5470 Payment Consumer API request. 5472 The IOTP Payment Bridge may remain accessible for payment processing 5473 without any further supplement of wallet identifiers and pass phrases 5474 until the transaction's payment status changes to some status 5475 different from 'InProgress'. 5477 It is up to the IOTP Application Core to decide whether a Payment 5478 Request Block or a Payment Exchange Block needs to be generated. One 5479 indicator might be the receipt of a previous Payment Exchange Block 5480 from the Payment Handler, e.g., the knowledge of the Payment Handler 5481 Payment Identifier. 5483 Input Parameters 5485 o Consumer Payment Identifier 5486 o Wallet Identifier and/or Pass Phrase 5487 o Database Function - the IOTP Payment bridge may refer to this 5488 API function for data management purposes, particularly, to 5489 inquire the remaining payment parameters and the current 5490 payment state 5492 XML definition: 5494 5495 5501 Output Parameters 5503 o Continuation Status 5504 o (Payment Scheme) Packaged Content - for insertion in the 5505 Payment Scheme Component of the next IOTP message (Payment 5506 Exchange or Request Block). 5508 The IOTP Application Core is allowed to reissue this request several 5509 times on failed analyses of the response. However, the IOTP Payment 5510 Bridge might reject the resumption request by using the "AttNotSupp" 5511 Error Code "naming" the Consumer Payment Identifier attribute. Then 5512 the Consumer has to apply normal error processing to the current 5513 (sub-)transaction and to issue a new Payment Request Block to the 5514 Payment Handler. 5516 XML definition: 5518 5520 5524 Tables 4 and 5 explain the attributes and elements; Table 3 5525 introduces the Error Codes. 5527 10.3.4 Resume Payment Payment Handler 5529 This API function resumes a payment at the Payment Handler side. 5531 The IOTP Payment Bridge may remain accessible for payment processing 5532 without any further supplement of wallet/till identifiers and pass 5533 phrases until the transaction's payment status changes to some status 5534 different from 'InProgress'. 5536 Input Parameters 5538 o Consumer Payment Identifier, Payment Handler Payment Identifier 5539 o Wallet Identifier - renaming to till identifier neglected - and 5540 Pass Phrase 5541 o Database Function - the IOTP Payment bridge may refer to this 5542 API function for data management purposes, particularly, to 5543 inquire the remaining payment parameters and the current 5544 payment state 5545 o (Payment Scheme) Packaged Content - copied from the Payment 5546 Scheme Component of the received IOTP message (Payment Exchange 5547 or Request Block). 5549 XML definition: 5551 5553 5560 Output Parameters 5562 o Continuation Status 5563 o (Payment Scheme) Packaged Content - for insertion in the 5564 Payment Scheme Component of the next Payment Exchange Block. 5566 The response message contains payment schema data if the continuation 5567 status signals "Continue". The IOTP Application Core is allowed to 5568 reissue this request several times on failed analyses of the 5569 response. However, the IOTP Payment Bridge might reject the 5570 resumption request by using the "AttNotSupp" Error Code "naming" the 5571 Consumer Payment Identifier attribute. Then the Payment Handler has 5572 to apply normal error processing to the transaction. 5574 XML definition: 5576 5578 5582 Tables 4 and 5 explain the attributes and elements; Table 3 5583 introduces the Error Codes. 5585 10.3.5 Continue Process 5587 This API function passes one specific IOTP Payment Scheme Component, 5588 i.e., the encapsulated Packaged Content elements, received from the 5589 counterparty (e.g. Consumer) to the IOTP Payment Bridge and responds 5590 with the next IOTP Payment Scheme Component for submission to the 5591 counterparty. 5593 Input Parameters 5595 o Consumer Payment Identifier, Payment Handler Payment Identifier 5596 o Process (Transaction) Type which distinguishes between Payments 5597 and Inquiries. 5598 o Wallet Identifier and/or Pass Phrase 5599 o (Payment Scheme) Packaged Content - copied from the Payment 5600 Scheme Component of the received Payment Exchange Block or from 5601 the Error Block. 5603 Each party should set all know Payment Identifiers. At least, each 5604 party must set the own Payment Identifier. 5606 XML definition: 5608 5609 5616 Output Parameters 5618 o Continuation Status 5619 o (Payment Scheme) Packaged Content - for insertion in the 5620 Payment Scheme Component of the next Payment Exchange Block or 5621 final Payment Response Block 5623 The response message contains payment schema data if the continuation 5624 status signals "Continue". The IOTP Payment Bridge must signal "End", 5625 if the payment scheme data was received within an IOTP Error Block 5626 containing an Error Component with severity HardError. 5628 XML definition: 5630 5631 5634 Tables 4 and 5 explain the attributes and elements; Table 3 5635 introduces the Error Codes. 5637 10.3.6 Change Process State 5639 The IOTP Application Core changes the current payment status by this 5640 request. The IOTP Payment Bridge may be notified about business level 5641 normal termination, cancellation, suspension, and processing errors. 5642 Notification happens by requesting the intended process state. The 5643 IOTP Payment Bridge processes the status change and reports the 5644 result. The IOTP Application Core has to analyze any returned process 5645 status in order to check whether the IOTP Payment Bridge has agreed 5646 or declined the status switch. E.g., the Process State "CompleteOk" 5647 may lead to the Payment Status "Failed" if the payment transaction 5648 has already failed. Alternatively, the function may issue an Error 5649 Response ("BusinessError") if the intended and current payment status 5650 are incompatible. 5652 Transaction Suspension is notified by the newly introduced Process 5653 State "Suspended". The other attribute values have been borrowed from 5654 the IOTP specification. 5656 This API function might be called by the Consumer, Merchant, or 5657 Payment Handler for each payment transaction anytime after the 5658 issuance of "CheckPaymentPossibility" to the IOTP Payment Bridge by 5659 the Consumer, the issuance of "GetPaymentInitializationData" by the 5660 Merchant, or the issuance of "StartPaymentPaymentHandler" by the 5661 Payment Handler. 5663 The Process States "Failed" and "ProcessError" are final in the sense 5664 that they can not be changed on subsequent calls. However, the API 5665 function should not return with an error code if such an incompatible 5666 call has been issued. Instead it should report the old unchanged 5667 Process State. 5669 Input Parameters 5671 o Consumer Payment Identifier, Payment Handler Payment Identifier 5672 - any known identifier should be supplied. Merchant should map 5673 their payment identifier to Payment Handler Payment Identifier 5674 o intended Payment Status 5675 o intended Completion Code 5676 o Process (Transaction) Type which distinguishes between Payments 5677 and Inquiries. 5678 o Wallet Identifier and/or Pass Phrase 5680 XML definition: 5682 5683 5697 Output Parameters 5699 o Process State and Percent Complete 5700 o Completion Code 5701 o Status Description and its language annotation 5703 XML definition: 5705 5706 5718 Tables 4 and 5 explain the attributes and elements; Table 3 5719 introduces the Error Codes. 5721 10.4 General Inquiry API Calls 5723 The following calls are not necessarily assigned to a payment 5724 transaction and may be issued at any time. There are no dependencies 5725 on any other calls. 5727 10.4.1 Inquire Payment Log 5729 This API call may be used to browse the completed payment transaction 5730 as well as to determine the set of pending or suspended transactions 5731 that are awaiting their completion or resumption. 5733 It is up to the IOTP Payment Bridge and the Existing Payment Software 5734 whether they support such inquiries. Therefore, it is recommended 5735 that the IOTP Application Core implements the required data base 5736 capabilities and provides the inquiry mechanisms on its own. However, 5737 the IOTP Application Core might use this API function to extend its 5738 own knowledge base about the transactions. 5740 Input Parameters 5742 o Brand Identifier - omission defaults to any 5743 o Payment Instrument Identifier - omission defaults to any 5744 o Consumer Payment Identifier, Payment Handler Payment Identifier 5745 - omission defaults to any 5746 o Process State - omission defaults to any 5747 o Completion Code - omission defaults to any 5748 o Payment Direction - omission defaults to any 5749 o Time Stamp From - omission defaults to 1900-01- 5750 01T00:00:00.000Z+0 5751 o Time Stamp To - omission defaults to 9999-12-31T23:59:59.999Z+0 5752 o Currency Code Type - omission defaults to any 5753 o Currency Code - omission defaults to any 5754 o Amount From - omission defaults to 0 5755 o Amount To - omission defaults to unlimited 5756 o Ok From - omission defaults to 1900-01-01T00:00:00.000Z+0 5757 o Ok To - omission defaults to 9999-12-31T23:59:59.999Z+0 5758 o Protocol Identifier - omission defaults to any 5759 o Maximal Number of transaction to report - omission defaults to 5760 unlimited 5761 o Wallet Identifier and/or Pass Phrase 5763 All input arguments are used to define restrictions for the inquiry 5764 of the payment log. The OkFrom and OkTo attributes are used to 5765 inquire payment transactions with a non-empty intersection with the 5766 payment's validity time range which was supplied by the IOTP Payment 5767 Component. 5769 However, there exists some risk of user unfriendliness: The user 5770 initiates the inquiries by the IOTP Application Core which defers the 5771 inquiries to the IOTP Payment Bridges. Then the IOTP Application Core 5772 might be requested for appropriate wallet identifiers and pass 5773 phrases. 5775 XML definition: 5777 5778 5804 Output Parameters 5806 o List of inquired payments. Information for each payment 5807 transaction is provided on: 5808 o Brand Identifier 5809 o Payment Instrument Identifier 5810 o Consumer Payment Identifier, Payment Handler Payment 5811 Identifier 5812 o Currency Code and Currency Code Type 5813 o Payment Amount 5814 o Payment Direction 5815 o Time Stamp 5816 o Process State and Percent Complete 5817 o Completion Code 5818 o Status Description and its language annotation 5819 o Protocol Identifier 5820 o Protocol Brand Identifier 5821 o OkFrom, OkTo - payment expiration dates 5822 o (Brand) Packaged Content Content - further payment brand 5823 description 5824 o (Protocol Brand) Packaged Content Content - further payment 5825 brand description 5826 o (Protocol Amount) Packaged Content Content - further payment 5827 protocol description 5828 o (Pay Protocol) Packaged Content Content - further payment 5829 protocol description 5831 XML definition: 5833 5834 5835 5839 5863 Generally, the IOTP Payment Bridge should respond as many attributes 5864 as possible. 5866 Tables 4 and 5 explain the attributes and elements; Table 3 5867 introduces the Error Codes. 5869 10.4.2 Remove Payment Log 5871 This API function is used by the individual parties to remove 5872 specific entries from the Payment Log file. The IOTP application core 5873 notifies the IOTP Payment Bridge resp. the payment modules that a 5874 particular transaction record is not needed any more and should be 5875 removed. 5877 Input Parameters 5879 o Consumer Payment Identifier, Payment Handler Payment Identifier 5880 - known identifier should be provided 5881 o Wallet Identifier and/or Pass Phrase 5883 XML definition: 5885 5886 5892 Output Parameters 5894 XML definition: 5896 5897 5899 Tables 4 and 5 explain the attributes and elements; Table 3 5900 introduces the Error Codes. 5902 Note that the Merchant Payment Identifier is mapped to the Payment 5903 Handler Payment Identifier. This is valid because the Payment Handler 5904 has not been involved, so far. 5906 10.4.3 Payment Instrument Inquiry 5908 The Payment Instrument Inquiry API function retrieves the properties 5909 of the Payment Instrument. The Payment Instrument Identifier could be 5910 omitted if this identifier is derived by other means, e.g., by 5911 analysis of the currently inserted chip card. If the Payment 5912 instrument could not uniquely determined, the IOTP Payment Bridge may 5913 provide suitable dialogs for user input. 5915 This API function might be used during problem resolution with the 5916 Customer Care Provider of the issuer of the payment instrument, in 5917 order to inquire payment instrument specific values. 5919 Input parameters 5921 o Brand Identifier 5922 o Payment Instrument Identifier 5923 o Protocol Identifier 5924 o Protocol Brand Identifier 5925 o Wallet Identifier and/or Pass Phrase 5926 o Property Type List - sequence of values whose language is 5927 identified by xml:lang 5928 o (Brand) PackagedContent Content - further payment brand 5929 description 5930 o (Protocol Brand) PackagedContent Content - further payment 5931 brand information 5932 o (Protocol Amount) PackagedContent Content - further payment 5933 protocol description 5934 o (Pay Protocol) PackagedContent Content - further payment 5935 protocol description 5937 The codes in the property type list are of two types: 5939 o generic codes which apply to all payment methods but might be 5940 unavailable 5941 o Payment Brand specific codes. 5943 Generic codes for the Property Type List are: 5945 Property Type Meaning 5946 Balance Current balance 5947 Limit Maximum balance 5948 PaymentLimit Maximum payment transaction limit 5949 Expiration Expiration date 5950 Identifier Issuer assigned identifier of the payment 5951 instrument. Usually, it does not match with 5952 the API's payment instrument identifier. 5953 LogEntries Number of stored payment transaction 5954 entries. The entries are numbered from 0 5955 (the most recent) to some non-negative 5956 value for the oldest entry. 5957 PayAmountn Payment Amount of the n-th recorded payment 5958 transaction, n may negative 5959 PayPartyn Remote party of the n-th payment recorded 5960 transaction, n may negative 5961 PayTimen Time of the n-th payment recorded 5962 transaction, n may negative 5964 XML definition: 5966 5970 5980 Output parameters 5982 o a list of zero or more unavailable property values whose 5983 language are identified by xml:lang. 5984 o a list of zero or more sets of "Properties Types", "Property 5985 Values" and "Property Descriptions" 5987 XML definition: 5989 5991 5995 5996 6001 Tables 4 and 5 explain the attributes and elements; Table 3 6002 introduces the Error Codes. 6004 10.4.4 Inquire Pending Payment 6006 This API call reports the presence of pending payment transactions. 6007 It does not respond further transaction details. Note that the IOTP 6008 Payment Bridge has to respond without the supplement of any pass 6009 phrase. 6011 Input Parameters 6013 o Wallet Identifier 6015 XML definition: 6017 6018 6021 Output Parameters 6023 o Response Code encodes the presence of pending payment 6024 transactions. 6026 XML definition: 6028 6029 6032 Tables 4 and 5 explain the attributes and elements; Table 3 6033 introduces the Error Codes. 6035 10.5 Payment Related Inquiry API Calls 6037 10.5.1 Check Payment Receipt 6039 This function is used by the Consumer and might be used by the 6040 Payment Handler to check the consistency, validity, and integrity of 6041 an IOTP Payment Receipt whereby the receipt might consists of 6042 attributes of the Payment Receipt Components and additional Packaged 6043 Content elements of the same component or of previous Payment Scheme 6044 Components. The IOTP Application Core has to check the 6045 PayReceiptNameRefs attribute of the Payment Receipt Component and to 6046 supply ALL Packaged Content Elements which are referred to. 6048 Such a verification might include internal consistency check of the 6049 receipt as well as consistency checks with the whole transaction. 6051 Input Parameters 6053 o Consumer Payment Identifier, Payment Handler Payment Identifier 6054 o Wallet Identifier and/or Pass Phrase 6055 o Payment Receipt Name References 6056 o (Payment Receipt and Payment Scheme) Packaged Content - 6057 originates from the Payment Receipt Component and previous 6058 Payment Request/Exchange/Response Components 6060 XML definition: 6062 6063 6070 Output Parameters 6072 XML definition: 6074 6075 6077 Tables 4 and 5 explain the attributes and elements; Table 3 6078 introduces the Error Codes. 6080 10.5.2 Expand Payment Receipt 6082 This expands IOTP Payment Receipt Components into a form which may be 6083 used for display or printing purposes. "Check Payment Receipt" should 6084 be used first if there is any question of the payment receipt 6085 containing errors. This function may also access the payment specific 6086 payment receipt and expand its content. The IOTP Application Core has 6087 to check the PayReceiptNameRefs attribute of the Payment Receipt 6088 Component and to supply ALL Packaged Content Elements which are 6089 referred to. 6091 Input Parameters 6093 o Consumer Payment Identifier, Payment Handler Payment Identifier 6094 o Wallet Identifier and/or Pass Phrase 6095 o Payment Receipt Name References 6096 o (Payment Receipt and Payment Scheme) Packaged Content - 6097 originates from the Payment Receipt Component and previous 6098 Payment Request/Exchange/Response Components 6100 XML definition: 6102 6103 6110 Output Parameters 6112 o Brand Identifier 6113 o Protocol specific Brand Identifier 6114 o Payment Instrument Identifier 6115 o Currency Code and Currency Code Type 6116 o Payment Amount 6117 o Payment Direction 6118 o Time Stamp - issuance of the receipt 6119 o Protocol Identifier 6120 o Protocol specific Transaction Identifier - this is an internal 6121 reference number which identifies the payment 6122 o Consumer Description, Payment Handler Description, and a 6123 language annotation 6124 o Style Sheet Net Location 6125 o Payment Property List. A list of type/value/description triples 6126 which contains additional information about the payment which 6127 is not covered by any of the other output parameters; property 6128 descriptions have to consider the language annotation. 6130 The Style Sheet Net Location refers to a Style Sheet (e.g. [XSL]) 6131 that contains visualization information about the reported XML 6132 encoded data. However, the IOTP Application Core may ignore this 6133 attribute. 6135 XML definition: 6137 6138 6154 6155 6160 The Existing Payment Software should return as many attributes as 6161 possible from the supplied IOTP Payment Receipt. 6163 Tables 4 and 5 explain the attributes and elements; Table 3 6164 introduces the Error Codes. 6166 10.5.3 Inquire Process State 6168 This API function returns the current payment status and optionally 6169 the Payment Receipt Component's Packaged Content. The Payment 6170 Handler's IOTP Payment Bridge must return this Packaged Content if it 6171 has been created. The Consumer's IOTP Payment Bridge may return it if 6172 it has been received and accepted by "Check Payment Receipt". 6174 Input Parameters 6176 o Consumer Payment Identifier, Payment Handler Payment Identifier 6177 - known payment identifiers should be provided. 6179 o Wallet Identifier and/or Pass Phrase 6181 XML definition: 6183 6184 6190 Output Parameters 6192 o Current Process State and Percent Complete 6193 o Completion Code 6194 o Status Description and its language annotation 6195 o Payment Receipt References 6196 o Payment Receipt Packaged Content Data, if available 6198 The Internet Open Trading Protocol provides a linking capability to 6199 the payment receipt delivery. Instead of encapsulating the whole 6200 payment specific data into the packaged content of the payment 6201 receipt, other Payment Scheme Components' Packaged Content might be 6202 referred to. 6204 XML definition: 6206 6208 6221 Tables 4 and 5 explain the attributes and elements; Table 3 6222 introduces the Error Codes. 6224 10.5.4 Start Payment Inquiry 6226 This API function responds any additional payment scheme specific 6227 data which is needed by the Payment Handler for Consumer initiated 6228 payment transaction inquiry processing. The IOTP Payment Bridge resp. 6229 Existing Payment Software has to determine the payment related items 6230 inclusive any call back functions that were provided with the "Start 6231 Payment Consumer" API function call. 6233 Input Parameters 6235 o Consumer Payment Identifier 6236 o Wallet Identifier and/or Pass Phrase 6238 XML definition: 6240 6241 6246 Output Parameters 6248 o (Payment Scheme) Packaged Content - intended for insertion in 6249 the Payment Scheme Component of the Inquiry Request Block 6251 XML definition: 6253 6255 6257 Tables 4 and 5 explain the attributes and elements; Table 3 6258 introduces the Error Codes. 6260 10.5.5 Inquire Payment Status 6262 The Payment Handler uses this API request for Consumer initiated 6263 inquiry processing. It differs from the previous "Inquire Process 6264 State" API function by the optional supplement of payment scheme 6265 specific data. The response may encapsulate further details about the 6266 payment transaction. However, payment schemes may omit any supplement 6267 of additional data and may mimic the "Inquire Process State" API 6268 function by neglecting any returned payment receipt. 6270 Input Parameters 6271 o Consumer Payment Identifier, Payment Handler Payment Identifier 6272 - known identifier should be provided 6273 o Wallet Identifier and/or Pass Phrase 6274 o (Payment Scheme) Packaged Content - copied from the Inquiry 6275 Request Block's Payment Scheme Component 6277 XML definition: 6279 6280 6286 Output Parameters 6288 o Current Process State 6289 o Completion Code 6290 o Status Description and its language annotation 6291 o (Payment Scheme) Packaged Content - intended for insertion in 6292 the Payment Scheme Component of the Inquiry Response Block 6294 XML definition: 6296 6298 6311 Tables 4 and 5 explain the attributes and elements; Table 3 6312 introduces the Error Codes. 6314 10.6 Other API Calls 6316 10.6.1 Manage Payment Software 6318 The following API function notifies the IOTP Payment Bridge about the 6319 intended registration, modification, or deletion of a payment 6320 instrument. The actual processing is up to the IOTP Payment Bridge. 6322 This API request may also be used to activate the IOTP Payment Bridge 6323 resp. Existing Payment Software for general administration purposes. 6325 Input Parameters 6327 o Brand Identifier 6328 o Protocol Identifier 6329 o Any action code: 6330 o New - add new payment method / instrument 6331 o Update - change the payment method's / instrument's data 6332 o Delete - delete a payment method / instrument 6333 o Wallet Identifier and/or Pass Phrase 6334 o (Brand) Packaged Content - further payment brand description 6335 o (Pay Protocol) Packaged Content - further payment protocol 6336 description 6337 o (Protocol Amount) Packaged Content - further payment protocol 6338 description 6340 If the Action attribute is set, the Brand and Protocol Identifier 6341 have to be set, too. The IOTP Payment Bridge has to provide the 6342 required user dialogs and selection mechanisms. E.g., updates and 6343 deletions may require the selection of the payment instrument. A new 6344 wallet might be silently generated on the supplement of a new Wallet 6345 Identifier or after an additional end user acknowledge. The IOTP 6346 Application Core should not provide any pass phrases for new wallets. 6347 Instead, the IOTP Payment Bridge has to request and verify them which 6348 may return their value to the IOTP Application Core in plain text. In 6349 addition, the IOTP Payment Bridge returns the supported 6350 authentication algorithms when a new brand and protocol pair has been 6351 registered. 6353 If the "Action" attribute is omitted, the IOTP Payment Bridge resp. 6354 Existing Payment Software pops up in a general interactive mode. 6356 XML definition: 6358 6361 6370 Output Parameters 6371 o An action code: 6372 o New - added new wallet 6373 o Update - changed wallet's configuration 6374 o Delete - removed a wallet 6375 o Wallet Identifier and/or Pass Phrase 6377 The IOTP Payment Bridge does not return any information about the set 6378 of registered payment instruments because these data items are 6379 dynamically inferred during the brand selection process at the 6380 beginning of each IOTP transaction. However, the IOTP Application 6381 Core has to be notified about new wallets and should be notified 6382 about updated and removed wallet (identifier)s". Alternatively, 6383 removed wallets can be implicitly detected during the next brand 6384 selection phase. Updated wallets do no affect the processing of the 6385 IOTP Application Core. The IOTP Payment Software resp. Existing 6386 Payment Software should only support the addition of at most one 6387 wallet because it is not able to report multiple additions at once 6388 back to the IOTP Application Core. 6390 XML definition: 6392 6393 6401 Tables 4 and 5 explain the attributes and elements; Table 3 6402 introduces the Error Codes. 6404 11. Called Functions 6406 There are two functions which can be called by the payment software: 6408 o The Call Back Function, which is used to provide information for 6409 Consumer or Payment Handler notification about the progress of the 6410 payment transaction. o The Database Function which is used to 6411 store, modify, and retrieve both temporary data during the payment 6412 transaction and data about suspended or completed payment 6413 transactions. 6415 Their use is illustrated in the diagram below. 6417 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 6418 IOTP Application ----calls---- 6419 | Core | | 6420 display | | v 6421 to <---------- Call Back <--calls--- Payment 6422 user | | Software 6423 | Data Base | 6424 | | | | | 6425 | | Work | <--calls---------| 6426 | | and | | | 6427 | |Logging| <--calls---------- 6428 | --------- | 6429 | | 6430 ---------------- 6431 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 6432 Figure 19 Called Functions 6434 11.1 Call Back Function 6436 The "Call Back" function provides the Consumer or Payment Handler 6437 with information about the payment's progress. Whenever this function 6438 is called, the content of the status description should be made 6439 available to the user. For example on a status bar, a pop up window, 6440 etc. 6442 A reference to the Call Back function is passed as a parameter to the 6443 Start Payment X API input message. The Call Back function is then 6444 called whenever the status changes or progress needs to be reported. 6446 Input Parameters 6448 o the software identifier of the caller 6449 o Consumer Payment Identifier, Payment Handler Payment Identifier 6450 - known identifier should be supplied 6451 o Process State and Percent Complete 6452 o Completion Code 6453 o Status Description and its language annotation, text which 6454 provides information about the progress of the call. It should 6455 be displayed or made available to, for example, the Consumer. 6457 Examples of Status Description could be: 6459 o "Paying 12.30 USD to XYZ Inc" 6460 o "Payment completed" 6461 o "Payment aborted" 6463 The valid languages are announced in the Call Back Language List 6464 attribute in "Start Payment X" API function calls. 6466 XML definition: 6468 6469 6484 Output Parameters 6486 XML definition: 6488 6489 6491 Tables 4 and 5 explain the attributes and elements; Table 3 6492 introduces the Error Codes. Basically, the call back function accepts 6493 all input arguments or rejects the whole request. It may even accept 6494 malformed requests. 6496 Some payment schemes may require that the Consumer may be able to 6497 cancel the payment at any time. The Call Back function can be used to 6498 facilitate this by returning the cancellation request on the next 6499 call. Note that there exist two mechanisms to notify the IOTP Payment 6500 Bridge about Cancellations or Suspensions. Either the "Call Back" 6501 function might use the response the next time it is called or the 6502 IOTP Application Core might issue a "Change Process State" request to 6503 the IOTP Application Core. Due to the latter case, IOTP Payment 6504 Bridge or Existing Payment Software, may ignore the details of the 6505 "Call Back" response. 6507 11.2 Work and Payment Log Database Function 6509 The Work Database Function stores, modifies, and retrieves temporary 6510 data. It is used, for example, to store data about pending payments, 6511 so that even if the payment software fails, it may be possible to 6512 restart payments by retrieving the data held in this database. When a 6513 payment completes, the data about the payment held in the Work 6514 Database is deleted. 6516 The Payment Log Database Function stores receipt data about a 6517 payment. It is used to store information about payments with a 6518 suspended or final payment status. This data should be held on 6519 permanent storage. It may even, for example, be held remotely in 6520 order to support keeping of payment records where there is no local 6521 permanent storage device. 6523 The API for both databases have been merged for homogeneous database 6524 access. It is assumed, that the IOTP Application Core defers most of 6525 the business related database care to the IOTP Payment Bridge and 6526 Existing Payment Software. Nevertheless, their data management may 6527 rely on the generic database capabilities of the IOTP Application 6528 Core. 6530 Deferring the actual data housekeeping to the IOTP Application Core 6531 is the proposed implementation because it offers IOTP Application 6532 Core the opportunities for further features. 6534 Input Parameters 6536 o the software identifier of the caller 6537 o Database Type which distinguishes between the Work and the 6538 PaymentLog Databases 6539 o Database Action: 6540 o New - which stores a new record 6541 o Update - which updates an already stored data record 6542 identified by the Database Entry Identifier 6543 o Get - which retrieves the record identified by the Database 6544 Entry Identifier 6545 o Delete - which deletes the record identified by the Database 6546 Entry Identifier 6547 o First - which positions a record pointer to the "first" 6548 record in the database and returns the Database Entry 6549 Identifier 6550 o Next - which positions the record pointer to the next record 6551 and returns the new Database Entry Identifier 6552 o Database Entry Identifier - which needs to be supplied on all 6553 actions except special "New" cases (see below). 6554 o Further attributes rephrase those from the "Start Payment 6555 X" and "Inquire Payment Log" Response message. They are set on 6556 action "New" and "Update" and omitted otherwise. 6557 o Database Data - additional payment software specific data, 6558 encoding IOTP Payment Bridge's and Existing Payment Software's 6559 internal states and data 6560 o (Brand and Protocol Brand) Packaged Content - further payment 6561 brand description 6562 o (Protocol Amount) Packaged Content - further payment protocol 6563 description 6564 o (Protocol) Packaged Content - further payment protocol 6565 description 6567 o (Payment Receipt and Payment Scheme) Packaged Content - only 6568 the Packaged Content Elements that form the payment receipt are 6569 expected to be stored in the data base. However, it is up to 6570 the IOTP Payment Bridge to decide which elements it stores 6571 o (Protocol) Packaged Content - further payment protocol 6572 description 6573 o (Trading Role) Packaged Content - further payment protocol 6574 description 6575 o (Authentication Request and Authentication Response) Packaged 6576 Content 6577 o (Algorithm) element - details about the authentication method; 6578 its ID attribute is neglected 6580 Typically, the entries of each wallet" define a collection of data 6581 items whereby the "First" and "Next" actions are used for sequential 6582 database scans. The Wallet Identifier identifies the associated 6583 collection in the data base. In this way records of the work database 6584 which relate to payments which are not complete and need to be 6585 canceled after a period of time, may be removed. 6587 The definition of which record represents the "First" and how the 6588 "Next" record is identified, is implementation dependent. The is no 6589 predefined order of the elements within each collection. However the 6590 use of "First" and "Next" must allow every record on the database to 6591 be referenced with exactly one report of each entry. 6593 The "New" action is used to extend a possibly empty collection. 6594 Omitted attribute values and elements' contents remain undefined. 6595 However, all REQUIRED attributes from the output parameter list - 6596 except the Data Entry Identifier - must be set. The "Update" action 6597 replaces only the attribute and content values of the referred 6598 database entry which are mentioned in the database request. The other 6599 values of the omitted attribute and elements are not affected. 6601 The "Delete" action returns the data base identifier or the next 6602 entry. 6604 XML definition: 6606 6613 6653 Output Parameters 6655 o Database Entry Identifier which uniquely identifies the record 6656 within the database 6657 o Further attributes and elements rephrase those from the "Start 6658 Payment X" and "Inquire Payment Log" Response message (or the 6659 input parameter list). They are copied from the input message 6660 on actions "New" or "Update" and filled with the actual values 6661 otherwise 6662 o Database Data - additional payment software specific data about 6663 the retrieved record 6665 Generally, the response should contain all the available attribute 6666 values. The behavior on undefined values is undefined. 6668 XML definition: 6670 6677 6708 Tables 4 and 5 explain the attributes and elements; Table 3 6709 introduces the Error Codes. However, it is assumed that the typical 6710 caller, i.e., IOTP Payment Bridge or Existing Payment Software, 6711 implements very basic resolution strategies. The caller may retry the 6712 API requests on error and give up after several retries. But the end 6713 user should be provided with the error description because it might 6714 contain further explanations. The error code "ReqRefused" may be used 6715 to signal the following example errors: 6717 o database entry not found 6718 o database full, no space left 6719 o database entry exceeds length limitation 6721 The Error Code "ReqRefused" is used to signal that the end of the 6722 database has been reached on the "Next" Action. 6724 12. Security Consideration 6725 [T.B.D.] 6727 Full Copyright Statement 6729 Copyright (C) The Internet Society 2000. 6731 This document and translations of it may be copied and furnished to 6732 others, and derivative works that comment on or otherwise explain it 6733 or assist in its implementation may be prepared, copied, published 6734 and distributed, in whole or in part, without restriction of any 6735 kind, provided that the above copyright notice and this paragraph are 6736 included on all such copies and derivative works. However, this 6737 document itself may not be modified in any way, such as by removing 6738 the copyright notice or references to the Internet Society or other 6739 Internet organizations, except as needed for the purpose of 6740 developing Internet standards in which case the procedures for 6741 copyrights defined in the Internet Standards process must be 6742 followed, or as required to translate it into languages other than 6743 English. 6745 The limited permissions granted above are perpetual and will not be 6746 revoked by the Internet Society or its successors or assigns. 6748 This document and the information contained herein is provided on an 6749 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 6750 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 6751 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 6752 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 6753 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6755 References 6757 [RFC XXXX] - D. Burdett, "Interenet Open Trading Protocol - IOTP, 6758 Version 1.0", September 1999. (currently draft-ietf-trade-iotp-v1.0- 6759 protcool-07.txt) 6761 [HTML] - Hyper Text Mark Up Language. The Hypertext Markup Language 6762 (HTML) is a simple markup language used to create hypertext documents 6763 that are platform independent. See RFC 1866 and the World Wide Web 6764 (W3C) consortium web site at: http://www.w3.org/MarkUp/ 6766 [HTTP] - Hyper Text Transfer Protocol versions 1.0 and 1.1. See RFC 6767 1945: Hypertext Transfer Protocol - HTTP/1.0. T. Berners-Lee, R. 6768 Fielding & H. Frystyk. May 1996. and RFC 2068: Hypertext Transfer 6769 Protocol - HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. 6770 Berners-Lee. January 1997. 6772 [ISO4217] - ISO 4217: Codes for the Representation of Currencies. 6773 Available from ANSI or ISO. 6775 [MIME] - Multipurpose Internet Mail Extensions. See RFC822, RFC2045, 6776 RFC2046, RFC2047, RFC2048 and RFC2049. 6778 [SET] - SET Secure Electronic Transaction(TM) , Version 1.0, May 31, 6779 1997 6780 Book 1: Business Description 6781 Book 2: Programmer's Guide 6782 Book 3: Formal Protocol Definition 6783 Download from: . 6785 [SET/IOTP] - Yoshiaki Kawatsura "SET Supplement for IOTP" (currently 6786 draft-ietf-trade-iotp-v1.0-set-00.txt) 6788 [UTC] - Universal Time Coordinated. A method of defining time 6789 absolutely relative to Greenwich Mean Time (GMT). Typically of the 6790 form: "CCYY-MM- DDTHH:MM:SS.sssZ+n" where the "+n" defines the number 6791 of hours from GMT. See ISO DIS8601. 6793 [XML] - Extensible Mark Up Language. A W3C recommendation. See 6794 http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998 6795 version [XSL] Extensible Style Language. See http://www.w3.org/TR 6797 Author's Address 6799 Hans-Bernhard Beykirch and Werner Hans 6800 IT Development & Coordination Center for the German Savings Banks 6801 Organization (SIZ) 6802 Konigswinterer Strase 553 6803 53227 Bonn 6804 Germany 6805 E-mail: Hans-Bernhard.Beykirch@siz.de, Werner.Hans@siz.de 6807 Masaaki Hiroya and Yoshiaki Kawatsura 6808 Hitachi, Ltd. 6809 890 Kashimada Saiwai-ku Kawasaki-shi 6810 Kanagawa, Japan 212-8567 6811 E-mail: hiroya@sdl.hitachi.co.jp, kawatura@bisd.hitachi.co.jp 6813 Expiration and File Name 6815 This draft expires September 2000. 6817 Its file name is draft-ietf-trade-iotp-v1.0-papi-00.txt.