tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3867

 
 
 

Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP)

Part 2 of 4, p. 12 to 34
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 12 
2.  Message Flow

   The following lists all functions of the IOTP Payment API:

      o  Brand Compilation Related API Functions

   "Find Accepted Payment Brand" identifies the accepted payment brands
   for any indicated currency amount.

   "Find Accepted Payment Protocol" identifies the accepted payment
   protocols for any indicated currency amount (and brand) and returns
   payment scheme specific packaged content for brand selection
   purposes.

   This function might be used in conjunction with the aforementioned
   function or called without any brand identifier.

   "Get Payment Initialization Data" returns additional payment scheme
   specific packaged content for payment processing by the payment
   handler.

   "Inquire Authentication Challenge" returns the payment scheme
   specific authentication challenge value.

   "Check Authentication Response" verifies the returned payment scheme
   specific authentication response value.

   "Change Process State" is used (here only) for abnormal termination.
   (cf. Payment Processing Related API Functions).

      o  Brand Selection Related API Functions

   "Find Payment Instrument" identifies which instances of a payment
   instrument of a particular payment brand are available for use in a
   payment.

   "Check Payment Possibility" checks whether a specific payment
   instrument is able to perform a payment.

Top      Up      ToC       Page 13 
   "Authenticate" forwards any payment scheme specific authentication
   data to the IOTP Payment Bridge for processing.

   "Change Process State" is used (here only) for abnormal termination.
   (cf. Payment Processing Related API Functions).

      o  Payment Processing Related API Functions

   "Start or Resume Payment Consumer/Payment Handler" initiate or resume
   a payment transaction.  There exist specific API functions for the
   two trading roles Consumer and Payment Handler.

   "Continue Process" forwards payment scheme specific data to the
   Existing Payment Software and returns more payment scheme specific
   data for transmission to the counter party.

   "Change Process State" changes the current status of payment
   transactions.  Typically, this call is used for termination or
   suspension without success.

      o  General Inquiry API Functions

   "Remove Payment Log" notifies the IOTP Payment Bridge that a
   particular entry has been removed from the Payment Log of the IOTP
   Application Core.

   "Payment Instrument Inquiry" retrieves the properties of Payment
   Instruments.

   "Inquire Pending Payment" reports any abnormal interrupted payment
   transaction known by the IOTP Payment Bridge.

   Payment Processing Related Inquiry API Functions

   "Check Payment Receipt" checks the consistency and validity of IOTP
   Payment Receipts, received from the Payment Handler or returned by
   "Inquire Process State" API calls.  Typically, this function is
   called by the Consumer during the final processing of payment
   transactions.  Nevertheless, this check might be advantageous both
   for Consumers and Payment Handlers on failure resolution.

   "Expand Payment Receipt" expands the Packaged Content of IOTP Payment
   Receipts as well as payment scheme specific payment receipts into a
   form which can be used for display or printing purposes.

   "Inquire Process State" responds with the payment state and the IOTP
   Payment Receipt Component.  Normally, this function is called by the
   Payment Handler for final processing of the payment transaction.

Top      Up      ToC       Page 14 
   "Start Payment Inquiry" prepares the remote inquiry of the payment
   transaction status and responds with payment scheme specific data
   that might be needed by the Payment Handler for the Consumer
   initiated inquiry processing.

   "Inquire Payment Status" is called by the Payment Handler on Consumer
   initiated inquiry requests.  This function returns the payment scheme
   specific content of the Inquiry Response Block.

   "Continue Process" and "Change Process State" (cf. Payment Processing
   Related API Calls)

      o  Other API Functions

   "Manage Payment Software" enables the immediate activation of the
   Existing Payment Software.  Further user input is under control of
   the Existing Payment Software.

   "Call Back" provides a general interface for the visualization of
   transaction progress by the IOTP Application Core.

   The following table shows which API functions must (+), should (#),
   or might (?) be implemented by which Trading Roles.

   API function                  Consumer  Payment Handler  Merchant
   ------------                  --------  ---------------  --------

   Find Accepted Payment Brand                                 +
   Find Accepted Payment Protocol                              #
   Find Payment Instrument          +

   Get Payment Initialization Data                             +
   Check Payment Possibility        +

   Start Payment Consumer           +
   Start Payment Payment Handler                  +
   Resume Payment Consumer          #
   Resume Payment Payment Handler                 #

   Continue Process                 +             +
   Inquire Process State            +             +            ?
   Change Process State             +             +            ?
   Check Payment Receipt            +             ?
   Expand Payment Receipt           #             ?

   Remove Payment Log               ?             ?            ?

   Inquire Authentication Challenge                            ?

Top      Up      ToC       Page 15 
   Authenticate                     +
   Check Authentication Response                               ?

   Payment Instrument Inquiry       ?
   Inquire Pending Payment          #             #
   Start Payment Inquiry            ?
   Inquire Payment Status                         ?

   Manage Payment Software          #             ?            ?

   Call Back                        #

        Table 1: Requirements on API Functions by the Trading Roles

   The next sections sketch the relationships and the dependencies
   between the API functions.  They provide the informal description of
   the progress alternatives and depict the communication and
   synchronization between the general IOTP Application Core and the
   payment scheme specific modules.

2.1.  Authentication Documentation Exchange

   This section describes how the functions in this document are used
   together to process authentication.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Authenticator   Inquire Authentication Challenge(Alg1*)   -> IPB
                   Inq. Auth. Challenge Response(Alg1,Ch1)   <- IPB
                   . . .
                   Inquire Authentication Challenge(Algn*)   -> IPB
                   Inq. Auth. Challenge Response(Algn,Chn)   <- IPB
                   Create and transmit Authentication Request Block
   Authenticatee   Authenticate(Alg1, Ch1)                   -> IPB
                   AuthenticateResponse(...)                 <- IPB
                   . . .
                   Authenticate(Algm, Chm)                   -> IPB
                   AuthenticateResponse(Res)                 <- IPB
                   Create and transmit Authentication Response Block
   Authenticator   Check Authentication Response(Algm,Chm,Res)->IPB
                   Check Auth. Response()                     <-IPB
                   Create and transmit Authentication Status Block
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

                  Figure 2. Authentication Message Flows

Top      Up      ToC       Page 16 
   1. (Authenticator Process) None, one or multiple IOTP Payment Bridges
      (IPB) are requested for one or multiple authentication challenge
      values ("Inquire Authentication Challenge").  Each value is
      encapsulated in an IOTP Authentication Request Component.  In
      addition, the IOTP Application Core may add payment scheme
      independent authentication methods.  All of them form the final
      IOTP Authentication Request Block, which describes the set of
      authentication methods being supported by the authenticator and
      from which the Authenticatee has to choose one method.

      Note that the interface of the API function is limited to the
      response of exactly one algorithm per call.  If the IOTP
      Application Core provides a choice of algorithms for input, this
      choice should be reduced successively by the returned algorithm
      ({Alg(i+1)*} is subset of {Algi*}).

      During the registration of new Payment Instruments, the IOTP
      Payment Bridge notifies the IOTP Application Core about the
      supported authentication algorithms.

   2. On the presence of an IOTP Authentication Block within the
      received IOTP message, the Authenticatee's IOTP Application Core
      checks whether the IOTP transaction type in the current phase
      actually supports the authentication process.

      For each provided Authentication Request Component, the IOTP
      Application Core analyzes the algorithms' names, the transaction
      context, and optionally user preferences in order to determine the
      system components which are capable to process the authentication
      request items.  Such system components might be the IOTP
      Application Core itself or any of the registered IOTP Payment
      Bridges.

      Subsequently, the IOTP Application Core requests the responses to
      the supplied challenges from the determined system components in
      any order.  The authentication trials stop with the first
      successful response, which is included in the IOTP Authentication
      Response Block.

      Alternatively, the IOTP Application might ask for a user
      selection.  This might be appropriate, if two or more
      authentication algorithms are received that require explicit user
      interaction, like PIN or chip card insertion.

      The Authenticatee's organizational data is requested by an IOTP
      Authentication Request Block without any content element.  On
      failure, the authentication (sequence) might be retried, or the
      whole transaction might be suspended or cancelled.

Top      Up      ToC       Page 17 
   3. (Authenticator Process) The IOTP Application Core checks the
      presence of the IOTP Authentication Response Component in the
      Authentication Response Block and forwards its content to the
      generator of the associated authentication challenge for
      verification ("Check Authentication Response").

      On sole organizational data request, its presence is checked.

      Any verification must succeed in order to proceed with the
      transaction.

2.2.  Brand Compilation

   The following shows how the API functions are used together so that
   the Merchant can (1) compile the Brand List Component, (2) generate
   the Payment Component, and (3) adjust the Order Component with
   payment scheme specific packaged content.

Top      Up      ToC       Page 18 
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Merchant      For each registered IOTP Payment Bridge
                 |  Find Accepted Payment Brand()             -> IPB
                 |  Find Accepted Payment Brand Response (B*) <- IPB
                 |  Find Accepted Payment Protocol(B1)        -> IPB
                 |  Find Accepted Payment Protocol Res.(P1*)  <- IPB
                 |  . . .
                 |  Find Accepted Payment Protocol(Bn)        -> IPB
                 |  Find Accepted Payment Protocol Res.(Pn*)  <- IPB
                 Create one Brand List Component, ideally sharing
                   common Brand, Protocol Amount, Currency Amount,
                   and Pay Protocol Elements
                 Create Trading Protocol Options Block
                 On brand independent transactions
                 |  Create Brand Selection Component, implicitly
                 |  Get Payment Initialization Data(B1,P1)   -> IPB
                 |  Get Payment Initialization Data Res.()   <- IPB
                 |  Optionally
                 |  |  Inquire Process State()               -> IPB
                 |  |  Inquire Process State Response(State) <- IPB
                 |  Create Offer Response Block
                 Transmit newly created Block(s)
   Consumer      Consumer selects Brand (Bi)/Currency/Protocol (Pj)
                   from those that will work and generates Brand
                   Selection Component - at least logically
                 On brand dependent transaction
                 |  Transmit Brand Selection Component
   Merchant      On brand dependent transaction
                 |  Get Payment Initialization Data(Bi,Pj)   -> IPB
                 |  Get Payment Initialization Data Res.()   <- IPB
                 |  Optionally
                 |  |  Inquire Process State()               -> IPB
                 |  |  Inquire Process State Response(State) <- IPB
                 |  Create Offer Response Block
                 |  Transmit newly created Block
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

                 Figure 3. Brand Compilation Message Flows

   1.  The Merchant's commerce server controls the shopping dialog with
       its own mechanisms until the Consumer checks out the shopping
       cart and indicates the payment intention.  The notion shopping
       subsumes any non-IOTP based visit of the Merchant Trading Role's
       (which subsumes Financial Institutes) web site in order to
       negotiate the content of the IOTP Order Component.  The
       subsequent processing switches to the IOTP based form by the
       activation of the Merchant's IOTP aware application.

Top      Up      ToC       Page 19 
   2.  The IOTP Application Core inquires for the IOTP level trading
       parameters (Consumer's shopping identifier, payment direction,
       initial currency amounts, discount rates, Merchant's and Delivery
       Handler's Net Locations, Non-Payment Handler's Organizational
       Data, initial order information, ....).

   3.  The registered IOTP Payment Bridges are inquired by the IOTP
       Application Core about the accepted payment brands ("Find
       Accepted Payment Brand").  Their responses provide most of the
       attribute values for the compilation of the Brand List
       Component's Brand Elements.  The IOTP Application Core might
       optionally match the returned payment brands with Merchant's
       general preferences.

       The IOTP Application Core must provide any wallet identifiers, if
       they are required by the IOTP Payment Bridges which signal their
       need by specific error codes (see below).  Any signaled error
       that could not be immediately solved by the IOTP Application Core
       should be logged - this applies also to the subsequent API calls
       of this section.  In this case, the IOTP Application Core creates
       an IOTP Error Block (hard error), transmits it to the Consumer,
       and terminates the current transaction.

   4.  The IOTP Application Core interrogates the IOTP Payment Bridges
       for each accepted payment brand about the supported payment
       protocols ("Find Accepted Payment Protocol").  These responses
       provide the remaining attribute values of the Brand Elements as
       well as all attribute values for the compilation of the Brand
       List Component's Protocol Amount and Pay Protocol Elements.

       Furthermore, the organisational data about the Payment Handler is
       returned.  The IOTP Application Core might optionally match the
       returned payment brands with Merchant's general preferences.

       Alternatively, the IOTP Application Core might skip the calls of
       "Find Accepted Payment Brands" (cf. Step 3) and issue the "Find
       Accepted Payment Protocol" call without any Brand given on the
       input parameter list.  In this case, the IOTP Payment Bridge
       responds to the latter call with the whole set of payment schemes
       supported w.r.t. the other input parameters.

   5.  The steps 3 and 4 are repeated during IOTP Value Exchange
       transactions - these steps are omitted in the previous figure.

   6.  The IOTP Application Core compiles the Brand List Component(s)
       and the IOTP Trading Protocol Options Block.  It is recommended
       that the "equal" items returned by IOTP Payment Bridge function
       calls are shared due to the extensive linking capabilities within

Top      Up      ToC       Page 20 
       the Brand List Component.  However, the compilation must consider
       several aspects in order to prevent conflicts - sharing detection
       might be textual matching (after normalization):

      o  Packaged Content Elements contained in the Brand List Component
         (and subsequently generated Payment and Order Components) might
         be payment scheme specific and might depend on each other.

      o  Currently, IOTP lacks precise rules for the content of the
         Packaged Content Element.  Therefore, transaction / brand /
         protocol / currency amount (in)dependent data might share the
         same Packaged Content Element or might spread across multiple
         Packaged Content Elements.

      o  The Consumer's IOTP Application Core transparently passes the
         Packaged Content Elements to the IOTP Payment Bridges which
         might not be able to handle payment scheme data of other
         payment schemes, accurately.

       The rules and mechanisms of how this could be accomplished are
       out of the scope of this document.  Furthermore, this document
       does not define any further restriction to the IOTP
       specification.

   7.  The IOTP Application Core determines whether the IOTP message can
       be enriched with an Offer Response Block.  This is valid under
       the following conditions:

      o  All payment alternatives share the attribute values and
         Packaged Content Elements of the subsequently generated IOTP
         Payment and Order Components.

      o  The subsequently generated data does not depend on any IOTP
         BrandSelInfo Elements that might be reported by the consumer
         within the TPO Selection Block in the brand dependent variant.

       If both conditions are fulfilled, the IOTP Application Core might
       request the remaining payment scheme specific payment
       initialization data from the IOTP Payment Bridge ("Get Payment
       Initialization Data") and compile the IOTP Offer Response Block.

       Optionally, the IOTP Application Core might request the current
       process state from the IOTP Payment Bridge and add the inferred
       order status to the IOTP Offer Response Block.  Alternatively,
       IOTP Application might determine the order status on its own.

       As in step 6, the rules and mechanisms of how this could be
       accomplished are out of the scope of this document.

Top      Up      ToC       Page 21 
   8.  The IOTP Application Core compiles the IOTP TPO Message including
       all compiled IOTP Blocks and transmits the message to the
       Consumer.  The IOTP Application Core terminates if an IOTP Offer
       Response Block has been created.

   9.  The Consumer performs the Brand Selection Steps (cf. Section 2.3)
       and responds with a TPO Selection Block if no IOTP Offer Response
       Block has been received.  Otherwise, the following step is
       skipped.

   10. On brand dependent transactions, the IOTP Application Core
       requests the remaining payment scheme specific payment
       initialization data from the IOTP Payment Bridge ("Get Payment
       Initialization Data"), compiles the IOTP Offer Response Block,
       transmits it to the Consumer, and terminates.  Like Step 7, the
       IOTP Application Core might access the current process state of
       the IOTP Payment Bridge for the compilation of the order status.

   Any error during this process raises an IOTP Error Block.

2.3.  Brand Selection

   This section describes the steps that happen mainly after the
   Merchant's Brand Compilation (in a brand independent transaction).
   However, these steps might partially interlace the previous process
   (in a brand dependent transaction).

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Merchant      Merchant generates Brand List(s) containing
                   Brands, Payment Protocols and Currency Amounts
                 On brand independent transactions
                 |  Merchant generates Offer Response Block
   Consumer      Compile set(s) of Brands B/Protocols P
                 for each set
                 |  Find Payment Instrument(B, P, C)        -> IPB
                 |  Find Payment Instrument Response (PI*)    <- IPB
                 Consumer selects Brand/Currency/Payment Instrument
                   from those that will work and generates Brand
                   Selection Component
                 For the Selection
                 |  Get Payment Initialization Data(B,C,PI,P) -> IPB
                 |  Get Payment Initialization Data Response()<- IPB
                 On brand dependent transaction
                 |  Generate and transmit TPO Selection Block
   Merchant      On brand dependent transaction
                 |  Merchant checks Brand Selection and generates
                 |  and transmits Offer Response Block
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

Top      Up      ToC       Page 22 
                  Figure 4. Brand Selection Message Flows

   1. The Merchant's commerce server controls the shopping dialog with
      its own mechanisms until the Consumer checks out the shopping cart
      and indicates his payment intention.  The subsequent processing
      switches to the IOTP based form by the activation of the
      Merchant's IOTP aware application.

   2. The IOTP Application Core compiles the IOTP Trading Protocol
      Options Block which contains the IOTP Brand List Component(s)
      enumerating Merchant's accepted payment brands and payment
      protocols and initiates the Brand Selection process.

   3. This first IOTP message activates the Consumer's IOTP aware
      application, e.g., the Web browser invokes a helper application
      (e.g., Java applet or external application).  Its IOTP Application
      Core

      o  infers the accepted payment brands, payment protocols, payment
         direction, currencies, payment amounts, any descriptions etc.,
         and their relationships from the IOTP message,

      o  determines the registered IOTP Payment Bridges,

      o  compiles one or multiple sets of brand and protocol such that
         the join of all sets describes exactly the payment alternatives
         being offered by the Merchant.

      o  inquires payment (protocol) support and the known payment
         instruments from each registered IOTP Payment Bridge for each
         compiled set ("Find Payment Instrument").  However, some IOTP
         Payment Bridges may refuse payment instrument distinction.

      The payment protocol support may differ between payment
      instruments if the IOTP Payment Bridge supports payment instrument
      distinction.

      These API calls are used to infer the payment alternatives at the
      startup of any payment transaction (without user unfriendly
      explicit user interaction).

      The IOTP Application Core must provide wallet identifiers, if they
      are requested by the IOTP Payment Bridges which signal their need
      by specific error codes (see below).

      It is recommended that the IOTP Application Core manages wallet
      identifiers.  But for security reasons, it should store pass
      phrases in plain text only in runtime memory.  Developers of IOTP

Top      Up      ToC       Page 23 
      Payment Bridges and payment software modules should provide a thin
      and fast implementation - without lengthy initialization processes
      - for this initial inquiry step.

   4. The IOTP Application Core verifies the Consumer's payment
      capabilities with the Merchant's accepted payment brands and
      currencies,

      o  displays the valid payment instruments and payment instrument
         independent payment brands (brand and protocol) together with
         their purchase parameters (payment direction, currency,
         amount), and

      o  requests the Consumer's choice or derives it automatically from
         any configured preferences.  Any selection ties one IOTP
         Payment Bridge with the following payment transaction.

      The handling and resolution of unavailable IOTP Payment Bridges
      during the inquiry in Step 3 is up to the IOTP Application Core.
      It may skip these IOTP Payment Bridges or may allow user supported
      resolution.

      Furthermore, it may offer the registration of new payment
      instruments when the Consumer is asked for payment instrument
      selection.

   5. The IOTP Application Core interrogates the fixed IOTP Payment
      Bridge whether the payment might complete with success ("Check
      Payment Possibility").  At this step, the IOTP Payment Bridge may
      issue several signals, e.g.,

      o  payment can proceed immediately,
      o  required peripheral inclusive of some required physical payment
         instrument (chip card) is unavailable,
      o  (non-IOTP) remote party (e.g., issuer, server wallet) is not
         available,
      o  wallet identifier or pass phrase is required,
      o  expired payment instrument (or certificate), insufficient
         funds, or
      o  physical payment instrument unreadable.

      In any erroneous case, the user should be notified and offered
      accurate alternatives.  Most probably, the user might be offered

      o  to resolve the problem, e.g., to insert another payment
         instrument or to verify the periphery,
      o  to proceed (assuming its success),
      o  to cancel the whole transaction, or

Top      Up      ToC       Page 24 
      o  to suspend the transaction, e.g., initiating a nested
         transaction for uploading an electronic purse.

      If the payment software implements payment instrument selection on
      its own, it may request the Consumer's choice at this step.

      If the check succeeds, it returns several IOTP Brand Selection
      Info Elements.

   6. The Steps 2 to 5 are repeated and possibly interlaced for the
      selection of the second payment instrument during IOTP Value
      Exchange transactions - this is omitted in the figure above.

   7. The IOTP Brand Selection Component is generated and enriched with
      the Brand Selection Info elements.  This component is transmitted
      to the Merchant inside a TPO Selection Block if the received IOTP
      message lacks the IOTP Offer Response Block.  The Merchant will
      then respond with an IOTP Offer Response Block (following the
      aforementioned compilation rules).

2.4.  Successful Payment

   An example of how the functions in this document are used together to
   effect a successful payment is illustrated in the Figure 5.  In the
   figure 5, PS0, PS1, ..., and PSn indicate the nth PayScheme Packaged
   Content data, and [ ] indicates optional.

   (Technically, two payments happen during IOTP Value Exchange
   transactions.)

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Consumer        Start Payment Consumer(Amount,[PS0]...)    -> IPB
                   Start Payment Cons. Res.([PS1], CS=Cont.)  <- IPB
                   Create and transmit Payment Request Block
   Payment Handler Start Payment Pay. Handler(Amount, [PS1])  -> IPB
                   Start Payment PH Response(PS2, CS=Cont.)   <- IPB
                   Create and transmit Payment Exchange Block
   Consumer        Continue Process(PS2)                      -> IPB
                   Continue Process Response(PS3, CS=Cont.)   <- IPB

            ... CONTINUE SWAPPING PAYMENT EXCHANGES UNTIL ...

   Payment Handler Continue Process Response([PSn], CS=End)   <- IPB
                   Request any local payment receipt
                   |  Inquire Process State()                 -> IPB
                   |  Inquire Proc. State Resp.(State, [Rcp.])<- IPB
                   Create and transmit Payment Response Block
                   Terminate transaction, actively

Top      Up      ToC       Page 25 
                   |  Change Process State(State)             -> IPB
                   |  Change PS Response(State=CompletedOK)   <- IPB
   Consumer        On receipt of final payment scheme data
                   |  Continue Process(PSn)                   -> IPB
                   |  Continue Process Response(CS=End)       <- IPB
                   Check Payment Receipt(Receipt)             -> IPB
                   Check Payment Receipt Response()           <- IPB
                   Request any local payment receipt
                   |  Inquire Process State()                 -> IPB
                   |  Inquire Proc. State Resp.(State, [Rcp.])<- IPB
                   Terminate transaction, actively
                   |  Change Process State(State)             -> IPB
                   |  Change PS Response(State=CompletedOk)   <- IPB
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

                  Figure 5. Example Payment Message Flows

   1. After Brand Selection and receipt of the IOTP Offer Response
      Block, the Consumer switches from communicating with the Merchant
      to communicating with the Payment Handler.

      This might be a milestone requiring the renewed Consumer's
      agreement about the payment transaction's continuation.
      Particularly, this is a good moment for payment suspension (and
      even cancellation), which will be most probably supported by all
      payment schemes.  Simply, because the actual payment legacy
      systems have not yet been involved in the current transaction.

      Such an agreement might be explicit per transaction or automatic
      based on configured preferences, e.g., early acknowledgments for
      specific payment limits.

      It is assumed, that the transaction proceeds with minimal user
      (Consumer and Payment Handler) interaction and that its progress
      is controlled by the IOTP Application Core and IOTP Payment
      Bridge.

   2. In order to open the actual payment transaction, the IOTP
      Application Core issues the "Start Payment Consumer" request
      towards the IOTP Payment Bridge.  This request carries the whole
      initialization data of the payment transaction being referred to
      by the IOTP Payment Bridge for subsequent consistency checks:

      o  payment brand and its description from the selected Brand
         Element of the IOTP Brand List Component,
      o  payment instrument from preceding inquiry step,

Top      Up      ToC       Page 26 
      o  further payment parameters (currency, amount, direction,
         expiration) from the selected Currency Amount element, Brand
         List Component, and Payment Component of the IOTP Offer
         Response Block,
      o  payment protocol from the selected IOTP Pay Protocol Element,
      o  order details contained in the IOTP Order Component which might
         be payment scheme specific,
      o  payment scheme specific data inclusive of the payment protocol
         descriptions from the IOTP Protocol Amount Element, and IOTP
         Pay Protocol Element, and
      o  payment scheme specific data inclusive of the payment protocol
         descriptions, in which the name attribute includes the prefix
         as "Payment:" from the Trading Role Data Component.

      Generally, the called API function re-does most checks of the
      "Check Payment Possibility" call due to lack of strong
      dependencies between both requests: There might be a significant
      delay between both API requests.

      The called API function may return further payment scheme specific
      data being considered as payment specific initialization data for
      the Payment Handler's IOTP Payment Bridge.

      If the fixed Existing Payment Software implements payment
      instrument selection on its own, it may request the Consumer's
      choice at this step.

      The IOTP Payment Bridge reports lack of capability quite similarly
      to the "Check Payment Possibility" request to the IOTP Application
      Core.  The Consumer may decide to resolve the problem, to suspend,
      or to cancel the transaction, but this function call must succeed
      in order to proceed with the transaction.

      Developers of payment modules may decide to omit payment
      instrument related checks like expiration date or refunds
      sufficiency, if such checks are part of the specific payment
      protocol.

      If the IOTP Payment Bridge requests wallet identifiers or pass
      phrases anywhere during the payment process, they should be
      requested by this API function, too.  It is recommended that the
      IOTP Application Core stores plain text pass phrases only in
      runtime memory.

      Finally, the IOTP Application Core generates the IOTP Payment
      Request Block, inserts any returned payment scheme data, and
      submits it to the Payment Handler's system.

Top      Up      ToC       Page 27 
   3. The Payment Handler's IOTP Application Core opens the payment
      transaction calling the "Start Payment Payment Handler" API
      function.  The payment brand, its description, payment protocol,
      payment specific data, payment direction, currency and payment
      amount are determined quite similar to the Consumer's IOTP
      Application Core.  Furthermore, the content of the IOTP Payment
      Scheme Component and the IOTP Brand Selection Info Elements are
      passed to this function.

      On success, the Payment Handler's IOTP Payment Bridge responds
      with payment scheme specific data.  On failures, this non-
      interactive server application has to resolve any problems on its
      own or to give up aborting the payment transaction.  However, the
      Consumer may restart the whole payment transaction.  Anyway, the
      payment log file should reflect any trials of payments.

      Eventually, the Payment Handler informs the Consumer about the
      current IOTP Process State using the IOTP Payment Response or IOTP
      Error Block.

      Note that the "Start Payment Payment Handler" call might return
      the Continuation Status "End" such that payment processing
      proceeds with Step 7.

   4. The IOTP Application Core verifies the presence of the Payment
      Exchange Block in the IOTP message and passes the contained
      payment scheme specific data to the fixed IOTP Payment Bridge
      ("Continue Process") which returns the next IOTP Payment Scheme
      Component.

      This Payment Scheme Component is encapsulated in an IOTP Payment
      Exchange Block and transmitted to the Payment Handler.

   5. The Payment Handler's IOTP Application Core verifies the presence
      of the Payment Exchange Block and passes the contained payment
      scheme specific data to the fixed IOTP Payment Bridge ("Continue
      Process") which returns the next IOTP Payment Scheme Component for
      encapsulation and transmission to the Consumer.

   6. The payment process continues with IOTP Payment Exchange Block
      exchanges, carrying the payment scheme specific data.  Each party
      (1) submits the embedded payment scheme specific data
      transparently to the appropriate IOTP Payment Bridge calling the
      "Continue Process" API function, (2) wraps the returned payment
      scheme specific data into an IOTP Payment Exchange Block, and (3)
      transmits this block to the counter party.

Top      Up      ToC       Page 28 
      However, the processing of the payment scheme specific data may
      fail for several reasons.  These are signaled by specific error
      codes which are transformed to IOTP Payment Response Blocks
      (generated by Payment Handler) or IOTP Error Blocks (both parties
      may generate them) and transmitted to the counter party.

   7. Eventually, the Payment Handler's IOTP Payment Bridge recognizes
      the termination of the payment transaction and reports this by the
      continuation status "End" on the output parameter of "Continue
      Process" (or "Start Payment Payment Handler").  Then, the IOTP
      Application Core issues the "Inquire Process State" API call and
      verifies whether an IOTP Payment Receipt Component has been
      returned.  The IOTP Application Core wraps the payment receipt,
      the status response, and the optional payment scheme specific data
      in an IOTP Payment Response Block and transmits this block to the
      Consumer.

      However, any of these API calls may fail or any response might be
      incomplete (e.g., lack of payment receipt).  Then, the Consumer
      has to be notified about the failed processing by an IOTP Error
      Block.

      Finally, the Payment Handler terminates the payment transaction
      with the "Change Process State" API call without awaiting any
      further response from the Consumer.  Further failures are not
      reported to the Consumer.

      Note that it might be possible that the Consumer's IOTP Payment
      Bridge has returned the previous payment scheme specific data with
      the continuation status "End".  Even in the absence of this
      knowledge - this status is not exchanged between the Consumer and
      the Payment Handler - the Payment Handler must not supply any
      further payment scheme specific data.  Such data will be rejected
      by the Consumer's IOTP Payment Bridge.

   8. The Consumer passes the optional payment scheme specific data and
      the payment receipt to the fixed IOTP Payment Bridge by "Continue
      Process" and "Check Payment Receipt" API calls.

      Afterwards, the IOTP Application Core issues the "Inquire Process
      State" API call and verifies whether extensions to the payment
      receipt have been returned.

      Finally, the transaction is terminated by calling the "Change
      Process State" API function which verifies and synchronizes the
      reported payment status with the local one and signals any
      inconsistencies.  Any Inconsistency and returned status text
      should be displayed to the Consumer.

Top      Up      ToC       Page 29 
      At this point, the payment transaction has already been closed by
      the Payment Handler.  Therefore, any failure has to be resolved
      locally or out-of-band.

2.5.  Payment Inquiry

   In Baseline IOTP, Payment inquiries are initiated by the Consumer in
   order to verify the current payment progress and process state at the
   remote Payment Handler.  In the figure 6, PS1 and PS2 indicate the
   first and second PayScheme Packaged Content data, and [ ] indicates
   optional.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Consumer        Start Payment Inquiry()                    -> IPB
                   Start Payment Inquiry Response([PS1])      <- IPB
                   Create and transmit Inquiry Request Trading Block
   Payment Handler Inquire Payment Status([PS1])              -> IPB
                   Inquire Payment Status Res.(State, [PS2])  -> IPB
                   Create and transmit Inquiry Response Trading
                     Block
   Consumer        If Payment Scheme Data present
                   |  Continue Process(PS2)                   -> IPB
                   |  Continue Process Response(CS=End)       <- IPB
                   Change Process State(State)                -> IPB
                   Change Process State Response(State)       <- IPB
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

                  Figure 6. Remote Process State Inquiry

   1. The Consumer might initiate a payment inquiry once the payment
      transaction has been opened by the IOTP Application Core, i.e., at
      any time after the initial submission of the IOTP Payment Request
      Block.  The IOTP Application Core requests any additional specific
      payment scheme data from the IOTP Payment Bridge which has been
      fixed during brand selection (cf. Section 2.3) using the "Start
      Payment Inquiry" API request.

      Erroneous API responses should be reported to the Consumer and
      valid alternatives (typically retry and cancellation) should be
      presented by the IOTP Application Core.

      This request might perform the complete initialization, e.g.,
      availability check of periphery or pass phrase supplement, and the
      IOTP Payment Bridge reports lack of capability quite similarly to
      the "Check Payment Possibility" request to the IOTP Application
      Core.

Top      Up      ToC       Page 30 
      If the IOTP Payment Bridge requests wallet identifiers or pass
      phrases anywhere during the payment process, they should be
      requested by this API function, too.  It is recommended that the
      IOTP Application Core store plain text pass phrases only in
      runtime memory.

      The IOTP Application Core encapsulates any Payment Scheme
      Component in an IOTP Inquiry Request Block and submits the block
      to the Payment Handler.

   2. The Payment Handler analyses the IOTP Inquire Request Block, maps
      the Transaction Identifier to payment related attributes (brand,
      consumer and payment identifiers), determines the appropriate IOTP
      Payment Bridge, and forwards the request to the this IOTP Payment
      Bridge ("Inquire Payment Status").  The IOTP Application Core
      transforms the response to an IOTP Inquiry Response Block and
      transmits it to the Consumer.

   3. On receipt of the respective IOTP Inquiry Response Block the
      Consumer's IOTP Application Core submits any encapsulated payment
      scheme specific data to the IOTP Payment Bridge for verification
      ("Continue Process").

   4. The IOTP Application Core passes the reported payment status
      (except textual descriptions) to the IOTP Payment Bridge ("Change
      Process State") for verification purposes and payment status
      change.  The IOTP Payment Bridge reports any inconsistencies as
      well as the final payment status to the IOTP Application Core.

      Any additional information that might be of interest to the
      Consumer has to be displayed by the IOTP Payment Bridge or
      Existing Payment Software on their own.

2.6.  Abnormal Transaction Processing

2.6.1.  Failures and Cancellations

   The IOTP specification distinguishes between several classes of
   failures:

      o  Business and technical errors
      o  Error depths of transport, message and block level
      o  Transient errors, warnings, and hard errors.

   Any IOTP Payment API has to deal with the receipt of failure
   notifications by and failure responses.  This proposal has borrowed
   the basic mechanisms for error reporting between the IOTP Application
   Core and the IOTP Payment Bridge from the actual protocol: Business

Top      Up      ToC       Page 31 
   errors are reported by Status Components within IOTP Response Blocks
   while technical errors are signaled by Error Components within IOTP
   Error Blocks.

   Cancellations are mimicked as specific business errors which might be
   initiated by each trading party.

   Preferring slim interfaces, this IOTP Payment API introduces one
   additional Error Code value for business error indication - errors
   can be raised on every API call.  On receipt of this value, the IOTP
   Application Core has to infer further details by the issuance of the
   API function call "Inquire Process State".

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Any Party       Issue some API request                     -> IPB
                   Error Response(Error Code)                 <- IPB
                   On "Business Error" response
                   |  Inquire Process State()                 -> IPB
                   |  Inquire P.S. Resp.(State, Receipt)      <- IPB
                   Analyze local process state and try to resolve
                      with optional user interaction
                   If Process State Change needed
                   |  Change Process State (State)            -> IPB
                   |  Change Process State Response(State)    <- IPB
                   If counter party's notification required
                   |  Create Error or Cancel Block (, add to next
                   |  message, ) and transmit it to counter party
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

                    Figure 7.  Error Response from IPB

   The specific Completion Codes "ConsCancelled", "MerchCancelled", and
   "PaymCancelled" - returned by "Inquire Process State" - determine
   that the IOTP Cancel Block has to be created instead of an IOTP Error
   Block.

   The rules for determining the required behavior of the IOTP
   Application Core are given in the IOTP specification.

   Note that any payment (intermediate) termination, i.e., failures,
   cancellations, and even successes are always reported to the IOTP
   Payment Bridge by the API function "Change Process State".  This API
   function does both status changes and consistency checking /
   synchronization.  Any suspicion of inconsistency should be reported
   by the IOTP Payment Bridge for display by the IOTP Application Core.

Top      Up      ToC       Page 32 
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Any Party       Error Block or Cancel Block Received
                   If Change Process State required
                   |  Change Process State (State)            -> IPB
                   |  Change Process State Response(State)    <- IPB
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

             Figure 8.  Error Notification from counter party

   Not every failure might be visible at the IOTP layer, e.g., the
   processing of payment transactions might temporarily be hampered by
   intermediate failures at the payment scheme or protocol transport
   layer which might be resolved by the actual components.

   However, final failures or cancellations have to be reported at the
   IOTP layer.  E.g., communication time-outs and heavily faulty
   communication channels may disable the transaction.

   Any system component may implement time-out recognition and use the
   aforementioned API mechanisms for the notification of process state
   changes.  But, time-outs may happens while communicating with both
   the counter party and local system components, like chip card readers
   or IOTP Payment Bridges.  Anyway, the Consumer's IOTP Application
   Core should notify the Consumer about the resolution alternatives,
   i.e., retry, suspension, and cancellation.

2.6.2.  Resumption

   Payment transaction resumption may apply at different steps of a
   payment transaction:

   o  The Consumer's and Payment Handler's view of the transaction might
      not be synchronized: Due to different time-out values the payment
      transaction may not have been suspended by the counter party.

      Any "Resume Payment ..." API function responds with an Error Code
      on non-suspended payment transaction that signals a business
      error.  Afterwards the IOTP Application Core has to issue the
      "Inquire Process State" API call for further analysis of the
      process state.

   o  One IOTP message sent by one party might not be processed
      successfully or even received by the counter party.  This needs to
      be handled by the actual payment scheme.  It is expected that the
      IOTP Application Core will not recognize anything.

Top      Up      ToC       Page 33 
   o  IOTP does not provide any specific signal for payment resumption.
      On receipt of every IOTP Payment Exchange Block, the IOTP
      Application Core has to decide whether this Block belongs to a
      pending transaction or to a suspended transaction that should be
      resumed.  The IOTP Application Core might call the "Inquire
      Process State" API function to update any lack of knowledge.

      Any "Resume Payment" API function responds with an Error Code on
      non-suspended payment transaction that signals a business error.
      Similar, the "Continue Process" API function should report
      business errors on non-pending payment transactions.

   o  The payment transaction may not have been created at the Payment
      Handler (early suspension and failed data transmission).  In that
      case, the IOTP Application Core should respond with a business
      error that signals the repetition of the payment transaction (by
      the Consumer).

      Any "Resume Payment", "Continue Process" or "Inquire Process
      State" API function should return with an Error Code
      "AttValIllegal" on non-existent payment transaction whereby the
      further Error Attribute "Names" denote the payment identifier.

   o  The IOTP Application Core should always request fresh payment
      scheme specific data on resumption - for synchronization purposes
      with the Existing Payment Software.  Old data in the cache that
      has not been sent to the counter party should not be accessed.

   If the Consumer does not reconnect within an acceptable amount of
   time, the Payment Handler's system may perform local failure
   resolution in order to close the transaction and to retain resources
   for other transactions ("Change Process State").  If the Consumer
   reconnect afterwards, an IOTP Payment Response or IOTP Error Block
   could be generated.

2.7.  IOTP Wallet Initialization

   At startup or on explicit user request the IOTP Application Core
   should check its IOTP Payment Bridges' internal status by searching
   for pending payment transactions.

   1. The IOTP Application Core interrogates the registered IOTP Payment
      Bridges about pending payment transactions.  The IOTP Application
      Core may store indicators for pending transactions and use them
      for driving any subsequent inquiry ("Inquire Pending Payment").

Top      Up      ToC       Page 34 
   2. If one or more IOTP Payment Bridges report the presence of pending
      transactions, the IOTP Application Core may try to suspend
      ("Change Process State") or resume (only Consumer: "Resume Payment
      Consumer") the pending transactions (on user request).

   The IOTP Payment Bridge may deny the processing of any new payment
   transactions until the pending transactions have been processed.
   Such denials are signaled by the error code "Business Error".

2.8.  Payment Software Management

   The IOTP Application Core provides only a simple and generic
   interface for the registration of new payment methods / instruments
   ("Manage Payment Software").  It receives the initial user request
   and defers the actual registration to the corresponding IOTP Payment
   Bridge.

   The IOTP Application Core may also activate the Existing Payment
   Software for further payment instrument and wallet administration.



(page 34 continued on part 3)

Next RFC Part