Re: 3D Secure++ for Push Payments

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
>
>

Received on Friday, 27 June 2014 18:44:25 UTC