RE: Ongoing payments - IOTP Version 2 extension

"Smith, Chris " <CHRIS.SMITH@ROYALBANK.COM> Mon, 27 November 2000 23:42 UTC

Return-Path: <ietf-trade-errors@lists.elistx.com>
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00901J7NIO@eListX.com>; Mon, 27 Nov 2000 18:42:59 -0500 (EST)
Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00903J7NIM@eListX.com> (original mail from CHRIS.SMITH@ROYALBANK.COM) ; Mon, 27 Nov 2000 18:42:59 -0500 (EST)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00901J7MII@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Mon, 27 Nov 2000 18:42:59 -0500 (EST)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00901J7MIH@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Mon, 27 Nov 2000 18:42:58 -0500 (EST)
Received: from uhrbc1p1.royalbank.com (uhrbc1p1.royalbank.com [198.96.131.220]) by eListX.com (PMDF V6.0-24 #44856) with SMTP id <0G4P005J5J7HD2@eListX.com> for ietf-trade@lists.elistx.com; Mon, 27 Nov 2000 18:42:58 -0500 (EST)
Received: from wsecure3.royalbank.com by uhrbc1p1.royalbank.com via smtpd (for one.elistx.com [209.116.252.130]) with SMTP; Mon, 27 Nov 2000 23:39:08 +0000 (UT)
Received: from 10.224.0.79 by se001021.royalbank.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Mon, 27 Nov 2000 18:41:34 -0500
Received: by se001025.rbc1.royalbank.com with Internet Mail Service ( 5.5.2650.21) id <XRBGZFHX>; Mon, 27 Nov 2000 18:42:22 -0500
Date: Mon, 27 Nov 2000 18:42:19 -0500
From: "Smith, Chris " <CHRIS.SMITH@ROYALBANK.COM>
Subject: RE: Ongoing payments - IOTP Version 2 extension
To: "'ietf-trade@lists.eListX.com'" <ietf-trade@lists.elistx.com>
Message-id: <55D770EEA49FD4118FDE00D0B7692F91243083@se001035.rbc1.royalbank.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative; boundary="Boundary_(ID_EglEGcl+hWH3EeXw4CJfhQ)"
X-Server-Uuid: 69f58f12-9d1a-11d3-825a-00609455ee28
X-WSS-ID: 163C2EA4137363-02-01
List-Owner: <mailto:ietf-trade-help@lists.elistx.com>
List-Post: <mailto:ietf-trade@lists.elistx.com>
List-Subscribe: <mailto:ietf-trade-request@lists.elistx.com?body=subscribe>
List-Unsubscribe: <mailto:ietf-trade-request@lists.elistx.com?body=unsubscribe>
List-Archive: <http://lists.elistx.com/archives/ietf-trade>
List-Help: <http://lists.elistx.com/doc/email-manage.html>, <mailto:ietf-trade-request@lists.elistx.com?body=help>

> -----Original Message-----
> From: Roth, Janet [mailto:roth@visa.com]
>
> Using game playing as an example:
> 
> Before starting the game, the merchant and customer systems
> negotiate the payment brand and protocol, and agree that the
> customer will be charged $3 for an initial 30 minutes of
> playing time, $.50 for each subsequent 10 minute period,
> and will be credited $.10 for each game level achieved.
> This can be expressed as agreeing to an immediate payment
> of $3 and to maximum incremental payments of $.50.

I like the idea, but even more, I like your example. Hopefully
it will allow for resolution of some of the issues that arise
around such payments.

In particular - given that the negotiation is only done up
front, how does the customer know that the merchant is using
a "valid clock"? As I understand your example, there is no
guaranteed closing step where the customer is informed of the
total amount. There is good reason for NOT having such a step,
because this may be impossible if the customer is accidentally
disconnected.

But - in the event the customer is disconnected, how do they
complain about overcharging? The merchant appears to be able
to continue charging you for several more 'units'. This may
be even more subtle when you reconnect two hours later, and
you really reconnect to the same game and position - and the
merchant then charges you for the two hours, arguing that he
had to expend resources to maintain your game, whether you
were actively playing, or 'just thinking' while 
disconnected.

If the customer is using a chipcard payment system, then a
disconnect will also prevent future payments. But a 'virtual
card' system, or even a credit card system, allows the merchant
to continue charging without further communication with the
customer.

------------------------------------------------------------
 Chris Smith                                     Royal Bank
 Senior Technical Consultant
 Smart Card Systems
 277 Front Street West, 2nd Floor
 Toronto, Ontario M5V 2X4
 Tel: (416) 348-6090
 Fax: (416) 348-2210

> -----Original Message-----
> From: Roth, Janet [mailto:roth@visa.com]
> Sent: November 27, 2000 06:09 PM
> To: 'ietf-trade@lists.eListX.com'
> Subject: Ongoing payments - IOTP Version 2 extension
> 
> 
> 
> Visa is interested in seeing a small extension to IOTP for 
> Version 2 that
> will support what we call "incremental" or "ongoing" 
> payments.  A familiar
> example of such an ongoing payment from the mundane, 
> pre-internet world is a
> pay-telephone call.  Internet based examples of such payments 
> might include
> not only payment for connection time, but also payment for ongoing
> activities such as game playing.  While this can be implemented under
> Version 1, it is somewhat awkward.
> 
> Specifically, we would like to see added to the standard IOTP element
> definitions the following:
> 
> 1) an optional data element indicating that this transaction 
> is one of three
> possibilities:  a stand-alone single payment (the default), 
> the initial
> payment of an ongoing payment transaction set, and an 
> incremental payment.
> (in the last case, the initial payment is referenced using 
> the Related To
> component). 
> 
> 2) an data element, used only for the initial payment of an ongoing
> transaction set, giving the maximum permitted incremental 
> payment amount in
> each offered currency.
> 
> The authentication of the customer/cardholder, and the 
> negotiation of the
> price and means of payment is performed once only, during the 
> processing of
> the initial payment for the transaction set.  This 
> negotiation includes both
> the agreement of an initial payment amount, and the maximum 
> amount for the
> subsequent incremental payments.  The subsequent incremental payment
> transactions would be for any amount not greater than the 
> agreed maximum.
> 
> Using game playing as an example:
> 
> Before starting the game, the merchant and customer systems 
> negotiate the
> payment brand and protocol, and agree that the customer will 
> be charged $3
> for an initial 30 minutes of playing time, $.50 for each subsequent 10
> minute period, and will be credited $.10 for each game level 
> achieved.  This
> can be expressed as agreeing to an immediate payment of $3 
> and to maximum
> incremental payments of $.50.  
> 
> In other words, the initial payment of the set indicates $3 
> in the "amount"
> attribute in the currency amount element and $.50 in the new maximum
> incremental amount.  The subsequent incremental payments may 
> contain any
> value up to $.50 in the "amount" attribute.  In this example, 
> if the game
> player had achieved a new game level, then the next payment 
> would be $.40.
> 
> 
> Janet Roth
> __________________________________________________
> roth@visa.com
> Chief Systems Architect
> Emerging Technologies - Application Architecture & Standards
> Visa International
> Ph. +1 (650) 432-1758;  FAX +1 (650) 432-3199
> Mailstop M1-8H, 900 Metro Center Blvd., Foster City CA, 
> 94404-2775, USA
> 
>