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

Specification of required fields #114

Closed
wants to merge 4 commits into from
Closed

Specification of required fields #114

wants to merge 4 commits into from

Conversation

mattsaxon
Copy link
Contributor

I'm suggesting a sequence string field that allows mandatory fields to
be specified and have removed some of the 'required' specifications in
the BasicCardResponse, related to discussion on
#9. I've only left PAN as

required as I think that is a safe assumption, then the merchant can
specify for example that CSC must be supplied for a particular
transaction using the requiredFields sequence in the BaseRequestData
dictionary.

I'm suggesting that if we like this model, we would move this
BaseRequestData dictionary object into the PaymentRequest API spec to
allow other payment methods to extend it.

I'm sure there are other ways to do this and am a newbie to
WebIDL/JavaScript APIs, so please forgive if I've modelled this
completely wrong for the language. I'll learn!

mattsaxon added 4 commits March 20, 2016 14:44
…y understanding of option 1 in the Payment Method Identifiers spec
I'm suggesting a sequence string field that allows mandatory fields to
be specified and have removed some of the 'required' specifications in
the BasicCardResponse, related to discussion on
#9. I've only left PAN as
required as I think that is a safe assumption, then the merchant can
specify for example that CSC must be supplied for a particular
transaction using the requiredFields sequence in the BaseRequestData
dictionary.

I'm suggesting that if we like this model, we would move this
BaseRequestData dictionary object into the PaymentRequest API spec to
allow other payment methods to extend it.

I'm sure there are other ways to do this and am a newbie to
WebIDL/JavaScript APIs, so please forgive  if I've modelled this
completely wrong for the language. I'll learn!
@mattsaxon mattsaxon changed the title Gh pages Specification of required fields Apr 2, 2016
@adrianhopebailie
Copy link
Collaborator

I'm +1 on the basic ideas here but unsure if we should have WebIDL in these specs at all.
See #132 for a discussion of that topic in general.

@mattsaxon are you happy to hold on this until we get a resolution on #132 or would you like the editors to merge and then change it later if required?

@burdges
Copy link

burdges commented Apr 10, 2016

Apologies if this sounds kinda obvious : We should make it clear the payment app's preferences and defaults dominate here over the merchants, unless the payment app knows it cares about specific preferences from the merchant. If we do not, then we'll might wind up with sill stuff like a combined BTC and CC wallets that hand out your CC billing address even when buying with BTC.

@mattsaxon
Copy link
Contributor Author

I think we should merge now, the ideas are agnostic to the language we use to define them. If we change documebtation approach, we will do it then.

@mattsaxon
Copy link
Contributor Author

Closed awaiting resolution to PR 133

@rsolomakhin
Copy link
Collaborator

I'm suggesting a sequence string field that allows mandatory fields to
be specified

+1 from me here. This would look sensible to me:

var request = new PaymentRequest([{
    supportedMethods: ["visa", "amex", "mastercard", "discover"],
    data: {
      requiredFields: ["cardNumber", "cardSecurityCode", "billingAddress.postalCode"]
    }
  }]);

This should be specified in Basic Card Payment, right?

@ianbjacobs ianbjacobs mentioned this pull request Jun 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants