Storing card information

[adamroach]

The flow in the current "Basic Card" spec has an annotation to the effect of "Merchant can store card details for future use (aka 'card on file')." I think this is actually behavior we want to discourage very strongly, rather than encourage.

The current web environment -- absent webpayments -- does lead to a situation where it is very much in merchants' interests to store credit card information, as the only other alternative is requiring customers to re-enter the information for each purchase. With the API that we're designing, this rationale goes away completely: since the user agent will store credit card information, the merchant site only needs to call the API to retrieve the card information whenever it is needed.

This provides a number of benefits.

First, it removes persistently stored credit card information from the middle of the network, where is it demonstrably vulnerable to capture by hostile parties. There have been a large number of high-profile cases recently that arise only because of the tendency to store card information. We can help the web move away from that.

Second, it provides users the convenience of only needing to update changed credit card information once -- in their user agent -- rather than once per merchant. Since the merchant can interact with the UA to retrieve completely up-to-date information, we can eliminate the friction of web sites having to request updated expiration dates, and eliminate the hassle of updating myriad web sites when assigned a new credit card number (e.g., due to a lost card).

Finally, this approach provides the user additional information, agency, and control over their information, as they can be presented with indicia and/or controls any time payment details are accessed.

I would propose (a) removing the suggestion of storing credit card information from the flow, and (b) adding text strongly discouraging sites from storing credit card numbers, in favor of querying the user agent each time.

[nickjshearer]

I would propose (a) removing the suggestion of storing credit card information from the flow, and (b) adding text strongly discouraging sites from storing credit card numbers, in favor of querying the user agent each time.

How would this work for merchants who were selling subscription services and wanted to still support basic card payments?

[rsolomakhin]

Both of you bring up good points. We can reword the phrasing to discourage storing credit card numbers, unless required for subscriptions.

[adamroach]

@nickjshearer asks:

How would this work for merchants who were selling subscription services and wanted to still support basic card payments?

I think @rsolomakhin describes a good balance for basic card, at least for now (that is, unless we can come up with something better).

However.

In most discussions I've heard so far, basic card is treated as a transitional technology, which we hope will soon be supplanted by something inherently more secure, such as token schemes. By my understanding, these schemes do not expose credit card information directly to merchants, instead interacting with a payment app to get a limited-use token which is then provided to the merchant.

Along a similar vein, electronic wallet schemes such as Apple Pay, to my understanding, employ what has been described to consumers as a "transaction-specific dynamic security code," which I would presume is non-reusable.

I'm also confident that providing you with the information necessary for me to transfer modern cryptocurrencies into your possession cannot reasonably provide information that would allow you to effect future transfers.

So, your query about handling subscription services is something that probably deserves additional thought. The basic card scheme is something of a rare unicorn in that it allows storing of information that can be used multiple times. We would be foolish to rely on its behavior in general, since other schemes won't be as amenable to such a setup.

[rsolomakhin]

As an example of other schemes handling recurring payments, Stripe's tokenized payments allow for subscriptions. Although it is Stripe that holds on to your information in this case, not the merchant. I'm not sure how that's implemented on Stripe side. In either case, the merchant should not be holding on to Stripe tokens.

[mattsaxon]

There are various use cases for tokenisation and these are closely linked to the recurring payment use cases that are discussed elsewhere.

Certain scenarios, even with the use of tokenisation, require the merchant to hold the token. An example of a repeat payment where the billing points are driven by an adhoc trigger, e.g. Consider where the trigger occurs away from the web browser.

I dont believe we should look to constrain the ecosystem, but we can point out the trade offs of the various approaches.

Be aware that the basic card payment specification at the moment requires the merchant to achieve a 'fuller' PCI certification as unencrypted PANs pass via the merchants site. This is irrespective of if the cards at stores.

As has been stated, we need to explore other more secure payment methods, basic card is just the start.

[adrianhopebailie]

As has been stated, we need to explore other more secure payment methods, basic card is just the start.

👍 to @mattsaxon

I'd be loathe to be too restrictive in the basic card spec because as @adamroach points out this is intended to be an interim step to bootstrap the system. (I originally proposed that we call it "Legacy Card Payments" to indicate this).

Any merchant that implements a website supporting this payment method will be subject to PCI DSS restrictions anyway so I'm not worried that they will be storing card details for future use unless they have all the checks in place. In fact, if they can avoid it, and the expensive PCI DSS audits that come with it they will.

My hope is that we will quickly see new payment methods that are designed for use by the card networks but don't require exchange of PANs at all.

We should also bare in mind that there are different types of tokenization. On the one hand we have tokens that are generated by the merchant PSP so that the merchant has a re-usable (but not PCI DSS sensitive) token it can use to initiate future payments (like for subscriptions).

I think we could put a pretty simple payment method spec together that defines a payment method like that but I don't think it should be in the basic card payment spec. This spec would need to provide an easy on-ramp for the likes of Braintree and Stripe that hold stored card details for millions of card holders and would like to leverage this to not use the basic card payment method.

On the other hand, issuer tokens are different and are provided by the payer instead of a PAN right from the beginning. The merchant and their PSP may never even see the original PAN. This type of system is not catered for by any of our payment method specs today and probabaly shouldn't be.

My assumption is that this is the kind of payment method that will be defined by the schemes themselves in collaboration with the entities that do issuer-side tokenisation and that payment apps will simply need to store the tokens and send them as part of the payment.

[adrianhopebailie]

Migrated to w3c/payment-method-basic-card#2