Credit Card Payment Trusted "Frame"




2 years ago
2 years ago


(Reporter: brady, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [specification][type:feature])



2 years ago
What problem would this feature solve?
Currently, most outsourced payment providers (e.g. Stripe, Braintree) require a customer to trust a merchant at minimum in the form of an iFrame URL that the merchant's site gives the customer in order for the customer to supply their payment details directly to Stripe and not to the merchant. This still leaves a security issue in that the merchant can influence who the customer supplies their card details to via that iFrame.

Who has this problem?
all sites that take credit cards

How do you know that the users identified above have this problem?
I've had the issue as a merchant

How are the users identified above solving this problem now?
Lots of security infrastructure and PCI compliance costs.

Do you have any suggestions for solving the problem? Please explain in detail.
If the browser vendors offered a "tag" in the form of <payment provider="stripe" />, it could shift the burden of trust away from the merchant towards a few browser vendors. The browser would render an iFrame (or some form setup) with its own mapping of "stripe" => "". The main downside here is that Firefox would have to maintain a list of providers to URLs although there are probably fewer of those than there are root SSL CAs. The upside could save tons of money in PCI compliance costs, especially for small organizations.

Is there anything else we should know?
Component: Security → Untriaged
Product: Mozilla Developer Network → Firefox
Component: Untriaged → Security

Comment 1

2 years ago
This is a product/web feature, not a security feature. Yes, it would need to be implemented securely, but that's not the same thing.
Component: Security → General

Comment 3

2 years ago
I agree that it's not a security feature for Firefox per se. It's more of a security benefit to web app developers.

Comment 4

2 years ago
(In reply to Daniel Veditz [:dveditz] from comment #2)
> This is a product/web feature, not a security feature. Yes, it would need to
> be implemented securely, but that's not the same thing.

What do you mean?  There's no support in browsers for schemes like the one Brady outlined.

Comment 5

2 years ago
Anyway, Apple Pay and Android Pay for the Web solves this problem and in a more thorough way.

The problem is rather that third-parties have no access to such technology since it requires native extensions which are anything but standardized.  The latter is "by design" according to hard-core Web architects.
You need to log in before you can comment on or make changes to this bug.