See also: IRC log
Spec: https://w3c.github.io/webpayments-payment-apps-api/
IJ: Please review updated draft
https://w3c.github.io/webpayments-payment-apps-api/#registration-and-unregistration
IJ: Jason completed his action about registration.
"Registration is not required to invoke a payment app or process a response. If a payment app is included in the list of recommended apps provided by the merchant and the user selects it during the checkout process then the app is not required to register itself with the user agent, it can still walk the user through the payment process that it provides and in the end provide a payment response to the user agent."
Andre: note the relation to second bullet.
IJ: Should payment apps api have "all the bits necessary to do payment apps, including modifications to payment request api?"
or
we should do pull requests to payment request API?
AdamR: I strongly prefer the latter.
Andre: Also prefer that it be done in payment request API
Mahesh: I am also leaning that way
AdamR: Let's put on the agenda of this week's call.
<scribe> ACTION: Ian is going to make small edits to 4.3 to make clearer that registration is not required to use a payment app; it's required for persistence [recorded in http://www.w3.org/2016/08/10-apps-minutes.html#action01]
Andre: We revisited recommended
payment apps
... in some cases flow can be awkward - merchant recommending
apps that the user may not have used before.
... for whatever reason, suppose user is inclined to use bob's
pay wallet, but doesn't yet have a bob pay account
[Aha moment]
Andre: You may need a wrapper for
some payment methods.
... you might find yourself with a payment app that acts like a
wrapper that knows how to invoke some payment methods.
... think Shopify's "active merchant" module
... which has 150 payment gateways connected into it; and
people can add their own via a library spec
... I am concerned there could be a proliferation of payment
apps that act as wrappers.
AdrianHB: Is that a
problem?
... can you stop people from coding?
[Discussion of hosted pages]
Andre: Suppose a merchant wants to use a hosted page (e.g., hosted by worldpay). As a merchant, I can redirect user to worldpay page, and worldpay has done the integration to paypal. Merchant beforehand has provided worldpay with credentials.
AdrianHB: Worldpay, similarly, could do this from a payment app
Andre: How does the customer know
they have to use the "worldpay payment" app to pay with some
payment method?
... if we allow apps to register themselves at checkout, this
helps.
AdrianHB: It's actually not the
worldpay payment app, it's branded for the merchant
... so we imagine worldpay or others building white label
payment apps
... and each merchant who wants it gets a branded version
... then it's up to the retailer to incentivize the user to
install the merchant app
... But we don't want to find ourselves in a place where
merchants require users to install the merchants' app
Andre: Can you have the same app register itself under multiple names?
IJ: Yes (different payment app identifier)
AdrianHB: But we need to be able
to enable the payment app to get javascript from another
origin
... we need think carefully about what that means.
Q. should merchants be able to limit apps to those that they accept?
AdrianHB: I think this defeats
the purpose of having payment methods (and decoupling them from
payment apps)
... how would a merchant say "I only support basic card payment
method supported by the browser"?
(IJ: Good question)
scribe: this is a pretty major
change in approach based on our early discussions
... if the merchant can say I accept PayPal (the payment
method)
... why do they need to limit the set of apps?
... if they want that level of control they can not use the
payment request API
AdrianHB: I understand that merchants want to control the payment system, but that's not how this system works.
AdrianHB Proposal: No filtering mechanism other than on payment methods
scribe: I don't want to facilitate an anti-pattern that sounds like "best viewed in browser X"
alyver: I think +1 to AHB
... we are working through payment request implementation on
our side
... one challenge we encountered was a merchant accepting N
payment methods supported by Shopify
... for our checkout to be a seamless experience, we can have
the checkout button trigger payment request, but it excludes
some payment apps
... so we've had to limit the scope of our payment request
implementation to those merchants who only accept credit
cards
... otherwise you get 2 different flows
AdamR: I heard AdrianHB said that
people can define their own PMIs
... I am also concerned about ossification
IJ: So I am hearing remove
accepted apps bits from the spec
... any design considering
<AdrianHB> Define their PMIs or use some other existing mechanism to hand-off the checkout to a specific app like custom-url protocols
IJ: I propose to add "if the merchant wants tine-grain control over apps...they can do this in several ways..."
AdamR: I think we should not talk about the anti-pattern
AdrianHB: Could say "This API is designed so that merchants do need to focus on application integration"
<scribe> ACTION: Ian to update decoupling section and remove filtering on apps from the spec and close the related issue with the resolution with link to the minutes [recorded in http://www.w3.org/2016/08/10-apps-minutes.html#action02]
https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#user-experience-descriptions
(IJ: I note that I need to remove the accepted apps column)
Andre: Add line numbers
<scribe> ACTION: AdrianHB to read the table for next week's call. [recorded in http://www.w3.org/2016/08/10-apps-minutes.html#action03]
[Adrian leaves]
AdamR: Regarding the table...I think you could collapse the table
IJ: Can we show up at TPAC with
payment app demos?
... How do we get polypill?
... Any payment app developers we could use with?
Andre: I will take away the question and see if we can find anyone to speak with.
Mahesh: I will get back to you as well.
17 August