SCA and 3D Secure Support

The Second Payment Services Directive (PSD2) is an EU Directive administered by the European Commission (Directorate General Internal Market) to regulate payment services and payment service providers throughout the European Economic Area (EEA).

Strong customer authentication (SCA) is a requirement of the PSD2 on payment service providers within the EEA. This requirement ensures that electronic payments are performed using multi-factor authentication, to increase the security of electronic payments.

3D Secure is a form of software-based SCA as defined by the PSD2.

Using 3D Secure

The following scenarios are supported for 3D Secure:

A customer is redirected to a payment gateway, and from there gets redirected to the 3D Secure provider's site.

This scenario is implemented by the payment gateway's vendor; a plugin does not participate.
A customer makes a payment using a modal form and gets redirected to the 3D Secure provider's site.

This scenario can be implemented in the checkout script of the GoModal method. A plugin developer must manually implement a redirection in the checkout script.
A customer makes a payment with the previously saved payment method (token) and gets redirected to the 3D Secure provider's site.

This scenario can be implemented with the Auth and Capture methods. If so, the Auth method must return an array with the following data:
- STATUS => 3DSECURE,
- REDIRECT_HASH with url, method and attrs (as in the Redirect method).
The URL needed to return from the 3D Secure provider's site can be taken from $params['environment']['return_url_3dsecure'] (for details, refer to Environment).

After returning from the 3D Secure provider's site, the Auth method is called with the 3D Secure response that contains in previous_transaction_data. If the Auth method returns STATUS APPROVED, the charge will be completed by calling the Capture method.

Note: The Sell method may also return the 3DSECURE status. If so, it cannot be used for charging recurring payments.

3D Secure 1.0 flow

The workflow below represents a payment using 3D Secure v1.0 flow:

A customer creates an Order in CloudBlue Commerce and proceeds to pay it.
A browser receives the request and calls Billing, initiating the payment flow.
Billing detects that the payment system is of the Custom type.
Billing calls the Is3DSecureActive method in the plugin associated with the payment method.
The plugin processes the request.
The plugin responds with the APPROVED status, that is, the plugin requires 3D Secure.
Billing calls the Auth method passing the previously saved payment method (token).
The plugin asks for the 3D Secure verification to the payment gateway.
The payment gateway requests the 3D Secure verification to the 3DS payment gateway.
The 3DS payment gateway responds with a verification context (a link to iFrame, a pop-up window, or a URL to the 3D Secure verification page).
The payment gateway responds with a status and verification context data.
The plugin responds with the 3DSECURE status, the Redirect URL and 3DS parameters (derived from the Verification context).
Billing responds with the Redirect URL and 3DS parameters.
The browser redirects the customer to the Redirect URL sending the 3DS parameters¹.
The 3DS payment gateway asks for the customer authentication data through an HTML form.
The customer fills out the form with their identity (for example, providing a one-time token received by SMS).
The browser dispatches the form data back to the 3DS payment gateway.
The 3DS payment gateway verifies the customer identity (for example, SMS, email, password, or one-time token).
The 3DS payment gateway responds with the status and result data.
The browser redirects to Billing with the 3DS response data.
Billing calls the Auth method, passing the 3DS response data.
The plugin checks the 3DS response data. The data will be received in the previous_transaction_data array.
The plugin initiates a preauthorization transaction, passing the 3DS response data.
The 3DS payment gateway checks the 3DS response data.
The 3DS payment gateway responds with the 3DS status.
The payment gateway processes the preauthorization transaction.
The payment gateway responds with the preauthorization result.
The plugin responds with the status and transaction details.
Billing calls the Capture method passing the last transaction data.
The plugin initiates the Capture transaction.
The payment gateway processes the Capture request.
The payment gateway responds with the Capture result.
The plugin responds with the status and transaction details.
Billing completes the transaction and updates the Payment and Order status.
The customer is redirected back to CloudBlue Commerce.

¹The 3DS parameters may contain the URL that the 3DS payment gateway will use to redirect a customer back to Billing. The return_url_3dsecure URL (provided by Billing) must be used for this purpose (for details, refer to Environment).

3D Secure 2.0 flow

3D Secure 2.0 introduces frictionless authentication, which allows issuers to approve a transaction without the need to interact with a cardholder.

The workflow below represents a payment using 3D Secure 2.0 flow:

Note: This sequence diagram is a proposal. The actual flow may differ depending on the payment gateway.

A customer creates an order in CloudBlue Commerce and proceeds to pay it.
A browser receives the request and calls Billing, initiating the payment flow.
Billing detects that the payment system is of the Custom type.
Billing calls the Is3DSecureActive method in the plugin associated with the payment method.
The plugin processes the request.
The plugin responds with the APPROVED status, that is, the plugin requires 3D Secure.
Billing calls the Auth method, passing the previously saved payment method (token).
The plugin asks for the 3D Secure authentication to the payment gateway.
The payment gateway requests the 3D authentication to the 3DS payment gateway.
The 3DS payment gateway verifies the customer's identity (for example, by SMS, email, password, or one-time token).
- The 3DS payment gateway challenges the customer's identity.
- The customer confirms their identity (for example, providing a one-time token received by SMS).
The 3DS payment gateway responds with the authentication context.
The payment gateway responds with the status and the authentication context data.
The plugin responds with the 3DSECURE status, Redirect URL (this must be the return_url_3dsecure URL), and 3DS parameters (derived from the authentication context).
Billing responds with the Redirect URL and 3DS parameters.
The browser redirects to Billing with the 3DS response data.
Billing calls the Auth method passing the 3DS response data.
The plugin checks the 3DS response data. The data will be received in the previous_transaction_data array.
The plugin responds with the status and transaction details.
Billing calls the Capture method, passing the last transaction data.
The plugin initiates the Capture transaction.
The payment gateway processes the Capture request.
The payment gateway responds with the Capture result.
The plugin responds with the status and transaction details.
Billing completes the transaction and updates the Payment and Order status.
The customer is redirected back to CloudBlue Commerce.

Out of SCA Scope Transactions

The PSD2 defines transaction types that are excluded from the SCA application. Among others, for electronic payments are the following:

“One Leg Out” Transactions: payments where the issuer or acquirer are based outside of the EEA.
Direct Debit Payments: preauthorized payments that enable an entity to withdraw money directly from a payer account.
Mail Orders/Telephone Orders (MOTO): these are not considered “electronic” payments and are out of the PSD2 scope.
Merchant Initiated Transactions (MIT): payments initiated by the merchant without the cardholder's presence (transaction are initiated automatically by the system).

Payment Plugin SDK provides the capability to determine MIT and MOTO transactions: this capability is ensured by the transaction_initiator and the transaction_moto data received in the input parameter.

The table below outlines the MIT with MOTO and MIT definition conditions:

Transaction description	Transaction type
A provider pays a reseller's order through the PCP.	MIT with MOTO
A reseller pays a subreseller's order through the RCP.	MIT with MOTO
A provider or reseller pays a customer's order through UX1 on behalf of the customer.	MIT with MOTO
A provider or reseller pays a customer's order through their panel (PCP or RCP).	MIT with MOTO
BSS automatically processes customer recurring or renewal orders.	MIT
Payments for automatic balance top-up.	MIT