You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: