Support for SCA and 3D Secure

Introduction

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:

1. 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.

2. 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 %Plug-inName%_GoModal() function. A plug-in developer must manually implement a redirection in the checkout script.

3. 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 functions %Plug-inName%_Auth() and %Plug-inName%_Capture(). In this case, the function %Plug-inName%_Auth() must return an array with the following data:

   • STATUS => 3DSECURE,
   • REDIRECT_HASH with url, method and attrs (as in %Plug-inName%_Redirect() function).

   The URL (that is needed to return from the 3D Secure provider's site) can be taken from $params['environment']['return_url_3dsecure].

   After return from the 3D Secure provider's site, the function %Plug-inName%_Auth() is called with the 3D Secure response that contains in previous_transaction_data. If %Plug-inName%_Auth() returns STATUS APPROVED, the charge will be completed by calling the %Plug-inName%_Capture() function.

   Note: The %Plug-inName%_Sell function also can return status 3DSECURE. In this case, it cannot be used for charging recurring payments.

The workflow below represents a payment with a token with 3D Secure involved:

“Out of SCA Scope” Transactions

The PSD2 defines transaction types that are excluded from 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 to be “electronic” payments and are out of the PSD2 scope.
• Merchant Initiated Transactions (MIT): payments initiated by the merchant without the cardholder presence.

CloudBlue Commerce Payment Plugin SDK provides the capability to determine MIT and MOTO transactions: this capability is ensured by the transaction_initiator sub-parameter of the payment_method parameter and the transaction_moto sub-parameter of the payment_method 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 the 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