How do we transition users and merchants from the current system to using the new API and apps?

[mattsaxon]

Consideration needs to be given to the user experience during transition to the WebPayments API.

During this period there will be the following issues;

1. Merchants wanting to accept payments methods where no payment application exists
2. Customers having no payment applications registered

To ease adoptions, these important situations need considering by the group.

[rsolomakhin]

Customers having no payment applications registered

Perhaps a browser can show a link to download, install, or open the payment app that is not registered. Something like this:

--------------------
    PAY: $10.00
 [pay with app abc]
 /install app xyx/
           [cancel]
--------------------

Here the "xyz" app is in the list of supported instruments of the merchant, but not registered on customer's computer.

[dlongley]

I added a related issue to the Web Payments Browser API spec here: WICG/historical-web-payments-browser-api@6d4c9e9

[rsolomakhin]

I would imagine that a custom payment instrument would be a URL, like so:

var supportedInstruments = ["https://thepaymentapp.com/pay"]

That URL can host both a payment website at index.html and links to related applications via manifest.json. For example:

{
  "related_applications": [
      {
        "platform": "play",
        "url": "https://play.google.com/store/apps/details?id=com.thepaymentapp.app1",
        "id": "com.thepaymentapp.app1"
      }, {
        "platform": "itunes",
        "url": "https://itunes.apple.com/app/thepaymentapp-app1/id123456789",
      }]
 }

[adrianhopebailie]

@mattsaxon given that the specs have matured somewhat since this was opened, do you have any thoughts on addressing this?

[mattsaxon]

@adrianhopebailey, the specs have matured, but I don't see anything that specifically relates to adoption. For example there is no facility for a merchant to migrate their cards on file info into a registered payment application. This issue is really saying we should be explicit about our thinking on adoption rather than write a spec and hope it will become adopted.

[adrianhopebailie]

This issue is really saying we should be explicit about our thinking on adoption rather than write a spec and hope it will become adopted.

👍 - do you have any proposals about how we would do this?

[corwinAmbre]

Could 3rd party integration be leveraged for that? Most of e-commerce merchants are relying on 3rd party in an iframe or a dedicated page to display actual payment step because of compliance rules or 3rd party strategy. They could act as hubs to move to payment applications with limited impact on merchants as merchants will continue to receive notifications from the 3rd party.
Merchants integrating payment methods as API will have more work to do to move to application system and it'll take a while depending of priorities, browser support...

[mattsaxon]

@adrianhopebailie , my proposal would be to create a WG use-cases document which focused on a more technical break-down of the IG uses cases which are customer scenario focused, not customer experience focused.

Example use cases to add would be;

1. Registration of stored payment details into a payment application

I suspect this needs consideration in the registration API to cover not just registration of apps, but also of instruments to apps.

1. Invocation of specific payment method by a merchant

I suspect that this needs no changes to the API, but is a worthwhile case to consider such that a merchant can invoke the API for one payment method, have this cancelled, then invoke a different payment method. This would effectively bypass the mediator to a large extent (unless multiple apps with the same PMI were registered)

We could use this document to capture other requirements we are identifying as they emerge.

[mattsaxon]

@corwinAmbre, I suspect you are correct, we just need to make sure the API work well in that context. There is an outstanding issue about should iframe invocation be allowed. I believe we need to be able to support this for such use cases.

[corwinAmbre]

Actually, due to PCI compliance rules, most of payment processing on ecommerce platforms are done by calling 3rd party into an iframe or a dedicated page. Currently, if you have the form defined in your hosted page as a merchant (to control UX), even if data are not coming to your server but directly to the payment provider, you have to be PCI compliant (level PCI A-EP). In case this group defines any new flow which could bring merchants into PCI compliance, we could be sure that merchants won't adopt it.
So yes, supporting iframe will be mandatory for me

[mattsaxon]

Agreed, the current flows for basic card are problematic until we add a tokenisation or encryption capability because of this.

[corwinAmbre]

As all payment providers have their own tokenisation system I don't think we will be able to promote a common one because of each one architecture, security and also features they provides to the merchants based on tokens.

[mattsaxon]

I haven't looked at this yet in great detail, but I think the API should be able to support the notion of an opaque token. However the Payment App and the Acquirer/Scheme/Issuer will probably be coupled because of the observation you made about non standardisation of tokenisation systems.

[ianbjacobs]

@mattsaxon,

Could you put this on a Flows Task Force agenda? I think there are two resources that we will want to start to work on:

• How to write a payment method specification
• How to apply the API in a variety of scenarios. (see your use case above).

I think the task force should start to put those documents in our wiki so that we can add to them as use cases arise, and get support from the community that is attempting to use the API.

Ian

[ianbjacobs]

Closing this issue for lack of activity.