Open ianbjacobs opened 5 years ago
In previous conversations about 3DS through payment handlers we sought to identify what data would be needed (e.g., about the merchant) for a payment handler to initiate a 3DS call. Some analysis of AREQ data was done as part of trying to answer this question: https://github.com/w3c/webpayments/wiki/3DSDataSources#data-about-the-merchant--transaction
Now, with SRC, it is at least possible that some input data is subsumed by an enrollment procedure that happens at another time.
The question remains open: what request data is required (or optional) to support 3DS flows initiated by a payment handler?
Ian
See our previous work on 3DS as a starting point: https://w3c.github.io/3ds/index.html
In previous conversations about 3DS through payment handlers we sought to identify what data would be needed (e.g., about the merchant) for a payment handler to initiate a 3DS call. Some analysis of AREQ data was done as part of trying to answer this question: https://github.com/w3c/webpayments/wiki/3DSDataSources#data-about-the-merchant--transaction
Now, with SRC, it is at least possible that some input data is subsumed by an enrollment procedure that happens at another time.
The question remains open: what request data is required (or optional) to support 3DS flows initiated by a payment handler?
Ian