RFC 3538
Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP)
RFC 3538 💖 Part 1 of 9
Okay bestie, this one is RFC 3538, the Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP) 🛍️✨. It was written by Y. Kawatsura from Hitachi in June 2003 and sits in the Informational category 🎀. Informational means it's sharing knowledge, not setting a standard. There's no "Obsoletes" or "Updates" line in the header, so it doesn't replace or change any other RFC 🦋. It's published by the Network Working Group, and this part covers the front matter, the Introduction, and the requirements and business model sections.
Status of this Memo
This memo is here to give info to the Internet community 💅. It is not a standard of any kind. Distribution is unlimited, so share it with everyone 🌈.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. 💜
Abstract
This doc gets into the nitty-gritty of the detailed Input/Output parameters for the IOTP Payment Application Programming Interface (API) 🔥. It also explains the Payment Bridge procedures for using SET (Secure Electronic Transaction) as the payment protocol inside Version 1.0 of IOTP 🧚. Basically, it's the blueprint for how these two systems plug together 🍓.
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
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
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......................................561. Introduction 🌸
This section gives you the outline of the whole doc 🗺️.
1.1 Objectives of this Document
This document explains how SET (Secure Electronic Transaction) works inside IOTP (Internet Open Trading Protocol) 💳✨.
1.2 Scope of this specification
1.2.1 The version of IOTP specification
This doc is based on IOTP Version 1.0 [RFC 2801] 📜.
1.2.2 The version of SET specification
This doc is based on SET Version 1.0 [SET] 🎀.
1.2.3 The version of IOTP Architecture document
This doc is based on the IOTP Payment API document Version 1.0 [IOTP Payment API] 🧚.
1.3 Audience
Okay, so this is for readers who already know these docs. Think of it as the reading list you need to finish first 📚💕:
- IOTP Specification Version 1.0 [RFC 2801]
- SET Specification, in particular Book 2:Programmer's Guide and Book3:Formal Protocol Definition,
- External Interface Guide to SET Secure Electronic Transaction
- Internet Open Trading Supplement: Architecture and Payment API [IOTP API]
1.4 Notation
SET Messages and Elements get the prefix "SET" 🏷️. For example:
SET PRes
SET OD
SET SaleDetail1.5 Terminology
This document uses these terms, and you'll see them everywhere 👑:
SET/IOTP The specification described in this document.
SET related message Both SET Messages and SET Initiation Messages2. Requirements & Development Policy 💅
This section covers the requirements and development policies for SET/IOTP 🎯.
The requirements for SET/IOTP are:
- To be based on SET specifications. Interoperability at the payment level must be maintained. 🫶
- 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. 🙅♀️
- 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 for SET/IOTP is:
- To minimize the number of message round trips 🔁
- To minimize the length of messages 📏
3. Business Models 🛍️
This section explains how the entity models differ between SET and IOTP, what the Trading Roles are in SET/IOTP, and what's in scope for SET/IOTP 🦋.
3.1 Entity models between SET and IOTP
Here's how SET and IOTP entities line up with 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
Here are the trading roles in SET/IOTP, the cast of characters 🎭💖:
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.
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].
ProviderNext up: section 3.3, where we get into the scope of transaction types 💜🌈
3.3. Scope of Transaction Types ✨
okay so here's what we're actually covering in this doc 💖 these are the IOTP transaction types that are supported:
- Brand Independent Baseline Purchase when SET is used for payment 🛍️
- Brand Dependent Baseline Purchase when SET is used for payment 💳
- Cash Advances (Brand Independent and Brand Dependent case) 💸
- Status Inquiry on SET payments 🔍
3.4. Types of transaction not in scope 🙈
and now the stuff that is NOT giving in this doc, so don't go looking for it here 💀 these transactions are NOT covered:
- Credit Reversal Process
- Customer Care Service with Consumer Related SET Certificate Registration
- Customer Care Service with Consumer Related SET Certificate Registration Inquiry
4. Architecture of SET/IOTP 🏗️🧚
the whole architecture, bestie, it's so pretty when you see it laid out 🌈
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 SoftwareFigure 2 SET/IOTP Architecture
so the pieces 👑
- IOTP Application Core (OAC): software that processes IOTP messages. It's the main character of the whole thing ✨
- IOTP Payment Bridge (OPB): the interface between OAC and Existing Payment Software. The SET Bridge is also an interface between OAC and SET Core 🌉
- Existing Payment Software (EPS): existing software that processes payments 💅 The SET Core is the software that supports the mechanisms in the 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 the SET related OPB and EPS 🫶
5. Trading Types of SET/IOTP 🛒
this chapter is the quick tour of the SET/IOTP trading types, so let's go 🚀
5.1. Baseline Purchase 💖
a Baseline Purchase has three steps, in this order:
(1) Offer Step 🎀
the consumer picks goods or services over the Internet (on the web, for instance), 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.
(1-a) Brand Independent Purchase 🦋
in a Brand Independent Purchase, the Merchant sends the TPO Block and Offer Response Block at the same time, right after the consumer decides to buy ⚡ this is the big win because it cuts out one round of messages compared with the Brand Dependent Purchase. Why? The contents of the Offer Response Block (for example, the description on the invoice) don't change based on the selected brand, so there's no reason to ask twice 🙌
(1-b) Brand Dependent Purchase 🌸
Brand Dependent Purchase is used when the contents of the Offer Response Block depend on the selected Payment Brand. With this method, currency selection and discounts based on payment method can be implemented 💜
(2) Payment Step 💳
the Consumer confirms the order and then pays for it with a SET Transaction. The SET Transaction messages get wrapped up (encapsulated) inside IOTP Messages 🎁
(3) Delivery Step 📦
once the Payment is done, the Consumer gets the goods or services, either online or physically delivered ✨
5.2. Cash Advances 💸
Cash Advances can happen through a Value Exchange Transaction in IOTP. Baseline IOTP supports a first Payment by SET and a second Payment by some other payment mechanism 🤝 The Cash Advance comes in two types: Brand Independent and Brand Dependent Cases.
5.3. Status Inquiry 🔍
a Consumer can send a SET Payment Inquiry in IOTP, and the SET Message gets encapsulated in an IOTP Message 🫶
6. General Flow of SET/IOTP 🌊
this chapter shows the general SET/IOTP message flows, aka the choreography 💃
6.1. Baseline Purchase 🎀
Baseline purchases come in two types, Brand Independent Purchase and Brand Dependent Purchase, and each one has its own chart below 📊
6.1.1. Brand Independent Baseline Purchase 🦋
here's how a Brand Independent Purchase flows 👀
(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)
(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)
(3) Merchant Side 🏪
OAC SET Bridge
|--------------->|
|FindAccepted |
| PaymentBrand |
|<---------------|
| Response |
|--------------->|
|FindAccepted |
| PaymentProtocol|
|<---------------|
| Response |
|--------------->|
|GetPaymentInit- |
| lizationData |
TPO & Offer Resp Msg. |<---------------|
<------------------------| Response |
To ConsumerFigure 5 Merchant Side flow for Brand Independent
(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
6.1.2 Brand Dependent Baseline Purchase 💖
okay so, a Brand Dependent Purchase has its own flow, and it's giving very organized 🎀 Here's how it goes:
(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 one is the same as Brand Independent, so no new drama here.
(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 ConsumerFigure 8 Merchant Side flow for Brand Dependent (1)
(4) Payment Handler Side 🧚
Same deal again: this flow is the same as Brand Independent.
6.2 Cash Advances 💸
ngl this one is short and sweet. IOTP Cash Advances can be done with a credit card using an IOTP Value Exchange Transaction. The cool part is that a Cash Advance can have a first Payment made through a SET Transaction and a second Payment made through some other payment mechanism, and Baseline IOTP supports that combo ✨ The general flow is omitted, so we're skipping the diagram.
6.3 Status Inquiry 🔍
Okay, Status Inquiry is where we check on a payment and get the update, and here's the flow:
(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
7. IOTP Payment APIs 🎀
This section is basically a cheat sheet of how SET/IOTP talks to the API calls, as laid out in [IOTP Payment API] 📋
Every parameter gets written up like this:
Parameter name : Mandatory (M) or Optional (O) : DescriptionIf you want the full scoop on the IOTP Payment APIs, go read [IOTP Payment API]. A "-" in the Description means "same as the description in the [IOTP Payment API]" 💅
Heads up: some fields are marked "#IMPLIED" in [IOTP Payment API]. But if SET/IOTP actually needs one of those fields, this document marks its Status as Mandatory, (M). So the Status column is about SET/IOTP, not the API doc 🙈
7.1 Brand Compilation Related API Calls 🧩
7.1.1 Find Accepted Payment Brand 🏷️
This API gets the payment scheme specific packaged data needed to generate the Brand Component. In this version of SET/IOTP, this API must be called before the Find Accepted Payment Protocol function. Lowkey the order matters here ✨
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.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.
Content7.1.2 Find Accepted Payment Protocol 🔐
This API receives the payment scheme specific packaged data that gets used to generate the PayProtocol Component. It's giving layers 💅
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.
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 grabs the packaged content inside the Payment Component. Think of it as opening the gift box 🎁
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 : -
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.
PackagedContentOutput 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 🙅♀️
Not used in the current version of SET/IOTP, so we can skip this one ✌️
7.1.5 Authenticate 🙅♀️
Also not used in the current version of SET/IOTP. Next!
7.1.6 Check Authentication Response 🙅♀️
Same story, not used in the current version of SET/IOTP.
7.2 Brand Selection Related API Calls 🌈
7.2.1 Find Payment Instrument ✨
Okay so this one is the API that finds the Payment Instruments the Payment Handler can accept on behalf of the Merchant. Main character energy 💅
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 : -7.2.2 Check Payment Possibility 🎀
So if the SET Bridge gets this API Message, it sends back three packaged content fields. Iconic behaviour, honestly 🫶
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.
Content7.3 Payment Transaction Related API Calls 💖
7.3.1 Start Payment Consumer 🦋
In SET/IOTP, this API is how the Consumer's SET Bridge handles the 1st SET Initiation and any SET messages after that. Lowkey the star of the show ⭐
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.
Content7.3.2 Start Payment Payment Handler 🌸
This API starts a payment on the Payment Handler's side. The SET Related Module does the payment initialization, then processes the SET Message it received and sends back the right one (like the 2nd SET Initiation or the SET PinitRes message). Plot twist, it's a whole process 😭
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
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 restarts a payment transaction that got suspended for some reason, like a time out. The last SET Message tied to that suspended transaction comes back as the Response. Rescue mission, but make it cute 💜
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.
Content7.3.4 Continue Process 🔥
This API passes a SET related message, which came from the counter party, over to the SET Bridge, and then accepts the next SET message as a response. It works on both sides, so let's go through each one 👑
(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.
Content7.3.5. Change Process State 🌈
The OAC uses this API to change the Process State of the OPB. For example, it's used to change the Payment Status after a SET Payment Transaction is completed. It also gets used when an error or a suspend happens. Serving range of organisation, no cap 💅
(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 isn't used in the current version of SET/IOTP. Not me skipping straight past it 🙈
7.4.2 Inquire Pending Payment 🦋
This API checks whether the payment Bridge or its wallet is being used right now, or not. Vibe check ✨
Input Parameters
----------------
WalletID : O : -
Output Parameters
-----------------
PayId : M : -7.4.3 Remove Payment Log 🫶
This API is used by both the Consumer and the Payment Handler. Teamwork makes the dream work 💖
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 checks a Payment Receipt. The catch is that the current SET specification doesn't support Receipts, so SET/IOTP sends its own visual information of a Receipt to the SET Bridge instead. Workaround energy, and honestly iconic 👑
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 ✨
okay so this API takes IOTP Payment Receipt Component packaged data and expands it into something you can actually display or print 🖨️💖 Here are the parameters:
Input Parameters
PayId : M : -
WalletId : O : -
PassPhrase : O : -
PackagedContent : M : See section 8.5.2.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 one checks the payment status. For example, when the OAC gets a Continue Payment Response API and the ContStatus is set to "End", it uses this API. It can be used at anytime 💅
(1) Consumer Payment Bridge
Input Parameters
PayId : M : Set ConsumerPayId
WalletId : O : -
PassPhrase : O : -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 call hands back the SET InqReq Message so you can 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.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 gets a SET InqReq message in an InquirePaymentDetail API. The SET Core processes it and creates a SET InqRes message, and the response wraps that SET InqRes message up 🎁
Input Parameters
PaymentHandlerPayId: M : -
WalletID : O : -
PassPhrase : O : -
PaySchemePackaged : M : See section 8.6.
ContentOutput Parameters
PaymentHandlerPayId: M : -
ProcessState : M : -
CompletionCode : O : -
xml:lang : O : -
StatusDesc : O : -
PaySchamePackaged : M : See section 8.6.
Content8. SET dependent Process ✨
this chapter covers the core concepts you need for developing SET/IOTP 🌸
8.1 Relationships between them for IOTP Purchase/Cash Advances 💜
this document describes SET Initiation Messages based on the [SET EIG]. The Merchant sends the 1st SET Initiation Message to the Consumer to kick off a SET payment transaction. After that, the other SET Initiation Messages (JPO, etc.) and the SET payment Transaction (SET PinitReq message, etc.) get exchanged between the Consumer and the Payment Handler 🦋
+------------+ +----------+
| | | |
| |<----------------| Merchant |
| | 1st SET InitMsg | |
| | +----------+
| Consumer | +----------+
| | | |
| |<--------------->| P.H. |
| | Other SET Init/ | |
+------------+ SET Message +----------+
Figure 11 Relationship between IOTP Messages and SET Messageswhen the Merchant sends any data (e.g., SET SaleDetail) other than SET Related messages (e.g., SET PinitRes message), there are two different ways to do it:
- (a) The Merchant sends the data via the Consumer.
- (b) The Merchant sends the data out-of-band.
in case (a), the Merchant wraps the data inside TradingRoleData.PackagedContent, which lives in the Offer Response Block sent to the Consumer. The data gets copied into the Payment Request Block and sent to the Payment Handler. This case assumes 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 a registered identification for IANA. Right now, these BrandIds are registered:
Amex, Dankort, JCB, Maestro, MasterCard, MICOS, VISA, atCredits, EZpay, GeldKarte, Mondex, paybox
8.2.2 Definition of ProtocolBrandId ✨
ProtocolBrandID is defined like this:
<Premise> SET BrandID is defined as brand[:Product]. ([] is indicated as optional.) In SET, the brandID is a brand name that matches the brand of the payment card. The Product is a product name too, defined as the type of product within that brand, like Gold Card.
Set IOTP ProtocolBrandId like this:
brand:Product:PCNHere's the breakdown:
- The brand above is the same as the sub data of SET BrandID, as Brand Name (brand), defined in SET.
- Product above is the same as the sub data of SET BrandID, as Product Name (Product), defined in SET.
- PCN above is the Promotional Card Name, and it's written in the SET Certificates.
Example:
Visa:Gold:WalMartSince 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 be omitted if necessary. The details of these definitions are as 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: VISAInvalid Examples:
VISA:Gold:
VISA::
VISA:
ProtocolBrandId which there is no brand.8.2.3 Definition of ProtocolId 🌈
ProtocolId is defined like this:
ProtocolId := SETName + Version
SETName := "SET"
Version := "v" + version + "." + revisionWhere the version is a 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. Here's the map between the BrandIds registered in IANA, ProtocolId, 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 VISAFor BrandIds that aren't listed above, the BrandId registrant (e.g., credit card company) MUST register it so that ProtocolBrandId can map one to one with the pair of BrandId and ProtocolId 👑
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 OptionalFor 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: 515A533033363632594BNote: The contents in ProtoclPackagedContent must be US-ASCII and encoded by BASE64. 🫧
8.3.2 FindPaymentInstrument Function ✨
okay bestie, this one is all about finding the payment instruments that belong to a BrandId and ProtocolBrandId 💖
(1) Information of PayInstrument
It 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, and they're giving different vibes 💅
Brand as Primary Brand: The Primary Brand is the Brand that's defined as brand in SET, like VISA, MasterCard, or Nicos. Iconic 👑
Brand as Dual Brand or Promotional Brand: A Dual Brand is a payment instrument that has two Brands, like UC-VISA (UC Card and VISA Card). This style is super popular in Japan 🌸
A Promotional Brand means that if the Consumer pays with that Brand, they get some extra perk, like a discount or frequent flyer points ✈️
- ProtocolBrandId as a Primary Brand 🧚
Example: MasterCard, MasterCard::UC, MasterCard:Gold: and MasterCard::WalMart are all MasterCard Brands.
- ProtocolBrandId as a Dual Brand or a Promotional Brand 🦋
Example: MasterCard::UC is the Dual Brand of "MasterCard" and "UC". SET:MasterCard::WalMart is the Promotional Brand of MasterCard-WalMart.
Now here's how the SET Bridge handles it. It gets the ProtocolBrandId from the OAC in the FindPaymentInstrument Function 🫶
(1) If the accepted ProtocolBrandId is XXX:YYY, the SET Related Module searches for ProtocolBrandIds with the string XXX:YYY:* (the * is a wild card). The corresponding PaymentInstrumentIds of all ProtocolBrandIds with the matching Primary Brand (regardless of also being a Dual Brand or Promotional Brand) get returned to the OAC, so the Consumer can select from them 🌈
(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 get returned to the OAC, so the Consumer can select from them 💜
Example:
Assume the ProtocolBrandIds correspond to the PaymentInstrumentIds in the SET Bridge like this 🍓
ProtocolBrandId PaymentInstrumentId
------------------------------------------
MasterCard 1
MasterCard::UC 2
MasterCard::WallMart 3
VISA::UC 4If the SET Bridge receives the ProtocolBrandId "MasterCard" in the FindPaymentInstrument Function, it will return "1", "2", and "3". But if it receives the ProtocolBrandId "MasterCard::UC" from the OAC, the SET Bridge will return only "2" 😭
8.3.3 GetPaymentInitializationData Function ✨
(1) Create TradingRolePackagedContent
If necessary, the SET Related Module generates a TradingRolePackagedContent that corresponds to the received ReceiverOrgID 💅 The ContentData of the TradingRolePackagedContent is the information 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 🤝
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, so the SET Related Module doesn't need to create one, then 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
Okay so SET Initiation Message Fields and IOTP Elements have a lot of similar items, so IOTP elements can be used for the corresponding SET Initiation Fields 💖 The other SET Initiation Fields, except URL information (more on that below), are encapsulated in the PayProtocolPackagedContent 📦
This document does not specify how the SET Related Module implements the 1st SET Initiation Process. Not our problem here 🙈
The following table shows the list of SET Initiation Fields that correspond 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.(b) SET-Version:
SET-Version can correspond to ProtocolId. The version number appears after the "v" for the SET-Version 🔥
ProtocolId -> _______
SETv1.0
~~~<- SET-VersionFigure 12 ProtocolId vs SET-Version
(c) SET-Brand:
SET-Brand can correspond to ProtocolBrandId 🎀
(d) SET-PurchAmt:
It's necessary to adjust the format of the Amount between IOTP and SET, since IOTP and SET use different syntax 💅
Assumption:
- In SET/IOTP, the "ISO4217-A" (the currency code represented by three letters, such as "USD") is mandatory.
- The Consumer Side SET Related Module should have a mapping table between "ISO4217-A" and "ISO4217-N" (the currency code represented by three digits, such as "840").
(d) -1 Content of the SET-PurchAmt
The content of the SET-PurchAmt is as follows:
SET PurchAmt: currency amount amtExp10For 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 consists of the following: Amount, CurrCodeType and CurrCode. For a description of each, see [RFC 2801]. For example, $129.50 is represented like this 💖
CurrCodeType="ISO4217-A"
CurrCode="USD"
Amount="129.50"(d) -3 Example of how-to-translate
The one-to-one mapping between the IOTP format and the SET format is super simple 🧚 This example sequence uses the IOTP amount element above.
- Translate from IOTP CurrCode (ISO4217-A) to SET currency (ISO-4217-N). For example, if CurrCode="USD", then the value of currency is "840".
- Calculate how many decimal places are represented in the Amount. For example, if Amount="129.50", there are "2" decimal places.
[The number of decimal places] *( -1)corresponds to the SET amtExp10. In the above case, SET amtExp10 = 2 * (-1) = -2.10^[The number of the Amount's decimal places] * Amountcorresponds to the SET amount. In the above example, SET amount = 10^2 * 129.50 = 12950.- Concatenate the three integers and use white spaces as a delimiter.
So in the above case, the SET PurchAmt is represented as "840 12950 -2" 🎉
(e) SET OD (Order Description) vs. IOTP Order Information
In IOTP, the OAC handles the Order Information, for things like display use, the same way SET uses the Order Information. The Payment Handler doesn't know the actual Order Information, because the Merchant and Payment Handler may exist in separate domains 🏠 However, the Payment Handler needs to get the SET OD from the Merchant, either via the Consumer or directly, because it needs the SET OD to create the 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 🔒 So SET/IOTP defines SET OD as the hash of the IOTP Order Information. The hash algorithm must be SHA1.
But the Order Component may include two or more Packaged Contents (see [RFC 2801]). So SET/IOTP specifies to create the hash like this 🫠
(e) -1. If the Name attribute does not have the Name attribute, such that the Order Component has only one Packaged Content, hash the Contents Data using SHA1 simply and encode it with BASE64.
(e) -2. Otherwise, such that there exists the Name attribute, sort the Packaged Contents in the UTF-16 character code order of the Name attribute, hash the Content Data using SHA1, and concatenate them in proper sequence. Then hash it using SHA1 again and encode it with BASE64 ✨
NOTE: To avoid different character encodings between applications, in this document, SET OD MUST be constructed from the ContentData in OrderPackagedContent as follows:
- Convert it to network byte ordered Unicode encoding data.
- Hash (1) using SHA1.
- Convert (2) to BASE64 US-ASCII data.
Therefore, "Content-Type" and "charset" MUST be "text/plain" and "us-ascii" respectively when the SET Initiation message is constructed 💜
(f) SET-***-URL vs. IOTP Net Location
In IOTP, the OAC handles location data, so the OAC doesn't need to pass net location data on to the OPB 🗺️ However, some vendor-implemented consumer SET/IOTP wallets may need the URL information to process the SET Initiation. So if necessary, the Consumer's SET Related Module must set the appropriate URL data in SET-***-URL 💖
(2) Create the next SET related message
The SET Related Module generates the next SET related message (a SET PInitReq or a SET Initiation Response) to be sent to the Payment Handler 📤
(3) Error check of the next SET related message.
If the SET related message created in (2) is a SET Initiation Response and includes any error, the SET Related Module creates an ErrorResponse message with the ErrorCode set to "EncapProtErr" and the Severity set to "HardError", and sends it to the OAC 🚨
(4) Create PaySchemePackagedContent
These are the parameters of the 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
The SET Bridge should store the following in the DataBase 🗄️
ConsumerPayIdPaySchemePackagedContentContStatusContentSoftwareId(corresponding to the PaySchemePackagedContent)ProcessState
8.4.2 StartPaymentPaymentHandler Function ✨
(1) Process for TradingRoleData 🎀
Okay bestie, the SET Bridge must processes appropriately 💅 For example, it can pass things to the SET Core whenever a TradingRolePackagedContent shows up as the input Parameter.
(2) SET Specific Process 🌸
The SET Related Module processes either the SET Initiation Response or the SET Transaction (SET PInitReq). It also generates a message (the next SET Initiation Message or SET PInitRes) that matches the results of what it just processed. That message gets sent to the Consumer 💖
(3) Error check of the next SET related message. 🚨
If the SET related message created in (2) has any error, the SET Related Module makes an ErrorResponse message with ErrorCode set to EncapProtErr and Severity set to HardError, then sends it to the OAC 😭
(4) Generate PaySchemePackagedContent 🧚
The PaySchemePackagedContent wraps the SET Initiation Message or SET PInitRes inside ContentData, and that's how you generate it. As output, the parameters look like this:
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 input parameters of PaySchemePackagedContent look like this:
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"The SET Related Module processes the SET Related Message inside the PaySchemePackagedContent. Then it creates a SET Related Message that corresponds to the processed one, if that's needed 🫶
(2) SET Related Message Error Check 🔍
If the SET related message created in (2) has any error, the SET Related Module makes an ErrorResponse message with ErrorCode set to EncapProtErr and Severity set to HardError, then sends it to the OAC 😭
(3) Create PaySchemePackagedContent 🎀
These are the parameters 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).
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 that came in from the Payment Handler is a SET PRes message, this data doesn't get 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, those values might get altered when the IOTP message is copied over to the SET message. So the Payment Handler needs to check the Elements in the IOTP components (Payment, etc.) against the Elements in the SET message and make sure they match. The IOTP Brand that the Merchant specified should correspond to the Brand used in the SET payment 🔥
The Brand Integrity check goes like this:
(a) After receiving the SET PReq message, check the Consumer selected Brand information (e.g., ProtocolBrandId) in the IOTP Payment Request against the 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").
Also, 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 🌈
Wrap the SET related Message (SET Initiation Message or SET Transaction Message) into the Content Data of PaySchemePackagedContent, then send it to the Sender. The output parameters of PaySchemePackagedContent look like this:
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 the SET related message created in (2) has any error, the SET Related Module makes an ErrorResponse message with ErrorCode set to EncapProtErr and Severity set to HardError, then sends it to the OAC 😭
If the SET related message created in (2) is a SET PRes message, and its message includes anything 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",
the SET Related Module makes an ErrorResponse message with ErrorCode set to "BusinessError"and and Severity set to HardError, then sends it to the OAC 💀
(4) Create PaySchemePackagedContent 🎀
These are the parameters 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". That's the finish line 🏁
8.4.5 InquireProcessState Function 🫧
(1) Setting ProcessState 💖
The values for the ProcessState are described in section 8.9.2.
(2) Setting CompletionCode 🔥
Set this to "Unspecified" when a SET Business Failure has happened, and set StatusDesc to the value that corresponds to AuthCode or CapCode.
(3) Setting StatusDesc 🙈
The values for PayStatusDesc aren't specified in the SET/IOTP.
(4) Create PayReceiptNameRefs 🧾
Set this to "PRes" in the PayReceiptNameRefs.
8.5 Payment Receipt 🧾
8.5.1 CheckPayReceipt Function 🌸
The SET Related Module doesn't check the Payment Receipt Information in any special way. As long as the request message is valid, it just sends back the general response message ✨
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.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.(2) Get the current status information 📚
The SET Related Module pulls the following elements out of the Data Base, using ConsumerPayId and PaymentHandlerPayId as keys:
BrandIdProtocolBrandIdPayInstrumentIdAmountCurrCodeTypeCurrCodePayDirection
(3) Get the SET Data 🧚
The SET Related Module gets the following data out of the SET PRes message, which is taken as the Request Message 💅
(a) The Date field in the MessageWrapper is slightly different between SET and IOTP. Here's what's different:
- There is no TimeZone in the Date field of SET.
- Second and Milli-second can be omitted in the Date field of SET.
So the SET Related Module needs to compensate for the Date information when the 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 isn't supported (i.e., it's omitted). SET Inquiry Messages are embedded in the PaySchemeData element inside IOTP Inquiry Messages 💜
The parameters of PaySchemePackagedContent in StartPaymentInquiryResponse 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 InqReq message which is encoded by BASE64.The parameters of PaySchemePackagedContent in InqurePaymentStatus 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 InqReq message which is encoded by BASE64.The parameters of PaySchemePackagedContent in InquirePaymentStatusResponse 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 InqRes message which is encoded by BASE64.The parameter of PaySchemePackagedContent in ContinueProcess is 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 InqRes message which is encoded by BASE64.8.7 Resume Process ⏯️
The parameter of PaySchemePackagedContent in RequmePaymentConsumerResponse is 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, isn't used in SET/IOTP 🙅♀️
8.9 SET Bridge ProcessState 🌟
8.9.1. SET Bridge ProcessState of Consumer 🎀
okay bestie, here's the consumer's state map for the SET Bridge 🗺️✨ every arrow is a transition, and the text under it tells you what triggers it 💅
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)8.9.2. SET Bridge ProcessState of Payment Handler 💜
and now the payment handler's version, which is basically the same energy with a couple of extra twists 🧚
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 🚚💖
okay so SET/IOTP has some opinions about delivery, and honestly they're iconic 👑
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. 📦
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 is a Business Error Code, and it gets set like this 🫶
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 doc recommends setting PercentComplete like so, and it's giving very organised 🦋
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
------------+---------------+------------------+----------------
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 happens in the SET Bridge, the Severity has to be always set to "HardError". no exceptions, bestie 💀
9. Error Handling 🛠️
this chapter is all about how errors get handled, so let's get into it ✨
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.
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:
- Error generated in SET Initiation Message
- 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".
(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 🌸
okay so the SET Related Module checks for the SET Business Error sitting in StatusCode inside the SET PRes message. 👀 When a SET Transaction Error happens, the module builds an ErrorResponse Message 💌 with the SET PRes tucked into PaySchemePackagedContent and ErrorCode set to "BusinessError". That gets sent back to OAC. Then OAC makes the Payment Response Block once it has the SET scheme specific receipt from InquireProcessState/Response, and that block goes to the Consumer 🎀
(2) Process of Consumer 🦋
the SET Related Module runs the exact same process it would if the Consumer were receiving a Payment Response Block. no notes, no changes, same energy 🫶
10. Security Considerations 🔐
okay bestie, this one is serious so listen up 😭 In IOTP, the Merchant and the Payment Handler might live in totally different domains. So if the Merchant passes the payment related information to the Payment Handler through the Consumer, the payment security level may depend on IOTP itself 💀 If you want to avoid that, you will need to check the integrity of that data using out-of-band communication between the Merchant and the Payment Handler. In that case the security level depends on the communication path between them 🔥
11. References 📚
these are the essential background reads, and readers are strongly encouraged to look them up for more info 🤓
[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.
[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 🌈
so IANA doesn't have to do anything here ✨ This document just points at an existing registry, iotp-codes, and at the time this RFC was published, these BrandID's were registered:
Amex, Dankort, JCB, Maestro, MasterCard, MICOS, VISA, atCredits,
EZpay, GeldKarte, Mondex, paybox13. Acknowledgement 💖
the author wants to shout out the contributors to this protocol (listed in alphabetic order of company), because it could not have been developed without them 🫶
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 SIZ14. Author's Address 🧚
Yoshiaki Kawatsura
Hitachi, Ltd.
890 Kashimada Saiwai-ku Kawasaki-shi
Kanagawa, 212-8567 Japan
EMail: kawatura@bisd.hitachi.co.jp15. Full Copyright Statement ⭐
this legal bit stays word-for-word, no edits, because the copyright notice itself isn't ours to remix 🙏
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 💜
📦 where this page comes from
- ietf: rfc3538 2003-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms