Re: 3D Secure++ for Push Payments

I think you are right, it should be called quote.
Invoices are normally issued when the funds are already owed.


On 27 June 2014 20:43, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> On 2014-06-27 11:07, Adrian Hope-Bailie wrote:
>
>> Hey Anders,
>>
>> I think we came to the same conclusion when I read your document the
>> other day :)
>>
> Nice!
>
>
>
>> Effectively what you are advocating is some form of
>> dual-factor/out-of-band authorisation of the transaction between the payer
>> and their provider right?
>> (That's what I see happening in steps 2 - 4).
>>
>> This is effectively what 3D secure does today between the card holder and
>> card issuer.
>>
> Right.
>
>
>
>> My experience of why the industry has been resistant to 3D secure
>> (mandated in South Africa by the way) is because initially it required the
>> buyer/payer to do some work up front to set it up.
>> i.e. It only protected proactive customers who were usually tech savvy
>> enough to do it.
>>
>> The result was that if the acquirer tried to push the customer through
>> the 3D secure process they got lost/confused and dropped off.
>> i.e. Very little incentive for the merchants (and therefore gateways) to
>> implement even when considering the reduction in chargeback fraud risk.
>>
>
> I see it like this:
> Merchants wont buy into anything that doesn't improve the user experience
> which 3D Secure did the opposite of.
> Banks OTOH, wont buy into anything that doesn't significantly improve over
> unauthenticated card-numbers and CCVs.
>
> Therefore I'm trying to address both wishes.
>
> Unfortunately that requires (IMO...) a fundamentally updated Web- and
> OS-platform.
> Fortunately the very same platform has numerous of other applications
> which currently are covered by native and/or propriety solutions.
> On top of that you can [hopefully] build essentially any payment system.
> My writeup was more a way to document one such solution and to see how it
> fits into other concepts like push payments.
>
>
>
>
>> Some notes on your steps to clarify where we overlap and how this relates
>> to the push payments model:
>>
>> 1. The payer gets a digitally signed payment request from the payee
>> I call this the invoicing step.
>>
> I prefer calling it the quote :-)
>
>
>  The payer has chosen the way they want to pay and is happy with the terms
>> so they request a digitally signed invoice from the payee.
>> In the request they express all of these choices/decisions and the payee,
>> by issuing the invoice, confirms that the choices/decisions are valid and
>> mutually accepted.
>>
>> 2. The payment request is redirected to the payment provider
>> I suspect that it many cases the bulk of the "chat" will be done by the
>> provider and not from the payer's user agent (app/browser/etc).
>> So the provider would get the available payment options, filter out the
>> ones it doesn't support and then present the payer with the remainder.
>> It may even be configured by the payer to auto-select based on some
>> preferences.
>>
> I guess this is a discussion point, should payment method be specified
> upfront (as today) or afterwards?
>
>
>
>> Side note:
>> This is where I think we should steer clear of dictating too much as the
>> communications/interaction between the provider and the payer is up to the
>> provider to design.
>> I see providers competing to provide the best user experience and if we
>> remove all possibilities of this by standardising every last step of the
>> process then I think we will get a lot of resistance.
>>
>> As such, I have intentionally not gone into detail around this process
>> and simply state that the channel between the payer and provider will be
>> secure and trusted by the payer.
>> The tools the provider gives the payer to establish this link is another
>> means of competitive differentiation for the providers.
>> It could be a mobile app, a desktop application, a website, a browser
>> plug-in, a dedicated piece of hardware even!
>>
>> The provider will deal with the bulk of the orchestartion of the protocol
>> and communicate with the payer as required to prompt for input (PINs,
>> payment method selection, gratuity, confirmation of payment, biometric
>> data? etc).
>>
>> So, in most cases I would say that in step 1 it is the payer's provider
>> requesting and receiving a digitally signed invoice and step 2 is skipped.
>>
>> 3. The payer authorizes the payment request at the payment provider using
>> a payer key
>> As I say above, we probably don't want to spec this step explicitly other
>> than to note that the provider SHOULD:
>> a. Ensure the channel between them and the payer is secure and cannot be
>> spoofed (multi-factor auth?)
>> b. Allow the user to confirm the payment before it is executed unless the
>> payer has explicitly set preferences around payment scenarios for which
>> they don't want to perform this extra step
>> (probably based on payment amount/trusted payees etc)
>>
>>
>> 4. The payment provider counter-signs the payment request with its
>> provider key
>> I would put this in the scope of the payment channel being used.
>> I can see that for an internet based payment channel this may be required
>> but if the channel is an existing channel out of band of the web this is
>> unneccessary right?
>> I.e. At this point the provider has confirmation from the payer to do the
>> transaction and enough details of the payee to execute it.
>>
>> Let's assume the channel is a direct bank transfer and the provider is a
>> local bank and the payee has therefore given the provider their bank
>> account details.
>> The provider than communicates directly with the payee's bank and
>> completes the transaction.
>>
>> 5. The resulting object is returned to the payee
>> 6. The payee pulls money from the received object trough its payment
>> provider
>>
>> These are pull-model steps so I wouldn't advocate them but I see how they
>> fit into the CNP use case you are addressing.
>> I realise that what these do that I haven't catered for above is provide
>> the payee with proof of payment
>> This is where I think some form of digital receipt will be required,
>> either as specified by the channel or in a generic way that we can describe
>> in a standard.
>>
>> To extend the example above, the channel is a local banking transfer
>> channel so it presupposes an agreement between the participating banks
>> about how they will deliver a proof of payment and to whom.
>>
>> If it is from the payee's provider directly to the payee then no further
>> work is required.
>> We can assume that the payer's provider has confirmation from the payee's
>> provider that the transaction completed (this would be part of the payment
>> execution protocol).
>> Therefore the payer can get a proof of payment signed by their provider.
>>
>> If the agreed method of distributing proof of payment is via the payer's
>> provider then the payee's provider would need to sign some form of digital
>> receipt and return this to the payer provider.
>> This can then be sent directly to the payee or to the payer or both.
>>
>> Our spec should allow a means (during the discovery phase) for the payee
>> to define how this should be delivered.
>> i.e. POST to and endpoint, email etc.
>>
> The short answer to all this is that I will try to stay out of the core
> because it looks rather messy.
> But providing examples on how to user the enhanced platform is in scope.
>
> Anders
>
>
>> Adrian
>>
>>
>>
>> On 27 June 2014 05:49, Anders Rundgren <anders.rundgren.net@gmail.com
>> <mailto:anders.rundgren.net@gmail.com>> wrote:
>>
>>     The merits of 3D Secure haven't been discussed in this list,
>>     probably because it has [rightfully] been rejected in the US.
>>     However, 3D Secure is a very cool idea, it just lacks a proper
>>     platform to run on.
>>
>>     When I read Adrian's push payment manifesto, I realized that the stuff
>>     I have worked with for a quite some time also could be useful as a
>> technical
>>     foundation for push payments.  Details:
>>
>>     0. Probably the payer must select payment type (=payment provider)...
>>     1. The payer gets a digitally signed payment request from the payee
>>     2. The payment request is redirected to the payment provider
>>     3. The payer authorizes the payment request at the payment provider
>> using a payer key
>>     4. The payment provider counter-signs the payment request with its
>> provider key
>>     5. The resulting object is returned to the payee
>>     6. The payee pulls money from the received object trough its payment
>> provider
>>
>>     Note that the payer's card details wouldn't be given to the merchant
>>     when you use your payment provider as the source rather than your
>> card.
>>     The payer only needs to be authenticated to the payment provider.
>>
>>     Although originally designed with another objective in mind, the
>> following
>>     steps and platform ought to work for push payments as well:
>>     http://webpki.org/papers/payments/securing-card-not-
>> present-transactions.pdf
>>
>>     I strongly believe that BaM-payments and Web-payments could/should be
>> identical.
>>
>>     There are several hurdles.  Banks are slow as h**l, Standardization
>> takes forever,
>>     and Google can do whatever they want:
>>     http://www.cnet.com/news/google-spells-out-ambitious-
>> plan-android-world-domination
>>
>>     Cheers,
>>     Anders
>>
>>
>>
>