Brand selection

[glelouarn]

In Europe, since the start of 2018 regulation requires to ask the buyer to select the brand it want to use when paying with a payment card supporting more than one brand. It is typically the case with CB (Carte Bancaire) in France where card are affiliated to two brands, CB and VISA or Mastercard.

As a consequence, using a CB/VISA or CB/Mastercard card in France requires the merchant to ask the buyer to select if she or he want to realize the payment using CB, VISA or Mastercard network.

How could we support that using basic-card?

[marcoscaceres]

Would just giving the following in payment request should work, no?:

  {
    supportedMethods: "basic-card",
    data: {
      supportedNetworks: ["visa", "mastercard", "cb"],
      supportedTypes: ["credit"],
    },
  },

The browser then says, "supported cards are visa, mastercard, cb".

[glelouarn]

I think it is not enough because the card support both, CB and MasterCard and we need an interaction with the buyer to know its choice to use either MasterCard network or CB network when validation card entry. That choice have to be transmitted to the acquirer and she or he will use that information during payment authorization.

[marcoscaceres]

MasterCard network or CB network

Ah, so you can have the same number, but different network? Is the use case different charges or something else?

[glelouarn]

Yes same card number and two different networks.

According buyer selected network, acquisition fees can differs. Main motivation of that regulation is to promote competition between networks giving a way for the buyer to select the one she or he want to use, even if the merchant have the availability to define default choice.

[marcoscaceres]

According buyer selected network, acquisition fees can differs.

Ok, but, today, that's handled by payment method modifiers. That is:

// merchant supports
const methods =   {
    supportedMethods: "basic-card",
    data: {
      supportedNetworks: ["visa", "mastercard", "cb"],
      supportedTypes: ["credit"],
    },
  }

const visaFee = {
  label: "Visa processing fee",
  amount: { currency: "EUR", value: "3.00" },
};

const mastercardFee = {
  label: "MasterCard processing fee",
  amount: { currency: "EUR", value: "4.00" },
};

// When you pick one... 
const modifiers = [
  {
    additionalDisplayItems: [visaFee],
    supportedMethods: "basic-card",
    total: {
      label: "Total due",
      amount: { currency: "USD", value: "68.00" },
    },
    data: {
      supportedNetworks: ["visa"],
      supportedTypes: ["credit"],
    },
  },
  {
    additionalDisplayItems: [mastercardFee],
    supportedMethods: "basic-card",
    total: {
      label: "Total due",
      amount: { currency: "USD", value: "69.00" },
    },
    data: {
      supportedNetworks: ["mastercard"],
      supportedTypes: ["credit"],
    },
  },
];

If this is just for merchant fees, then the above has you covered, no? Hmm... I guess you still need it if you need to route the payment. So maybe BasicCardResponse needs to have "type" and "network" and the browser needs to actually allow the user to pick with "mode" the card is operating under?

PS: a friendly reminder to all that when exemplifying someone by gender, please use "she or he" or "he or she", or just "they".

[marcoscaceres]

Fixed example typos above.

[glelouarn]

Many thanks Marcos for those detailed elements.,

In France use case, we aren't looking to distinguish fees for buyer. Problematic is to identify how to route the transaction according the fact that the brand information is associated to a buyer explicit choice.

As a consequence, in my opinion, BasicCardRequest should contain something like "preferedNetworks" to manage merchant networks presentation order.

Concerning BasicCardResponse, it should probably contain something like "selectedNetwork".

[marcoscaceres]

In France use case, we aren't looking to distinguish fees for buyer. Problematic is to identify how to route the transaction according the fact that the brand information is associated to a buyer explicit choice.

Right - got it: The API doesn't currently tell you which network on the card was selected by the user. Do you have a link to where this law is described (hopefully in English, if it's EU🤞)? This would mean a significant change to browser's UIs and how our card type detection code works - so need to verify this with our legal folks to understand what the law actually stipulates and who needs to comply with it.

As a consequence, in my opinion, BasicCardRequest should contain something like "preferedNetworks" to manage merchant networks presentation order.

The payment request spec says:

When ordering payment handlers and payment instruments, the user agent is expected to honor user preferences over other preferences.

The instruments part is supposed to handle "network" display, if I recall correctly. However, in case there is no preference, wouldn't the ordering in the list suffice:

    // Merchant's preferred order is...  
    supportedNetworks: ["visa", "mastercard", "cb"],

Concerning BasicCardResponse, it should probably contain something like "selectedNetwork".

Yep, makes sense.

[glelouarn]

From SEPA CARDS STANDARDISATION (SCS) "VOLUME" BOOK 2 (Vol Ref. 7.2.2.50), we have on page 35:

Req T53: The payment brands and product types accepted by the Acceptor for the transaction shall be displayed so the Cardholder can choose the application to be used to perform the transaction. The Acceptor may determine the method and the order in which the payment brands and product types are displayed to the Cardholder. If not all payment brands and product types are displayed at once for selection, the Acceptor shall inform the Cardholder how to select the other supported payment brands and product types.

[marcoscaceres]

Thanks for the pointer @glelouarn. Just to clarify:

The payment brands and product types accepted by the Acceptor for the transaction shall be displayed so the Cardholder can choose the application to be used to perform the transaction.

I think all browsers are good here, in as far as all browsers say what "type" and "network" is supported.

The Acceptor may determine the method and the order in which the payment brands and product types are displayed to the Cardholder.

This is "MAY determine" - thus optional. So this is already covered by the ordering of:

  supportedNetworks: ["visa", "mastercard", "cb"],

If not all payment brands and product types are displayed at once for selection, the Acceptor shall inform the Cardholder how to select the other supported payment brands and product types.

I think the above is also fine at a UI level for all browsers, no?

I think we only need is a proof that a credit card can have be on two networks but have the same number. Can you provide a link to show that (or a test number that I can run against bindb)?

[glelouarn]

Looking Chrome implementation, we are asked to select or add a new card:

When payment handler is selected, card acquisition process display all supported networks:

If not all payment brands and product types are displayed at once for selection, the Acceptor shall inform the Cardholder how to select the other supported payment brands and product types.

I think the above is also fine at a UI level for all browsers, no?

In my opinion, what is done seems not enough to comply, I will detail it.

If not all payment brands and product types are displayed at once for selection

We are in that case where not all payment brands and product types are displayed before selecting the payment handler. On first screen, we haven't any logo or network selection capabilities. As a consequence, we have to comply with the second rule:

the Acceptor shall inform the Cardholder how to select the other supported payment brands and product types.

One way to support that, for instance in CB case could be to:

• Display CB logo next Mastercard and Visa,
• Detect the card is supporting two networks and adapt detected network accordingly,
• Give a way for the buyer to select either CB brand or Visa/Mastercard one,
• Return that buyer choice to the acquirer because it have to be transmitted during authorization process

Note that CB and merchants are requesting for an additional requirements giving us a way to define their preferred network in the case where the buyer doesn't select the network he want to use (even if he have the choice).

I think we only need is a proof that a credit card can have be on two networks but have the same number. Can you provide a link to show that (or a test number that I can run against bindb)?

It is not quite easy to detect a card as supporting two networks, here is for instance bindb result for my personal VISA/CB card:

There is not any information according CB support and as a PSP, we need to access a specific BIN database indicating additional information such as CB support.

[adrianhopebailie]

It is not quite easy to detect a card as supporting two networks, here is for instance bindb result for my personal VISA/CB

If this is the case then who is supposed to identify the fact that the card has two networks?

How is this done today with regular card forms?

I suspect that given this is a region specific requirement I suspect it will need to be solved by the merchant. i.e. When they get the basic-card response they will need to to perform the same logic they would use for a regular card capture form today to determine if the card has multiple networks and if so, prompt the user to select one.

[glelouarn]

If this is the case then who is supposed to identify the fact that the card has two networks?

Today it is service provider.

How is this done today with regular card forms?

Page with card fields display recognized network or networks and select default merchant choice if more than one network match is detected for that card. The user can change that choice clicking on other available network logo. Using previous Google sample, it is as if we have CB next to MC and VISA logo. When car BIN is typed, for my personal card MC should be grayed, CB or MC clickable with a pre-selection of one of them according merchant choice (for instance supportedNetworks order).

I suspect that given this is a region specific requirement I suspect it will need to be solved by the merchant. i.e. When they get the basic-card response they will need to to perform the same logic they would use for a regular card capture form today to determine if the card has multiple networks and if so, prompt the user to select one.

Can't agree with that even if merchant need interaction to detect card type, we are looking for a global better user experience for all markets. Co-branded card are not exclusive to France market, even if I can't identify all of them, I suppose we have the same issue on other European or not European markets. Any people to help identifying if there are other co-branded card such as CB in France or Bancontact/Mister Cash in Belgium?

[ithinkihaveacat]

@glelouarn I'm having trouble understanding this requirement. Are there any examples/screenshots of retailers/payment providers supporting the ideal/correct flow right now? e.g. screenshots of Amazon, Fnac, PayPal, Apple Pay, etc.

Also, is this actually a requirement now? The PDF you linked to has a large "Draft" watermark on every page.

[marcoscaceres]

I’ll note that if it is a draft, we should speak to those folks. Their concept of Acceptor assumes a website, but not a browser UI coordinating with a website. That kinda makes a mess of that spec because it’s unclear who is supposed to conform.

[glelouarn]

@ithinkihaveacat , @marcoscaceres

Here is one screenshoot one solution:

Applying that regulation is recent and for the moment a few merchant are conform. I'll try to pick you real samples latter.

Effectively, the reference I gave you was a working content. Here is applicable text.

Article 8, more particularly last chapter:

6.   Payment card schemes, issuers, acquirers, processing entities and other technical service providers
shall not insert automatic mechanisms, software or devices on the payment instrument or at equipment
applied at the point of sale which limit the choice of payment brand or payment application, or both, by
the payer or the payee when using a co-badged payment instrument.

Payees shall retain the option of installing automatic mechanisms in the equipment used at the point of
sale which make a priority selection of a particular payment brand or payment application but payees
shall not prevent the payer from overriding such an automatic priority selection made by the payee in its
equipment for the categories of cards or related payment instruments accepted by the payee.

[adrianhopebailie]

That kinda makes a mess of that spec because it’s unclear who is supposed to conform.

+1 - hence my question about who is supposed to detect that the card has two networks.

In the Payment Request ecosystem, when using the basic-card payment method, the browser is just a repository of card data. The ability of the browser to perform network or card type filtering is a "bonus" but should not be assumed to always be possible (or accurate) in my opinion.

The browser shows card network logos but that is just a some UI sugar. Unless there is an open database of card BINs that can be used to correctly classify every card into the correct network and type this will always be a best effort and we can never expect browsers to get this 100% correct.

we are looking for a global better user experience for all markets

I agree but there are limits. This regulation smells a lot like the cookie notifications regulations that force websites to show notifications to their users to warn them they are using cookies, i.e. written by people with a very narrow view of the way the technology works. I don't think it is our job to work around bad regulations.

We can work with a regulator that is prepared to be open-minded and try to help them achieve their goals but they must accept that the Web is an open network, solutions that require proprietary databases of card BINs are not going to be acceptable.

I think that if we allow the user (when they store the card in the browser) to specify what network it is then we have met the obligations of the text you provide above. That said, this still requires browsers to do a lot of work to:
a) Figure out the possible networks that a user can choose from
b) Add a step in their flows to allow the user to make this selection

I don't see this as a likely candidate for implementation before CR since merchants can currently provide this network selection step after getting the PaymentResponse, even thought this is a less desirable user experience.

[ianbjacobs]

What is the implementation cost of determining and then returning selectedNetwork and selectedType for BasicCard?

[mattsaxon]

I suggest we make this a SHOULD, payment handlers/mediators could then differentiate themselves by supporting this functionality and the spec does not prevent the regulations from being met, in fact it supports it.

[mattsaxon]

Or perhaps just a MAY

[marcoscaceres]

Proposal would be to add nullable type and network members.

[ianbjacobs]

Based on discussion in Sinagpore [1], I believe our expectation is not to change this version of Basic Card but instead document this topic in the FAQ [2].

[1] https://www.w3.org/2018/04/19-wpwg-minutes.html#item08
[2] https://github.com/w3c/payment-request-info/wiki/FAQ

[ianbjacobs]

@mattsaxon, @glelouarn, @vkuntz, here is a draft FAQ entry. Comments welcome,
Ian

Q. Does Payment Request API support user choice of processing path when more than one is possible?

A. No. In some situations, there may be more than one way to process a payment. For example, a user in France might have a card that can be processed either as "Visa" (same with "Mastercard") or "Carte
Bancaire." Users may have different incentives for choosing a processing path (e.g., costs or loyalty programs).

Under some regulations (e.g., in Europe since 2018), merchants may be required to offer the user a choice of processing path. At this time, Payment Request API does not directly support this type of choice. More specifically, the Basic Card Specification does not support response data about processing choice, which means that even if a payment handler were to offer such a choice, the handler could not return the relevant information in the Basic Card response.

At this time, the Web Payments Working Group recommends that merchants and users determine
processing choice following completion of Payment Request API.

EDITED by @adrianhopebailie: s/direct/directly/

[glelouarn]

Many thanks for the FAQ item lightening FTF discussion. I’m sincerely sorry not being able to participate to the Singapore discussion and I’m really sorry again to re-open the discussion that was done during last FTF meeting.

Today, networks are considered as a static deterministic list implemented by browser agents. It works great and seems simple to appreciate at a technical and functional point of view.

However, why not to open that static list of browser default supported networks list giving capabilities for merchant to define new ones. How is defined a network? A name, an identifier and a logo? Why not to define a manifest format for that?

With a standard network manifest format, a merchant will be able to extend browser default list with local networks she or he wants to support. Last question to solve is how to detect non built-in networks? Why not to use an event listener similarly to what was done for shippingaddresschange?

It could be an event like cardbinchange giving a way for the merchant to implement its local brand detection. In case the browser build-in detection resolve the brand differently of the merchant implementation, why not to let the merchant ask consumer to select the brand he want to use?

What would be the complexity to implement such model in basic-card?

Just to try having a broader understanding according functional problematic, please take a look on page 2 of that presentation representing card payments in Europe (light blue=international schemes, dark blue=local schemes):

My personal feeling is that if browser implementation doesn’t support local schemes, there is no chance for those implementation to be generalized on market with strong local brand such as France. Alternative will probably be to use specific merchant/brand payment handlers but if we go in that direction, what is the interest to invest on browser “basic-card” native implementation?

[stpeter]

@glelouarn This is a valuable suggestion. However, I am not sure if we want to give merchants the ability to define local schemes at "run time" - this seems to be something we might want the schemes (e.g., Carte Bancaire in France or non-card schemes like Boleto in Brazil) to define via manifest and register with the browsers at "compile time".

[adrianhopebailie]

@glelouarn thanks for this info, the data around use of local networks is very compelling and I think we'd see similar numbers in countries outside Europe (such as Japan) where local networks are much more widely supported than the large international networks.

You asked:

Today, networks are considered as a static deterministic list implemented by browser agents. It works great and seems simple to appreciate at a technical and functional point of view.

However, why not to open that static list of browser default supported networks list giving capabilities for merchant to define new ones. How is defined a network? A name, an identifier and a logo? Why not to define a manifest format for that?

This has been a point of contention in the group for some time however given that the networks represented in the group are predominantly international networks it has maybe not had the level of focus you'd like.

The list of possible networks is hard-coded by the browsers and comes from here https://www.w3.org/Payments/card-network-ids. I understand this to be for security reasons. i.e. Browsers want to do strong data validation of built-in payment methods and that requires enumerations to be well-defined (i.e. this can't just be a set if random strings).

Things have moved along a bit since so perhaps @marcoscaceres, @aestes or @zkoch can comment on the viability of making the list of networks more flexible.

That said, I would recommend following the change request procedure defined in the card-network-ids document to add any regional networks you think need to be in the list.

As a general comment it does seem that the design of the basic-card payment method (and in some respects the PR API) continues to be very biased toward the US market which is unfortunate.

What many of the discussions in Singapore highlighted for me is that implementing a payment handler for basic-card (whether built into the browser or as a stand-alone handler) will require some level of BIN matching capabilities, which is something of a dark art considering there is no authoritative source on BINs, issuers and networks that I am aware.

We continue to skirt this issue but I think we are simply pushing this complexity onto merchants (like we have done to date with gift cards, coupons, billing address collection etc).

It would be helpful to understand how merchants are expected to do this under current legislation so we can understand the impact it would make on the API if it were implemented.

i.e. If a merchant gets a PAN back from the PR API how are they expected to determine that it is a multi-network card? Is there a public database they can use to look this up?

[stpeter]

I'd agree with @adrianhopebailie - let's figure out how to address this in the card-network-ids work. For basic-card, the BIN issue is indeed a mess for the user agent. As one example, we don't want to ask for the billing address if the card is prepaid, but figuring out if the card is prepaid requires black magic and is not all that reliable. Another example is multi-network cards (which again the browser might want to determine on behalf of the user).

[glelouarn]

@adrianhopebailie, @stpeter, many thanks for your precision.

Just to be sure, if we want local network be represented as a brand in browser basic-card native implementation, we should:

• Reference network in https://www.w3.org/Payments/card-network-ids (it seems already done for Cartes Bancaires).
• Define a way to detect the brand from the BIN. Is that detection must be static (managed locally to web browser) or can be computed remotely (using remote BIN detection service)?
• In case of co-branded network, find a way to manage multiple brands selection but it seems complicated and we are not sure browser vendors have to go in that direction?

As one example, we don't want to ask for the billing address if the card is prepaid, but figuring out if the card is prepaid requires black magic and is not all that reliable.

Fully agree, in my opinion such capabilities are region specifics and I’m not sure it is the right place to manage that logic in browser. In my mind, such regional or business logic must be delegated to merchant and it was the sense of my proposal including a listener on ‘cardbinchange’ to delegate brand detection to merchant.

[adrianhopebailie]

Fully agree, in my opinion such capabilities are region specifics and I’m not sure it is the right place to manage that logic in browser. In my mind, such regional or business logic must be delegated to merchant and it was the sense of my proposal including a listener on ‘cardbinchange’ to delegate brand detection to merchant.

This sounds like it might be a good starting point to address this. Could you expand a little on how this might work? Maybe a polyfill or even some pseudo-code?

[ianbjacobs]

Rather than a new "cardbinchange" could we leverage "paymentmethodchange" [1]?

Also: Suppose I could store the card in my browser twice: once with "Visa" as the supportedNetwork, once with CB as the supportedNetwork. The browser could show me one or both (according to what the rules require and what the merchant expresses through PR API). There would have to be some UI tests to see whether seeing the same card twice with two different networks is confusing.

Then the question is: how does the browser know all the supportedNetworks?

Ian

[1] https://github.com/w3c/payment-request/pull/695/files

[marcoscaceres]

Rather than a new "cardbinchange" could we leverage "paymentmethodchange" [1]?

Possible.

once with "Visa" as the supportedNetwork, once with CB as the supportedNetwork.

Browser's currently derive this automatically by looking at the BIN.

The browser could show me one or both (according to what the rules require and what the merchant expresses through PR API).

True... the browser could then allow the user to override the network(s).

There would have to be some UI tests to see whether seeing the same card twice with two different networks is confusing.

Sure, but that's an browser vendor concern (not a standardization or regulatory concern).

Then the question is: how does the browser know all the supportedNetworks?

I guess some kind of picker.

[glelouarn]

I don't fully understood how "paymentmethodchange" works. Saying "possible" are you assuming that one event will be called more than one time while typing card number in a basic-card implementation (for every digit)? Will we be able to interact with browser to get back to it detected brand(s)?

I discussed with CB and it seems they are opened to consider a solution where they provides a service to detect brands supported by a card from PAN first digits. Supposing such a service exist:

• Could we integrate such a service calls natively in browser?
• If not, why not to only support natively global brands and give capabilities for merchant/PSP to manage that detection using "payentmethodchange" event?

Is there any of us able to go ahead on that topic with other brands such as "Girocard", "Bancontact"...

[marcoscaceres]

Spec was deprecated. No longer applies.