Mixing 3DS with Payment Methods about 3ds HOT 8 OPEN

Hi @stpeter,

From our earliest conversations about 3DS my recollection is that it is intended to be a general-purpose authentication framework. For that reason, we've been talking about 3DS functionality separate from any specific payment method specification (and our 3DS spec lives separately from the tokenization spec, for example).

Recently there has been some suggestion that at least in the near future, the 3DS and tokenization work is likely to be tightly coupled, and so we may need a wrapper around the two to tell the story. But at least for now, the answer to your second question is "yes, in theory one could use 3DS for a variety of payment methods."

Ian

from 3ds.

@ianbjacobs I guess it just struck me, looking at the request example in the 3DS spec, that the data object could get awfully messy if the merchant supports 2 or 3 or 4 payment methods because none of the fields are "namespaced" and some of the fields could apply to less than all the methods. However, I suppose the use of tuples for [[serializedMethodData]] might make it easier for the user agent to disentangle the business logic. (Sorry, just thinking aloud here...)

from 3ds.

that the data object could get awfully messy if the merchant supports 2 or 3 or 4 payment methods because none of the fields are "namespaced" and some of the fields could apply to less than all the methods.

This is one of the reasons that we proposed the use of JSON-LD very early on in the Web Payments process (and to put more of a focus on data modeling in the beginning). It would remove the ambiguity and provide a future-proofed upgrade mechanism, but it may be too late for the WG to change direction at this point (and given the participants, I would imagine that they'll attempt to solve the problem by nesting/pairing data... which has it's own combinatorial complexity issues. As these specifications get more complex, we expect even more of these sorts of issues to surface.

from 3ds.

The PaymentResponse includes the selected payment method via methodName. For URL-identified payment methods, it would seem that that would be enough to help merchants know what they are getting.

from 3ds.

Right. This is more about how the user agent teases apart the business logic of the PaymentRequest. Everything becomes clear by the time the PaymentResponse is generated. Perhaps we haven't run into this yet because (a) browser implementers are smart or (b) merchants haven't been generating PaymentRequest objects with multiple payment methods.

from 3ds.

@stpeter, when you say "PaymentRequest objects with multiple payment methods." do you mean "a PaymentRequest object when in request data they indicated that they accept multiple payment methods"?
Ian

from 3ds.

@ianbjacobs It seems we avoid this problem by defining multiple different request objects: BasicCardRequest for basic card, CreditTransferRequest for SEPA, applePayMethod for Apple Pay, InterledgerRequest for Interledger, etc. So perhaps I'm just confused by what goes into the methodData constructor shown in the tokenized card example, since it looks generic but in fact isn't. :-)

from 3ds.

@stpeter, sorry it took me so long. Now I better understand your point. I agree that we will need to address this question if we create a reusable 3DS module.

Ian

from 3ds.