Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316)

I’m one of the architect’s on Worldpay’s Hosted Payment Page proposition, and am looking at the proposal around canMakeActivePayment() to understand how it might work with our platform. I strongly suspect that other Payment Service Providers are going to have similar concerns / issues to us, and so wanted to contribute to this discussion.

Essentially our proposition allows Merchants a very quick time to market by providing an out of the box payment carousel and single integration to many different payment methods and providers, including cards, bank transfers, bank mandates, loyalty cards, etc. The payment journey consists of an initial set-up process where the Merchant configures our system with a list of Payment Methods they wish to accept, and then during each checkout they initialize the payment flow and then redirect the consumer (shopper / end-user) onto our platform; we then take them through the payment process with the list of the available payment methods (subject to configuration, amount, currency, etc.)  typically being the first thing the consumer sees.

In terms of how we extend our proposition to work with WebPayments, we have a couple of options; 

1. The Hosted Payment Page proposition queries canMakeActivePayment() as part of bootstrapping our carousel page, and in the scenario where paying via the browser is possible it adds a new element to the page that allows the Shopper to drop directly into the Web Payments workflow.

2. The Hosted Payment Page proposition has an initial landing page that checks to see if any browser-supported payment methods are available. If so then we pass control directly to the web payments flow; this would work well in the scenario suggested by @dlongley where we can register a 'checkout with worldpay.com' option to the Web Payments process.

Both of these suggestions would seem to fall foul of the rate-limiting though in the scenario where a Consumer buys something from Merchant A, who is integrated via Worldpay, and then goes to buy something else from Merchant B, also integrated via Worldpay, within the 30 minute period. In both cases the top-level domain would be the same (payments.worldpay.com), so we’d fail that check, and given the Merchant we’re operating  on behalf would vary between different invocations of the page the set of payment methods passed into PaymentMethodData.supportedMethods is also likely to vary; meaning we would also fail the second rate-limit check.

In some cases it may be possible to initiate the PaymentRequest from the Merchant’s site, for example if they choose to embed the proposition within an iframe or where they do an initial set-up call with us prior to redirecting the consumer; however typically Hosted Payment Pages are used by the less technically advanced customers. In this case we sell a very basic integration proposition that is deliberately kept as simple as possible; they tell our site about their inventory (including stock control if desired), we generate a unique link for each item which they then paste into their page, and the payment is initiated via the consumer performing a put or get onto that URL – hence anything to do with the PaymentRequest would have to happen from within our domain.

@maheshkk added a review comment 4 days ago that states that the quota resets ‘after the session ends; window closed / navigate away from page’ or ‘after certain timeout’. Depending on what is meant by the ‘session’ in this scenario, and how that may vary across browsers, this could help with the problem; however it would still seem to have an edge-case where the Consumer is buying things in parallel or doesn’t close the window before starting another purchase on another tab.

I should also note that I do see another potential option here; I expect many Merchants will request a more seamless integration where the Web Payments API populates our payment carousel with the individual payment methods supported by the browser, but all of the additional payment methods supported by a PSP appear alongside them. This means that if a Consumer clicks on Visa, for example, they trigger the Web Payments workflow within their browser; however if they click on an unsupported payment method they fall back into existing PSP payment flows.  From a merchant point of view this has the benefit of still providing a unified checkout process, and minimizing Consumer interactions – both of which should reduce drop-off. Technically this is largely just another integration scenario that would be subject to the same API constraints however.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/pull/316#issuecomment-264865982