3 ms·

What is the support like for storing payment information with a site? Ex: example.com wants to store my payment information to help expedite future purchases.

What is the support like for storing payment information with a site? Ex: example.com wants to store my payment information to help expedite future purchases. I ask this as someone who works at a large online retailer whose CISO has specifically asked to keep them informed of things that could improve our security posture around payments. Inability for a site to store payment information would discourage large sites from supporting this, or at best slow the implementation and support of it. Apologies if this is somewhere in one of the two documents. I tried to skim through the ~150 pages to find related items.

ahopebailie 7y ago
The APIs aren't really designed to solve for this. If the site knows you and has payment credentials stored they won't need to use Payment Request API (although they still can). Storing payment credentials differs by payment method. If you're talking about card payments then you have to deal with things like PCI-DSS and/or tokenization but there are other ways to pay which may support this use case more explicitly, for example by capturing explicit permission from the user to allow the merchant to make future purchases seamlessly. This is something we're trying to find a standard protocol for with https://openpayments.dev https://openpayments.dev so that the ecosystem is less fragmented. But, this is not linked to the W3C work explicitly
rictic 7y ago
Worth questioning why you want to store payment info. One common reason is for a faster subsequent checkout experience. If this API gives a fast checkout experience without storing data, then you've potentially got the benefit of storing payment info without the exposure of storing sensitive data. (disclosure: I work at google on the web, but not on anything payments related)
- rene_kapusta 7y ago
  Regarding storing sensitive data at the client -- how good / bad / secure is it to store data in the IndexedDB store (as this is the only option for web apps used in the PR modal)?
- strictnein 7y ago
  Imagine the multiple ways a customer interacts with a large retailer. It won't always be through a specific browser tied to a Google/etc account. They'll likely order things through their work computer, home computer, phone browser, retail app, etc. The common account between those all will likely be the retail store's account, not a Google/etc account. At a certain scale, any reduction of friction results in $xx million in increased sales.

ahopebailie 7y ago

The APIs aren't really designed to solve for this. If the site knows you and has payment credentials stored they won't need to use Payment Request API (although they still can). Storing payment credentials differs by payment method. If you're talking about card payments then you have to deal with things like PCI-DSS and/or tokenization but there are other ways to pay which may support this use case more explicitly, for example by capturing explicit permission from the user to allow the merchant to make future purchases seamlessly. This is something we're trying to find a standard protocol for with https://openpayments.dev https://openpayments.dev so that the ecosystem is less fragmented. But, this is not linked to the W3C work explicitly

rictic 7y ago

Worth questioning why you want to store payment info. One common reason is for a faster subsequent checkout experience. If this API gives a fast checkout experience without storing data, then you've potentially got the benefit of storing payment info without the exposure of storing sensitive data. (disclosure: I work at google on the web, but not on anything payments related)

rene_kapusta 7y ago
Regarding storing sensitive data at the client -- how good / bad / secure is it to store data in the IndexedDB store (as this is the only option for web apps used in the PR modal)?
strictnein 7y ago
Imagine the multiple ways a customer interacts with a large retailer. It won't always be through a specific browser tied to a Google/etc account. They'll likely order things through their work computer, home computer, phone browser, retail app, etc. The common account between those all will likely be the retail store's account, not a Google/etc account. At a certain scale, any reduction of friction results in $xx million in increased sales.