summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3538.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3538.txt')
-rw-r--r--doc/rfc/rfc3538.txt3139
1 files changed, 3139 insertions, 0 deletions
diff --git a/doc/rfc/rfc3538.txt b/doc/rfc/rfc3538.txt
new file mode 100644
index 0000000..df6e0b7
--- /dev/null
+++ b/doc/rfc/rfc3538.txt
@@ -0,0 +1,3139 @@
+
+
+
+
+
+
+Network Working Group Y. Kawatsura
+Request for Comments: 3538 Hitachi
+Category: Informational June 2003
+
+
+ Secure Electronic Transaction (SET) Supplement for the
+ v1.0 Internet Open Trading Protocol (IOTP)
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ This document describes detailed Input/Output parameters for the
+ Internet Open Trading Protocol (IOTP) Payment Application Programming
+ Interface (API). It also describes procedures in the Payment Bridge
+ for the use of SET (SET Secure Electronic Transaction) as the payment
+ protocol within Version 1.0 of the IOTP.
+
+Table of Contents
+
+ 1. Introduction....................................................3
+ 1.1 Objectives of this Document.................................3
+ 1.2 Scope of this specification.................................3
+ 1.2.1 The version of IOTP specification.....................3
+ 1.2.2 The version of SET specification......................4
+ 1.2.3 The version of IOTP Architecture document.............4
+ 1.3 Audience....................................................4
+ 1.4 Notation....................................................4
+ 1.5 Terminology.................................................4
+ 2. Requirements & Development Policy...............................4
+ 3. Business Models.................................................5
+ 3.1 Entity models between SET and IOTP..........................5
+ 3.2 Role of Participants........................................5
+ 3.3 Scope of Transaction Types..................................6
+ 3.4 Types of transaction not in scope...........................6
+ 4. Architecture of SET/IOTP........................................7
+ 5. Trading Types of SET/IOTP.......................................7
+ 5.1 Baseline Purchase...........................................7
+ 5.2 Cash Advances...............................................8
+ 5.3 Status Inquiry .............................................8
+
+
+
+Kawatsura Informational [Page 1]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ 6. General Flow of SET/IOTP........................................8
+ 6.1 Baseline Purchase...........................................9
+ 6.1.1 Brand Independent Baseline Purchase...................9
+ 6.1.2 Brand Dependent Baseline Purchase....................13
+ 6.2 Cash Advances..............................................14
+ 6.3 Status Inquiry.............................................15
+ 7. IOTP Payment APIs..............................................16
+ 7.1 Brand Compilation Related API Calls........................16
+ 7.1.1 Find Accepted Payment Brand..........................16
+ 7.1.2 Find Accepted Payment Protocol.......................17
+ 7.1.3 Get Payment Initialization Data......................18
+ 7.1.4 Inquire Authentication Challenge.....................19
+ 7.1.5 Authenticate.........................................19
+ 7.1.6 Check Authentication Response........................19
+ 7.2 Brand Selection Related API Calls..........................20
+ 7.2.1 Find Payment Instrument..............................20
+ 7.2.2 Check Payment Possibility............................21
+ 7.3 Payment Transaction Related API Calls......................22
+ 7.3.1 Start Payment Consumer...............................22
+ 7.3.2 Start Payment Payment Handler........................23
+ 7.3.3 Resume Payment Consumer..............................24
+ 7.3.4 Continue Process.....................................25
+ 7.3.5. Change Process State................................26
+ 7.4 General Inquiry API Calls..................................26
+ 7.4.1 Payment Instrument Inquiry...........................26
+ 7.4.2 Inquire Pending Payment..............................26
+ 7.4.3 Remove Payment Log...................................27
+ 7.5 Payment Related Inquiry API Calls..........................27
+ 7.5.1 Check Payment Receipt................................27
+ 7.5.2 Expand Payment Receipt...............................27
+ 7.5.3 Inquire Process State................................28
+ 7.5.4 Start Payment Inquiry................................29
+ 7.5.5 Inquire Payment Status...............................30
+ 8. SET dependent Process..........................................30
+ 8.1 Relationships between them for IOTP Purchase/Cash Advances.30
+ 8.2 Definition of Identifiers..................................31
+ 8.2.1 Definition of BrandId................................31
+ 8.2.2 Definition of ProtocolBrandId........................31
+ 8.2.3 Definition of ProtocolId.............................33
+ 8.2.4 Relationship between Ids.............................33
+ 8.3 Process prior to Payment...................................34
+ 8.3.1 FindAcceptedPaymentProtocol Function.................34
+ 8.3.2 FindPaymentInstrument Function.......................35
+ 8.3.3 GetPaymentInitializationData Function................36
+ 8.4 Process of Payment.........................................37
+ 8.4.1 StartPaymentConsumer Function........................37
+ 8.4.2 StartPaymentPaymentHandler Function..................41
+ 8.4.3 ContinueProcess Function (Consumer Side).............42
+
+
+
+Kawatsura Informational [Page 2]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ 8.4.4 ContinueProcess Function (Payment Handler Side)......43
+ 8.4.5 InquireProcessState Function.........................45
+ 8.5 Payment Receipt............................................45
+ 8.5.1 CheckPayReceipt Function.............................45
+ 8.5.2 ExpandPayReceipt Function............................45
+ 8.6 Status Inquiry.............................................46
+ 8.7 Resume Process.............................................47
+ 8.8 SET Scheme Specific Authentication on IOTP.................47
+ 8.9 SET Bridge ProcessState....................................48
+ 8.9.1 SET Bridge ProcessState of Consumer..................48
+ 8.9.2 SET Bridge ProcessState of Payment Handler...........49
+ 8.10 Relationship between Pay Step and Deliv Step on SET/IOTP..49
+ 8.11 Completion Code...........................................50
+ 8.12 PercentComplete...........................................50
+ 8.13 Severity..................................................51
+ 9. Error Handling.................................................51
+ 9.1 Types of Errors............................................51
+ 9.2 IOTP Level Error (OAC Error)...............................52
+ 9.3 IOTP Level Error (SET Bridge Error)........................52
+ 9.4 SET Level Error (SET Technical Error)......................52
+ 9.4.1 SET Initiation Error.................................52
+ 9.4.2 SET Transaction Error................................53
+ 9.5 SET Level Error (SET Business Error).......................53
+ 10. Security Considerations.......................................54
+ 11. References....................................................54
+ 12. IANA Considerations...........................................55
+ 13. Acknowledgement...............................................55
+ 14. Author's Address..............................................55
+ 15. Full Copyright Statement......................................56
+
+1. Introduction
+
+ This chapter describes the outline of this document.
+
+1.1 Objectives of this Document
+
+ This document describes how SET (SET Secure Electronic Transaction)
+ works within the IOTP (Internet Open Trading Protocol).
+
+1.2 Scope of this specification
+
+1.2.1 The version of IOTP specification
+
+ This document is written based on IOTP Version 1.0 [RFC 2801].
+
+
+
+
+
+
+
+Kawatsura Informational [Page 3]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+1.2.2 The version of SET specification
+
+ This document is written based on SET Version 1.0 [SET].
+
+1.2.3 The version of IOTP Architecture document
+
+ This document is written based on IOTP Payment API document Version
+ 1.0 [IOTP Payment API].
+
+1.3 Audience
+
+ This document is indented for readers who are familiar with the
+ following documents:
+
+ 1) IOTP Specification Version 1.0 [RFC 2801]
+ 2) SET Specification, in particular Book 2:Programmer's Guide and
+ Book3:Formal Protocol Definition,
+ 3) External Interface Guide to SET Secure Electronic Transaction
+ 4) Internet Open Trading Supplement: Architecture and Payment API
+ [IOTP API]
+
+1.4 Notation
+
+ SET Messages and Elements are described with the prefix "SET".
+
+ Examples:
+ SET PRes
+ SET OD
+ SET SaleDetail
+
+1.5 Terminology
+
+ This document uses the following terms:
+
+ SET/IOTP The specification described in this document.
+ SET related message Both SET Messages and SET Initiation Messages
+
+2. Requirements & Development Policy
+
+ This chapter describes the requirements and development policies of
+ SET/IOTP.
+
+ The requirements of SET/IOTP are as follows:
+
+ o To be based on SET specifications. Interoperability at the
+ payment level must be maintained.
+
+
+
+
+
+Kawatsura Informational [Page 4]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ o To not enforce modifications which are specific to SET/IOTP.
+ General features of IOTP should not be tampered with to cater to a
+ particular payment method.
+
+ o To keep integrity between IOTP and SET. Inconstancy must not be
+ raised between IOTP and SET elements when they have the same
+ meaning.
+
+ The development policy of SET/IOTP is as follows:
+
+ o To minimize the number of message round trips
+
+ o To minimize the length of messages
+
+3. Business Models
+
+ This chapter describes the difference in entity models between SET
+ and IOTP, the definitions of Trading Roles in SET/IOTP, and the scope
+ of SET/IOTP.
+
+3.1 Entity models between SET and IOTP
+
+ The following table describes how SET and IOTP entities correspond to
+ each other.
+
+ | IOTP Entity SET Entity |
+ | ------------------------------------------------ |
+ | Consumer <---> Card Holder |
+ | Merchant <---> Merchant (Initiation) |
+ | Payment Handler <---> Merchant (Payment) |
+ | Delivery Handler<---> None |
+ | None <---> Acquirer |
+
+ Figure 1 Entity Models between SET and IOTP
+
+3.2 Role of Participants
+
+ The following table describes the trading roles in SET/IOTP.
+
+ Trading Roles Role
+ -------------------------------------------------------------
+ Consumer An Individual who purchases goods and/or
+ services, and pays for the value received
+ by choosing a SET Transaction. This
+ individual corresponds with the
+ CardHolder in SET.
+
+
+
+
+
+Kawatsura Informational [Page 5]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ Merchant An organization that provides goods and/or
+ services for purchase, accepts payment
+ methods, delivers invoices and triggers
+ payment processes.
+
+ Payment Handler An organization that processes negotiations on
+ payments including SET payment transactions.
+
+ Delivery Handler An Organization that ships digital or physical
+ goods to the Consumer.
+
+ Customer Care The same as in [RFC 2801].
+ Provider
+
+ Merchant Care The same as in [RFC 2801].
+ Provider
+
+3.3 Scope of Transaction Types
+
+ The types of IOTP transactions that are supported in this document
+ are as follows:
+
+ o Brand Independent Baseline Purchase when SET is used for payment
+
+ o Brand Dependent Baseline Purchase when SET is used for payment
+
+ o Cash Advances (Brand Independent and Brand Dependent case)
+
+ o Status Inquiry on SET payments
+
+3.4 Types of transaction not in scope
+
+ The types of transactions that are NOT covered in this document are
+ as follows:
+
+ o Credit Reversal Process
+
+ o Customer Care Service with Consumer Related SET Certificate
+ Registration
+
+ o Customer Care Service with Consumer Related SET Certificate
+ Registration Inquiry
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 6]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+4. Architecture of SET/IOTP
+
+ SET/IOTP Architecture is as follows:
+
+ IOTP client (Consumer) <---------------> IOTP server (Merchant)
+ ^ Internet ^
+ | IOTP Payment | IOTP Payment
+ | API | API
+ v v
+ IOTP/Payment Bridge IOTP/Payment Bridge
+ ^ ^
+ | Existing Payment APIs, e.g., |
+ | SET, Mondex, etc. |
+ v v
+ Existing Payment Software Existing Payment Software
+
+ Figure 2 SET/IOTP Architecture
+
+ IOTP Application Core (OAC): Software that processes IOTP messages.
+ IOTP Payment Bridge (OPB): Interface between OAC and Existing Payment
+ Software. SET Bridge is also an interface between OAC and SET Core.
+
+ Existing Payment Software (EPS): Existing Software that processes
+ Payments. The SET Core is software that supports mechanisms in SET
+ specification from Book1 to Book3. EPS does NOT necessarily have to
+ implement the SET Initiation Processor, which is specified in SET
+ EIG. SET Related Module Both SET related OPB and EPS.
+
+5. Trading Types of SET/IOTP
+
+ This chapter describes the outline of SET/IOTP trading types.
+
+5.1 Baseline Purchase
+
+ Three steps will take place in a Baseline Purchase in the following
+ order:
+
+ (1) Offer Step
+
+ Consumer selects goods/services over the Internet, for instance on
+ the web, and then chooses the payment method (SET is selected), the
+ SET brand, the payment currency, and then confirms the invoice.
+
+ There are two Offer Process types, Brand Independent and Brand
+ Dependent.
+
+
+
+
+
+
+Kawatsura Informational [Page 7]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ (1-a) Brand Independent Purchase
+
+ In a Brand Independent Purchase, the Merchant sends the TPO Block and
+ Offer Response Block simultaneously after the consumer's purchase
+ decision. The Brand Independent Purchase has the merit of
+ eliminating one round of messages compared with the Brand Dependent
+ Purchase because the contents of the Offer Response Block (for
+ example, the description on the invoice) do not change based on the
+ selected brand.
+
+ (1-b) Brand Dependent Purchase
+
+ Brand Dependent Purchase is used when the contents of the Offer
+ Response Block are dependent on the selected Payment Brand. With
+ this method, the currency selection and discounts based on payment
+ method can be implemented.
+
+ (2) Payment Step
+
+ The Consumer confirms the order and then pays for the order with a
+ SET Transaction. The SET Transaction messages will be encapsulated
+ in IOTP Messages.
+
+ (3) Delivery Step
+
+ After completing the Payment, the Consumer receives the
+ goods/services via either on-line or physical delivery.
+
+5.2 Cash Advances
+
+ Cash Advances can be made via a Value Exchange Transaction in IOTP. A
+ first Payment by SET and a second Payment by some other payment
+ mechanism is supported in Baseline IOTP. The Cash Advance has two
+ types - Brand Independent and Brand Dependent Cases.
+
+5.3 Status Inquiry
+
+ A Consumer can send a SET Payment Inquiry in IOTP. The SET Message
+ is encapsulated in an IOTP Message.
+
+6. General Flow of SET/IOTP
+
+ This chapter illustrates the general SET/IOTP message flows.
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 8]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+6.1 Baseline Purchase
+
+ Baseline purchases consist of two types, Brand Independent Purchase
+ and Brand Dependent Purchase. Each type is illustrated in the charts
+ below.
+
+6.1.1 Brand Independent Baseline Purchase
+
+ The general flow of a Brand Independent Purchase is as follows:
+
+ (1) Consumer Side (Before PayRequest Message)
+
+ SET Core SET Bridge OAC
+ | | | TPO & OfferResp message
+ | | |<------------------- From
+ | |<------------| Merchant
+ | | FindPayment |
+ | | Instrument|
+ | |------------>|
+ | | Response |
+ | |<------------|
+ | | CheckPayment|
+ | | Possibility|
+ | |------------>|
+ | | Response |
+ | |<------------|
+ |<------------| StartPayment|
+ |------------>| Consumer|
+ | |------------>| PayRequest Message
+ | | Response |-------------------> To Payment
+ (SET Init Resp/ Handler
+ SET PInitReq)
+
+ Figure 3 Consumer Side for Brand Independent (1)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 9]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ (2) Consumer Side (After PayRequest Message)
+
+ SET Core SET Bridge OAC
+ | | | Pay Exch Message
+ | | |<------------------- From
+ | SET PInitRes|<------------| (SET PInitRes) P.H.
+ |<------------| Continue |
+ |------------>| Process |
+ | SET PReq |------------>| Pay Exch Message
+ | | Response |-------------------> To P.H.
+ | | | (SET PReq)
+ | | | Pay Exch Message
+ | | |<------------------ From P.H.
+ | SET PRes |<------------| (SET PRes)
+ |<------------| Continue |
+ |------------>| Process |
+ | |------------>|
+ | |Response[END]|
+ | |<------------|
+ | | CheckPayment|
+ | | Receipt |
+ | |------------>|
+ | | Response |
+ | |<------------|
+ | |ExpandPayment|
+ | | Receipt |
+ | |------------>|
+ | | Response |
+ | |<------------|
+ | |ChangeProcess|
+ | | State |
+ | |------------>|
+ | | Response |
+
+ Figure 4 Consumer Side flow for Brand Independent (2)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 10]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ (3) Merchant Side
+
+ OAC SET Bridge
+ |--------------->|
+ |FindAccepted |
+ | PaymentBrand |
+ |<---------------|
+ | Response |
+ |--------------->|
+ |FindAccepted |
+ | PaymentProtocol|
+ |<---------------|
+ | Response |
+ |--------------->|
+ |GetPaymentInit- |
+ | lizationData |
+ TPO & Offer Resp Msg. |<---------------|
+ <------------------------| Response |
+ To Consumer
+
+ Figure 5 Merchant Side flow for Brand Independent
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 11]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ (4) Payment Handler Side.
+
+ OAC SET Bridge SET Core
+ PayRequest Message | | |
+ From ---------------------->| | |
+ Consumer (SET Init Res/ |--------------->| |
+ SET PInitReq) |StartPayment |------------>|
+ | PaymentHandler |<------------|
+ PayExch Message |<---------------| |
+ To <----------------------| Response | |
+ Consumer (SET Init Req/ . . .
+ SET PInitRes) . . .
+ PayExch Mssage | | |
+ ---------------------->| | |
+ From Consumer (SET PReq) |--------------->| SET PReq |
+ | Continue |------------>|
+ | Process |<------------|
+ |<---------------| SET PRes |
+ | Response | |
+ |--------------->| |
+ | Inquire | |
+ | ProcessState | |
+ |<---------------| |
+ | Response | |
+ |--------------->| |
+ | ChangeProcess | |
+ | State | |
+ PayResponse Message |<---------------| |
+ <------------------------| Response | |
+ To Consumer (SET PRes)
+
+ Figure 6 Payment Handler side flow for Brand Independent
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 12]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+6.1.2 Brand Dependent Baseline Purchase
+
+ The general flow of a Brand Dependent Purchase is as follows:
+
+ (1) Consumer Side (Before PayRequest Message)
+
+ SET Core SET Bridge OAC
+ | | | TPO message
+ | | |<------------------- From
+ | |<------------| Merchant
+ | | FindPayment |
+ | | Instrument|
+ | |------------>|
+ | | Response |
+ | |<------------|
+ | | CheckPayment|
+ | | Possibility|
+ | |------------>| TPO Selection Msg.
+ | | Response |-------------------> To Merchant
+ | | |<------------------ From Merchant
+ | |<------------| Offer Response Msg.
+ |<------------| StartPayment|
+ |------------>| Consumer|
+ | |------------>| PayRequest Message
+ | | Response |-------------------> To Payment
+ (SET Init Resp/ Handler
+ SET PInitReq)
+
+ Figure 7 Consumer Side flow for Brand Dependent (1)
+
+ (2) Consumer Side (After PayRequest Message)
+
+ This flow is the same as Brand Independent.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 13]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ (3) Merchant Side
+
+ OAC SET Bridge
+ |--------------->|
+ |FindAccepted |
+ | PaymentBrand |
+ |<---------------|
+ | Response |
+ |--------------->|
+ |FindAccepted |
+ | PaymentProtocol|
+ TPO Message |<---------------|
+ <------------------------| Response |
+ To Consumer | |
+ TPO Selection Message | |
+ ------------------------>| |
+ From Consumer |--------------->|
+ |GetPaymentInit- |
+ | lizationData |
+ Offer Response Message |<---------------|
+ <------------------------| Response |
+ To Consumer
+
+ Figure 8 Merchant Side flow for Brand Dependent (1)
+
+ (4) Payment Handler Side
+
+ This flow is the same as Brand Independent.
+
+6.2 Cash Advances
+
+ IOTP Cash Advances processes can be made with a credit card using an
+ IOTP Value Exchange Transaction. In Cash Advances a first Payment by
+ a SET Transaction, and a second Payment by some other payment
+ mechanism, is supported in Baseline IOTP. The general flow is
+ omitted.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 14]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+6.3 Status Inquiry
+
+ The general flow of a Status Inquiry is as follows:
+
+ (1) Consumer Side
+
+ SET Core SET Bridge OAC
+ | | |
+ | | |
+ | |<------------|
+ |<------------| StartPayment|
+ |------------>| Inquiry|
+ | SET InqReq |------------>| Inquiry Request
+ | | Response |-------------------> To P.H.
+ | | | (SET InqReq)
+ | | |
+ | | | Inquiry Response
+ | | |<------------------- From P.H.
+ | | | (SET InqRes)
+ | SET Inq Res |<------------|
+ |<------------| Continue |
+ |------------>| Process|
+ | SET InqReq |------------>|
+ | | [End] |
+ | |ChangeProcess|
+ | | State|
+ | |<------------|
+ |<------------|
+
+ Figure 9 Consumer Side flow for Status Inquiry
+
+ (2) Payment Handler Side
+
+ OAC SET Bridge SET Core
+ InquiryReq message | | |
+ From ------------------------>| | |
+ Consumer (SET InqReq) |------------->| |
+ |InquirePayment|------------>|
+ | Status| SET InqReq |
+ | |<------------|
+ | | SET InqRes |
+ InquiryResp message |<-------------| |
+ To <------------------------| Response | |
+ Consumer (SET InqRes) |
+
+ Figure 10 Payment Handler Side flow for Status Inquiry
+
+
+
+
+
+Kawatsura Informational [Page 15]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+7. IOTP Payment APIs
+
+ This section provides a summary of SET/IOTP interactions with API
+ calls as in [IOTP Payment API].
+
+ The description of parameters hereafter are written as follows:
+
+ Parameter name : Mandatory (M) or Optional (O) : Description
+
+ For more details on the IOTP Payment APIs, see [IOTP Payment API].
+ "-" in the Description is the same as description in the [IOTP
+ Payment API].
+
+ Notice: Status is the status of SET/IOTP. Though some Fields are
+ specified "#IMPLIED" in [IOTP Payment API], if the fields must be
+ used in SET/IOTP, this document specifies the status as Mandatory,
+ (M).
+
+7.1 Brand Compilation Related API Calls
+
+7.1.1 Find Accepted Payment Brand
+
+ Receive the payment scheme specific packaged data to generate Brand
+ Component. In this version of SET/IOTP, This API must be called
+ before Find Accepted Payment Protocol function.
+
+ Input Parameters
+ ----------------
+ PayDirection : M : This must be set "Debit".
+ CurrCodeType : M : This should be set "ISO4217-A".
+ CurrCode : M : -
+ Amount : M : -
+ MerchantPayId : M : -
+ MerchantOrgId : M : -
+ WalletId : O : -
+ MerchantData : O : The details are not specified in
+ this document.
+ Output Parameters
+ -----------------
+ BrandItem : M : See NOTE below.
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 16]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ NOTE: Parameters of BrandItem
+ -----------------------------
+ BrandId : M : This is defined in the section 8.2.1.
+ xml:lang : M : -
+ BrandName : M : Brand Name, such as "MasterCard".
+ BrandLogoNetLocn : M : -
+ BrandNarrative : O : This is not specified in this document.
+ BrandPackaged : O : This is not used in the SET/IOTP.
+ Content
+
+7.1.2 Find Accepted Payment Protocol
+
+ Receive the payment scheme specific packaged data to generate the
+ PayProtocol Component.
+
+ Input Parameters
+ ----------------
+ BrandId : M : This is defined in the section 8.2.1.
+ PayDirection : M : This must be set "Debit".
+ CurrCodeType : M : This should be set "ISO4217-A".
+ CurrCode : M : -
+ Amount : M : -
+ MerhcantPayId : M : -
+ MercahntOrgId : M : -
+ WalletId : O : -
+ BrandPackaged : O : This is not used in the SET/IOTP.
+ Content
+ MerchantData : O : This is not specified in the SET/IOTP.
+
+ Output Parameters
+ -----------------
+ ProtocolItem : M : See NOTE below.
+ BrandItem : M : -
+
+ NOTE Parameters of ProtocolItem
+ -------------------------------
+ ProtocolId : M : This is set "SETv1.0".
+ ProtocolBrandId : M : This is set the Payment Protocol Specific
+ ID corresponding to the BrandId as Input
+ Parameter and ProtocolId as the
+ Output Parameter. For the detail,
+ see 8.2.2.
+ xml:lang : M : -
+ ProtocolName : M : This is not specified in this document
+ but must be included the protocol name
+ and its version at least.
+
+
+
+
+
+Kawatsura Informational [Page 17]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ PayReqNetLocn : O : The Net Location indicating where a
+ unsecured Payment Request Message should
+ be sent if this protocol choice is used.
+ SecPayReqNetLocn : O : The Net Location indicating where
+ a secured Payment Request Message
+ should be sent if this protocol choice
+ is used.
+ ProtocolAmount : O : This is not used in the SET/IOTP.
+ PackagedContent
+ PayProtocol : M : The XML Packaged Data, which includes
+ PackagedContent the information for the 1st SET
+ Initiation Process. See for the details
+ to section 8.3.1.
+ Brand : M : In this document, BrandId, which is the
+ same as Input Parameter,must be set ONLY.
+ See NOTE below.
+ CurrencyAmount : M : See NOTE below.
+ ProtocolBrand : M : Multiple Components are not arrowed in
+ the current version of SET/IOTP.
+
+ Note Parameters of CurrencyAmount
+ ---------------------------------
+ CurrCodeType : M : This should be set "ISO4217-A".
+ CurrCode : M : -
+ Amount : M : -
+
+ Note Parameters of Brand
+ ------------------------
+ BrandId : M : -
+
+7.1.3 Get Payment Initialization Data
+
+ This API is used to get the packaged content in Payment Component.
+
+ Input Parameters
+ ----------------
+ BrandId : M : See the details of section 8.2.1.
+ MerchantPayId : M : -
+ PayDirection : M : This is set "Debit".
+ CurrCodeType : M : This is set "ISO5217-A".
+ CurrCode : M : -
+ Amount : M : -
+ OkFrom : M : -
+ OkTo : M : -
+ ReceiverOrgId : M : Organization ID which is used to get
+ TradingRolePackagedContents, which
+ depend on the organizations for each.
+ MerchantOrgId : M : -
+
+
+
+Kawatsura Informational [Page 18]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ ProtocolId : M : This field must be set "SETv1.0".
+ WalletId : O : -
+ PassPhrase : O : -
+ ProtocolBrand : M : -
+ BrandPackaged : O : This is not used in the current version
+ Content of SET/IOTP.
+ ProtocolAmount : O : This is not used in the current version
+ PackagedContent of SET/IOTP.
+ PayProtocolPackaged: M : This field is copied from the
+ Content PayProtocol Component.
+ OrderPackaged : M : Packaged Data regarding the Order data,
+ Content which the Merchant's OAC sets.
+ BrandSelBrandInfo : O : This is not used in the current
+ PackagedContent version of SET/IOTP.
+ BrandSelProtocol : O : This is not used in the
+ AmountInfoPackaged current version of SET/IOTP.
+ Content
+ BrandSelCurrency : O : This is not used in the
+ AmountInfo current version of SET/IOTP.
+ PackagedContent
+
+ Output Parameters
+ -----------------
+ OkFrom : M : -
+ OkTo : M : -
+ OrderPackaged : M :Changed OrderPackagedContent if
+ Content it rewrites the order information.
+ Otherwise, passed the same input
+ data to OAC.
+ TradingRole : O : The receiver depended
+ PackagedContent TradingRolePackagedContent. The Name
+ Attribute of the packaged contents
+ must include "Payment:" as the prefix,
+ for example "Payment:SET-OD". Multiple
+ TradingRoleData may be returned.
+
+7.1.4 Inquire Authentication Challenge
+
+ This is not used in the current version of SET/IOTP.
+
+7.1.5 Authenticate
+
+ This is not used in the current version of SET/IOTP.
+
+7.1.6 Check Authentication Response
+
+ This is not used in the current version of SET/IOTP.
+
+
+
+
+Kawatsura Informational [Page 19]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+7.2 Brand Selection Related API Calls
+
+7.2.1 Find Payment Instrument
+
+ This API is used to get the Payment Instruments that can be accepted
+ by the Payment Handler on behalf of the Merchant.
+
+ Input Parameters
+ ----------------
+ BrandId : M : See the details of section 8.2.2.
+ ProtocolId : M : This must be set "SETv1.0".
+ PayDirection : M : This must be set "Debit".
+ CurrCodeType : M : This should be set "ISO5217-A".
+ CurrCode : M : -
+ Amount : M : -
+ ConsumerPayId : M : -
+ WalletId : O : -
+ ProtocolBrand : M : -
+ BrandPackaged : O : This is not used in the current
+ Content version of SET/IOTP.
+ ProtocolAmount : O : This is not used in the current
+ PackagedContent version of SET/IOTP.
+ PayProtocolPackaged: M : See details for section 8.3.1.
+ Content
+
+ Output Parameters
+ -----------------
+ PayInstrument : M : Multiple PayInstrument Ids may
+ be returned. See NOTE below.
+
+ NOTE Parameters of PayInstrument
+ --------------------------------
+ Id : M : This must be unique each SET
+ Certificates which the
+ Consumer can use.
+ xml:lang : M : -
+ PayInstName : M : -
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 20]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+7.2.2 Check Payment Possibility
+
+ If the SET Bridge receives this API Message, the SET Bridge returns
+ three packaged content fields.
+
+ Input Parameters
+ ----------------
+ BrandId : M : This is set the consumer selected
+ BrandId.
+ PaymentInstrumentId: M : This is set the consumer selected
+ PaymentInstrumentID.
+ PayDirection : M : This is set "Debit".
+ CurrCodeType : M : This is set "ISO4217-A".
+ CurrCode : M : -
+ Amount : M : -
+ ProtocolId : M : This must be set "SETv1.0".
+ WalletId : O : -
+ Passphrase : O : -
+ ConsumerPayId : M : -
+ ProtocolBrand : M : This is set the consumer selected
+ ProtocolBrand Component.
+ BrandPackaged : O : This is not used in the current
+ Content version of SET/IOTP.
+ ProtocolAmount : O : This is not used in the current
+ PackagedContent version of SET/IOTP.
+ PayProtocol : M : This field is copied from the PayProtocol
+ PackagedContent Component
+
+ Output Parameter
+ ---------------
+ BrandSelBrandInfo : O : This is not used in the current
+ PackagedContent version of SET/IOTP.
+ BrandSelProtocol : O : This is not used in the
+ AmountInfoPackaged current version of SET/IOTP.
+ Content
+
+ BrandSelCurrency : O : This is not used in the
+ AmountInfoPackaged current version of SET/IOTP.
+ Content
+
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 21]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+7.3 Payment Transaction Related API Calls
+
+7.3.1 Start Payment Consumer
+
+ In SET/IOTP, this API is used for the Consumer's SET Bridge to
+ process the 1st SET Initiation and any subsequent SET messages.
+
+ Input Parameters
+ ----------------
+ BrandId : M : ID for the consumer selected
+ Brand. See the details of
+ section 8.2.1.
+ PaymentInstrumentId: M : ID for the consumer selected
+ Instrument.
+ CurrCodeType : M : The consumer selected CurrCodeType.
+ CurrCode : M : The consumer selected CurrCode.
+ Amount : M : The consumer selected Amount.
+ PayDirection : M : Indicates the payment direction
+ from the Consumer's prospective.
+ ProtocolId : M : The consumer selected ProtocolId.
+ OkFrom : M : -
+ OkTo : M : -
+ ConsumerPayId : M : -
+ WalletID : O : -
+ Passphrase : O : -
+ CallBackFunction : O : This is not used in the SET/IOTP.
+ CallBackLanguage : O : This is not used in the SET/IOTP.
+ List
+ ProtocolBrand : M : ID for the consumer selected
+ Protocol dependent Brand information.
+ BrandPackaged : O : This is not used in the current
+ Content version of SET/IOTP.
+ ProtocolAmount : O : This is not used in the current
+ PackagedContent version of SET/IOTP.
+ PayProtocolPackaged : M : See section 8.2.2.
+ Content
+
+ Output Parameters
+ -----------------
+ ContStatus : M : "Continue" must be set if there is
+ in no problem
+ PaySchemePackaged : M : See section 6.5.1.
+ Content
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 22]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+7.3.2 Start Payment Payment Handler
+
+ This API is used to initiate a payment on the Payment Handler's side.
+ The SET Related Module does a payment initialization. The SET
+ Related Module processes SET Message received and returns the
+ appropriate SET Message (e.g., 2nd SET Initiation or SET PinitRes
+ message).
+
+ Input Parameters
+ ----------------
+ BrandId : M : ID for the consumer selected Brand.
+ See the details of section 8.2.1.
+ ConsumerPayId : O : ID for the consumer generated payment
+ transaction.
+ CurrCodeType : M : The consumer selected CurrCodeType.
+ This should be set "ISO4217-A".
+ CurrCode : M : The consumer selected CurrCode.
+ Amount : M : The consumer selected Amount.
+ PayDirection : M : This is set "Debit".
+ ProtocolId : M : The consumer selected ProtocolId.
+ This must be set "SETv1.0".
+ OkFrom: : M : -
+ OkTo : M : -
+ PaymentHandlerPayId: M : -
+ MerchantOrgId : M : -
+ WalletID : O : -
+ Passphrase : O : -
+ CallBackFunction : O : This is not used in the SET/IOTP.
+ CallBackLanguage : O : This is not used in the SET/IOTP.
+ List
+ BrandPackaged : O : This is not used in the current
+ Content version of SET/IOTP.
+ ProtocolAmountP : O : This is not used in the current
+ PackagedContent version of SET/IOTP.
+ PayProtocolPackaged: M : -
+ Content
+ ProtocolBrand : M : Information for the consumer selected
+ Protocol dependent Brand.
+ BrandSelBrandInfo : O : This is not used in the current
+ PackagedContent version of SET/IOTP.
+ BrandSelProtocol : O : This is not used in the
+ AmountInfo current version of SET/IOTP.
+ PackagedContent
+ BrandSelCurrency : O : This is not used in the
+ AmountInfo current version of SET/IOTP.
+ PackagedContent
+
+
+
+
+
+Kawatsura Informational [Page 23]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ TradingRolePackaged: O : Copied from the TradingRoleData
+ Content Component. The Name Attribute of
+ the packaged contents must include
+ "Payment:" as the prefix,
+ for example "Payment:SET-OD".
+ PaySchemePackaged : M : See section 6.5.2.
+ Content
+
+ Output Parameters
+ -----------------
+ PaySchemePackaged : M : See section 6.5.2.
+ Content
+ ContStatus : M : "Continue" must be set if there
+ is no problem.
+
+7.3.3 Resume Payment Consumer
+
+ This API is used to restart a payment transaction when the
+ transaction is suspended for some reason such as a time out. The
+ last SET Message relevant to this suspended transaction is returned
+ as the Response.
+
+ Input Parameters
+ ----------------
+ ConsumerPayId : M : -
+ WalletId : O : -
+ PassPhrase : O : -
+ CallBackFunction : O : This is not used in the current version
+ of SET/IOTP.
+ CallBack : O : This is not used in the current version
+ LanguageList of SET/IOTP.
+
+ Output Parameters
+ -----------------
+ ContStatus : M : -
+ PaySchamePackaged : M : See section 8.7.
+ Content
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 24]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+7.3.4 Continue Process
+
+ This API is used to pass a SET related message, received from the
+ counter party, to the SET Bridge, and accept the next SET message as
+ a response.
+
+ (1) Consumer Side Payment Bridge
+
+ Input Parameters
+ ----------------
+ PayId : M : Set ConsumerPayId
+ WalletId : O : -
+ PassPhrase : O : -
+ PaySchemePackaged : M : See section 8.4.3.
+ Content
+
+ Output Parameters
+ -----------------
+ ContStatus : M : Set "End" if SET PRes message is
+ received in the PaySchemePackagedContent
+ as the input parameter, otherwise set
+ "Continue".
+ PaySchemePackaged : O : If ContStatus is set "End", this is not
+ Content used. See 8.4.3.
+
+ (2) Payment Handler Side Payment Bridge
+
+ Input Parameters
+ ----------------
+ PayId : M : Set PaymentHandlerPayId
+ WalletId : O : -
+ PassPhrase : O : -
+ PaySchemePackaged : M : See section 8.4.4.
+ Content
+
+ Output Parameters
+ -----------------
+ ContStatus : M : Set "End" if SET PRes message is
+ received in the
+ PaySchemePackagedContent as the
+ output parameter, otherwise set
+ "Continue".
+ PaySchemePackaged : M : See section 8.4.4.
+ Content
+
+
+
+
+
+
+
+Kawatsura Informational [Page 25]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+7.3.5. Change Process State
+
+ This API is used by the OAC to change the Process State of the OPB.
+ For instance, it is used to change the Payment Status after a SET
+ Payment Transaction was completed. When an error or suspend happens,
+ this API is also used.
+
+ (1) Consumer Side Payment Bridge
+
+ Input Parameters
+ ----------------
+ PayId : M : Set ConsumerPayId
+ ProcessState : M : -
+ CompletionCode : M : -
+ ProcessType : M : -
+ WalletID : O : -
+ PassPhrase : O : -
+
+ Output Parameters
+ -----------------
+ ProcessState : M : -
+ CompletionCode : M : -
+ PercentComplete : O : See section 8.13.
+ xml:lang : O : -
+ StatusDesc : O : This field is not specified in SET/IOTP.
+
+7.4 General Inquiry API Calls
+
+7.4.1 Payment Instrument Inquiry
+
+ This API is not used in the current version of SET/IOTP.
+
+7.4.2 Inquire Pending Payment
+
+ This API is used to check whether the payment Bridge or its wallet is
+ currently in use, or not.
+
+ Input Parameters
+ ----------------
+ WalletID : O : -
+
+ Output Parameters
+ -----------------
+ PayId : M : -
+
+
+
+
+
+
+
+Kawatsura Informational [Page 26]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+7.4.3 Remove Payment Log
+
+ This API is used both Consumer and Payment Handler.
+
+ Input Parameters
+ ----------------
+ PayId : M : -
+ WallerId : O : -
+ Passphrase : O : -
+
+ There is no output parameters.
+
+7.5 Payment Related Inquiry API Calls
+
+7.5.1 Check Payment Receipt
+
+ This API is used to check a Payment Receipt. However since the
+ current SET specification does not support Receipts, SET/IOTP sends
+ its own visual information of a Receipt to the SET Bridge.
+
+ Input Parameters
+ ----------------
+ PayId : M : -
+ WalletId : O : -
+ PassPhrase : O : -
+ PaySchemePackaged : M : See section 8.5.1.
+ Content
+
+ Output Parameters
+ -----------------
+ There is no output Parameter.
+
+7.5.2 Expand Payment Receipt
+
+ This expands an IOTP Payment Receipt Component packaged data into a
+ form which may be used for display or printing purposes.
+
+ Input Parameters
+ ----------------
+ PayId : M : -
+ WalletId : O : -
+ PassPhrase : O : -
+ PackagedContent : M : See section 8.5.2.
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 27]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ Output Parameters
+ -----------------
+ BrandId : M : -
+ ProtocolBrandId : M : -
+ PayInstrumentId : M : -
+ PaySchemePayId : M : LID_M in the SET PRes message is
+ set. (The format of this value must
+ be same as SET Initiation.)
+ Amount : M : Amount * AuthRatio (or CapRatio if
+ available). CapRatio should be the
+ high priority than AuthRatio.
+ CurrCodeType : M : -
+ CurrCode : M : -
+ PayDirection : M : -
+ ProtocolId : M : -
+ ProtocolTransId : O : -
+ TimeStamp : M : This value should be used the
+ Date field of MessageWrapper in the
+ SET PRes message
+ xml:lang : O : This is not used in the SET/IOTP.
+ ConsumerDesc : O : This is not used in the SET/IOTP.
+
+ PaymentHandlerDesc : O : This is not used in the SET/IOTP.
+ StyleNetLocn : O : This is not used in the SET/IOTP.
+ PaymentProperty : O : This is not used in the SET/IOTP.
+
+7.5.3 Inquire Process State
+
+ This API is used to check the payment status. For example, when the
+ OAC receives a Continue Payment Response API, it uses this API if the
+ ContStatus is set to "End". This API can be used at anytime.
+
+ (1) Consumer Payment Bridge
+
+ Input Parameters
+ ----------------
+ PayId : M : Set ConsumerPayId
+ WalletId : O : -
+ PassPhrase : O : -
+
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 28]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ Output Parameters
+ -----------------
+ ProcessState : M : -
+ PercentComplete : O : See 8.13 for the guideline of
+ setting value.
+ CompletionCode : O : See section 8.12.
+ xml:lang : O : -
+ StatusDesc : O : -
+ PayReceiptNameRefs : O : This is not used in the SET/IOTP.
+ PayReceiptPackConts: O : This is not used in the SET/IOTP.
+
+ (2) Payment Handler Payment Bridge
+
+ Input Parameters
+ ----------------
+ PayId : M : Set PaymentHandlerPayId
+ WalletId : O : -
+ PassPhrase : O : -
+
+ Output Parameters
+ -----------------
+ ProcessState : M : -
+ PercentComplete : O : See section 8.13 for the guideline
+ of setting value.
+ CompletionCode : O : See section 8.12.
+ xml:lang : O : -
+ StatusDesc : O : -
+ PayReceiptNameRefs : O : This is set "PRes".
+ PayReceiptPackConts: O : This is not used in the SET/IOTP.
+
+7.5.4 Start Payment Inquiry
+
+ This API call returns the SET InqReq Message in order to process a
+ SET Inquiry.
+
+ Input Parameters
+ ----------------
+ ConsumerPayId : M : -
+ WalletId : O : -
+ Passphrase : O : -
+
+ Output Parameters
+ -----------------
+ PaySchemePackaged : M: Packaged Data to include SET
+ Content InqReq message. See section 8.6.
+
+
+
+
+
+
+Kawatsura Informational [Page 29]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+7.5.5 Inquire Payment Status
+
+ The Payment Handler uses this API request for Consumer initiated
+ inquiry processing. In SET/IOTP, the Payment Handler's SET Bridge
+ receives a SET InqReq message in an InquirePaymentDetail API. The
+ SET Core processes it, and creates a SET InqRes message. The
+ response encapsulates the SET InqRes message.
+
+ Input Parameters
+ ----------------
+ PaymentHandlerPayId: M : -
+ WalletID : O : -
+ PassPhrase : O : -
+ PaySchemePackaged : M : See section 8.6.
+ Content
+
+ Output Parameters
+ -----------------
+ PaymentHandlerPayId: M : -
+ ProcessState : M : -
+ CompletionCode : O : -
+ xml:lang : O : -
+ StatusDesc : O : -
+ PaySchamePackaged : M : See section 8.6.
+ Content
+
+8. SET dependent Process
+
+ This chapter describes the core concepts for the development of
+ SET/IOTP.
+
+8.1 Relationships between them for IOTP Purchase/Cash Advances
+
+ This document describes SET Initiation Messages based on the [SET
+ EIG]. Merchant sends the 1st SET Initiation Message to the Consumer
+ in order to activate a SET payment transaction. After this message,
+ the other SET Initiation Messages (JPO, etc.) and the SET payment
+ Transaction (SET PinitReq message, etc.) are exchanged between the
+ Consumer and the Payment Handler.
+
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 30]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ +------------+ +----------+
+ | | | |
+ | |<----------------| Merchant |
+ | | 1st SET InitMsg | |
+ | | +----------+
+ | Consumer | +----------+
+ | | | |
+ | |<--------------->| P.H. |
+ | | Other SET Init/ | |
+ +------------+ SET Message +----------+
+
+ Figure 11 Relationship between IOTP Messages and SET Messages
+
+ When the Merchant sends any data (e.g., SET SaleDetail) except a SET
+ Related messages (e.g., SET PinitRes message), it can send it by two
+ different methods:
+
+ (a) The Merchant sends the data via the Consumer.
+ (b) The Merchant sends the data out-of-band.
+
+ In case (a), the Merchant sends the data by encapsulating it into
+ TradingRoleData.PackagedContent inside the Offer Response Block sent
+ to Consumer. The data is copied to the Payment Request Block and
+ sent to the Payment Handler. This case assumes that the format of
+ the data is already agreed upon between the Merchant and the Payment
+ Handler.
+
+ This document does not specify case (b).
+
+8.2 Definition of Identifiers
+
+8.2.1 Definition of BrandId
+
+ BrandId should be used registered identification for IANA. Now, the
+ following BrandIds have registered:
+
+ Amex, Dankort, JCB, Maestro, MasterCard, MICOS, VISA, atCredits,
+ EZpay, GeldKarte, Mondex, paybox
+
+8.2.2 Definition of ProtocolBrandId
+
+ ProtocolBrandID is defined as follows:
+
+ <Premise> SET BrandID is defined as brand[:Product]. ([] is indicated
+ as optional.) In SET, The brandID is a brand name, which corresponds
+ to the brand of the payment card. Additionally the Product is a
+ product name, which is defined as the type of product within the
+ specific brand such as Gold Card.
+
+
+
+Kawatsura Informational [Page 31]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ Set IOTP ProtocolBrandId as follows:
+
+ brand:Product:PCN
+
+ In here,
+
+ o The brand above is the same as the sub data of SET BrandID, as
+ Brand Name (brand), defined in SET.
+ o Product above is the same as the sub data of SET BrandID, as
+ Product Name (Product), defined in SET.
+ o PCN above is the Promotional Card Name, and is written in the SET
+ Certificates.
+
+ Example:
+
+ Visa:Gold:WalMart
+
+ Since SET Brand ID has a colon between brand and Product, the two
+ colons should be able to delimit Brand, Product, and PCN.
+
+ Product and PCN can omit if necessary. For the detail of these
+ definitions are follows:
+
+ (1) The case of omitting Product
+
+ Definition: brand::PCN
+ Example: VISA::UC_VISA
+
+ (2) The case of omitting PCN
+
+ Definition: brand:Product
+ Example: VISA:Gold
+
+ (3) The case of omitting Product, PCN
+
+ Definition: brand
+ Example: VISA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 32]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ Invalid Examples:
+ VISA:Gold:
+ VISA::
+ VISA:
+ ProtocolBrandId which there is no brand.
+
+8.2.3 Definition of ProtocolId
+
+ Protocolld defines as follows:
+
+ ProtocolId := SETName + Version
+ SETName := "SET"
+ Version := "v" + version + "." + revision
+
+ Where the version is number matching a major SET version, and the
+ revision is the number matching a minor SET revision.
+ Example:
+ "SETv1.0","SETv2.0"
+
+ NOTE: In the current version of SET/IOTP, "SETv1.0" is fixed as
+ ProtocolId.
+
+8.2.4 Relationship between Ids
+
+ ProtocolBrandId must be unique and depends on BrandId and ProtocolId.
+ The followings are map among BrandId and ProtocolId, which have
+ registered in IANA, and ProtocolBrandId.
+
+ BrandId ProtocolId ProtocolBrandId
+ -----------------------------------------
+ Amex SETv1.0 Amex
+ Dankort SETv1.0 Dankort
+ JCB SETv1.0 JCB
+ MasterCard SETv1.0 MasterCard
+ Nicos SETv1.0 Amex
+ VISA SETv1.0 VISA
+
+ Regarding to the BrandIds except above, the BrandId registrant (e.g.,
+ credit card company) MUST register it in order to be able to map one
+ to one between ProtocolBrandId and the pair of BrandId and
+ ProtocolId.
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 33]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+8.3 Process prior to Payment
+
+8.3.1 FindAcceptedPaymentProtocol Function
+
+ (1) Parameter of PayProtocolPackagedContent
+
+ Name : O : This is not used in SET/IOTP.
+ Content : M : This should be set "PCDATA".
+ Transform : M : This is set "BASE64".
+ ContentData : M : SET specific protocol data. Includes data
+ that is used to create the 1st SET Initiation
+ Message that is not contained in other
+ IOTP elements.
+
+ (2) Parameter in the ContentData
+
+ Parameters of ContentData are described below. The Field Values
+ follow the [SET EIG].
+
+ Field Required
+ ------------------------------------
+ MIME-Version Optional
+ Content-Transfer-Encoding Mandatory
+ SET-Initiation-Type Mandatory
+ SET-LID-M Optional
+ SET-InstallTotalTrance Optional
+ SET-Recurring Optional
+ SET-Ext-OID Optional
+ SET-Ext-Data Optional
+ SET-Ext-Mandatory Optional
+ SET-Echo-In-Response Optional
+ SET-Echo-In-Request Optional
+
+ For Example:
+
+ MIME-Version: 1.0
+ Content-Transfer-Encoding: Binary
+ SET-Initiation-Type: Payment-Initiation
+ SET-Recurring: 31 19960223
+ SET-Service-URL: http://www.custcare.com/index.html
+ SET-LID-M: 515A533033363632594B
+
+ Note: The contents in ProtoclPackagedContent must be US-ASCII and
+ encoded by BASE64.
+
+
+
+
+
+
+
+Kawatsura Informational [Page 34]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+8.3.2 FindPaymentInstrument Function
+
+ (1) Information of PayInstrument
+
+ Returns a list of Payment Instrument IDs related to the BrandId and
+ ProtocolBrandId. In this document, BrandId and ProtocolId are
+ defined in section 8.2.
+
+ In this document, Brand has two recognized meanings in SET/IOTP, as
+ follows:
+
+ Brand as Primary Brand:
+ The Primary Brand is the Brand which is defined as brand in SET,
+ such as VISA, MasterCard, Nicos.
+
+ Brand as Dual Brand or Promotional Brand:
+ The Dual Brand is the payment instrument which has two Brand, such
+ as UC-VISA (UC Card and VISA Card) This style is popular in Japan.
+
+ A Promotional Brand means that, if the Consumer pays with that
+ Brand, then the Consumer will receive some additional benefit such
+ as discount or frequent flyer point.
+
+ 1. ProtocolBrandId as a Primary Brand
+
+ Example:
+
+ "MasterCard", "MasterCard::UC", "MasterCard:Gold:" and
+ "MasterCard::WalMart" are all MasterCard Brands.
+
+ 2. ProtocolBrandId as a Dual Brand or a Promotional Brand
+
+ Example:
+
+ "MasterCard::UC" is Dual Brand of "MasterCard" and "UC".
+ "SET:MasterCard::WalMart" is Promotional Brand of MasterCard-
+ WallMart.
+
+ The SET Bridge receives the ProtocolBrandId from the OAC in the
+ FindPaymentInstrument Function,
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 35]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ (1) If the accepted ProtocolBrandId is XXX:YYY
+
+ The SET Related Module searches for ProtocolBrandIds with the
+ string "XXX:YYY:*" (* is wild card), the corresponding
+ PaymentInstrumentIds of all ProtocolBrandIds with the matching
+ Primary Brand (regardless of also being a Dual Brand or
+ Promotional Brand) will be returned to the OAC, for the Consumer
+ to select from.
+
+ (2) If the accepted ProtocolBrandId is XXX:YYY:ZZZ
+
+ The SET Related Module searches for ProtocolBrandIDs with the
+ string "XXX:YYY:ZZZ", only the corresponding PaymentInstrumentIds
+ of the ProtocolBrandIds that match the Dual Brand or Promotional
+ Brand will be returned to OAC, for the Consumer to select from.
+
+ Example:
+
+ Assume ProtocolBrandIds are correspond to PaymentInstrumentIds in
+ the SET Bridge as follows,
+
+ ProtocolBrandId PaymentInstrumentId
+ ------------------------------------------
+ MasterCard 1
+ MasterCard::UC 2
+ MasterCard::WallMart 3
+ VISA::UC 4
+
+ If the SET Bridge receives a ProtocolBrandId as "MasterCard" in
+ the FindPaymentInstrument Function, the SET Bridge will return
+ "1","2", and "3". However, if the SET Bridge receives a
+ ProtocolBrandId as "MasterCard::UC" to OAC, SET Bridge will
+ returns only "2".
+
+8.3.3 GetPaymentInitializationData Function
+
+ (1) Create TradingRolePackagedContent
+
+ If necessary, The SET Related Module generates
+ TradingRolePackagedContent corresponded to the received
+ ReceiverOrgID. The ContentData of TradingRolePackagedContent is the
+ information which the Payment Handler needs to process the SET
+ Transaction (for example, the SET SaleDetail. and the SET OD). The
+ ContentData, Content, and the Transform must be agreed upon between
+ the Merchant and the Payment Handler beforehand.
+
+
+
+
+
+
+Kawatsura Informational [Page 36]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ The Name Attribute of the packaged contents must include "Payment:"
+ as the prefix, for example "Payment:SET-OD". If there is no
+ PackagedContent corresponding to ReceiverOrgID, such that the SET
+ Related Module does not need to create the PackagedContent, the
+ TradingRolePackagedContent is not created.
+
+ Parameters in TradingRolePackagedContent
+ ----------------------------------------
+ Name : O : This is not specified in the current SET/IOTP.
+ Content : M : Should be identical between the Payment
+ Handler and the Merchant.
+ Transform : M : Should be identical between the Payment
+ Handler and the Merchant.
+ ContentData : M : Element Data for the Payment Handler to
+ process the SET Transaction. Should be
+ identical between the Payment Handler and
+ the Merchant.
+
+8.4 Process of Payment
+
+8.4.1 StartPaymentConsumer Function
+
+ (1) Process of the 1st SET Initiation Message
+
+ Since there are similar items between the SET Initiation Message
+ Fields and IOTP Elements, IOTP elements can be used for the
+ corresponding SET Initiation Fields. Other SET Initiation Fields,
+ except URL information (for detail, see below), is encapsulated in
+ the PayProtocolPackagedContent.
+
+ This document does not specify how the SET Related Module implements
+ the 1st SET Initiation Process.
+
+ The following table shows the list of SET Initiation Fields that
+ corresponds to IOTP Elements.
+
+ SET Initiation Field IOTP Element (in TPO.Brandlist)
+ ---------------------------------------------------------------
+ SET-Version Consumer selected ProtocolId
+ SET-Brand Consumer selected ProtocolBrandId
+ SET-Amount Consumer selected Amount Data in
+ CurrencyAmount.
+ --------------------------------------------------------------
+ SET Initiation Field IOTP Element (in OfferResp)
+ --------------------------------------------------------------
+ Order Description The hash data of ContentData of
+ PackagedContent of Order Component.
+
+
+
+
+Kawatsura Informational [Page 37]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ (b) SET-Version:
+
+ SET-Version can be corresponded to ProtocolId. The version number
+ appears after the "v" for the SET-Version.
+
+ ProtocolId -> _______
+ SETv1.0
+ ~~~<- SET-Version
+
+ Figure 12 ProtocolId vs SET-Version
+
+ (c) SET-Brand:
+
+ SET-Brand can be corresponded to ProtocolBrandId.
+
+ (d) SET-PurchAmt:
+ It is necessary to adjust the format of the Amount between IOTP and
+ SET, since IOTP and SET use different syntax.
+
+ Assumption:
+
+ o In SET/IOTP, The "ISO4217-A" (the currency code which is
+ represented by three alphabet, such as "USD") is mandatory.
+
+ o Consumer Side SET Related Module should have a mapping table
+ between "ISO4217-A" and "ISO4217-N" (the currency code which is
+ represented by three digit, such as "840").
+
+ (d) -1 Content of the SET-PurchAmt
+
+ The content of the SET-PurchAmt is as follows:
+
+ SET PurchAmt: currency amount amtExp10
+
+ For a description see [SET] Book 2, page 299. For example, $129.50
+ is represented by "840 12950 -2". In this case, the corresponding
+ values for the "currency", "amount" and "amtExp10" are "840", "12950"
+ and "-2" respectively.
+
+ (d) -2 Content of IOTP Amount Elements
+
+ The content of the three IOTP amount elements consist of the
+ following: Amount, CurrCodeType and CurrCode. For a description of
+ each, see [RFC 2801]. For example, $129.50 is represented by the
+ following:
+
+ CurrCodeType="ISO4217-A"
+ CurrCode="USD"
+
+
+
+Kawatsura Informational [Page 38]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ Amount="129.50"
+
+ (d) -3 Example of how-to-translate
+
+ The one-to-one mapping between the IOTP format and the SET format
+ is very simple. This example of sequence below uses the example
+ of IOTP amount Element above.
+
+ 1) Translate from IOTP CurrCode (ISO4217-A) to SET currency (ISO-
+ 4217-N). For example, if CurrCode="USD", then the value of
+ currency is "840".
+
+ 2) Calculate how many decimal places are represented in the Amount.
+ For example, if Amount="129.50", there are "2" decimal places.
+
+ 3) [The number of decimal places] *( -1) corresponds to the SET
+ amtExp10. In the above case, SET amtExp10 = 2 * (-1) = -2.
+
+ 4) 10^[The number of the Amount's decimal places] * Amount
+ corresponds to the SET amount. In the above example, SET amount =
+ 10^2 * 129.50 = 12950.
+
+ 5) Concatenate three integers and use white spaces as a delimiter.
+
+ Finally, in the above case, the SET PurchAmt is represented as "840
+ 12950 -2".
+
+ (e) SET OD (Order Description) vs. IOTP Order Information
+
+ In the IOTP, the OAC handles the Order Information, such as display
+ use, as SET uses the Order Information. Payment Handler does not
+ know the actual Order Information because the Merchant and Payment
+ Handler may exist in the separate domains. However, Payment Handler
+ needs to get the SET OD from Merchant via the Consumer or directly
+ because Payment Handler needs the SET OD to create 2nd SET Initiation
+ message and after. In this situation, the Merchant should not pass
+ the actual order information to the Payment Handler because the order
+ information may be considered private data. Therefore, SET/IOTP
+ defines SET OD as the hash of IOTP Order Information. The hash
+ algorithm must be SHA1.
+
+ But the Order Component may be included two or more Packaged Content
+ (see [RFC 2801]). Therefore SET/IOTP specifies to create hash as
+ follows:
+
+ (e) -1. If the Name attribute does not have the Name attribute, such
+ that the Order Component have only one Packaged Content, hash the
+ Contents Data using SHA1 simply and be encoded by BASE64.
+
+
+
+Kawatsura Informational [Page 39]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ (e) -2. Otherwise, such that there exists the Name attribute, sort
+ the Packaged Contents in the UTF-16 character code order of Name
+ attribute and hash the Content Data using SHA1 and concatenate them
+ in proper sequence, then hash it using SHA1 again and be encoded by
+ BASE64.
+
+ NOTE:
+ To avoid different character encodings between applications, in this
+ document, SET OD MUST be constructed from the ContentData in
+ OrderPackagedContent as follows:
+
+ (1) Convert it to network byte ordered Unicode encoding data.
+ (2) Hash (1) using SHA1
+ (3) Convert (2) to BASE64 US-ASCII data
+
+ Therefore, "Content-Type","charset" MUST be "text/plain","us-ascii"
+ respectively when SET Initiation message is constructed.
+
+ (f) SET-***-URL vs. IOTP Net Location
+
+ In IOTP, the OAC handles location data therefore the OAC does not
+ need to pass net location data on to the OPB. However, some vender
+ implemented consumer SET/IOTP wallets may need the URL information to
+ process the SET Initiation. Thus, if necessary, the Consumer's SET
+ Related Module must set appropriate URL data to SET-***-URL.
+
+ (2) Create the next SET related message
+
+ Generate SET related message (SET PInitReq or SET Initiation
+ Response) at the SET Related Module, to be sent to the Payment
+ Handler.
+
+ (3) Error check of the next SET related message.
+
+ If SET related message which is created in (2) is SET Initiation
+ Response and includes any error in it, SET Related Module creates an
+ ErrorResponse message with ErrorCode to "EncapProtErr" and the
+ Severity to "HardError" and sent it to the OAC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 40]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ (4) Create PaySchemePackagedContent
+
+ The followings are the parameter of PaySchemePackagedContent in
+ StartPaymentConsumerResponse.
+
+ ContentData : M : SET Related Message which is encoded by
+ BASE64. (e.g., SET PinitRes message or
+ SET Initiation Response Message)
+ Name : O : This is not used in the current SET/IOTP.
+ Content : M : This field should be set to "PCDATA".
+ Transform : M : This must be set "BASE64".
+
+ (5) Store of the Payment Information
+
+ SET Bridge should store the following in the DataBase:
+
+ o ConsumerPayId
+ o PaySchemePackagedContent
+ o ContStatus
+ o ContentSoftwareId (corresponding to the PaySchemePackagedContent)
+ o ProcessState
+
+8.4.2 StartPaymentPaymentHandler Function
+
+ (1) Process for TradingRoleData
+
+ SET Bridge must processes appropriately, for example pass it to the
+ SET Core, if there exists the TradingRolePackagedContent as the input
+ Parameter.
+
+ (2) SET Specific Process
+
+ The SET Related Module processes the SET Initiation Response or the
+ SET Transaction (SET PInitReq). In addition, the SET Related Module
+ generates a message (the next SET Initiation Message or SET PInitRes)
+ corresponding to the results of the processed message. This message
+ will be sent to the Consumer.
+
+ (3) Error check of the next SET related message.
+
+ If SET related message which is created in (2) includes any error,
+ SET Related Module create an ErrorResponse message with ErrorCode to
+ "EncapProtErr" and the Severity to "HardError" and sent it to the
+ OAC.
+
+
+
+
+
+
+
+Kawatsura Informational [Page 41]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ (4) Generate PaySchemePackagedContent
+
+ PaySchemePackagedContent which Encapsulate the SET Initiation Message
+ or SET PInitRes into ContentData and generate the
+ PaySchemePackagedContent. The Parameters of PaySchemePackagedContent
+ as Output is as follows:
+
+ ContentData : M : SET Related Message which is encoded by
+ BASE64 (e.g., SET PinitRes message or
+ SET Initiation Response Message).
+ Name : O : This is not used in the current SET/IOTP.
+ Content : M : This field should be set to "PCDATA".
+ Transform : M : This must be set "BASE64"
+
+8.4.3 ContinueProcess Function (Consumer Side)
+
+ (1) SET Specific Process
+
+ The Parameters of PaySchemePackagedContent as Input is as follows:
+
+ ContentData : M : SET Related Message which is encoded by
+ BASE64 (e.g., SET PinitRes message,
+ SET PRes message or SET Initiation
+ Response Message).
+ Name : O : This is not used in the current SET/IOTP.
+ Content : M : This field should be set to "PCDATA".
+ Transform : M : This must be set "BASE64"
+
+ SET Related Module processes the SET Related Message in the
+ PaySchemePackagedContent, then SET Related Message corresponding to
+ the processed message is created if necessary.
+
+ (2) SET Related Message Error Check
+
+ If SET related message which is created in (2) includes any error,
+ SET Related Module create an ErrorResponse message with ErrorCode to
+ "EncapProtErr" and the Severity to "HardError" and sent it to the
+ OAC.
+
+ (3) Create PaySchemePackagedContent
+
+ The followings are the parameter of PaySchemePackagedContent in
+ ContinueProcessResponse.
+
+ ContentData : M : SET Related Message which is encoded by
+ BASE64 (e.g., SET PinitReq message,
+ SET PReq message or SET Initiation
+ Response Message).
+
+
+
+Kawatsura Informational [Page 42]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ Name : O : This is not used in the current SET/IOTP.
+ Content : M : This field should be set to "PCDATA".
+ Transform : M : This must be set "BASE64".
+
+ If the ContentData which has received from Payment Handler is SET
+ PRes message, this data is not created.
+
+8.4.4 ContinueProcess Function (Payment Handler Side)
+
+ (1) Brand Integrity Check between IOTP Elements and SET Elements
+
+ Since the Consumer sets the Amount and Brand in the SET Message,
+ based on the IOTP message, it might be altered when the IOTP message
+ is copied to the SET message. Thus, the Payment Handler needs to
+ check the Elements in IOTP components (Payment, etc.) and the
+ Elements in the SET message to make sure they are consistent. The
+ IOTP Brand specified by the Merchant should correspond to the Brand
+ used in the SET payment.
+
+ The Brand Integrity check sequence is as follows:
+
+ (a) After receiving the SET PReq message, check the Consumer selected
+ Brand information (e.g., ProtocolBrandId) in the IOTP Payment Request
+ against information in the SET certificate in the SET PReq message.
+
+ (b) If they do not match, return a SET Bridge Level Error
+ (Severity="HardError", ErrorCode="AttNotValid" and Names="BrandId").
+
+ Additionally, the SET PReq message signature must be verified with
+ the SET CardHolder's certificate. (This is done during a normal SET
+ Transaction.)
+
+ NOTE: This integrity check is necessary evenif There is no
+ Promotional Card Name in the ProtocolBrandId because SET may have
+ selected the MasterCard even though IOTP has selected the VISA.
+
+ (2) SET Related Process
+
+ Encapsulate the SET related Message (SET Initiation Message or SET
+ Transaction Message) in to Content Data of PaySchemePackagedContent
+ and send it to the Sender.
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 43]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ The followings are the parameters of PaySchemePackagedContent as
+ output.
+
+ ContentData : M : SET Related Message which is encoded by
+ BASE64 (e.g., SET PinitReq message,
+ SET PReq message or SET Initiation
+ Response Message).
+ Name : O : This is not used in the current SET/IOTP.
+ Content : M : This field should be set to "PCDATA".
+ Transform : M : This must be set "BASE64".
+
+ (3) SET Related Message Error Check
+
+ If SET related message which is created in (2) includes any error,
+ SET Related Module create an ErrorResponse message with ErrorCode to
+ "EncapProtErr" and the Severity to "HardError" and sent it to the
+ OAC.
+
+ If SET related message which is created in (2) is SET PRes message,
+ and its message includes except:
+
+ (a) CompletionCode in SET PRes message is "authorizationPerformed"
+ and AuthCode is "Approved" or (b) CompletionCode in SET PRes message
+ is "capurePerformed" and CapCode "Success",
+
+ SET Related Module create ErrorResponse message with ErrorCode to
+ "BusinessError"and the Severity to "HardError" and sent it to the
+ OAC.
+
+ (4) Create PaySchemePackagedContent
+
+ The followings are the parameter of PaySchemePackagedContent in
+ ContinueProcessResponse.
+
+ ContentData : M : SET Related Message which is encoded by
+ BASE64 (e.g., SET PinitRes message,
+ SET PRes message or next SET Initiation
+ Message).
+ Name : O : "PRes" only if ContentData includes
+ SET PRes message, otherwise this is
+ not used in the current SET/IOTP.
+ Content : M : This field should be set to "PCDATA".
+ Transform : M : This must be set "BASE64".
+
+ If ContentData includes the SET PRes message, ContStatus MUST be
+ "End".
+
+
+
+
+
+Kawatsura Informational [Page 44]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+8.4.5 InquireProcessState Function
+
+ (1) Setting ProcessState
+
+ Values for the ProcessState are described in section 8.9.2.
+
+ (2) Setting CompletionCode
+
+ Set to "Unspecified" when a SET Business Failure has occurred, and
+ set StatusDesc to the value corresponding to AuthCode or CapCode.
+
+ (3) Setting StatusDesc
+
+ The values for PayStatusDesc are not specified in the SET/IOTP.
+
+ (4) Create PayReceiptNameRefs
+
+ Set to "PRes" in the PayReceiptNameRefs
+
+8.5 Payment Receipt
+
+8.5.1 CheckPayReceipt Function
+
+ SET Related Module does not check the Payment Receipt Information
+ especially, sends the general response message as long as valid
+ request message.
+
+ The Parameters of PayReceiptPackagedContent are followings:
+
+ Name : O : This MUST be set "PRes"
+ Content : M : This field should be set to "PCDATA".
+ Transform : M : This must be set "BASE64".
+ ContentData : M : SET PRes message which is encoded by BASE64.
+
+8.5.2 ExpandPayReceipt Function
+
+ (1) PayReceiptPackagedContents
+
+ The Parameters of PayReceiptPackagedContent are as follows:
+
+ Name : O : This MUST be set "PRes"
+ Content : M : This field should be set to "PCDATA".
+ Transform : M : This must be set "BASE64".
+ ContentData : M : SET PRes message which is encoded by BASE64.
+
+
+
+
+
+
+
+Kawatsura Informational [Page 45]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ (2) Get the current status information
+
+ SET Related Module gets out the following element from Data Base
+ using ConsumerPayId, PaymentHandlerPayId as keys.
+
+ o BrandId
+ o ProtocolBrandId
+ o PayInstrumentId
+ o Amount
+ o CurrCodeType
+ o CurrCode
+ o PayDirection
+
+ (3) Get the SET Data
+
+ SET Related Module gets the following data from SET PRes message
+ which take as the Request Message.
+
+ (a) Date Field in the MessageWrapper Date field between SET and IOTP
+ is slightly different. The different things are as follows:
+
+ o There is no TimeZone in the Date field of SET.
+
+ o Second and Milli-second can be omitted in the Date field of SET
+
+ Therefore, SET Related Module needs to compensate the Date
+ information when TimeStamp field is set.
+
+ (b) AuthRatio in SET PRes message. (CapRatio is high priority than
+ AuthRatio if available.)
+
+ (c) LID_M in SET PRes message. (The style of this value is the same
+ as it of SET Initiation message.)
+
+8.6 Status Inquiry
+
+ In SET/IOTP, SET Inquiry Initiation is not supported (i.e., omitted).
+ SET Inquiry Messages are embedded in the PaySchemeData element in
+ IOTP Inquiry Messages.
+
+ The Parameters of PaySchemePackagedContent in
+ StartPaymentInquiryResponse are follows:
+
+ Name : O : This is not used in the SET/IOTP.
+ Content : M : This field should be set to "PCDATA".
+ Transform : M : This must be set "BASE64".
+ ContentData : M : SET InqReq message which is encoded by BASE64.
+
+
+
+
+Kawatsura Informational [Page 46]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ The Parameters of PaySchemePackagedContent in InqurePaymentStatus are
+ follows:
+
+ Name : O : This is not used in the SET/IOTP.
+ Content : M : This field should be set to "PCDATA".
+ Transform : M : This must be set "BASE64".
+ ContentData : M : SET InqReq message which is encoded by BASE64.
+
+ The Parameters of PaySchemePackagedContent in
+ InquirePaymentStatusResponse are follows:
+
+ Name : O : This is not used in the SET/IOTP.
+ Content : M : This field should be set to "PCDATA".
+ Transform : M : This must be set "BASE64".
+ ContentData : M : SET InqRes message which is encoded by BASE64.
+
+ The Parameter of PaySchemePackagedContent in ContinueProcess are
+ follows:
+
+ Name : O : This is not used in the SET/IOTP.
+ Content : M : This field should be set to "PCDATA".
+ Transform : M : This must be set "BASE64".
+ ContentData : M : SET InqRes message which is encoded by BASE64.
+
+8.7 Resume Process
+
+ The Parameter of PaySchemePackagedContent in
+ RequmePaymentConsumerResponse are as follows:
+
+ Name : O : This is not used in the SET/IOTP.
+ Content : M : This field should be set to "PCDATA".
+ Transform : M : This must be set "BASE64".
+ ContentData : M : SET Related Message which is encoded by
+ BASE64 (e.g., SET PinitRes message
+ or SET Initiation Response Message).
+
+8.8 SET Scheme Specific Authentication on IOTP
+
+ IOTP authentication, which uses the SET Scheme, is not used in
+ SET/IOTP.
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 47]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+8.9 SET Bridge ProcessState
+
+8.9.1 SET Bridge ProcessState of Consumer
+
+ No Status ----> InProgress : When StartPaymentConsumer Function
+ is called
+
+ InProgress ---> InProgress : When ContinueProcess Function
+ is called
+ : When ChangeProcessState Function
+ (ProcessState="Failed") is called
+
+ InProgress ---> ProcessError : When ChangeProcessState Function
+ (ProcessState="ProcessError") is
+ called
+ : The Technical Error (Hard Error)
+ is occurred in SET Bridge
+
+ InProgress ---> CompletedOK : When ChangeProcessState Function
+ (ProcessState="CompletedOK") is
+ called
+
+ InProgress ---> Failed : When ChangeProcessState Function
+ (ProcessState="failed") is called
+ : The Business Error is occurred
+ in SET Bridge
+
+ InProgress ---> Suspended : When ChangeProcessState Function
+ (ProcessState="Suspended") is
+ called
+ : ErrorCode="ResumeRequired" is
+ is occurred.
+
+ Suspend ---> InProgress : ResumePaymentConsumer Function
+ is called
+
+ Suspend ---> ProcessError : When ChangeProcessState Function
+ (ProcessState="ProcessError") is
+ called (the Technical Error is
+ occurred prior to ResumePayment-
+ Consumer Function call)
+ : The Technical Error (Hard Error)
+ is occurred in SET Bridge (the
+ Technical Error is occurred while
+ ResumePaymentConsumer is calling)
+
+
+
+
+
+
+Kawatsura Informational [Page 48]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+8.9.2 SET Bridge ProcessState of Payment Handler
+
+ No Status ----> InProgress : When StartPaymentPaymentHandler
+ is called
+
+ InProgress ---> InProgress : When ContinueProcess Function
+ is called
+ : When ChangeProcessState Function
+ (ProcessState="Failed") is called
+
+ InProgress ---> ProcessError : When ChangeProcessState Function
+ (ProcessState="ProcessError") is
+ called
+ : The Technical Error (Hard Error)
+ is occurred in SET Bridge
+ : SET Error Message is occurred
+
+ InProgress ---> CompletedOK : When SET Transaction is completed.
+
+ InProgress ---> Failed : When ChangeProcessState Function
+ (ProcessState="failed") is called
+ : The Business Error is occurred
+ in SET Bridge
+
+ CompletedOK ---> Failed : When ChangeProcessState Function
+ or CancelPayment Function
+ (ProcessState="Failed") is called
+ and the payment is cancelled.
+
+8.10 Relationship between Pay Step and Deliv Step on SET/IOTP
+
+ SET/IOTP recommends the following regarding Delivery:
+
+ Physical Goods
+ --------------
+ For physical goods, the IOTP Delivery Exchanges should be omitted.
+ That is, set DelivExch=False and DelivAndPayResp=False in the
+ Delivery Component. This is to avoid the situation where the IOTP
+ Delivery Handler must check with the IOTP Payment Handler on the
+ status of a credit authorization. When a Delivery Inquiry
+ transaction might occur, the DelivReqNetLocn attribute in the
+ DeliveryData Element must have been specified at the time of the
+ original Offer Response Message. If you want to use the Delivery
+ Exchange, you need to process the inquiry of the credit authorization
+ out of IOTP between IOTP Payment Handler and Delivery Handler.
+
+
+
+
+
+
+Kawatsura Informational [Page 49]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ Digital Goods
+ -------------
+ For digital goods sold through SET/IOTP, authorization should be
+ processed on a real-time basis.
+
+8.11 Completion Code
+
+ In SET/IOTP, the CompletionCode, which is a Business Error Code, is
+ set as follows:
+
+ Value Description
+ ------------------------------------------------------
+ BrandNotSupp This value is not used.
+ CurrNotSupp This value is not used.
+ AuthError The IOTP Authentication has
+ failed for any reason.
+ InsuffFunds This value is not used.
+ InstBrandInvalid This value is not used.
+ PaymentDecl A SET business failure has occurred.
+ InstNotValid This value is not used.
+ BadInstrument This value is not used.
+ Unspecified Unspecified error. There is some known
+ problem or error, which does not fall
+ into one of the other CompletionCodes.
+
+8.12 PercentComplete
+
+ This document recommends to set the PercentComplete as follows:
+
+ SET Related Setting for Setting for Value of
+ Message Consumer Paymnet Handler PercentComplete
+ ------------+---------------+------------------+-----------------
+ SET Initia- |After 1st SET |After 1st SET |20
+ tion |Initiation |Initiation |
+ |Response has |Response has |
+ |Cteated |Processed |
+ |(See Note) |(See Note) |
+ ------------+---------------+------------------+----------------
+ SET PinitReq|After Created |After Processed |40
+ ------------+---------------+------------------+----------------
+ SET PinitRes|After Processed|After Created |60
+ ------------+---------------+------------------+----------------
+ SET PReq |After Created |After Processed |80
+ ------------+---------------+------------------+----------------
+ SET PRes |After Processed|After Created |100
+ ------------+---------------+------------------+----------------
+
+
+
+
+
+Kawatsura Informational [Page 50]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ Note: According to the SET Initiation, PercentComplete should be set
+ "20" at the timing of 1st SET Initiation Response is
+ created/processed because number of its message is variable.
+
+8.13 Severity
+
+ In the current version of SET/IOTP, if a technical error occurs in
+ the SET Bridge, the Severity has to be always set to "HardError".
+
+9. Error Handling
+
+ This chapter describes types of handling Errors.
+
+9.1 Types of Errors
+
+ SET/IOTP defines the following error types:
+
+ (1) IOTP Level Error
+
+ This is defined as an error which is NOT specified in [SET EIG] nor
+ [SET]. IOTP Level Errors are divided into two types according to the
+ following:
+
+ OAC Level Error: Error in the OAC. This error is defined in the
+ [IOTP].
+
+ SET Related Module Level Error: Error generated in by process on
+ the SET Related Module, not specified in [SET EIG] nor [SET]. For
+ example, when checking the consistency between SET and IOTP elements
+ on SET Related Module, an error might be returned to OAC.
+
+ (2) SET Level Error
+
+ This is defined as an error which is specified in [SET EIG] or [SET].
+ SET Level Errors have been divided into two types of error according
+ to following:
+
+ SET Technical Level Error: Error in the SET Related Module. This
+ error is defined in [SET] or [SET EIG]. SET Technical Level Errors
+ are further subdivided into two types of errors:
+
+ (a) SET Initiation Error Error while the SET Initiation Process is in
+ progress.
+
+ (b) SET Transaction Error Error when the SET Transaction (SET
+ PInitReq message, SET PReq message, etc.) is in progress.
+
+
+
+
+
+Kawatsura Informational [Page 51]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ SET Business Level Error: Error when a business error (e.g., an
+ authorization failure) occurs while the SET Transaction is being
+ processed. In SET, Business Level Errors will be returned in the SET
+ PRes message. SET does not use a SET Error Message for this type of
+ error. However, it is necessary to present the OAC with what kind of
+ SET Business Error has occurred.
+
+ In this below, the details of each errors above are described.
+
+9.2 IOTP Level Error (OAC Error)
+
+ When OAC Level Errors have occurred, if necessary, the sender and
+ receiver must issue ChangeProcessState API and change the status.
+ For the detail of these errors, see [IOTP].
+
+9.3 IOTP Level Error (SET Bridge Error)
+
+ This is the error generated in a process on the SET Related Module,
+ not specified in [SET EIG] nor [SET]. For example, when checking the
+ inconsistency between SET and IOTP elements on SET Related Module, it
+ might cause an error. This error should be notified to OAC.
+
+ In this case, as a response message, Payment Scheme Data is not
+ returned. An appropriate information must be set to Status Response.
+
+9.4 SET Level Error (SET Technical Error)
+
+9.4.1 SET Initiation Error
+
+ There are two SET Initiation errors as follows:
+
+ o Error generated in SET Initiation Message
+
+ o Error generated in SET Initiation Response Message.
+
+ (1) SET Initiation Message Error
+
+ [SET EIG] describes the error handling when a problem rises in SET
+ Initiation Message. So the Consumer will do the same error handling
+ in 9.4.2.
+
+ When SET Initiation Error rises in 1st Initiation Message, an error
+ message will be returned to the Merchant. If an error occurs after
+ 2nd Initiation Message, an error message will be returned to the
+ Payment Handler. SET Initiation Response will be generated having
+ SET-Error-Field in Response Message Header and will be returned
+ ErrorCode as "PayEncapError" and Severity as "HardError".
+
+
+
+
+Kawatsura Informational [Page 52]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ (a) SET Initiation Response Error
+
+ In SET EIG, there is no description about the handling on the
+ problems in SET Initiation Response. However, it is necessary to
+ define some handling for the problems in SET/IOTP
+
+ (b) Process of Payment Handler
+
+ When a problem rises in SET Initiation Response, SET Related Module
+ generates ErrorResponse, which is included the "EnCapProtoErr" as
+ ErrorCode and the "HardError" as Severity. But
+ PaySchemePackagedContent is not included in this API.
+
+ (2) Process of Consumer
+
+ ChangeProcessState API must be issued, and ProcessState must be
+ modified.
+
+9.4.2 SET Transaction Error
+
+ (1) Process of Sender
+
+ When a SET Transaction Error rises, SET Core creates SET Error
+ Message. Then the SET Related Module creates ErrorResponse Message
+ which includes "HardError" as Severity, "EnCapProtoErr" as ErrorCode
+ and PaySchemePackagedContent. The SET Bridge passes the
+ ErrorResponse Message to OAC. OAC will generate an Error Block which
+ includes PaySchemePackagedContent and sends it to the Receiver side.
+
+ (2) Process of Receiver
+
+ With ContinueProcess API, receiver's OAC sends the message including
+ the PaySchemeData to SET Bridge. SET Bridge passes the SET Error
+ Message to SET Core for this process. After that, SET Bridge sends
+ "End" status with ContinueProcessResponse API.
+
+9.5 SET Level Error (SET Business Error)
+
+ (1) Process of Payment Handler
+
+ SET Related Module checks the SET Business Error in StatusCode in SET
+ PRes message. When SET Transaction Error occurs, SET Related Module
+ creates ErrorResponse Message which is included SET PRes as
+ PaySchemePackagedContent and ErrorCode as "BusinessError" and returns
+ it to OAC. OAC creates Payment Response Block after gets the SET
+ scheme specific receipt in InquireProcessState/Response, and sends it
+ to the Consumer.
+
+
+
+
+Kawatsura Informational [Page 53]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ (2) Process of Consumer
+
+ SET Related Module conducts the same process as in the process that
+ Consumer receives Payment Response Block.
+
+10. Security Considerations
+
+ In the IOTP, Merchant and Payment Handler may exist in different
+ domains. So, if the Merchant passes the payment related information
+ to the Payment Handler via the Consumer, the payment security level
+ may depend on the IOTP. If you want to avoid this, you will need to
+ check integrity of these data by using out-of-band communication
+ between the Merchant and the Payment Handler. In this case, the
+ security level depends on the communication path between them.
+
+11. References
+
+ The following books provide essential background material. Readers
+ are strongly encouraged to consult these references for more
+ information.
+
+ [BASE64] Base64 Content-Transfer-Encoding. A method of
+ transporting binary data defined by MIME. See: RFC
+ 2045: Multipurpose Internet Mail Extensions (MIME)
+ Part One: Format of Internet Message Bodies. N.
+ Freed & N.Borenstein. November 1996.
+
+ [RFC 2801] Burdett, D., "Internet Open Trading Protocol -
+ IOTP, Version 1.0", RFC 2081, April 2000.
+
+ [SET] SET Secure Electronic Transaction (TM) , Version
+ 1.0, May 31, 1997
+ Book 1: Business Description
+ Book 2: Programmer's Guide
+ Book 3: Formal Protocol Definition
+
+ [SET EIG] External Interface Guide to SET Secure Electronic
+ Transaction, Sep 24, 1997.
+
+ [SJR] "SET Secure Electronic Transaction Specification"
+ Support for Japanese Requirements, Mar 16, 1998.
+
+ [IOTP Payment API] Hans, W., et al., "Payment API for v1.0 Internet
+ Open Trading Protocol (IOTP)", Work in Progress.
+
+
+
+
+
+
+
+Kawatsura Informational [Page 54]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+ [ISO4217] ISO 4217: Codes for the Representation of
+ Currencies. Available from ANSI or ISO.
+
+ [XML] Extensible Mark Up Language. A W3C recommendation.
+ See http://www.w3.org/TR/1998/REC-xml-19980210 for
+ the 10 February 1998 version.
+
+12. IANA Considerations
+
+ This document does not ask for any action from IANA. It references
+ an existing registry, iotp-codes, where at the time of publication of
+ this RFC the following BrandID's are registered:
+
+ Amex, Dankort, JCB, Maestro, MasterCard, MICOS, VISA, atCredits,
+ EZpay, GeldKarte, Mondex, paybox
+
+13. Acknowledgement
+
+ The author of this document appreciates the following contributors to
+ this protocol (in alphabetic order of company) without which it could
+ not have been developed.
+
+ Andrew Drapp Hitachi Europe, Ltd.
+
+ David Burdett Commerce One (ex. Mondex International)
+
+ Donald Eastlake 3rd Motorola (ex. IBM)
+
+ Hans-Bernhard Beykirch SIZ
+
+ John Wankmuller MasterCard International
+
+ Mark Linehan IBM
+
+ Richad D. Brown Kedemon (ex. Globe SET)
+
+ Werner Hans SIZ
+
+14. Author's Address
+
+ Yoshiaki Kawatsura
+ Hitachi, Ltd.
+ 890 Kashimada Saiwai-ku Kawasaki-shi
+ Kanagawa, 212-8567 Japan
+
+ EMail: kawatura@bisd.hitachi.co.jp
+
+
+
+
+
+Kawatsura Informational [Page 55]
+
+RFC 3538 SET Supplement for IOTP June 2003
+
+
+15. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawatsura Informational [Page 56]
+