Re: Web payments messaging and APIs

On 2015-10-02 23:48, Manu Sporny wrote:
> On 10/01/2015 12:36 PM, Nick Shearer wrote:
>> I haven’t had a lot of time to look over the spec, but I will say
>> that discussion of having a web payments spec include NFC and
>> offline proximity payments seems like something that drastically
>> increases the scope of any work the WG has to do.
>
> Yes, agreed. To be more clear:
>
> * The proposal is to make the NFC Web Payments API a separate
>    deliverable, after Phase I is complete (which gets the core messages
>    right).
> * Offline proximity payments is something we have to be aware of, but
>    is clearly not in the Web Payments Phase I scope.
>
>> There are many additional complications and factors involved for
>> physical payments - I am not sure I agree with you when you suggest
>> the messaging formats could remain the same and only the transport
>> change, for example.
>
> Yes, you're right. To be more clear:
>
> The Web Payments messages carrying tokenized payment data (roughly
> 4KB-32KB in size *hand waving*) could probably be used across HTTP or a
> BTLE connections as-is.
>
> However, when it comes to NFC, URLs would most likely have to be
> exchanged to bootstrap the payments process, which would then be handed
> off to  a more capable device (like a mobile phone's browser). The Web
> Payments message formats could be used to communicate via the more
> capable device.

Just a short comment on proximity payments versus Web Payments:

The bigger question is whether local payment protocols like EMV should reach the Web,
or the opposite, Web payment schemes will eventually be used locally as well.
Currently they are entirely different.

My personal preference is creating Web schemes but always (at least mentally)
verify that they without a major rewrite also can be used locally.  It *seems*
that it is only the initiation that must remain different and that part may
not even belong to the payment protocol.

If a Web scheme becomes successful, the migration to proximity will probably happen
because current POS-protocols are dated and constrained by smart cards which have
very limited UI, Processing, and Networking capabilities.

Apple Pay and Android Pay (for practical reasons) are "card emulators".

Cheers,
Anders


>
> -- manu
>

Received on Saturday, 3 October 2015 08:17:34 UTC