Subject: Ongoing payments - IOTP Version 2 extension

From: "Roth, Janet" <[email-masked]>
Date: Mon, 27 Nov 2000 15:09:11 -0800

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
__________________________________________________
[email-masked]
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

---

From: "Smith, Chris " <[email-masked]>
Date: Mon, 27 Nov 2000 18:42:19 -0500

> -----Original Message-----
> From: Roth, Janet [mailto:[email-masked]]
>
> 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:[email-masked]]
> Sent: November 27, 2000 06:09 PM
> To: [email-masked]'
> Subject: Ongoing payments - IOTP Version 2 extension
> 
> 
>

---

From: "Roth, Janet" <[email-masked]>
Date: Tue, 28 Nov 2000 10:34:03 -0800

The issues Chris raises are interesting ones, but IOTP in and of itself
can't resolve them.  Those have to be addressed by the overall payment
protocol.  
 
Firstly, because of these issues (and others not mentioned) a payment
protocol designed to accomodate ongoing payments needs to ensure that the
customer system is present and "approves" each incremental payment.  (There
are of course a variety of methods of implementing the customer approval.
Just as an example, continuing to play a game after a signal of some sort
indicating that more money is required might indicate approval of the next
increment).  
 
As Chris points out, it must be possible to "close" the transaction, even if
the customer is no longer present.  The protocol should ensure that the
merchant/acquirer cannot get paid without doing this. 
 
If the customer is still connected, there can also be an (informational)
message to the customer system that indicates the closure and gives the
status.  Otherwise, the customer may go to her issuer site (later, when
reconnected) to determine the transaction status.
 
A payment product's business rules must determine how disputes are handled.
Depending on the business model, you may allow "chargebacks", or may not.
(if you do, those are back-end issues, and are not part of the customer
system interface to the merchant system).  If not, then the payment protocol
must certainly provide a refund mechanism.  
 
In the event a particular merchant is mischarging or otherwise mis-behaving,
and not providing refunds or other customer satisfaction, then the recourse
would be defined by the owner, or guarantor, of the payment acceptance mark
under which the payments were made.  What is done (such as sanctions on the
merchant) seem to be primarily business questions (or possible legal
questions), rather than technical or protocol issues. 
 
    -Janet Roth

 -----Original Message-----
From: Smith, Chris [mailto:[email-masked]]
Sent: Monday, November 27, 2000 3:42 PM
To: [email-masked]'
Subject: RE: Ongoing payments - IOTP Version 2 extension

> From: Roth, Janet [ mailto:[email-masked] <mailto:[email-masked]> ] 
> 

> From: Roth, Janet [ mailto:[email-masked] <mailto:[email-masked]> ] 
> negotiate the