Use of custom schemes is not great...

[marcoscaceres]

Wouldn't this have the same issues that were discussed here (even though those were for identity, but same thing applies here I think):
https://github.com/WICG/digital-identities/blob/main/custom-schemes.md

Some platforms have moved away from using custom schemes... this seems to encourage them, which doesn't seem great.

[aneeshali]

Hey Marcos,

The Payment Request API is suitable for pull payments where the communication needs to be 2-way. Also it needs active integration work from the merchant side.

The proposed solution is focused on push payments, where the payment actually happens out of band from the payer to payee. In this scenario, we provide an easy way for the merchants to make use of the browser capabilities with a lightweight change, and doesn't require any active integration. This would mean the merchants don't need to drastically change their current workflows, which is an important factor to consider.
Please note that the merchants already have a way to handle out of band notification upon push payment completion (Example: a QR is displayed and the merchant waits for an out of band communication about payment completion). So this can be treated as a purely 1-way (passive) communication, and the browser isn't required to pass back any data to the merchant.

So we should treat this proposal not as a replacement but as a solution that complements Payment Request API, so we have solutions for both push and pull payments.

[marcoscaceres]

Right, but what about the custom schemes? The core of my question was related to those. Relying on custom schemes doesn’t seem like a viable solution.

[rsolomakhin]

Hi @marcoscaceres, thank you for the link to @RByers 's doc!

Is my understanding correct: that doc raises concerns about how an OS handles schemes to invoke an installed application? E.g., Android's data element for intent-filters can specify a custom scheme:

<intent-filter . . . >
    <data android:scheme="something" android:host="project.example.com" />
    ...
</intent-filter>

The payment link explainer states:

"The browser is responsible for detecting the presence of a "payment" link in any page. It then notifies the payment clients that have registered the associated scheme for receiving "payment" links."

And that sounds extremely similar to what @RByers was describing in Concerns with custom schemes doc:

"use of custom URL schemes (eg. openid4vp: and mdoc:) to enable verifier websites to invoke holder (wallet) applications"

In summary, I think what @RByers was trying to say: A user agent should not simply forward URLs to the apps installed on the device, because that may result in bad user experience and other issues.

I don't have the full context for what alternative was proposed due to Concerns with custom schemes, but I think it's safe to say that the Chrome team should keep these concerns in mind when designing and implementing this feature.

Would you suggest moving away from custom schemes (the explainer mentions upi, bitcoin, and paypal) toward the standard https?

One strawman solution to the raised concerns: Make the user agent be a mediator for the payment links, so it can determine what to do with different schemes, before possibly invoking a "payment client" to handle the payment link. If that can be used to alleviate the concerns, should that be in the upcoming spec?

Cheers! 🍻
Rouslan

[aneeshali]

Thank you @rsolomakhin for chiming in.

Hey @marcoscaceres I wanted to add a little more context on how we are thinking about custom schemes.

1. Security of the payment links should be considered a separate problem (some potential ideas explained later on how we can solve for it). Custom schemes themselves are not intended to solve for security.
2. Custom schemes are important when we look at interoperable payment methods like UPI, Pix, Bitcoin etc since multiple wallets can support such payment methods. It won't be trivial to have a valid https URL in such cases (if we are looking to rely on the security that comes with https) that can work with any supported wallet.
3. For payment methods that have already standardized a custom scheme, introducing something different could hinder adoption. The schemes below from IANA registry of URI schemes are all meant for push payment.

bitcoin
bitcoincash
ethereum
payto, which includes a broader range of schemes including ACH, IBAN, Bitcoin, UPI etc.

Moving away from a scheme-based approach will make these standards less usable.

4. The browser shouldn't be concerned about the standardization of the schemes. That should be considered out of the Browser's scope. The Browser should look at the scheme only for the purpose of mapping to the supported wallet provider (browser-integrated-wallet or a wallet plugin).

Based on my limited understanding of the concerns with custom schemes for identity, I wanted to share a few thoughts in the context of push payments.

• While the user experience concerns are relevant in the identity space, it's a problem that is mostly solved in the push payment space. The merchants/PSPs have done this with the help of their own polling/notification infrastructure. For example, when a user scans a QR and makes a payment, the payment page is automatically updated to show the payment confirmation.
• The security concerns (how to trust the payment links) and the considerations around XSS attacks are super relevant and we need to come up with a solution that's secure.

For security, we are looking into adopting the approach followed by UPI with the help of digital signatures. The UPI URL contains a MID (merchantId) and a signature, and there are lookup services made available by UPI to lookup the public key for a given MID. This way the payer is able to cryptographically verify the authenticity of the payment link before proceeding with the payment. This is all possible with UPI due to their centralized infrastructure that facilitates such use cases. We can follow a similar approach but utilize decentralized identifiers (did:web to begin with but can be expanded in future to other DID methods) instead of MIDs. We think we can begin with did:web which will help us to piggyback on the https security. We are still ironing out the details and going through security reviews, and are hoping to share with the broader audience once we have internal alignment.

In its simplest form, the solution can be something like we reserve a couple of query parameters in the URL, like did-url and paymentlink-signature. The Browser can look for these fields and independently verify the payment link. The did-url itself can be trusted only if the hosting domain returns a static header containing the did-url. Such an approach will help us rely on the security of the hosting domain and will provide protection against XSS attacks to a great extent.

So to summarize, the Browser will have 2 responsibilities:

• Independently verify the signature associated with the payment link.
• Map the payment link to the wallet provider based on the scheme, and pass control to the wallet provider if there is a match.

With this added context, we would love to hear your thoughts/feedback on the approach and whether there are bigger concerns on the usage of custom schemes.

[nickjshearer]

The Payment Request API is suitable for pull payments where the communication needs to be 2-way

Yes and no…it’s suitable for push payments. We had a lot of discussion about this when we first created the spec. An Open Banking payment is a push payment and you could quite happily support that with Payment Request.

The API contract does necessitate two way communication - that I think is the problem here - but that doesn’t mean we couldn’t use the same data structures. One part of PaymentRequest is defining a standardised interface for describing payment methods you support and what the payment is compromised of…this seems like it potentially could be used here?

[aneeshali]

Thanks @nickjshearer. Agreed that open banking payments are push payments. And happy to chat more if there are ways to make things work with Payment Request, keeping in mind that the goal is to make it really light weight for the PSPs to incorporate.

Sharing a few more details on the thought process and how we internally concluded that payment links will be a viable solution that has higher changes for the PSPs to adopt.

Taking Pix in Brazil as an example. Pix has already established a standard for payment target by utilizing the EMVCo QR standard. All the payment details are part of the Pix code, so ideally we shouldn't add an overhead for the PSPs to also embed the same details in a different format. Even if a PSP is agreeing to do it, it wouldn't add much value. This is because the wallet provider can extract all the relevant payment details from the Pix code. If anything is missing in the Pix code, there are backend services that can provide such missing information.

So now we are left with the problem of identifying the payment method, which can be solved with the help of custom schemes (keeping the security considerations aside).

So overall, we are looking at a very light weight change for the merchants/PSPs on top of what they already do. Which is to wrap the same payment target in the form of a payment link.

Please share your feedback and would love to chat more if there are other approaches to consider.

@rsolomakhin and @stephenmcgruer please feel free to add anything that I missed.

[rsolomakhin]

@aneeshali wrote:

So now we are left with the problem of identifying the payment method, which can be solved with the help of custom schemes (keeping the security considerations aside).

An alternative method for identifying the payment scheme is to put it in the path, i.e., change from (1) to (2):

1. <custom-scheme>://<hostname>/<qr-code>
2. https://<hostname>/<custom-scheme>/<qr-code>

But then we would encounter the problem of having a valid-looking URL that does not necessarily maps to a meaningful location on the web.

[aneeshali]

I agree @rsolomakhin that the first option is better for clearer semantics.

If there are no further comments on this topic, I would like to resolve this issue and move forward.

[rsolomakhin]

Before we close this down, @marcoscaceres and @nickjshearer - Do you have suggestions on how to improve payment links from your perspective, e.g., to make other implementers jobs easier?

[ianbjacobs]

Hi all,

I wonder if there's a benefit of offering two ways to specify these links.

For proprietary payment methods (e.g., Google Pay or Apple Pay) use HTTPS URLs as "href" values. This might even allow some synergies with the Payment Request ecosystem. I haven't thought through the full implications, but perhaps a Payment Method manifest could be used for some validation by the browser before a user experience.

For standardized payment methods where there might be more than one handler I agree that having to register a domain name is a blocker. In this case:

• Use the "type" attribute (e.g., with an application registration subtype) to indicate the payment method (e.g., and I'm making this up, application/upi or application/pix).
• Use the "href" attribute for the data to be passed to the application. I could imagine leveraging different URL schemes here depending on context (e.g., https: or data:).

I am mostly thinking a media type registration (e.g., application/upi) might be easier than a URL scheme registration (but I don't have evidence), and that handling URLs with well-established schemes will just make life easier.

It will also be easier for owners of proprietary payment methods to not have to register custom URL schemes.