"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.
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.
(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 [RFC2801]. For example, $129.50 is represented by the
following:
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 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 [RFC2801]). 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.
(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.
(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.
(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).
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.
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".
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.
(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.
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.
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)
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.
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
------------+---------------+------------------+----------------
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.
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".
(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.
(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.
[RFC2801] Burdett, D., "Internet Open Trading Protocol -
IOTP, Version 1.0", RFC2081, 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
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 RFCthe 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
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 RFCEditor function is currently provided by the
Internet Society.