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

Spec feedback #8

Open
asolove-stripe opened this issue Aug 22, 2018 · 0 comments
Open

Spec feedback #8

asolove-stripe opened this issue Aug 22, 2018 · 0 comments

Comments

@asolove-stripe
Copy link

asolove-stripe commented Aug 22, 2018

Here's an outline of my thoughts after reviewing the draft spec. I'll close this issue after we discuss these at today's meeting.

Request data
- requestLevel cases
  separate into two things: is 3ds required? is challenge required/not allowed/don't care?
    merchant likely doesn't know which until address entered
  references to "step up" should be changed to "challenge flow", which is the official 3DS spec term
- handler for 3DS will need to receive or collect shipping address for physical goods
  merchant needs a way to mark whether shipping is needed or not
  merchant needs events to listen on shipping changes and possibly change 3DS config
  where do we specify "stuff the 3DS module requires of its host payment method?"
- handler will need to gather email and 
- payee data
  order number, merchant id, acquirer id, acquirer merchant id, merchant name, 
  opt in to encrypted or tokenized card number


Response data
- cases of ThreeDSResponse
  (See Cardinal's 3DS2 result test cases at https://cardinaldocs.atlassian.net/wiki/spaces/CCen/pages/412712961/3DS+2.0+Test+Cases)
  if we add a requestLevel=never3DS, then returned data shape is different
    is the shape of returned data then specified by the host payment method?
  if there's an error during 3ds, or ACS is unavailable or times out
    if 3ds required, handler should prompt for another form of payment
    if 3ds not required, handler maybe falls back to returnign card/token without performing 3ds.
  there are lots of case intersections, for example:
    if 3ds is required but merchant specifies frictionless, what do we do if frictionless denied?
      give up and ask for another payment method from the customer?
      try 3ds again and allow a challenge?

Privacy/data gathering
- points in the spec still stand: we don't know what to do here, probably need browsers to make a suggestion
- how we will load method_url, or get around the need to, is the biggest question for this spec

Footnote
- Should 3DS reference point to a specific version of the spec rather than a landing page that will point to the latest 3DS-related specs and change over time?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant