Re: [Uri-review] Review request for payto URI scheme, draft 01

[Florian Dold <[e-mail]>]

On 04/11/2018 06:39 PM, Adrian Hope-Bailie wrote:
> This seems a very sensible idea to me. A few questions and comments:
> 
> How should userinfo and port data in the authority be interpreted in
> this scheme? Are they allowed at all?
> Would it not be more appropriate to have the method-specific account
> identifier in the userinfo?
> Example: payto://CH9300762011623852957@sepa/

We have initially considered this.  There are some payment methods,
however, (such as the Indian UPI) that have an "@" character in the
identifier of a user's account, which makes this syntax less attractive
(since "@" is simply forbidden in the userinfo).

Thus we'd have to define an additional encoding for some characters in
the userinfo part of the URI.  When we use the "query parameters" for
this, the encoding is already handled in a standard way.

> I'd also like to see if we can align your concepts of payment method
> with those being defined in the W3C Web Payments APIs such that there is
> a clear mapping between the URI and the payment APIs.

I'd also be happy for the two concepts to align, and I think it's
possible without too many problems.  So far the only fixed payment
method in the WPWG's "Payment Method Identifiers" CR is "basic-card",
where payto would not work, since the money isn't "pushed" to some
target address but "pulled" from the user's credit card.

The URI-based payment methods are restricted to "https" and tied to
particular services on the Web.

An easy way to consolidate the payto URI scheme with the WPWG's work
would be to simply allow payto URIs as payment methods.  This would
preserve backwards compatibility and not interfere too much with the
existing "Payment Method Identifiers" spec.

> This would make it possible to use these URIs as a declarative way of
> invoking the API.
> Example: 
> 
> Clicking an element like <a
> href="payto://CH9300762011623852957@sepa/?amount=EUR:10">Pay by SEPA
> transfer</a> would invoke the same browser processing as calling the API
> from Javascript.
> 
> new PaymentRequest(
>   [{supportedMethods: "sepa", data: {account: "CH9300762011623852957"}}], 
>   {total:{amount:{currency: "EUR", value: "10.00" }}},
>   {}).show();

Yes, the ability to initiate payments without JavaScript would be great
(and sought after by privacy conscious users with NoScript browser
extensions).  The processing of the payment in the browser could then
still use the same machinery as defined by the Payment Request API and
related standards.

> Perhaps we can adopt the same payment method registry?

That would work for some payment methods, but not for all.  The payment
methods supported by the Payment Request API are a superset of what can
be supported by payto.  You can't, for example, "address" a merchant's
account with payto in order to pay them via your credit card.

Simply allowing payto URIs (of course without the specific
amount/currency) as payment method identifiers would solve this nicely.

> Finally, I'd like to make you aware of some related work we're doing in
> the Interledger community.
> 
> 1. Payment Pointers
> 
> https://interledger.org/rfcs/0026-payment-pointers/>
> These are intended to be the equivalent of email addresses for payment
> accounts.
> 
> I don't entirely agree with your analogy between payto and mailto which
> is why we invented payment pointers.
> 
> Mailto was an after-thought and a way turn an existing identifier into a
> URI form.
> Email addresses on their own are very recognizable as such so the URI
> for is only useful in machine-read contexts.
> 
> The purpose of payment pointers is to create a similar concept for payments.
> I.e. An identifier that is simple to exchange and easily recognizable
> as, a) not an email address and b) a pointer to a payment account
> 
> That is not to say there is not a need for the payto URI but I don't
> think the payto/mailto comparison is a good one or explains the purpose
> of payto well.

Interesting!  I do see the need for such a short identifier that's not
coupled to a particular payment system, and I understand your point
about payto/mailto not being a good analogy.

Though I'd say that payto is completely orthogonal to payment pointers,
and _intended_ to address specific payment methods, even legacy or more
uncommon ones.

> 
> 2. Interledger Addresses
> 
> I'd like to request that you add Interledger to your payment method
> registry.
> The authority would be an ILP Address as defined
> in: https://interledger.org/rfcs/0015-ilp-addresses/

Certainly, I'll include it in the next draft after I've gathered all the
feedback.

Thanks for these interesting points!

Florian