3D Secure (3DS) is an authorisation step that can be added to a purchase journey, it’s aim to avoid card fraud by asking for additional security information. There has been lots of discussion/criticism around it’s implementation, my aim in this post is not about these issues but about how to actually implement it.
The 3DS process is not hosted on the vendors server, instead the user is directed to a third party site to enter their details. The current recommendation is that this is done through an iFrame on the vendors site. The previous recommendation was that the user is redirected to the 3DS pages.
A key issue here (aside from the phishing concerns!) is that iFrames are hard to handle without JavaScript, the vendor must post details to the 3DS server so we need to provide non-js messaging and controls so the user can continue and complete the process.
3D Secure process
- The 3DS page is included through an iFrame
- Within the iFrame, the customer negotiates the 3DS process and the result is then posted back to a page hosted by the vendor
- The vendors page uses the result of the call to update the transaction held in session data. We can use JavaScript at this point to submit the parent page
- The backend system determines the appropriate result page, success or failure, and this is presented to the user
For the non-js version, as mentioned, the vendors page loaded in the iFrame should include a button that targets the parent page (target=top”) so the user can continue manually.