Implement 3D Secure 2

Quick thoughts and a wrinkle from today's call reviewing the details.

First, it seems like what we'll be able to do is have a turbocharged createPayment() function that behaves differently based on whether or not 3D Secure is enabled for the payment gateway (and, if it is enabled, if 3D Secure is required or not ... sometimes it may not be required).

If 3D Secure is disabled, the flow is pretty straightforward:

1. Custom card integration appears on the Payment information pane. When submitted, the encrypted card fields are stored on the payment method in a new field (or fields?) that stores the encrypted data.
2. Nothing extra on the review page.
3. On the Payment process pane, the data is submitted to Adyen in a /payments request. If it fails, the customer is sent backwards with an error message. If successful, great! All done.

If 3D Secure is enabled, the flow looks a little more complicated:

1. Custom card integration appears on the Payment information pane. When submitted, the encrypted card fields are stored on the payment method in a new field (or fields?) that stores the encrypted data.
2. Additionally, during that submit process, the data is submitted to Adyen in a /payments request that includes the parameters needed to decide if 3D Secure should be required.
3. On the review page, we'll incorporate a custom checkout pane similar to Braintree's 3DS implementation that includes the necessary HTML and JavaScript to accommodate the 3DS request.
4. When the 3DS pane is submitted, the response is stored on the payment method.
5. On the Payment process pane, the 3DS details are sent in the /payments/details request, which will then result in the payment succeeding or failing (or being canceled by the customer).

There's a minor difference if 3D Secure is enabled but not required for a customer. This will mean that an authorization has already been created at Adyen. We will need the createPayment() function to know about it and not reauthorize payment during Payment process. If the checkout flow is configured to authorize and capture, the payment should be captured at this point.

It's a bit of a pain, because the authorization will exist even if the customer doesn't complete checkout, but that's why we need to clearly document that automated capture should always be disabled for the Drupal Commerce implementation. Perhaps in the future we can add a setting to automatically cancel these authorizations on cron after a certain amount of time has elapsed.

Finally, the quirk: a 3D Secure response may require a redirect. The Adyen docs aren't clear re: whether or not this should fit into our offsite payment gateway flow or else if we should redirect from the review step and return to the review step. It seems like their JS component may be doing some of the handling of the response. Unclear without trial and error.

rszrama → credited TomTech → .

Automatically closed - issue fixed for 2 weeks with no activity.