Re: [w3c/payment-request] Consider specifying a testing IDL for a mock payment UI (#799)

I started looking at how we might implement such a test API in Chrome. The main thing I'd like is a way for tests to inject a payment instrument (e.g. credit card or payment app). We currently have some test hooks that can directly manipulate the database in the browser process [1]. To make this available to WPT, we'd need to expose corresponding JavaScript bindings. This raises two issues:

1. Increase in binary size. Is it worth it for a test-only API?
2. Website abusing the test API to confuse user (e.g. injecting a bogus payment instrument that makes it looks like to user that their browser is hijacked), even if they cannot directly steal money from user's existing payment types.

What do other vendors think about these?

As a data point, the Chrome Web Bluetooth folks ran into similar issues [2] and decided to put the test API behind a compile flag, so it's only available for `content_shell`. The downside was that the tests can't be run using the regular web platform test scripts.

[1] https://cs.chromium.org/chromium/src/chrome/browser/ui/views/payments/payment_request_browsertest_base.h?l=181
[2] https://docs.google.com/document/d/1Nhv_oVDCodd1pEH_jj9k8gF4rPGb_84VYaZ9IG8M_WY/edit#heading=h.ydr456a07ivp

-- 
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/payment-request/issues/799#issuecomment-460448050