Specifying Mandatory Data

[mattsaxon]

It needs to be possible for a merchant to specify mandatory data for a payment.

Whilst this is somewhat related to issue #9, it is distinct because that issue talk about the mandatory data from a payment scheme perspective.

However a merchant must be able to tell the payment application that a CVC and/or the billing address is needed for a particular payment. This will depend on the merchants risk stance for the particular transaction.

[adrianhopebailie]

Could this be interpreted as a requirement for the payment method specs?

i.e. Today we simply list a set of payment method identifiers that are applicable to the spec whereas perhaps we should consider the case where the spec defines a generic data format for requests and responses and depending on the specific payment method selected there are additional constraints.

[mattsaxon]

Following the pattern I see emerging, to meet the requirement, I believe we need a BasicCardRequest object that is passed into the PaymentRequest constructor in the data field.

I'm unclear at this stage if we need a more generic way of doing this, but my suspicion is that we do need a base Request structure and Response structure that BasicCardRequest and BasicCardResonse derive from.

Since I'm not Javascript and WebIDL expert, I'm not sure the right way to model this.

[rsolomakhin]

a merchant must be able to tell the payment application that a CVC and/or the billing address is needed for a particular payment.

How about adding this to the payment options along with requestShipping?

var options = {
  requestShipping: false,
  requestCardSecurityCode: true,
  requestCardBillingAddress: false
};

• Advantage: simple.
• Disadvantage: not all payment apps provide cards, so this information does not fit nicely into the common options object.

[zkoch]

How about adding this to the payment options

I think options is going to get overloaded really quick if we start doing that.

I think my preference for now is for us to just recommend in the basic card spec that payment apps should always return: card number, expiration, cvc, name on card, billing address

If the merchant doesn't need all of that, they can just ignore what they don't need.

[webpayments-specs]

Uggh. I mean, you are right. They can definitely ignore what they do not
need. On the other hand, we are exposing very private data that was never
requested.

On Tue, Mar 29, 2016 at 4:22 PM, Zach Koch notifications@github.com wrote:

How about adding this to the payment options

I think options is going to get overloaded really quick if we start doing
that.

I think my preference for now is for us to just recommend in the basic
card spec that payment apps should always return: card number, expiration,
cvc, name on card, billing address

If the merchant doesn't need all of that, they can just ignore what they
don't need.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#97 (comment)

-Shane

[mattsaxon]

-1, requesting unnecessary information leads to greater cart abandonment. I think that the info should go in a separate field, probably the object data field, which is supposed to contain payment method specific data. Should this perhaps be named PaymentRequestData?

[dlongley]

+1 to @mattsaxon ...

As I've argued elsewhere, we probably want "data" to be more broadly scoped. It would also be better, in my view, to allow the consumption of payment request messages that may include these sorts of extensible options -- at any place in the message. This may be related to #15.

[mattsaxon]

I've got a PR waiting to be submitted on this, but am just waiting for CfC lockdown to be removed (if it hasn't already).

[sideshowbarker]

I've got a PR waiting to be submitted on this, but am just waiting for CfC lockdown to be removed (if it hasn't already).

As the new guy here, the notion of a “lockdown” blocking submission of PRs seems really odd to me. Is it just some informal understanding about the core contributors from the WG, or is there an actual documented policy somewhere about that? How are 3rd-party contributors supposed to know there’s a lockdown on submitting new PRs?

From where I sit, it seems like you should be able to just go ahead and submit your PR rather than waiting. But maybe I’m misunderstanding something.

[mattsaxon]

Probably my mistake then, I'll submit now, PR #114

[adrianhopebailie]

@mattsaxon can you have a fresh look at this and close or migrate to https://github.com/w3c/webpayments-methods-card/issues/

[msporny]

What was the resolution on this issue?

[ianbjacobs]

My understanding from @adrianhopebailie is that this "mandatory" instruction would be payment method specific information. I don't know whether it has made its way yet into the basic card spec.

I presume that at some point, if this becomes useful across payment methods we could add it to the payment request API as a standard field.

Ian

[msporny]

I don't know whether it has made its way yet into the basic card spec.

We should keep the issue open until /something/ makes its way into a spec or we decide to not address this issue.

[adrianhopebailie]

We have decided not to address the issue until such time as there is evidence from multiple payment method specs that this is a feature worth standardizing.

Having an issue open that says "We may do something here in future" adds no value as an issue that we are tracking.