RE: Ongoing payments - IOTP Version 2 extension

["Roth, Janet" <[e-mail]>]

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:[e-mail]]
Sent: Monday, November 27, 2000 3:42 PM
To: '[e-mail]'
Subject: RE: Ongoing payments - IOTP Version 2 extension



> -----Original Message----- 
> From: Roth, Janet [ mailto:[e-mail] <mailto:[e-mail]> ] 
> 
> 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: [phone] 
 Fax: [phone] 

> -----Original Message----- 
> From: Roth, Janet [ mailto:[e-mail] <mailto:[e-mail]> ] 
> Sent: November 27, 2000 06:09 PM 
> To: '[e-mail]' 
> 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 
> __________________________________________________ 
> [e-mail] 
> Chief Systems Architect 
> Emerging Technologies - Application Architecture & Standards 
> Visa International 
> Ph. [phone];  FAX [phone] 
> Mailstop M1-8H, 900 Metro Center Blvd., Foster City CA, 
> 94404-2775, USA 
> 
>