idnits 2.17.1 draft-ietf-trade-iotp-v1.0-set-01.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 Internet-Drafts being working documents. ** 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-set-01.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-trade-iotp-v1.0-set-01.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-trade-iotp-v1.0-set-01.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-trade-iotp-v1.0-set-01.txt,', but the file name used is 'draft-ietf-trade-iotp-v1.0-set-01' == No 'Intended status' indicated for this document; assuming Proposed Standard 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 are 4 instances of too long lines in the document, the longest one being 3 characters 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 1422: '...it card company) MUST register it in o...' RFC 2119 keyword, line 1694: '...document, SET OD MUST be constructed f...' RFC 2119 keyword, line 1701: '...-Type","charset" MUST be "text/plain",...' RFC 2119 keyword, line 1896: '...e SET PRes message, ContStatus MUST be...' RFC 2119 keyword, line 1923: '... : O : This MUST be set to "PRes"...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == 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 (September 2000) is 8624 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: 'TM' is mentioned on line 162, but not defined == Missing Reference: 'IOTP API' is mentioned on line 190, but not defined == Missing Reference: 'End' is mentioned on line 615, but not defined == Unused Reference: 'BASE64' is defined on line 2357, but no explicit reference was found in the text == Unused Reference: 'ISO4217' is defined on line 2369, but no explicit reference was found in the text == Unused Reference: 'XML' is defined on line 2384, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2801 (ref. 'IOTP') -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO4217' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET EIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'SJR' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 10 errors (**), 1 flaw (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRADE Working Group Yoshiaki Kawatsura 2 INTERNET-DRAFT Hitachi 3 Expires: March 2001 September 2000 5 SET Supplement for the v1.0 Internet Open Trading Protocol (IOTP) 6 --- ---------- --- --- ---- -------- ---- ------- -------- ------ 8 Status of This Document 10 This draft, file name draft-ietf-trade-iotp-v1.0-set-01.txt, is a 11 supplement to the Internet Open Trading Protocol Specification 12 version 1.0, and is intended to become an Informational RFC. 13 Distribution of this document is unlimited. Comments should be sent 14 to the TRADE working group mailing list . 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes detailed Input/Output parameters for the IOTP 36 Payment API and a procedure in the Payment Bridge for using SET as 37 the payment protocol within Version 1.0 of the Internet Open Trading 38 Protocol (IOTP). 40 Copyright 42 Copyright (C) The Internet Society 2000. 44 Table of Contents 46 Status of This Document....................................1 47 Abstract...................................................1 48 Copyright..................................................1 50 Table of Contents..........................................2 51 1. Introduction............................................5 52 1.1 Objectives of this Document............................5 53 1.2 Scope of this specification............................5 54 1.2.1 The version of IOTP specification....................5 55 1.2.2 The version of SET specification.....................5 56 1.2.3 The version of IOTP Architecture document............5 57 1.3 Audience...............................................5 58 1.4 Notation...............................................6 59 1.5 Terminology............................................6 60 2. Requirements & Development Policy.......................6 61 3. Business Models.........................................6 62 3.1 Entity models between SET and IOTP.....................7 63 3.2 Role of Participants...................................7 64 3.3 Scope of Transaction Types.............................8 65 3.4 Types of transaction not in scope......................8 66 4. Architecture of SET/IOTP................................8 67 5. Trading Types of SET/IOTP...............................9 68 5.1 Baseline Purchase......................................9 69 5.2 Cash Advances.........................................10 70 5.3 Status Inquiry .......................................10 71 6. General Flow of SET/IOTP...............................10 72 6.1 Baseline Purchase.....................................10 73 6.1.1 Brand Independent Baseline Purchase.................10 74 6.1.2 Brand Dependent Baseline Purchase...................13 75 6.2 Cash Advances.........................................14 76 6.3 Status Inquiry........................................14 77 7. IOTP Payment APIs......................................15 78 7.1 Brand Compilation Related API Calls...................16 79 7.1.1 Find Accepted Payment Brand.........................16 80 7.1.2 Find Accepted Payment Protocol......................16 81 7.1.3 Get Payment Initialization Data.....................18 82 7.1.4 Inquire Authentication Challenge....................19 83 7.1.5 Authenticate........................................19 84 7.1.6 Check Authentication Response.......................19 85 7.2 Brand Selection Related API Calls.....................19 86 7.2.1 Find Payment Instrument.............................19 87 7.2.2 Check Payment Possibility...........................20 88 7.3 Payment Transaction Related API Calls.................21 89 7.3.1 Start Payment Consumer..............................21 90 7.3.2 Start Payment Payment Handler.......................22 91 7.3.3 Resume Payment Consumer.............................23 92 7.3.4 Continue Process....................................24 93 7.3.5. Change Process State...............................24 94 7.4 General Inquiry API Calls.............................25 95 7.4.1 Payment Instrument Inquiry..........................25 96 7.4.2 Inquire Pending Payment.............................25 97 7.4.3 Remove Payment Log..................................25 98 7.5 Payment Related Inquiry API Calls.....................26 99 7.5.1 Check Payment Receipt...............................26 100 7.5.2 Expand Payment Receipt..............................26 101 7.5.3 Inquire Process State...............................27 102 7.5.4 Start Payment Inquiry...............................28 103 7.5.4 Start Payment Inquiry...............................28 104 7.5.5 Inquire Payment Status..............................29 105 8. SET dependent Processes................................29 106 8.1 Relationships between them for IOTP Purchase/Cash Advances29 107 8.2 Definition of Identifiers.............................30 108 8.2.1 Definition of BrandId...............................30 109 8.2.2 Definition of ProtocolBrandId.......................30 110 8.2.3 Definition of ProtocolId............................31 111 8.2.4 Relationship between Ids............................32 112 8.3 Process prior to Payment..............................32 113 8.3.1 FindAcceptedPaymentProtocol Function................32 114 8.3.2 FindPaymentInstrument Function......................33 115 8.3.3 GetPaymentInitializationData Function...............35 116 8.5 Process of Payment....................................35 117 8.5.1 StartPaymentConsumer Function.......................35 118 8.5.2 StartPaymentPaymentHandler Function.................39 119 8.5.3 ContinueProcess Function(Consumer Side).............40 120 8.5.4 ContinueProcess Function (Payment Handler Side).....40 121 8.5.5 InquireProcessState Function........................42 122 8.6 Payment Receipt.......................................42 123 8.6.1 CheckPayReceipt Function............................42 124 8.6.2 ExpandPayReceipt Function...........................43 125 8.7 Status Inquiry........................................44 126 8.8 Resume Process........................................44 127 8.9 SET Scheme Specific Authentication on IOTP............45 128 8.10 SET Bridge ProcessState..............................45 129 8.10.1 SET Bridge ProcessState of Consumer................45 130 8.10.2 SET Bridge ProcessState of Payment Handler.........46 131 8.11 Relationship between Pay Step and Deliv Step on SET/IOTP46 132 8.12 Completion Code......................................47 133 8.13 PercentComplete......................................47 134 8.14 Severity.............................................48 135 8.15 Error Code...........................................48 136 9. Error Handling.........................................48 137 9.1 Types of Errors.......................................48 138 9.2 IOTP Level Error (OAC Error)..........................49 139 9.3 IOTP Level Error (SET Bridge Error)...................49 140 9.4 SET Level Error(SET Technical Error)..................49 141 9.4.1 SET Initiation Error................................50 142 9.4.2 SET Transaction Error...............................50 143 9.5 SET Level Error (SET Business Error)..................51 145 10. Security Consideration................................52 147 Full Copyright Statement..................................52 149 References................................................53 151 Acknowledgement...........................................54 152 Authors Address...........................................54 153 Expiration and File Name..................................54 155 1. Introduction 157 This chapter describes the outline of this document. 159 1.1 Objectives of this Document 161 This document describes how SET (SET Secure Electronic 162 Transaction[TM]) works within the IOTP (Internet Open Trading 163 Protocol). 165 1.2 Scope of this specification 167 1.2.1 The version of IOTP specification 169 This document is written based on IOTP Ver. 1.0 [IOTP]. 171 1.2.2 The version of SET specification 173 This document is written based on SET Ver. 1.0 [SET]. 175 1.2.3 The version of IOTP Architecture document 177 This document is written based on IOTP Payment API document Ver 1.0.1 178 [IOTP Payment API]. 180 1.3 Audience 182 This document is indented for readers who are familiar with the 183 following documents. 185 1) The IOTP Specification Version 1.0 [IOTP] 186 2) The SET Specification, in particular Book 2:Programmer's Guide and 187 Book3:Formal Protocol Definition, 188 3) External Interface Guide to SET Secure Electronic Transaction 189 4) Internet Open Trading Supplement: Architecture and Payment API 190 [IOTP API] 192 1.4 Notation 194 SET Messages and Elements are described with the prefix "SET". 196 Examples: 197 SET PRes 198 SET OD 199 SET SaleDetail 201 1.5 Terminology 203 This document uses the following terms: 205 SET/IOTP The specification described in this document. 206 SET related message Both SET Messages and SET Initiation Messages 208 2. Requirements & Development Policy 210 This chapter describes the requirements and development policy of 211 SET/IOTP. 213 The requirements of SET/IOTP are as follows: 215 o To be based on SET specifications. 216 Interoperability at the payment level must be maintained. 217 o To not require IOTP modifications which are specific to SET/IOTP. 218 General features of IOTP should not be tampered with to cater to a 219 particular payment method. 220 o To keep integrity between IOTP and SET. 221 Inconstancy must not be raised between IOTP and SET elements when 222 they have the same meaning. 224 The development policy of SET/IOTP is as follows: 225 o To minimize the number of message round trips 226 o To minimize the length of messages 228 3. Business Models 230 This chapter describes the difference in entity models between SET 231 and IOTP, the definitions of Trading Roles in SET/IOTP, and the scope 232 of SET/IOTP. 234 3.1 Entity models between SET and IOTP 236 The following table describes how SET and IOTP entities correspond to 237 each other. 239 | IOTP Entity SET Entity | 240 | ----------------------------------------------- | 241 | Consumer <---> Card Holder | 242 | Merchant <---> Merchant(Initiation) | 243 | Payment Handler <---> Merchant(Payment) | 244 | Delivery Handler<---> None | 245 | None <---> Acquirer | 247 [Figure 1 Entity Models between SET and IOTP] 249 3.2 Role of Participants 251 The following table describes the trading roles in SET/IOTP. 253 Trading Roles Role 254 ------------------------------------------------------------- 255 Consumer An Individual who purchases goods and/or 256 services, and pays for the value received 257 by choosing a SET Transaction. This 258 individual corresponds with the 259 CardHolder in SET. 261 Merchant An organization that provides goods and/or 262 services for purchase, accepts payment 263 methods, delivers invoices and triggers 264 payment processes. 266 Payment Handler An organization that processes negotiations on 267 payments including SET payment transactions. 269 Delivery Handler An Organization that ships digital or physical 270 goods to the Consumer. 272 Customer Care The same as in [IOTP]. 273 Provider 275 Merchant Care The same as in [IOTP]. 276 Provider 278 3.3 Scope of Transaction Types 280 The types of IOTP transactions that are supported in this document 281 are as follows: 283 o Brand Independent Baseline Purchase when SET is used for payment 285 o Brand Dependent Baseline Purchase when SET is used for payment 287 o Cash Advances (Brand Independent and Brand Dependent case) 289 o Status Inquiry on SET payments 291 3.4 Types of transaction not in scope 293 The types of transactions that are NOT covered in this document are 294 as follows: 296 o Credit Reversal Process 298 o Customer Care Service with Consumer Related SET Certificate 299 Registration 301 o Customer Care Service with Consumer Related SET Certificate 302 Registration Inquiry 304 4. Architecture of SET/IOTP 306 SET/IOTP Architecture is as follows: 308 IOTP client (consumer) <---------------> IOTP server (merchant) 309 ^ Internet ^ 310 | IOTP Payment | IOTP Payment 311 | API | API 312 v v 313 IOTP/Payment Bridge IOTP/Payment Bridge 314 ^ ^ 315 | Existing Payment APIs, e.g., | 316 | SET, Mondex, etc. | 317 v v 318 Existing Payment Software Existing Payment Software 320 [Figure 2 SET/IOTP Architecture] 322 IOTP Application Core(OAC): Software that processes IOTP messages. 324 IOTP Payment Bridge(OPB): Interface between OAC and Existing Payment 325 Software. SET Bridge is also an interface between OAC and SET Core. 327 Existing Payment Software (EPS): Existing Software that processes 328 Payments. The SET Core is software that supports mechanisms in SET 329 specification from Book1 to Book3. EPS does NOT necessarily have to 330 implement the SET Initiation Processor, which is specified in SET 331 EIG. 333 SET Related Module: Both SET related OPB and EPS. 335 5. Trading Types of SET/IOTP 337 This chapter describes the outline of SET/IOTP trading types. 339 5.1 Baseline Purchase 341 Three steps will take place in a Baseline Purchase in the following 342 order: 344 (1) Offer Step 346 Consumer selects goods/services over the Internet, for instance on 347 the web, and then chooses the payment method (SET is selected), the 348 SET brand, the payment currency, and then confirms the invoice. 350 There are two Offer Process types, Brand Independent and Brand 351 Dependent. 353 (1-a) Brand Independent Purchase 355 In a Brand Independent Purchase, the Merchant sends the TPO Block and 356 Offer Response Block simultaneously after the consumer's purchase 357 decision. The Brand Independent Purchase has the merit of eliminating 358 one round of messages compared with the Brand Dependent Purchase 359 because the contents of the Offer Response Block (for example the 360 price or description on the invoice) do not change based on the 361 selected brand. 363 (1-b) Brand Dependent Purchase 365 Brand Dependent Purchase is used when the contents of the Offer 366 Response Block are dependent on the selected Payment Brand. With this 367 method, the currency selection and discounts based on payment method 368 can be implemented. 370 (2) Payment Step 372 The Consumer confirms the order and then pays for the order with a 373 SET Transaction. The SET Transaction messages will be encapsulated in 374 IOTP Messages. 376 (3) Delivery Step 378 After completing the Payment, the Consumer receives the 379 goods/services via either on-line or physical delivery. 381 5.2 Cash Advances 383 Cash Advances can be made via a Value Exchange Transaction in IOTP. A 384 first Payment by SET and a second Payment by some other payment 385 mechanism is supported in Baseline IOTP. The Cash Advance has two 386 types - Brand Independent and Brand Dependent Cases. 388 5.3 Status Inquiry 390 A Consumer can send a SET Payment Inquiry in IOTP. The SET Message is 391 encapsulated in an IOTP Message. 393 6. General Flow of SET/IOTP 395 This chapter illustrates the general SET/IOTP message flows. 397 6.1 Baseline Purchase 399 Baseline purchases consist of two types, Brand Independent Purchase 400 and Brand Dependent Purchase. Each type is illustrated in the charts 401 below. 403 6.1.1 Brand Independent Baseline Purchase 405 The general flow of a Brand Independent Purchase is as follows: 407 (1) Consumer Side (Before PayRequest Message) 409 SET Core SET Bridge OAC 410 | | | TPO & OfferResp message 411 | | |<------------------- From 412 | |<------------| Merchant 413 | | FindPayment | 414 | | Instrument| 415 | |------------>| 416 | | Response | 417 | |<------------| 418 | | CheckPayment| 419 | | Possibility| 420 | |------------>| 421 | | Response | 422 | |<------------| 423 |<------------| StartPayment| 424 |------------>| Consumer| 425 | |------------>| PayRequest Message 426 | | Response |-------------------> To Payment 427 (SET Init Resp/ Handler 428 SET PInitReq) 430 [Figure 3 Comsumer Side for Brand Dependent(1)] 432 (2) Consumer Side (After PayRequest Message) 434 SET Core SET Bridge OAC 435 | | | Pay Exch Message 436 | | |<------------------- From 437 | SET PInitRes|<------------| (SET PInitRes) P.H. 438 |<------------| Continue | 439 |------------>| Process | 440 | SET PReq |------------>| Pay Exch Message 441 | | Response |-------------------> To P.H. 442 | | | (SET PReq) 443 | | | Pay Exch Message 444 | | |<------------------ From P.H. 445 | SET PRes |<------------| (SET PRes) 446 |<------------| Continue | 447 |------------>| Process | 448 | |------------>| 449 | |Response[END]| 450 | |<------------| 451 | | CheckPayment| 452 | | Receipt | 453 | |------------>| 454 | | Response | 455 | |<------------| 456 | |ExpandPayment| 457 | | Receipt | 458 | |------------>| 459 | | Response | 460 | |<------------| 461 | |ChangeProcess| 462 | | State | 463 | |------------>| 464 | | Response | 466 [Figure 4 Comsumer Side flow for Brand Dependent(2)] 468 (3) Merchant Side 470 OAC SET Bridge 471 |--------------->| 472 |FindAccepted | 473 | PaymentBrand | 474 |<---------------| 475 | Response | 476 |--------------->| 477 |FindAccepted | 478 | PaymentProtocol| 479 |<---------------| 480 | Response | 481 |--------------->| 482 |GetPaymentInit- | 483 | lizationData | 484 TPO & Offer Resp Msg. |<---------------| 485 <------------------------| Response | 486 To Consumer 488 [Figure 5 Merchant Side flow for Brand Dependent] 490 (4) Payment Handler Side. 492 OAC SET Bridge SET Core 493 PayRequest Message | | | 494 From ---------------------->| | | 495 Consumer (SET Init Res/ |--------------->| | 496 SET PInitReq) |StartPayment |------------>| 497 | PaymentHandler |<------------| 498 PayExch Message |<---------------| | 499 To <----------------------| Response | | 500 Consumer (SET Init Req/ . . . 501 SET PInitRes) . . . 502 PayExch Mssage | | | 503 ---------------------->| | | 504 From Consumer (SET PReq) |--------------->| SET PReq | 505 | Continue |------------>| 506 | Process |<------------| 507 |<---------------| SET PRes | 508 | Response | | 509 |--------------->| | 510 | Inquire | | 511 | ProcessState | | 512 |<---------------| | 513 | Response | | 514 |--------------->| | 515 | ChangeProcess | | 516 | State | | 517 PayResponse Message |<---------------| | 518 <------------------------| Response | | 519 To Consumer (SET PRes) 521 [Figure 6 Payment Handler side flow for Brand Independent] 523 6.1.2 Brand Dependent Baseline Purchase 525 The general flow of a Brand Dependent Purchase is as follows: 527 (1) Consumer Side (Before PayRequest Message) 529 SET Core SET Bridge OAC 530 | | | TPO message 531 | | |<------------------- From 532 | |<------------| Merchant 533 | | FindPayment | 534 | | Instrument| 535 | |------------>| 536 | | Response | 537 | |<------------| 538 | | CheckPayment| 539 | | Possibility| 540 | |------------>| TPO Selection Msg. 541 | | Response |-------------------> To Merchant 542 | | |<------------------ From Merchant 543 | |<------------| Offer Response Msg. 544 |<------------| StartPayment| 545 |------------>| Consumer| 546 | |------------>| PayRequest Message 547 | | Response |-------------------> To Payment 548 (SET Init Resp/ Handler 549 SET PInitReq) 551 [Figure 7 Comsumer Side flow for Brand Independent(1)] 553 (2) Consumer Side (After PayRequest Message): 554 This flow is the same as Brand InDependent. 556 (3) Merchant Side: 558 OAC SET Bridge 559 |--------------->| 560 |FindAccepted | 561 | PaymentBrand | 562 |<---------------| 563 | Response | 564 |--------------->| 565 |FindAccepted | 566 | PaymentProtocol| 567 TPO Message |<---------------| 568 <------------------------| Response | 569 To Consumer | | 570 TPO Selection Message | | 571 ------------------------>| | 572 From Consumer |--------------->| 573 |GetPaymentInit- | 574 | lizationData | 575 Offer Response Message |<---------------| 576 <------------------------| Response | 577 To Consumer 579 [Figure 8 Merchant Side flow for Brand Independent(1)] 581 (4) Payment Handler Side: 582 This flow is the same as Brand Dependent. 584 6.2 Cash Advances 586 IOTP Cash Advances processes can be made with a credit card using an 587 IOTP Value Exchange Transaction. In Cash Advances a first Payment by 588 a SET Transaction, and a second Payment by some other payment 589 mechanism, is supported in Baseline IOTP. The general flow is 590 omitted. 592 6.3 Status Inquiry 594 The general flow of a Status Inquiry is as follows: 596 (1) Consumer Side 598 SET Core SET Bridge OAC 599 | | | 600 | | | 601 | |<------------| 602 |<------------| StartPayment| 603 |------------>| Inquiry| 604 | SET InqReq |------------>| Inquiry Request 605 | | Response |-------------------> To P.H. 606 | | | (SET InqReq) 607 | | | 608 | | | Inquiry Response 609 | | |<------------------- From P.H. 610 | | | (SET InqRes) 611 | SET Inq Res |<------------| 612 |<------------| Continue | 613 |------------>| Process| 614 | SET InqReq |------------>| 615 | | [End] | 616 | |ChangeProcess| 617 | | State| 618 | |<------------| 619 |<------------| 621 [Figure 9 Consumer Side flow for Status Inquiry] 623 (2) Payment Handler Side 625 OAC SET Bridge SET Core 626 InquiryReq message | | | 627 From ------------------------>| | | 628 Consumer (SET InqReq) |------------->| | 629 |InquirePayment|------------>| 630 | Status| SET InqReq | 631 | |<------------| 632 | | SET InqRes | 633 InquiryResp message |<-------------| | 634 To <------------------------| Response | | 635 Consumer (SET InqRes) | 637 [Figure 10 Payment Handler Side flow for Status Inquiry] 639 7. IOTP Payment APIs 641 This section provides a summary of SET/IOTP interactions with API 642 calls as in [IOTP Payment API]. 644 The description of parameters hereafter are written as follows: 646 Parameter name : Mandatory(M) or Optional(O) : Description 648 For more details on the IOTP Payment APIs, see [IOTP Payment API]. 649 "-" in the Description is the same as description in the [IOTP 650 Payment API]. 652 Notice: Status is the status of SET/IOTP. Though some Fields are 653 specified "#IMPLIED" in [IOTP Payment API], if the fields must be 654 used in SET/IOTP, this document specifies the status as 655 Mandatory,(M). 657 7.1 Brand Compilation Related API Calls 659 7.1.1 Find Accepted Payment Brand 661 Receive the payment scheme specific packaged data to generate Brand 662 Component. In this version of SET/IOTP, This API must be called 663 before Find Accepted Payment Protocol function. 665 Input Parameters 666 ---------------- 667 PayDirection : M : This must be set to "Debit". 668 CurrCodeType : M : This should be set to "ISO4217-A". 669 CurrCode : M : - 670 Amount : M : - 671 MerchantPayId : M : - 672 MerchantOrgId : M : - 673 WalletId : O : - 674 MerchantData : O : The details are not specified in 675 this document. 677 Output Parameters 678 ----------------- 679 BrandItem : M : See NOTE below. 681 NOTE: Parameters of BrandItem 682 ----------------------------- 683 BrandId : M : This is defined in the section 8.2.1. 684 xml:lang : M : - 685 BrandName : M : Brand Name, such as "MasterCard". 686 BrandLogoNetLocn : M : - 687 BrandNarrative : O : This is not specified in this document. 688 BrandPackaged : O : This is not used in the SET/IOTP. 689 Content 691 7.1.2 Find Accepted Payment Protocol 693 Receive the payment scheme specific packaged data to generate the 694 PayProtocol Component. 696 Input Parameters 697 ---------------- 698 BrandId : M : This is defined in the section 8.2.1. 699 PayDirection : M : This must be set to "Debit". 700 CurrCodeType : M : This should be set to "ISO4217-A". 701 CurrCode : M : - 702 Amount : M : - 703 MerhcantPayId : M : - 704 MercahntOrgId : M : - 705 WalletId : O : - 706 BrandPackaged : O : This is not used in the SET/IOTP. 707 Content 708 MerchantData : O : This is not specified in the SET/IOTP. 710 Output Parameters 711 ----------------- 712 ProtocolItem : M : See NOTE below. 713 BrandItem : M : - 715 NOTE Parameters of ProtocolItem 716 ------------------------------- 717 ProtocolId : M : This is set to "SETv1.0". 718 ProtocolBrandId : M : This is set to the Payment Protocol Specific 719 ID corresponding to the BrandId as Input 720 Parameter and ProtocolId as the 721 Output Parameter. For the detail, 722 see 8.2.2. 723 xml:lang : M : - 724 ProtocolName : M : This is not specified in this document 725 but must include the protocol name and 726 its version at least. 727 PayReqNetLocn : O : The Net Location indicating where a 728 unsecured Payment Request Message should 729 be sent if this protocol choice is used. 730 SecPayReqNetLocn : O : The Net Location indicating where 731 a secured Payment Request Message 732 should be sent if this protocol choice 733 is used. 734 ProtocolAmount : O : This is not used in the SET/IOTP. 735 PackagedContent 736 PayProtocol : M : The XML Packaged Data, which includes 737 PackagedContent the information for the 1st SET 738 Initiation Process. See for the details 739 to section 8.3.1. 740 Brand : M : In this document, ONLY BrandId, which is 741 the same as Input Parameter, must be set. 742 See NOTE below. 743 CurrencyAmount : M : See NOTE below. 744 ProtocolBrand : M : Multiple Components are not allowed in 745 the current version of SET/IOTP. 747 NOTE Parameters of CurrencyAmount 748 --------------------------------- 749 CurrCodeType : M : This should be set to "ISO4217-A". 750 CurrCode : M : - 751 Amount : M : - 753 NOTE Parameters of Brand 754 ------------------------ 755 BrandId : M : - 757 7.1.3 Get Payment Initialization Data 759 This API is used to get the packaged content in Payment Component. 761 Input Parameters 762 ---------------- 763 BrandId : M : See the details of section 8.2.1. 764 MerchantPayId : M : - 765 PayDirection : M : This is set to "Debit". 766 CurrCodeType : M : This is set to "ISO5217-A". 767 CurrCode : M : - 768 Amount : M : - 769 OkFrom : M : - 770 OkTo : M : - 771 ReceiverOrgId : M : Organization ID which is used to get 772 TradingRolePackagedContents, which 773 depend on the organizations for each. 774 MerchantOrgId : M : - 775 ProtocolId : M : This field must be set to "SETv1.0". 776 WalletId : O : - 777 PassPhrase : O : - 778 ProtocolBrand : M : - 779 BrandPackaged : O : This is not used in the current version 780 Content of SET/IOTP. 781 ProtocolAmount : O : This is not used in the current version 782 PackagedContent of SET/IOTP. 783 PayProtocolPackaged: M : This field is copied from the 784 Content PayProtocol Component. 785 OrderPackaged : M : Packaged Data regarding the Order data, 786 Content which the Merchant's OAC sets. 787 BrandSelBrandInfo : O : This is not used in the current 788 PackagedContent version of SET/IOTP. 789 BrandSelProtocol : O : This is not used in the 790 AmountInfoPackaged current version of SET/IOTP. 791 Content 792 BrandSelCurrency : O : This is not used in the 793 AmountInfo current version of SET/IOTP. 794 PackagedContent 796 Output Parameters 797 ----------------- 798 OkFrom : M : - 799 OkTo : M : - 800 OrderPackaged : M :Changed OrderPackagedContent if 801 Content it rewrites the order information. 802 Otherwise, passed the same input 803 data to OAC. 804 TradingRole : O : The receiver dependent 805 PackagedContent TradingRolePackagedContent. The Name 806 Attribute of the packaged contents 807 must include "Payment:" as the prefix, 808 for example "Payment:SET-OD". Multiple 809 TradingRoleData may be returned. 811 7.1.4 Inquire Authentication Challenge 813 This is not used in the current version of SET/IOTP. 815 7.1.5 Authenticate 817 This is not used in the current version of SET/IOTP. 819 7.1.6 Check Authentication Response 821 This is not used in the current version of SET/IOTP. 823 7.2 Brand Selection Related API Calls 825 7.2.1 Find Payment Instrument 827 This API is used to get the Payment Instruments that can be accepted 828 by the Payment Handler on behalf of the Merchant. 830 Input Parameters 831 ---------------- 832 BrandId : M : See the details of section 8.2.2. 833 ProtocolId : M : This must be set to "SETv1.0". 834 PayDirection : M : This must be set to "Debit". 835 CurrCodeType : M : This should be set to "ISO5217-A". 836 CurrCode : M : - 837 Amount : M : - 838 ConsumerPayId : M : - 839 WalletId : O : - 840 ProtocolBrand : M : - 841 BrandPackaged : O : This is not used in the current 842 Content version of SET/IOTP. 843 ProtocolAmount : O : This is not used in the current 844 PackagedContent version of SET/IOTP. 845 PayProtocolPackaged: M : See details for section 8.3.1. 846 Content 848 Output Parameters 849 ----------------- 850 PayInstrument : M : Multiple PayInstrument Ids may 851 be returned. See NOTE below. 853 NOTE Parameters of PayInstrument 854 -------------------------------- 855 Id : M : This must be unique for each SET 856 Certificates which the 857 Consumer can use. 858 xml:lang : M : - 859 PayInstName : M : - 861 7.2.2 Check Payment Possibility 863 If the SET Bridge receives this API Message, the SET Bridge returns 864 three packaged content fields. 866 Input Parameters 867 ---------------- 868 BrandId : M : This is set to the consumer selected 869 BrandId. 870 PaymentInstrumentId: M : This is set to the consumer selected 871 PaymentInstrumentID. 872 PayDirection : M : This is set to "Debit". 873 CurrCodeType : M : This is set to "ISO4217-A". 874 CurrCode : M : - 875 Amount : M : - 876 ProtocolId : M : This must be set to "SETv1.0". 877 WalletId : O : - 878 Passphrase : O : - 879 ConsumerPayId : M : - 880 ProtocolBrand : M : This is set to the consumer selected 881 ProtocolBrand Compornent. 882 BrandPackaged : O : This is not used in the current 883 Content version of SET/IOTP. 885 ProtocolAmount : O : This is not used in the current 886 PackagedContent version of SET/IOTP. 887 PayProtocol : M : This field is copied from the PayProtocol 888 PackagedContent Component 890 Output Parameter 891 --------------- 892 BrandSelBrandInfo : O : This is not used in the current 893 PackagedContent version of SET/IOTP. 894 BrandSelProtocol : O : This is not used in the 895 AmountInfoPackaged current version of SET/IOTP. 896 Content 898 BrandSelCurrency : O : This is not used in the 899 AmountInfoPackaged current version of SET/IOTP. 900 Content 902 7.3 Payment Transaction Related API Calls 904 7.3.1 Start Payment Consumer 906 In SET/IOTP, this API is used for the Consumer's SET Bridge to 907 process the 1st SET Initiation and any subsequent SET messages. 909 Input Parameters 910 ---------------- 911 BrandId : M : ID for the consumer selected 912 Brand. See the details of 913 section 8.2.1. 914 PaymentInstrumentId: M : ID for the consumer selected 915 Instrument. 916 CurrCodeType : M : The consumer selected CurrCodeType. 917 CurrCode : M : The consumer selected CurrCode. 918 Amount : M : The consumer selected Amount. 919 PayDirection : M : Indicates the payment direction 920 from the Consumer's prospective. 921 ProtocolId : M : The consumer selected ProtocolId. 922 OkFrom : M : - 923 OkTo : M : - 924 ConsumerPayId : M : - 925 WalletID : O : - 926 Passphase : O : - 927 CallBackFuncton : O : This is not used in the SET/IOTP. 928 CallBackLanguage : O : This is not used in the SET/IOTP. 929 List 930 ProtocolBrand : M : ID for the consumer selected 931 Protocol dependent Brand information. 933 BrandPackaged : O : This is not used in the current 934 Content version of SET/IOTP. 935 ProtocolAmount : O : This is not used in the current 936 PackagedContent version of SET/IOTP. 937 PayProtocolPackaged: M : See section 8.2.2. 938 Content 940 Output Parameters 941 ----------------- 942 ContStatus : M : "Continue" must be set if there is 943 in no problem 944 PaySchemePackaged : M : See section 6.5.1. 945 Content 947 7.3.2 Start Payment Payment Handler 949 This API is used to initiate a payment on the Payment Handler's side. 950 The SET Related Module does a payment initialization. The SET Related 951 Module processes SET Message received and returns the appropriate SET 952 Message (e.g. 2nd SET Initiation or SET PinitRes message). 954 Input Parameters 955 ---------------- 956 BrandId : M : ID for the consumer selected Brand. 957 See the details of section 8.2.1. 958 ConsumerPayId : O : ID for the consumer generated payment 959 transaction. 960 CurrCodeType : M : The consumer selected CurrCodeType. 961 This should be set to "ISO4217-A". 962 CurrCode : M : The consumer selected CurrCode. 963 Amount : M : The consumer selected Amount. 964 PayDirection : M : This is set to "Debit". 965 ProtocolId : M : The consumer selected ProtocolId. 966 This must be set to "SETv1.0". 967 OkFrom: : M : - 968 OkTo : M : - 969 PaymentHandlerPayId: M : - 970 MerchantOrgId : M : - 971 WalletID : O : - 972 Passphase : O : - 973 CallBackFunction : O : This is not used in the SET/IOTP. 974 CallBackLanguage : O : This is not used in the SET/IOTP. 975 List 976 BrandPackaged : O : This is not used in the current 977 Content version of SET/IOTP. 978 ProtocolAmountP : O : This is not used in the current 979 PackagedContent version of SET/IOTP. 980 PayProtocolPackaged: M : - 981 Content 982 ProtocolBrand : M : Information for the consumer selected 983 Protocol dependent Brand. 984 BrandSelBrandInfo : O : This is not used in the current 985 PackagedContent version of SET/IOTP. 986 BrandSelProtocol : O : This is not used in the 987 AmountInfo current version of SET/IOTP. 988 PackagedContent 989 BrandSelCurrency : O : This is not used in the 990 AmountInfo current version of SET/IOTP. 991 PackagedContent 992 TradingRolePackaged: O : Copied from the TradingRoleData 993 Content Component. The Name Attribute of 994 the packaged contents must include 995 "Payment:" as the prefix, 996 for example "Payment:SET-OD". 997 PaySchemePackaged : M : See section 6.5.2. 998 Content 1000 Output Parameters 1001 ----------------- 1002 PaySchemePackaged : M : See section 6.5.2. 1003 Content 1004 ContStatus : M : "Continue" must be set if there 1005 is no problem. 1007 7.3.3 Resume Payment Consumer 1009 This API is used to restart a payment transaction when the 1010 transaction is suspended for some reason such as a time out. The last 1011 SET Message relevant to this suspended transaction is returned as the 1012 Response. 1014 Input Parameters 1015 ---------------- 1016 ConsumerPayId : M : - 1017 WalletId : O : - 1018 PassPhrase : O : - 1019 CallBackFunction : O : This is not used in the current version 1020 of SET/IOTP. 1021 CallBack : O : This is not used in the current version 1022 LanguageList of SET/IOTP. 1024 Output Parameters 1025 ----------------- 1026 ContStatus : M : - 1027 PaySchamePackaged : M : See section 8.8. 1028 Content 1030 7.3.4 Continue Process 1032 This API is used to pass a SET related message, received from the 1033 counter party, to the SET Bridge, and accept the next SET message as 1034 a response. 1036 (1) Consumer Side Payment Bridge 1037 Input Parameters 1038 ---------------- 1039 PayId : M : Set ConsumerPayId 1040 WalletId : O : - 1041 PassPhrase : O : - 1042 PaySchemePackaged : M : See section 8.5.3. 1043 Content 1045 Output Parameters 1046 ----------------- 1047 ContStatus : M : Set to "End" if SET PRes message is 1048 received in the PaySchemePackagedContent 1049 as the input parameter, otherwise set 1050 "Continue". 1051 PaySchemePackaged : O : If ContStatus is set to "End", this is not 1052 Content used. See 8.5.3. 1054 (2) Payment Handler Side Payment Bridge 1055 Input Parameters 1056 ---------------- 1057 PayId : M : Set PaymentHandlerPayId 1058 WalletId : O : - 1059 PassPhrase : O : - 1060 PaySchemePackaged : M : See section 8.5.4. 1061 Content 1063 Output Parameters 1064 ----------------- 1065 ContStatus : M : Set to "End" if SET PRes message is 1066 received in the 1067 PaySchemePackagedContent as the 1068 output parameter, otherwise set 1069 "Continue". 1070 PaySchemePackaged : M : See section 8.5.4. 1071 Content 1073 7.3.5. Change Process State 1075 This API is used by the OAC to change the Process State of the OPB. 1076 For instance, it is used to change the Payment Status after a SET 1077 Payment Transaction was completed. When an error or suspend happens, 1078 this API is also used. 1080 (1) Consumer Side Payment Bridge 1081 Input Parameters 1082 ---------------- 1083 PayId : M : Set ConsumerPayId 1084 ProcessState : M : - 1085 CompletionCode : M : - 1086 ProcessType : M : - 1087 WalletID : O : - 1088 PassPhrase : O : - 1090 Output Parameters 1091 ----------------- 1092 ProcessState : M : - 1093 CompletionCode : M : - 1094 PercentComplete : O : See section 8.13. 1095 xml:lang : O : - 1096 StatusDesc : O : This field is not specified in SET/IOTP. 1098 7.4 General Inquiry API Calls 1100 7.4.1 Payment Instrument Inquiry 1102 This API is not used in the current version of SET/IOTP. 1104 7.4.2 Inquire Pending Payment 1106 This API is used to check whether the payment Bridge or its wallet is 1107 currently in use, or not. 1109 Input Parameters 1110 ---------------- 1111 WalletID : O : - 1113 Output Parameters 1114 ----------------- 1115 PayId : M : - 1117 7.4.3 Remove Payment Log 1119 This API is used by both the Consumer and Payment Handler. 1121 Input Parameters 1122 ---------------- 1123 PayId : M : - 1124 WallerId : O : - 1125 Passphrase : O : - 1127 There is no output parameters. 1129 7.5 Payment Related Inquiry API Calls 1131 7.5.1 Check Payment Receipt 1133 This API is used to check a Payment Receipt. However since the 1134 current SET specification does not support Receipts, SET/IOTP sends 1135 its own visual information of a Receipt to the SET Bridge. 1137 Input Parameters 1138 ---------------- 1139 PayId : M : - 1140 WalletId : O : - 1141 PassPhrase : O : - 1142 PaySchemePackaged : M : See section 8.6.1. 1143 Content 1145 Output Parameters 1146 ----------------- 1147 There is no output Parameter. 1149 7.5.2 Expand Payment Receipt 1151 This expands an IOTP Payment Receipt Component packaged data into a 1152 form which may be used for display or printing purposes. 1154 Input Parameters 1155 ---------------- 1156 PayId : M : - 1157 WalletId : O : - 1158 PassPhrase : O : - 1159 PackagedContent : M : See section 8.6.2. 1161 Output Parameters 1162 ----------------- 1163 BrandId : M : - 1164 ProtocolBrandId : M : - 1165 PayInstrumentId : M : - 1166 PaySchemePayId : M : LID_M in the SET PRes message is 1167 set. (The format of this value must 1168 be same as SET Initiation. 1169 Amount : M : Amount * AuthRatio(or CapRatio if 1170 available). CapRatio should be the 1171 high priority than AuthRatio. 1172 CurrCodeType : M : - 1173 CurrCode : M : - 1174 PayDirection : M : - 1175 ProtocolId : M : - 1176 ProtocolTransId : O : - 1177 TimeStamp : M : This value should use the Date 1178 field of MessageWrapper in the 1179 SET PRes message 1180 xml:lang : O : This is not used in the SET/IOTP. 1181 ConsumerDesc : O : This is not used in the SET/IOTP. 1183 PaymentHandlerDesc : O : This is not used in the SET/IOTP. 1184 StyleNetLocn : O : This is not used in the SET/IOTP. 1185 PaymentProperty : O : This is not used in the SET/IOTP. 1187 7.5.3 Inquire Process State 1189 This API is used to check the payment status. For example, when the 1190 OAC receives a Continue Payment Response API, it uses this API if the 1191 ContStatus is set to "End". This API can be used at anytime. 1193 (1) Consumer Payment Bridge 1194 Input Parameters 1195 ---------------- 1196 PayId : M : Set ConsumerPayId 1197 WalletId : O : - 1198 PassPhrase : O : - 1200 Output Parameters 1201 ----------------- 1202 ProcessState : M : - 1203 PercentComplete : O : See 8.13 for the guideline of 1204 setting value. 1205 CmpletionCode : O : See section 8.12. 1206 xml:lang : O : - 1207 StatusDesc : O : - 1208 PayReceiptNameRefs : O : This is not used in the SET/IOTP. 1209 PayReceiptPackConts: O : This is not used in the SET/IOTP. 1211 (2) Payment Handler Payment Bridge 1213 Input Parameters 1214 ---------------- 1215 PayId : M : Set PaymentHandlerPayId 1216 WalletId : O : - 1217 PassPhrase : O : - 1219 Output Parameters 1220 ----------------- 1221 ProcessState : M : - 1222 PercentComplete : O : See section 8.13 for the guideline 1223 of setting value. 1224 CmpletionCode : O : See section 8.12. 1225 xml:lang : O : - 1226 StatusDesc : O : - 1227 PayReceiptNameRefs : O : This is set to "PRes". 1228 PayReceiptPackConts: O : This is not used in the SET/IOTP. 1230 7.5.4 Start Payment Inquiry 1232 This API call returns the SET InqReq Message in order to process a 1233 SET Inquiry. 1235 Input Parameters 1236 ---------------- 1237 ConsumerPayId : M : - 1238 WalletId : O : - 1239 Passphrase : O : - 1241 Output Parameters 1242 ----------------- 1243 PaySchemePackaged : M : Packaged Data to include SET 1244 Content InqReq message. See 8.7. 1246 7.5.4 Start Payment Inquiry 1248 This API call returns the SET InqReq Message in order to process a 1249 SET Inquiry. 1251 Input Parameters 1252 ---------------- 1253 ConsumerPayId : M : - 1254 WalletId : O : - 1255 Passphrase : O : - 1257 Output Parameters 1258 ----------------- 1259 PaySchemePackaged : M: Packaged Data to include SET 1260 Content InqReq message. See section 8.7. 1262 7.5.5 Inquire Payment Status 1264 The Payment Handler uses this API request for Consumer initiated 1265 inquiry processing. In SET/IOTP, the Payment Handler's SET Bridge 1266 receives a SET InqReq message in an InquirePaymentDetail API. The SET 1267 Core processes it, and creates a SET InqRes message. The response 1268 encapsulates the SET InqRes message. 1270 Input Parameters 1271 ---------------- 1272 PaymentHandlerPayId: M : - 1273 WalletID : O : - 1274 PassPhrase : O : - 1275 PaySchemePackaged : M : See section 8.7. 1276 Content 1278 Output Parameters 1279 ----------------- 1280 PaymentHandlerPayId: M : - 1281 ProcessState : M : - 1282 CompletionCode : O : - 1283 xml:lang : O : - 1284 StatusDesc : O : - 1285 PaySchamePackaged : M : See section 8.7. 1286 Content 1288 8. SET dependent Processes 1290 This chapter describes the core concepts for the development of 1291 SET/IOTP. 1293 8.1 Relationships between them for IOTP Purchase/Cash Advances 1295 This document describes SET Initiation Messages based on the [SET 1296 EIG]. Merchant sends the 1st SET Initiation Message to the Consumer 1297 in order to activate a SET payment transaction. After this message, 1298 the other SET Initiation Messages (JPO [SJR], etc.) and the SET 1299 payment Transaction (SET PinitReq message, etc.) are exchanged 1300 between the Consumer and the Payment Handler. 1302 +------------+ +----------+ 1303 | | | | 1304 | |<----------------| Merchant | 1305 | | 1st SET InitMsg | | 1306 | | +----------+ 1307 | Consumer | +----------+ 1308 | | | | 1309 | |<--------------->| P.H. | 1310 | | Other SET Init/ | | 1311 +------------+ SET Message +----------+ 1313 [Figure 11 Relationship between IOTP Messages and SET Messages] 1315 When the Merchant sends any data (ex. SET SaleDetail) except a SET 1316 Related messages (ex. SET PinitRes message), it can send it by two 1317 different methods: 1319 (a) The Merchant sends the data via the Consumer. 1320 (b) The Merchant sends the data out-of-band. 1322 In case (a), the Merchant sends the data by encapsulating it into 1323 TradingRoleData.PackagedContent inside the Offer Response Block sent 1324 to Consumer. The data is copied to the Payment Request Block and sent 1325 to the Payment Handler. This case assumes that the format of the data 1326 is already agreed upon between the Merchant and the Payment Handler. 1328 This document does not specify case (b). 1330 8.2 Definition of Identifiers 1332 8.2.1 Definition of BrandId 1334 BrandId should be used registered identification for IANA. Now, the 1335 following BrandIds have registered. 1337 Amex, Dankort, JCB, MasterCard, NICOS and VISA 1339 8.2.2 Definition of ProtocolBrandId 1341 ProtocolBrandID is defined as follows: 1343 Premise: 1344 SET BrandID is defined as brand[:Product]. ([] is indicated as 1345 optional.) In SET, the BrandID is a brand name, which corresponds to 1346 the brand of the payment card. Additionally the Product is a product 1347 name, which is defined as the type of product within the specific 1348 brand such as Gold Card. 1350 Set IOTP ProtocolBrandId as follows. 1352 brand:Product:PCN 1354 In here, 1355 o The brand above is the same as the sub-data of SET BrandID, as 1356 Brand Name(brand), defined in SET. 1357 o Product above is the same as the sub-data of SET BrandID, as 1358 Product Name(Product), defined in SET. 1359 o PCN above is the Promotional Card Name, and is written in the SET 1360 Certificates. 1362 Example: 1363 Visa:Gold:WalMart 1365 Since SET Brand ID has a colon between brand and Product, the two 1366 colons should be able to delimit Brand, Product, and PCN. 1368 Product and PCN can omit if necessary. For the detail of these 1369 definitions are follows: 1371 (1) The case of omitting Product 1372 Definition: brand::PCN 1373 Example: VISA::UC_VISA 1375 (2) The case of omitting PCN 1376 Definition: brand:Product 1377 Example: VISA:Gold 1379 (3) The case of omitting Product, PCN 1380 Definition: brand 1381 Example: VISA 1383 Invalid Examples: 1384 VISA:Gold: 1385 VISA:: 1386 VISA: 1387 ProtocolBrandId where there is no brand. 1389 8.2.3 Definition of ProtocolId 1391 Protocolld defines as follows: 1393 ProtocolId := SETName + Version 1394 SETName := "SET" 1395 Version := "v" + version + "." + revision 1397 Where the version is number matching a major SET version, and the 1398 revision is the number matching a minor SET revision. 1400 Example: 1401 "SETv1.0","SETv2.0" 1403 NOTE: In the current version of SET/IOTP, "SETv1.0" is fixed as 1404 ProtocolId. 1406 8.2.4 Relationship between Ids 1408 ProtocolBrandId must be unique and depends on BrandId and ProtocolId. 1409 The followings are map among BrandId and ProtocolId, which have been 1410 registered in IANA, and ProtocolBrandId. 1412 BrandId ProtocolId ProtocolBrandId 1413 ----------------------------------------- 1414 Amex SETv1.0 Amex 1415 Dankort SETv1.0 Dankort 1416 JCB SETv1.0 JCB 1417 MasterCard SETv1.0 MasterCard 1418 Nicos SETv1.0 Amex 1419 VISA SETv1.0 VISA 1421 Regarding BrandIds, except above, the BrandId registrant (for example 1422 a credit card company) MUST register it in order to assure a one to 1423 one mapping between ProtocolBrandId and the pair of BrandId and 1424 ProtocolId. 1426 8.3 Process prior to Payment 1428 8.3.1 FindAcceptedPaymentProtocol Function 1430 (1) Parameter of PayProtocolPackagedContent 1432 Name : O : This is not used in SET/IOTP. 1433 Content : M : This should be set to "PCDATA". 1434 Transform : M : This is set to "BASE64". 1435 ContentData : M : SET specific protocol data. Includes data 1436 that is used to create the 1st SET Initiation 1437 Message that is not contained in other 1438 IOTP elements. 1440 (2) Parameter in the ContentData 1442 Parameters of ContentData are described below. The Field Values 1443 follow the [SET EIG]. 1445 Field Required 1446 ------------------------------------ 1447 MIME-Version Optional 1448 Content-Transfer-Encoding Mandatory 1449 SET-Initiation-Type Mandatory 1450 SET-LID-M Optional 1451 SET-InstallTotalTrance Optional 1452 SET-Recurring Optional 1453 SET-Ext-OID Optional 1454 SET-Ext-Data Optional 1455 SET-Ext-Mandatory Optional 1456 SET-Echo-In-Response Optional 1457 SET-Echo-In-Request Optional 1459 For Example: 1461 MIME-Version: 1.0 1462 Content-Transfer-Encoding: Binary 1463 SET-Initiation-Type: Payment-Initiation 1464 SET-Recurring: 31 19960223 1465 SET-Service-URL: http://www.custcare.com/index.html 1466 SET-LID-M: 515A533033363632594B 1468 Note: The contents in ProtoclPackagedContent must be US-ASCII and 1469 encoded by BASE64. 1471 8.3.2 FindPaymentInstrument Function 1473 (1) Information about PayInstrument 1474 Returns a list of Payment Instrument IDs related to the BrandId and 1475 ProtocolBrandId. In this document, BrandId and ProtocolId are 1476 defined in section 8.2. 1478 In this document, Brand has two recognized meanings in SET/IOTP, as 1479 follows: 1481 Brand as Primary Brand: 1482 The Primary Brand is the Brand which is defined as brand in SET, 1483 such as VISA, MasterCard, Nicos. 1485 Brand as Dual Brand or Promotional Brand: 1486 The Dual Brand is the payment instrument which has two Brand, such 1487 as UC-VISA (UC Card and VISA Card). This style is popular in 1488 Japan. 1490 A Promotional Brand means that, if the Consumer pays with that 1491 Brand, then the Consumer will receive some additional benefit such 1492 as discount or frequent flyer point. 1494 1.ProtocolBrandId as a Primary Brand 1496 Example: 1497 "MasterCard", "MasterCard::UC", "MasterCard:Gold:" and 1498 "MasterCard::WalMart" are all MasterCard Brands. 1500 2.ProtocolBrandId as a Dual Brand or a Promotional Brand 1502 Example: 1503 "MasterCard::UC" is Dual Brand of "MasterCard" and "UC". 1504 "SET:MasterCard::WallMart" is Promotional Brand of MasterCard- 1505 WallMart. 1507 The SET Bridge receives the ProtocolBrandId from the OAC in the 1508 FindPaymentInstrument Function: 1510 (1) If the accepted ProtocolBrandId is XXX:YYY 1511 The SET Related Module searches for ProtocolBrandIds with the 1512 string "XXX:YYY:*" (* is wild card), the corresponding 1513 PaymentInstrumentIds of all ProtocolBrandIds with the matching 1514 Primary Brand (regardless of also being a Dual Brand or 1515 Promotional Brand) will be returned to the OAC, for the Consumer 1516 to select from. 1518 (2) If the accepted ProtocolBrandId is XXX:YYY:ZZZ 1519 The SET Related Module searches for ProtocolBrandIDs with the 1520 string "XXX:YYY:ZZZ", only the corresponding PaymentInstrumentIds 1521 of the ProtocolBrandIds that match the Dual Brand or Promotional 1522 Brand will be returned to OAC, for the Consumer to select from. 1524 Example: 1525 Assume ProtocolBrandIds correspond to PaymentInstrumentIds in the 1526 SET Bridge as follows, 1528 ProtocolBrandId PaymentInstrumentId 1529 ------------------------------------------ 1530 MasterCard 1 1531 MasterCard::UC 2 1532 MasterCard::WallMart 3 1533 VISA::UC 4 1535 If the SET Bridge receives a ProtocolBrandId as "MasterCard" in 1536 the FindPaymentInstrument Function, the SET Bridge will return 1537 "1","2", and "3". However, if the SET Bridge receives a 1538 ProtocolBrandId as "MasterCard::UC" to OAC, SET Bridge will 1539 returns only "2". 1541 8.3.3 GetPaymentInitializationData Function 1543 (1) Create TradingRolePackagedContent 1544 If necessary, the SET Related Module generates 1545 TradingRolePackagedContent corresponded to the received 1546 ReceiverOrgID. The ContentData of TradingRolePackagedContent is the 1547 information which the Payment Handler needs to process the SET 1548 Transaction (for example: the SET SaleDetail and the SET OD). The 1549 ContentData, Content, and the Transform must be agreed upon between 1550 the Merchant and the Payment Handler beforehand. 1552 The Name Attribute of the packaged contents must include "Payment:" 1553 as the prefix, for example "Payment:SET-OD". If there is no 1554 PackagedContent corresponding to ReceiverOrgID, such that the SET 1555 Related Module does not need to create the PackagedContent, the 1556 TradingRolePackagedContent is not created. 1558 Parameters in TradingRolePackagedContent 1559 ---------------------------------------- 1560 Name : O : This is not specified in the current SET/IOTP. 1561 Content : M : Should be identical between the Payment 1562 Handler and the Merchant. 1563 Transform : M : Should be identical between the Payment 1564 Handler and the Merchant. 1565 ContentData : M : Element Data for the Payment Handler to 1566 process the SET Transaction. Should be 1567 identical between the Payment Handler and 1568 the Merchant. 1570 8.5 Process of Payment 1572 8.5.1 StartPaymentConsumer Function 1574 (1) Process the 1st SET Initiation Message 1576 (a) Since there are similar items between the SET Initiation Message 1577 Fields and IOTP Elements, IOTP elements can be used for the 1578 corresponding SET Initiation Fields. Other SET Initiation Fields, 1579 except URL information (for detail, see below), are encapsulated in 1580 the PayProtocolPackagedContent. 1582 This document does not specify how the SET Related Module implements 1583 the 1st SET Initiation Process. 1585 The following table shows the list of SET Initiation Fields that 1586 corresponds to IOTP Elements. 1588 SET Initiation Field IOTP Element (in TPO.Brandlist) 1589 --------------------------------------------------------------- 1590 SET-Version Consumer selected ProtocolId 1591 SET-Brand Consumer selected ProtocolBrandId 1592 SET-Amount Consumer selected Amount Data in 1593 CurrencyAmount. 1594 -------------------------------------------------------------- 1596 SET Initiation Field IOTP Element (in OfferResp) 1597 -------------------------------------------------------------- 1598 Order Description The hash data of ContentData of 1599 PackagedContent of Order Component. 1601 (b) SET-Version: 1602 SET-Version can correspond to ProtocolId. The version number appears 1603 after the "v" for the SET-Version. 1605 ProtocolId -> _______ 1606 SETv1.0 1607 ~~~<- SET-Version 1609 [Figure 12 ProtocolId vs SET-Version] 1611 (c) SET-Brand: 1612 SET-Brand can be corresponded to ProtocolBrandId. 1614 (d) SET-PurchAmt: 1615 It is necessary to adjust the format of the Amount between IOTP and 1616 SET, since IOTP and SET use different syntax. 1618 Assumption: 1619 o In SET/IOTP, The "ISO4217-A"(the currency code which is represented 1620 by three alphabet, such as "USD") is mandatory. 1621 o Consumer Side SET Related Module should have a mapping table 1622 between "ISO4217-A" and "ISO4217-N"(the currency code which is 1623 represented by three digit, such as "840"). 1625 (d)-1 Content of the SET-PurchAmt 1626 The content of the SET-PurchAmt is as follows: 1628 SET PurchAmt: currency amount amtExp10 1630 For a description see [SET] Book 2, page 299. For example, $129.50 1631 is represented by "840 12950 -2". In this case, the corresponding 1632 values for the "currency", "amount" and "amtExp10" are "840", "12950" 1633 and "-2" respectively. 1635 The content of the three IOTP amount elements consist of the 1636 following: Amount, CurrCodeType and CurrCode. For a description of 1637 each, see [IOTP]. For example, $129.50 is represented by the 1638 following: 1640 CurrCodeType="ISO4217-A" 1641 CurrCode="USD" 1642 Amount="129.50" 1644 (d)-3 Example of how-to-translate 1645 The one-to-one mapping between the IOTP format and the SET format is 1646 very simple. This example of sequence below uses the example of IOTP 1647 amount Element above. 1649 1) Translate from IOTP CurrCode (ISO4217-A) to SET currency (ISO- 1650 4217-N). For example, if CurrCode="USD", then the value of 1651 currency is "840". 1652 2) Calculate how many decimal places are represented in the 1653 Amount. For example, if Amount="129.50", there are "2" decimal 1654 places. 1655 3) [The number of decimal places] *( -1) corresponds to the SET 1656 amtExp10. In the above case, SET amtExp10 = 2 * (-1) = -2. 1657 4) 10^[The number of the Amount's decimal places] * Amount 1658 corresponds to the SET amount. In the above example, SET amount = 1659 10^2 * 129.50 = 12950. 1660 5) Concatenate three integers and use white spaces as a delimiter. 1662 Finally, in the above case, the SET PurchAmt is represented as "840 1663 12950 -2". 1665 (e) SET OD (Order Description) vs. IOTP Order Information 1667 In the IOTP, the OAC handles the Order Information, such as display 1668 use, as SET uses the Order Information. The Payment Handler does not 1669 know the actual Order Information because the Merchant and Payment 1670 Handler may exist in the separate domains. However, The Payment 1671 Handler needs to get the SET OD from Merchant via the Consumer or 1672 directly because Payment Handler needs the SET OD to create 2nd SET 1673 Initiation message and after. In this situation, the Merchant should 1674 not pass the actual order information to the Payment Handler because 1675 the order information may be considered private data. Therefore, 1676 SET/IOTP defines SET OD as the hash of IOTP Order Information. The 1677 hash algorithm must be SHA1. 1679 But the Order Component may includ two or more Packaged Content(see 1680 [IOTP]). Therefore SET/IOTP specifies to create hash as follows: 1682 (e)-1. If the Name attribute does not have a value, such that the 1683 Order Component have only one Packaged Content, hash the Contents 1684 Data using SHA1 simply and be encoded by BASE64. 1686 (e)-2. Otherwise, such that there exists the Name attribute, sort the 1687 Packaged Contents in the UTF-16 charactor code order of Name 1688 attribute and hash the Content Data using SHA1 and concatenate them 1689 in proper sequence, then hash it using SHA1 again and be encoded by 1690 BASE64. 1692 NOTE: 1693 To avoid different character encodings between applications, in this 1694 document, SET OD MUST be constructed from the ContentData in 1695 OrderPackagedContent as follows: 1697 (1) Convert it to network byte orderd Unicode encoding data. 1698 (2) Hash (1) using SHA1 1699 (3) Convert (2) to BASE64 US-ASCII data 1701 Therefore, "Content-Type","charset" MUST be "text/plain","us-ascii" 1702 respectively when SET Initiation message is constructed. 1704 (f) SET-***-URL vs. IOTP Net Location 1706 In IOTP, the OAC handles location data therefore the OAC does not 1707 need to pass net location data on to the OPB. However, some vender 1708 implemented consumer SET/IOTP wallets may need the URL information to 1709 process the SET Initiation. Thus, if necessary, the Consumer's SET 1710 Related Module must set appropriate URL data to SET-***-URL. 1712 (2) Create the next SET related message 1714 Generate SET related message (SET PInitReq or SET Initiation 1715 Response) at the SET Related Module, to be sent to the Payment 1716 Handler. 1718 (3) Error check of the next SET related message. 1720 If the SET related message which is created in (2) is a SET 1721 Initiation Response and includes any error in it, the SET Related 1722 Module creates an ErrorResponse message with ErrorCode to 1723 "EncapProtErr" and the Severity to "HardError" and sends it to the 1724 OAC. 1726 (4) Create PaySchemePackagedContent 1728 The followings are the parameter of PaySchemePackagedContent in 1729 StartPaymentConsumerResponse. 1731 ContentData : M : SET Related Message which is encoded by 1732 BASE64. (e.g. SET PinitRes message or 1733 SET Initiation Response Message) 1734 Name : O : This is not used in the current SET/IOTP. 1735 Content : M : This field should be set to "PCDATA". 1736 Transform : M : This must be set to "BASE64". 1738 (5) Store of the Payment Information 1740 SET Bridge should store the followings in the DataBase: 1742 o ConsumerPayId 1743 o PaySchemePackagedContent 1744 o ContStatus 1745 o ContentSoftwareId (corresponding to the PaySchemePackagedContent) 1746 o ProcessState 1748 8.5.2 StartPaymentPaymentHandler Function 1750 (1) Process for TradingRoleData 1751 SET Bridge must processes appropriately, for example pass it to the 1752 SET Core, if there exists the TradingRolePackagedContent as an input 1753 Parameter. 1755 (2) SET Specific Process 1756 The SET Related Module processes the SET Initiation Response or the 1757 SET Transaction (SET PInitReq). In addition, the SET Related Module 1758 generates a message (the next SET Initiation Message or SET PInitRes) 1759 corresponding to the results of the processed message. This message 1760 will be sent to the Consumer. 1762 (3) Error check of the next SET related message. 1763 If SET related message which is created in (2) includes any error, 1764 the SET Related Module creates an ErrorResponse message with 1765 ErrorCode to "EncapProtErr" and the Severity to "HardError" and sends 1766 it to the OAC. 1768 (4) Generate PaySchemePackagedContent 1769 PaySchemePackagedContent which Encapsulates the SET Initiation 1770 Message or SET PInitRes into ContentData and generates the 1771 PaySchemePackagedContent. The Parameters of PaySchemePackagedContent 1772 as Output is as follows: 1774 ContentData : M : SET Related Message which is encoded by 1775 BASE64. (e.g. SET PinitRes message or 1776 SET Initiation Response Message) 1777 Name : O : This is not used in the current SET/IOTP. 1778 Content : M : This field should be set to "PCDATA". 1779 Transform : M : This must be set to "BASE64" 1781 8.5.3 ContinueProcess Function(Consumer Side) 1783 (1) SET Specific Process 1784 The Parameters of PaySchemePackagedContent as Input is as follows: 1786 ContentData : M : SET Related Message which is encoded by 1787 BASE64. (e.g. SET PinitRes message, 1788 SET PRes message or SET Initiation 1789 Response Message) 1790 Name : O : This is not used in the current SET/IOTP. 1791 Content : M : This field should be set to "PCDATA". 1792 Transform : M : This must be set to "BASE64" 1794 SET Related Module processes the SET Related Message in the 1795 PaySchemePackagedContent, then SET Related Message corresponding to 1796 the processed message is created if necessary. 1798 (2) SET Related Message Error Check 1799 If SET related message which is created in (2) includes any error, 1800 SET Related Module creates an ErrorResponse message with ErrorCode of 1801 "EncapProtErr" and Severity of "HardError" and sends it to the OAC. 1803 (4) Create PaySchemePackagedContent 1804 The followings are the parameters of PaySchemePackagedContent in 1805 ContinueProcessResponse. 1807 ContentData : M : SET Related Message which is encoded by 1808 BASE64. (e.g. SET PinitReq message, 1809 SET PReq message or SET Initiation 1810 Response Message) 1811 Name : O : This is not used in the current SET/IOTP. 1812 Content : M : This field should be set to "PCDATA". 1813 Transform : M : This must be set to "BASE64". 1815 If the ContentData which is received from Payment Handler is a SET 1816 PRes message, this data ia not created. 1818 8.5.4 ContinueProcess Function (Payment Handler Side) 1820 (1) Brand Integrity Check between IOTP Elements and SET Elements 1822 Since the Consumer sets the Amount and Brand in the SET Message, 1823 based on the IOTP message, it might be altered when the IOTP message 1824 is copied to the SET message. Thus, the Payment Handler needs to 1825 check the Elements in IOTP components (Payment, etc.) and the 1826 Elements in the SET message to make sure they are consistent. The 1827 IOTP Brand specified by the Merchant should correspond to the Brand 1828 used in the SET payment. 1830 The Brand Integrity check sequence is as follows: 1832 (a) After receiving the SET PReq message, check the Consumer 1833 selected Brand information (e.g. ProtocolBrandId) in the IOTP 1834 Payment Request against information in the SET certificate in the 1835 SET PReq message. 1837 (b) If they do not match, return a SET Bridge Level Error 1838 (Severity="HardError", ErrorCode="AttNotValid" and 1839 Names="BrandId"). 1841 Additionally, the SET PReq message signature must be verified with 1842 the SET CardHolder's certificate. (This is done during a normal 1843 SET Transaction.) 1845 NOTE: This integrity check is necessary even if there is no 1846 Promotional Card Name in the ProtocolBrandId because SET may have 1847 selected MasterCard even though IOTP has selected VISA. 1849 (2) SET Related Process 1850 Encapsulate the SET related Message (SET Initiation Message or SET 1851 Transaction Message) in Content Data of PaySchemePackagedContent and 1852 send it to the Sender. 1854 The followings are the parameters of PaySchemePackagedContent as 1855 output. 1857 ContentData : M : SET Related Message which is encoded by 1858 BASE64. (e.g. SET PinitReq message, 1859 SET PReq message or SET Initiation 1860 Response Message) 1861 Name : O : This is not used in the current SET/IOTP. 1862 Content : M : This field should be set to "PCDATA". 1863 Transform : M : This must be set to "BASE64". 1865 (3) SET Related Message Error Check 1866 If SET related message which is created in (2) includes any error, 1867 SET Related Module creates an ErrorResponse message with ErrorCode of 1868 "EncapProtErr" and Severity of "HardError" and sends it to the OAC. 1870 If SET related message which is created in (2) is SET PRes message, 1871 unless its message has 1873 (a) CompletionCode in SET PRes message is "authorizationPerformed" 1874 and AuthCode is "Approved" or 1875 (b) CompletionCode in SET PRes message is "capurePerformed" and 1876 CapCode "Success", 1878 then SET Related Module creates ErrorResponse message with ErrorCode 1879 of "BusinessError" and Severity of "HardError" and sends it to the 1880 OAC. 1882 (4) Create PaySchemePackagedContent 1883 The followings are the parameter of PaySchemePackagedContent in 1884 ContinueProcessResponse. 1886 ContentData : M : SET Related Message which is encoded by 1887 BASE64. (e.g. SET PinitRes message, 1888 SET PRes message or next SET Initiation 1889 Message) 1890 Name : O : "PRes" only if ContentData includes 1891 SET PRes message, otherwise this is 1892 not used in the current SET/IOTP. 1893 Content : M : This field should be set to "PCDATA". 1894 Transform : M : This must be set to "BASE64". 1896 If ContentData includes the SET PRes message, ContStatus MUST be 1897 "End". 1899 8.5.5 InquireProcessState Function 1901 (1) Setting ProcessState 1902 Values for the ProcessState are described in section 8.10. 1904 (2) Setting CompletionCode 1905 Set to "Unspecified" when a SET Business Failure has occurred, and 1906 set StatusDesc to the value corresponding to AuthCode or CapCode. 1908 (3) Setting StatusDesc 1909 The values for PayStatusDesc are not specified in the SET/IOTP. 1911 (4) Create PayReceiptNameRefs 1912 Set to "PRes" in the PayReceiptNameRefs 1914 8.6 Payment Receipt 1916 8.6.1 CheckPayReceipt Function 1918 SET Related Module does not check the Paymnt Receipt Information. It 1919 sends the general response messsage as long as valid request message. 1921 The Parameters of PayReceiptPackagedContent are followings: 1923 Name : O : This MUST be set to "PRes" 1924 Content : M : This field should be set to "PCDATA". 1926 Transform : M : This must be set to "BASE64". 1927 ContentData : M : SET PRes message which is encoded by BASE64. 1929 8.6.2 ExpandPayReceipt Function 1931 (1) PayReceiptPackagedContents 1933 The Parameters of PayReceiptPackagedContent are followings: 1935 Name : O : This MUST be set to "PRes" 1936 Content : M : This field should be set to "PCDATA". 1937 Transform : M : This must be set to "BASE64". 1938 ContentData : M : SET PRes message which is encoded by BASE64. 1940 (2) Get the current status information 1942 SET Related Module gets out the following element from Data Base 1943 using ConsumerPayId, PaymentHandlerPayId as keys. 1945 o BrandId 1946 o ProtocolBrandId 1947 o PayInstrumentId 1948 o Amount 1949 o CurrCodeType 1950 o CurrCode 1951 o PayDirection 1953 (3) Get the SET Data 1955 SET Related Module gets the following data from SET PRes message 1956 which take as the Request Message. 1958 (a) Date Field in the MessageWrapper 1959 Date field between SET and IOTP is slightly different. The different 1960 things are follows: 1962 o There is no TimeZone in the Date field of SET. 1964 o Second and Milli-second can be omitted in the Date field of SET 1966 Therefore, SET Related Module needs to convert the Date information 1967 when TimeStamp field is set. 1969 (b) AuthRatio in SET PRes message(CapRatio is high priority than 1970 AuthRatio if available) 1972 (c) LID_M in SET PRes message (The style of this value is the same as 1973 it of SET Initiation message). 1975 8.7 Status Inquiry 1977 In SET/IOTP, SET Inquiry Initiation is not supported (i.e. omitted). 1978 SET Inquiry Messages are embedded in the PaySchemeData element in 1979 IOTP Inquiry Messages. 1981 The Parameters of PaySchemePackagedContent in 1982 StartPaymentInquiryResponse are follows: 1984 Name : O : This is not used in the SET/IOTP. 1985 Content : M : This field should be set to "PCDATA". 1986 Transform : M : This must be set to "BASE64". 1987 ContentData : M : SET InqReq message which is encoded by BASE64. 1989 The Parameters of PaySchemePackagedContent in InqurePaymentStatus are 1990 follows: 1992 Name : O : This is not used in the SET/IOTP. 1993 Content : M : This field should be set to "PCDATA". 1994 Transform : M : This must be set to "BASE64". 1995 ContentData : M : SET InqReq message which is encoded by BASE64. 1997 The Parameters of PaySchemePackagedContent in 1998 InquirePaymentStatusResponse are follows: 2000 Name : O : This is not used in the SET/IOTP. 2001 Content : M : This field should be set to "PCDATA". 2002 Transform : M : This must be set to "BASE64". 2003 ContentData : M : SET InqRes message which is encoded by BASE64. 2005 The Parameter of PaySchemePackagedContent in ContinueProcess are 2006 follows: 2008 Name : O : This is not used in the SET/IOTP. 2009 Content : M : This field should be set to "PCDATA". 2010 Transform : M : This must be set to "BASE64". 2011 ContentData : M : SET InqRes message which is encoded by BASE64. 2013 8.8 Resume Process 2015 The Parameter of PaySchemePackagedContent in 2016 RequmePaymentConsumerResponse are follows: 2018 Name : O : This is not used in the SET/IOTP. 2019 Content : M : This field should be set to "PCDATA". 2020 Transform : M : This must be set to "BASE64". 2021 ContentData : M : SET Related Message which is encoded by 2022 BASE64. (e.g. SET PinitRes message 2023 or SET Initiation Response Message) 2025 8.9 SET Scheme Specific Authentication on IOTP 2027 IOTP authentication, which uses the SET Scheme, is not used in 2028 SET/IOTP. 2030 8.10 SET Bridge ProcessState 2032 8.10.1 SET Bridge ProcessState of Consumer 2034 No Status ----> InProgress : When StartPaymentConsumer Functon 2035 is called 2037 InProgress ---> InProgress : When ContinueProcess Function 2038 is called 2039 : When ChangeProcessState Function 2040 (ProcessState="Failed") is called 2042 InProgress ---> ProcessError : When ChangeProcessState Function 2043 (ProcessState="ProcessError") is 2044 called 2045 : A Technical Error (Hard Error) 2046 has occurred in SET Bridge 2048 InProgress ---> CompletedOK : When ChangeProcessState Function 2049 (ProcessState="CompletedOK") is 2050 called 2052 InProgress ---> Failed : When ChangeProcessState Function 2053 (ProcessState="failed") is called 2054 : A Business Error has occurred 2055 in the SET Bridge 2057 InProgress ---> Suspended : When ChangeProcessState Function 2058 (ProcessState="Suspended") is 2059 called 2060 : ErrorCode="ResumeRequired" has 2061 occurred. 2063 Suspended ---> InProgress : ResumePaymentConsumer Function 2064 is called 2066 Suspended ---> ProcessError : When ChangeProcessState Function 2067 (ProcessState="ProcessError") is 2068 called (a Technical Error has 2069 occurred prior to ResumePayment- 2070 Consumer Function call) 2071 : A Technical Error (Hard Error) 2072 has occurred in SET Bridge( the 2073 Technical Error is occurred while 2074 ResumePaymentConsumer is calling) 2076 8.10.2 SET Bridge ProcessState of Payment Handler 2078 No Status ----> InProgress : When StartPaymentPaymentHandler 2079 is called 2081 InProgress ---> InProgress : When ContinueProcess Function 2082 is called 2083 : When ChangeProcessState Function 2084 (ProcessState="Failed") is called 2086 InProgress ---> ProcessError : When ChangeProcessState Function 2087 (ProcessState="ProcessError") is 2088 called 2089 : A Technical Error (Hard Error) 2090 has occurred in SET Bridge 2091 : SET Error Message has occurred 2093 InProgress ---> CompletedOK : When SET Transaction is completed. 2095 InProgress ---> Failed : When ChangeProcessState Function 2096 (ProcessState="failed") is called 2097 : A Business Error has occurred 2098 in SET Bridge 2100 CompletedOK ---> Failed : When ChangeProcessState Function 2101 or CancelPayment Function 2102 (ProcessState="Failed") is called 2103 and the payment is cancelled. 2105 8.11 Relationship between Pay Step and Deliv Step on SET/IOTP 2107 SET/IOTP recommends the following regarding Delivery: 2109 Physical Goods 2110 -------------- 2111 For physical goods, the IOTP Delivery Exchanges should be omitted. 2112 That is, set DelivExch=False and DelivAndPayResp=False in the 2113 Delivery Component. This is to avoid the situation where the IOTP 2114 Delivery Handler must check with the IOTP Payment Handler on the 2115 status of a credit authorization. When a Delivery Inquiry 2116 transaction might occur, the DelivReqNetLocn attribute in the 2117 DeliveryData Element must have been specified at the time of the 2118 original Offer Response Message. If you want to use the Delivery 2119 Exchange, you need to process the inquiry of the credit authorization 2120 out of IOTP between IOTP Payment Handler and Delivery Handler. 2122 Digital Goods 2123 ------------- 2124 For digital goods sold through SET/IOTP, authorization should be 2125 processed on a real-time basis. 2127 8.12 Completion Code 2129 In SET/IOTP, the CompletionCode, which is a Business Error Code, is 2130 set as follows: 2132 Value Description 2133 ------------------------------------------------------ 2134 BrandNotSupp This value is not used. 2135 CurrNotSupp This value is not used. 2136 AuthError The IOTP Authentication has 2137 failed for any reason. 2138 InsuffFunds This value is not used. 2139 InstBrandInvalid This value is not used. 2140 PaymentDecl A SET business failure has occurred. 2141 InstNotValid This value is not used. 2142 BadInstrument This value is not used. 2143 Unspecified Unspecified error. There is some known 2144 problem or error, which does not fall 2145 into one of the other CompletionCodes. 2147 8.13 PercentComplete 2149 This document recommends to set to the PercentComplete as follows: 2151 SET Related Setting for Setting for Value of 2152 Message Consumer Paymnet Handler PercentComplete 2153 ------------+---------------+------------------+----------------- 2154 SET Initia- |After 1st SET |After 1st SET |20 2155 tion |Initiation |Initiation | 2156 |Response has |Response has | 2157 |been Created |been Processed | 2158 |(See Note) |(See Note) | 2159 ------------+---------------+------------------+---------------- 2160 SET PinitReq|After Created |After Processed |40 2161 ------------+---------------+------------------+---------------- 2162 SET PinitRes|After Processed|After Created |60 2163 ------------+---------------+------------------+---------------- 2164 SET PReq |After Created |After Processed |80 2165 ------------+---------------+------------------+---------------- 2166 SET PRes |After Processed|After Created |100 2167 ------------+---------------+------------------+---------------- 2169 Note: According to the SET Initiation, PercentComplete should be set 2170 "20" at the timing of 1st SET Initiation Response is 2171 created/processed because number of its message is valiable. 2173 8.14 Severity 2175 In the current version of SET/IOTP, if a technical error occurs in 2176 the SET Bridge, the Severity is always set to "HardError". 2178 8.15 Error Code 2180 9. Error Handling 2182 This chapter describes types of handling Errors. 2184 9.1 Types of Errors 2186 SET/IOTP defines the following error types: 2188 (1) IOTP Level Error 2189 This is defined as an error which is NOT specified in [SET EIG] nor 2190 [SET]. IOTP Level Errors are divided into two types according to the 2191 following: 2193 OAC Level Error: Error in the OAC. This error is defined in the 2194 [IOTP]. 2196 SET Related Module Level Error: Error generated in by process on 2197 the SET Related Module, not specified in [SET EIG] nor [SET]. For 2198 example, when checking the consistency between SET and IOTP elements 2199 on SET Related Module, an error might be returned to OAC. 2201 (2) SET Level Error 2202 This is defined as an error which is specified in [SET EIG] or [SET]. 2203 SET Level Errors have been divided into two types of error according 2204 to following: 2206 SET Technical Level Error: Error in the SET Related Module. This 2207 error is defined in [SET] or [SET EIG]. SET Technical Level Errors 2208 are further subdivided into two types of errors: 2210 (a) SET Initiation Error 2211 Error while the SET Initiation Process is in progress. 2213 (b) SET Transaction Error 2214 Error when the SET Transaction (SET PInitReq message, SET PReq 2215 message, etc.) is in progress. 2217 SET Business Level Error: Error when a business error (e.g. an 2218 authorization failure) occurs while the SET Transaction is being 2219 processed. In SET, Business Level Errors will be returned in the SET 2220 PRes message. SET does not use a SET Error Message for this type of 2221 error. However, it is necessary to present the OAC with what kind of 2222 SET Business Error has occurred. 2224 In this below, the details of each errors above are described. 2226 9.2 IOTP Level Error (OAC Error) 2228 When OAC Level Errors have occurred, if necessary, the sender and 2229 receiver must issue ChangeProcessState API and change the status. 2230 For the detail of these errors, see [IOTP]. 2232 9.3 IOTP Level Error (SET Bridge Error) 2234 This is the error generated in a process on the SET Related Module, 2235 not specified in [SET EIG] nor [SET]. For example, when checking the 2236 inconsistency between SET and IOTP elements on SET Related Module, it 2237 might cause an error. This error should be notified to OAC. 2239 In this case, as a response message, Payment Scheme Data is not 2240 returned. An appropriate information must be set to Status Response. 2242 9.4 SET Level Error(SET Technical Error) 2243 9.4.1 SET Initiation Error 2245 There are two SET Initiation errors as follows: 2247 o Error generated in SET Initiation Message. 2248 o Error generated in SET Initiation Response Message. 2250 (1) SET Initiation Message Error 2252 [SET EIG] describes the error handling when a problem rises in SET 2253 Initiation Message. So the Consumer will do the same error handling 2254 in 9.4.2. 2256 When SET Initiation Error rises in 1st Initiation Message, an error 2257 message will be returned to the Merchant. If an error occurs after 2258 2nd Initiation Message, an error message will be returned to the 2259 Payment Handler. SET Initiation Response will be generated having 2260 SET-Error-Field in Response Message Header and will be returned 2261 ErrorCode as "PayEncapError" and Severity as "HardError". 2263 (1) SET Initiation Response Error 2265 In SET EIG, there is no description about the handling of the 2266 problems in SET Initiation Response. However, it is necessary to 2267 define some handling for the problems in SET/IOTP. 2269 (a) Process of Payment Handler 2270 When a problem rises in SET Initiation Response, SET Related Module 2271 generates ErrorResponse, which is included the "EnCapProtoErr" as 2272 ErrorCode and the "HardError" as Severity. But 2273 PaySchemePackagedContent is not included in this API. 2275 (b) Process of Consumer 2276 ChangeProcessState API must be issued, and ProcessState must be 2277 modified. 2279 9.4.2 SET Transaction Error 2281 (1) Process of Sender 2283 When a SET Transaction Error rises, SET Core creates SET Error 2284 Message. Then the SET Related Module creates ErrorResponse Message 2285 which includes "HardError" as Severity, "EnCapProtoErr" as ErrorCode 2286 and PaySchemePackagedContent. The SET Bridge passes the ErrorResponse 2287 Message to OAC. OAC will generate an Error Block which includes 2288 PaySchemePackagedContent and sends it to the Receiver side. 2290 (2) Process of Receiver 2291 With ContinueProcess API, receiver's OAC sends the message including 2292 the PaySchemeData to SET Bridge. SET Bridge passes the SET Error 2293 Message to SET Core for this process. After that, SET Bridge sends 2294 "End" status with ContinueProcessResponse API. 2296 9.5 SET Level Error (SET Business Error) 2298 (1) Process of Payment Handler 2299 SET Related Module checks the SET Business Error in StatusCode in SET 2300 PRes message. When SET Transaction Error occurs, SET Related Module 2301 creates an ErrorResponse Message which includes SET PRes as 2302 PaySchemePackagedContent and ErrorCode as "BusinessError" and returns 2303 it to OAC. OAC creates Payment Response Block after it gets the SET 2304 scheme specific receipt in InquireProcessState/Response, and sends it 2305 to the Consumer. 2307 (2) Process of Consumer 2308 SET Related Module conducts the same process as in the case that 2309 Consumer receives a Payment Response Block. 2311 10. Security Consideration 2313 In the IOTP, Merchant and Payment Handler may exist in different 2314 domains. So, if the Merchant passes the payment related information 2315 to the Payment Handler via the Consumer, the payment security level 2316 may depend on the IOTP. If you want to avoid this, you will need to 2317 check integrity of these data by using out-of-band communication 2318 between the Merchant and the Payment Handler. In this case, the 2319 security level depends on the communication path between them. 2321 See also security considerations section of [IOTP]. 2323 Full Copyright Statement 2325 Copyright (C) The Internet Society 2000. 2327 This document and translations of it may be copied and furnished to 2328 others, and derivative works that comment on or otherwise explain it 2329 or assist in its implementation may be prepared, copied, published 2330 and distributed, in whole or in part, without restriction of any 2331 kind, provided that the above copyright notice and this paragraph are 2332 included on all such copies and derivative works. However, this 2333 document itself may not be modified in any way, such as by removing 2334 the copyright notice or references to the Internet Society or other 2335 Internet organizations, except as needed for the purpose of 2336 developing Internet standards in which case the procedures for 2337 copyrights defined in the Internet Standards process must be 2338 followed, or as required to translate it into languages other than 2339 English. 2341 The limited permissions granted above are perpetual and will not be 2342 revoked by the Internet Society or its successors or assigns. 2344 This document and the information contained herein is provided on an 2345 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2346 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2347 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2348 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2349 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2351 References 2353 The following books provide essential background material. Readers 2354 are strongly encouraged to consult these references for more 2355 information. 2357 [BASE64] - Base64 Content-Transfer-Encoding. A method of transporting 2358 binary data defined by MIME. See: RFC 2045: Multipurpose Internet 2359 Mail Extensions (MIME) Part One: Format of Internet Message Bodies. 2360 N. Freed & N.Borenstein. November 1996. 2362 [IOTP] - RFC 2801, D. Burdett, "Interenet Open Trading Protocol - 2363 IOTP, Version 1.0", April 2000 2365 [IOTP Payment API] - Internet Open Trading Supplement: Architecture 2366 and Payment API, Version 1.0, September 2000. (currently draft-ietf- 2367 trade-iotp-v1.0-papi-01.txt) 2369 [ISO4217] -ISO 4217: Codes for the Representation of Currencies. 2370 Available from ANSI or ISO. 2372 [SET] - SET Secure Electronic Transaction(TM) , Version 1.0, May 31, 2373 1997 2374 Book 1: Business Description 2375 Book 2: Programmer's Guide 2376 Book 3: Formal Protocol Definition 2378 [SET EIG] - External Interface Guide to SET Secure Electronic 2379 Transaction, Sep 24, 1997. 2381 [SJR] - (SET Secure Electronic Transaction Specification) Support for 2382 Japanese Requirements, Mar 16,1998. 2384 [XML] - Extensible Mark Up Language. A W3C recommendation. See 2385 http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998 2386 version. 2388 Acknowledgement 2390 The author of this document appreciates the following contributors to 2391 this protocol (in alphabetic order) without which it could not have 2392 been developed. 2394 Hans-Bernhard Beykirch SIZ 2395 Richad D. Brown GlobeSET 2396 David Burdett Commerce One (ex. Mondex International) 2397 Andrew Drapp Hitachi, Ltd. 2398 Donald Eastlake 3rd Motorola (ex. IBM) 2399 Werner Hans SIZ 2400 Mark Linehan IBM 2401 John Wankmuller MasterCard International 2403 Authors Address 2405 Yoshiaki Kawatsura 2406 Hitachi, Ltd. 2407 890 Kashimada Saiwai-ku Kawasaki-shi 2408 Kanagawa, 212-8567 Japan 2410 Email: kawatura@bisd.hitachi.co.jp 2412 Expiration and File Name 2414 This draft expires March 2001. 2416 Its file name is draft-ietf-trade-iotp-v1.0-set-01.txt.