Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

If a card payment fails, should we support exclusion of that card instrument from matching? #237

Closed
ianbjacobs opened this issue Aug 15, 2016 · 4 comments

Comments

@ianbjacobs
Copy link
Collaborator

Scenario:

  • User chooses a card to pay
  • Basic card data is sent to merchant,
  • Payment fails (e.g., card rejected after some validation)

Should there be a mechanism whereby the merchant can re-invoke the API with some data
about the failed instrument, and the browser can take it into account in a variety of ways,
such as:

  • Excluding it from the list of available instruments, or
  • Highlighting it as "having failed previously"

The use case may be extensible to other pull methods, but I'll focus on cards for now.

My sense is that we should not add such a feature in v1. Merchants can display an
error message and ask the user to pick another card, and we can rely on the user
to do the right thing (or fail again).

It does not seem to me that merchant-applied filtering (e.g., "this time around I don't take
cards of this type") using Zach's proposal is the right solution since that is not instrument-specific.

Ian

@halindrome
Copy link
Contributor

Unless the payment method has a unique identifier (NOT THE PAN) that the merchant can use to call it out to the mediator, I cannot imagine any way to support this. So, question: do we have that?

If we do not have that, then a merchant can always 1) remote that type of card from their accepted forms of payment, or 2) just remember it and reject another attempt with the same card in the same session (flag it to their own JS running in the user agent).

I personally wouldn't want the merchant passing my PAN around nor remembering it from session to session. But that's why I want support for things other than basic card ;-)

Conversely, if a payment app knows that a payment method has failed (because they are processing the payment request and returning a token indicating success or failure of the payment) I am perfectly comfortable with the Payment App conveying this information to the user and omitting the payment method from the available collection. That's the job of my smart wallet - don't let me overdraw my checking account (or whatever).

@arthurchow
Copy link

Perhaps not a PAN being passed around, but maybe {paymentnetwork: visa, cardIdentifierIndex:1, result: failed} so the browser would interpret that and won't present card 1 from being shown to the user on try #2?

@adrianba
Copy link
Contributor

I don't believe any changes should be made here at the moment.

There are two aspects to consider:

  1. What do you do if there is a payment failure (e.g. card declined) and you need to ask again?
    This is something that we will need to spend more time on but I don't think we need to in v1.
  2. If there is a payment failure, should the failed instrument somehow be removed.
    I don't believe there is a case to support this. Failure could occur for many reasons some of which can be corrected by the user. For example, a large transaction might be declined by an issuer but a phone call to their customer service line might enable the transaction to succeed when re-attempted.

I recommend closing this issue.

@ianbjacobs
Copy link
Collaborator Author

Closed per discussion at TPAC 2017:
http://www.w3.org/2017/11/06-wpwg-minutes#item08

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants