Location declaration

[davidbenoit]

I am struggling to figure out how to use the Payment Request API in conjunction with basic-card, and meet the Location Declaration rules from Visa.

Specifically, rules regarding entities with multiple locations for online processing:

A merchant with multiple merchant locations must only assign the merchant location that is appropriate to each transaction ...

and

... your website must prominently display the merchant country that will be used to process the
transaction on either the checkout screen used to present the final transaction amount or within the sequence of web pages that the cardholder accesses during the checkout process. It must not be a link to a separate page. It is important that the cardholder knows whether the transaction will be domestic or international before the cardholder commits to the purchase. ...

Specifically, I am dealing with the case where I don't know which entity will be designated for the first clause until the cardholder has specified the first 6 digits (IIN) of the card. At that time, I will know where the card was issued, and how to best match a merchant entity with the issuing bank of the card. But I need to know that information and have a method to present that information to the cardholder before they commit to purchase (see above).

With PR, I don't seem to have any opportunity to present that information. The final step of the payment sheet is too late to make that declaration - declaring it after clicking "buy" is not an option.

Am I missing something, or is this not currently possible with PR?

[rsolomakhin]

Hi @davidbenoit . basic-card in Chrome will not share the first 6 digits of the card with the merchant until the user has clicked the "Confirm" button on the CVC unlock screen of the Payment Request UI.

I recommend that you call paymentResponse.complete('unknown') at this point to dismiss the Payment Request UI, analyze the first 6 digits of the card and present to the user an HTML UI that displays the country and prompt a user action to proceed, e.g., a <button> click.

It's unfortunate that the full transaction cannot be completed within the Payment Request UI here. It may be possible in the future to utilize either modifiers or paymentmethodchange event to improve this user experience.

[davidbenoit]

Agreed that this is the only way that I could use this right now, but would an enhancement to the API make this possible in a future release? If we're aiming to have a unified checkout experience using PR, this type of hack destroys that.

[rsolomakhin]

would an enhancement to the API make this possible in a future release?

Yep, if you have a few locations, you should be able to call PR API like so:

new PaymentRequest[{
    supportedMethods: 
      'basic-card',
  }], {
    total: {
      label: 'Total',
      amount: {
        currency: 'USD',
        value: '1.00',
      },
    },
    modifiers: [{
      supportedMethods: 'basic-card',
      total: {
        label: '(Canada) Total',
        amount: {
          currency: 'CAD',
          value: '1.00',
        },
      },
      data: {
        cardNumberPrefix: '411111',
      }
    }]
  }).show();

Such an enhancement would require some changes to either this spec or to https://w3c.github.io/payment-method-basic-card/.

[davidbenoit]

I'm not sure I could encode all of the rules for which location I want to choose in that way - the prefix list is long, and changes often. I would think that a callback/hook similar to onshippingaddresschange would be ideal; it could take the prefix as input and modify the sheet in the same way.

[ianbjacobs]

Hi @davidbenoit,

I have some questions:

• Are the location declaration rules required by other card networks?
• Is the merchant's PSP the only entity in a position to answer the question "how to best match a merchant entity with the issuing bank of the card"?

Ian

[1] https://lists.w3.org/Archives/Public/public-payments-wg/2018Nov/0008.html

[rsolomakhin]

Hm, it's tricky to communicate to the user that the first 6 digits of their card will be shared with the merchant when they select a card in the UI, which is what you seem to be proposing to do via the paymentmethodchangeevent. There's a way to keep the user in the payment sheet through paymentResponse.retry(), but we would have to expand that API to support non-error cases as well. For example:

// Show notification after user confirms payment.
if (/^411111.*/.exec(paymentResponse.details.cardNumber)) {
  // Returns when the user acknowledges the notification.
  await paymentResponse.retry({'notification': 'Merchant country: CANADA'});
}

@aestes : Do you have a way to handle this better?

[ianbjacobs]

Also, does this relate to @aestes observation about a use of updateWith for a non-error case?
w3c/payment-method-basic-card#72 (comment)

[davidbenoit]

I should have been a bit more clear in my requirements for this too :) In my current non-PR implementation, I use a combination of the currency, IIN, and billing country to determine the entity that merchant that is actually responsible for the transaction. Also, that entity name is what I need declared, since when I change from, say, a default of "WidgetCo, LLC" to "DifferentUkWidgetName, PLC" - not just/only declaring the country. The full document is more clear on this (still kinda vague), but the name of the company and the country associated are required to be disclosed to the consumer.

@ianbjacobs : I am not aware of other networks having this requirement, but maybe they are just riding the coattails :)

[marcoscaceres]

Making as "future feature candidate"... I'm still a bit unsure about what the exact requirements are here?