.Strong Customer Authentication (SCA) is a European regulatory requirement (PSD2) to reduce fraud and make online payments more secure. SCA is built upon the two-factor methodology that requires authentication to use at least two of the following three elements:

• Something the customer knows - e.g., password or credit card number,
• Something the customer has - e.g., phone or hardware token,
• Something the customer is - e.g., fingerprint or face recognition.

SCA will only be enforced for customer-initiated transactions (CIT) within Europe. Customer-initiated transactions are transactions where the customer is present. It also includes the sign-up for recurring transactions where the customer card is saved for future use. The following subsequent transactions are labelled merchant-initiated transactions (MIT) and are out-of-scope for SCA.

Customer-initiated transactions also include transactions where a customer is present and pays with a stored card. These transactions were usually performed without SCA and customer interaction. Billwerk+ payments offer a Card-on-file functionality where the customer does not have to enter card details, but only go through SCA.

Wallet-based payment methods such as Apple Pay, Google Pay, MobilePay, Vipps, and Swish have a built-in layer of authentication to meet the SCA requirement. For online card payments, 3D Secure is used to meet the SCA requirement.

3D Secure

3D Secure is a protocol designed to be an additional security layer for online card transactions. It was originally developed by Visa with the intention of improving the security of Internet payments and offered to customers under the Verified by Visa brand. Other card brands have adopted 3D Secure under the names:

• SecureCode (Mastercard)
• ProtectBuy (Discover)
• J/Secure (JCB International)
• SafeKey (American Express)
• Secured by Nets (Dankort)

Later revisions of the protocol have been produced by EMVCo under the name EMV 3D Secure. Version 2 of the protocol was published in 2016 with the aim of complying with new PSD2 requirements and resolving some of the shortcomings of the original protocol. Version 2 is now mandatory.

3D Secure has often been avoided by merchants as the 3D Secure step introduces friction which leads to customer drop-offs and lost conversion. The new version introduces a better user experience that will help minimize some of the friction that authentication adds into the checkout flow. In some cases, the 3D Secure step can be completely frictionless without requiring any customer interaction based on data provided by you the merchant. If the 3D Secure step is not frictionless, it has a challenge authentication flow where the customer is required additional authentication by the issuer (e.g., bank).

Liability Shift

One of the main benefits of 3D Secure is that liability for fraudulent chargebacks (stolen or counterfeit cards) shifts from you to the card issuer. The general rule is, if a customer successfully completes a 3D Secure challenge authentication flow, the liability for fraudulent chargebacks shifts from you, the merchant, to the card issuer.

In most cases, card schemes grant liability shift after a successful frictionless flow, but this can differ based on region. We advise you to contact Billwerk+ or your acquirer for the specific rules that apply to you.

A challenge authentication flow can be mandated by providing an argument to the SCA step. See description below of the argument challenge_indicator. For Checkout sessions where a card is saved for subsequent merchant-initiated transactions, that is recurring sessions and charge sessions with the recurring flag set, the challenge flow is always presented to the customer. That is to make sure that the customer is strongly authenticated for a series of merchant-initiated transactions, e.g., subscription payments.

📘

Notice

There is no liability shift for recurring merchant-initiated transactions and for Dankort.

Notice that there is no liability shift for recurring merchant-initiated transactions and for Dankort.

Controlling 3D Secure

So what should you do? 3D Secure is built into the payment and sign-up flows of Billwerk+ payments Checkout, so 3D Secure does not affect your integration directly, but there are a number of required settings and controls available.

SCA settings in Admin

3D Secure and Secured by Nets are configured on the specific acquirer agreements in the Billwerk + Payments Administration under Configuration → Acquiring. This is normally a one-time task that is done when an account is set live. Usually, it is automatically set-up, or it is done together with Billwerk+ payments Support. Once the SCA capabilities are enabled, payments and signups will utilize 3D Secure if cards are enrolled in 3D. A couple of settings are important:

• Require SCA by default: If no specific option is given to Checkout (see below), the default is to require SCA if the card is enrolled. This might not be the desired default as un-enrolled cards will succeed resulting in no authentication and liability shift. Setting this option will require SCA by default so un-enrolled cards will be declined. Notice that the SCA requirement can be controlled explicitly when creating Billwerk+ payments Checkout sessions. See below on payment method options.
• Disallow 3D Secure attempted: If a card issuer, e.g., cardholder bank, does not support 3D Secure, but the card is enrolled, the result of the 3D Secure flow will be "attempted". The cardholder will not be prompted for any authentication, but normally the attempted result will also mean liability shift. Use this setting to disallow attempted as sufficient 3D Secure authentication.

Checkout payment method options

When creating a Checkout session, SCA rules can be defined for specific card types or all types in general. For the specific syntax see Checkout Payment Methods.

The following SCA rules can be applied using a prefix to the payment type.

• sca-• SCA is required. If a card is not enrolled it will be declined.
• nosca-• SCA is not used. The transaction will fail if SCA is required by the issuer. This argument is only relevant for transactions outside Europe due to PSD2.

If no specific rule is defined the default is to use SCA for all enrolled cards, but also accept unenrolled cards.`

📘

Notice

Payment type settings can also be defined on Checkout Configurations in the Billwerk+ payments Admin under Configuration → Checkout.

In addition to the SCA controls, the argument challenge_indicator can be used to control whether a challenge flow is mandatory. See below.

SCA data

Frictionless authentication flow or not - it’s all about the data! For issuing banks to make a decision on whether a frictionless authentication can be granted, they will need information about the customer and the context of the payment. Some of this data is provided by Billwerk+, e.g., customer browser information, but some of the data needs to be provided by you the merchant. That is information on the customer and the current purchase. The issuer can use this information to make a risk assessment for the transaction. E.g., match customer information and purchase information such as delivery address with their records and previous transactions. To what extent issuers are going to utilize this information is unknown. It is expected that many issuers will not have frictionless determination in their first implementations of 3D Secure v2. Secured by Nets is currently using a simple rule where the authentication flow is frictionless for amounts below 450 DKK. Expected to change by the end of 2020 to 225 DKK (30 EUR).

The SCA data can be given explicitly, but if the data is not present, Billwerk+ will try to use information from the customer entity and charge billing and delivery addresses if these are present. Notice that the data given explicitly is not stored at Billwerk+ payments and only used in the SCA process. That is, there are no GDPR implications for these data.

SCA data can be provided in the parameter sca_data when creating a Checkout session. SCA data is not mandatory, but we recommend that you provide at least the essential data. The essential data is:

Example: Create session request with essential SCA data

{
	"order": {
		"handle": "..."
	},
	"sca_data": {
		"name": "John Doe",
		"email": "[email protected]",
		"home_phone": {
			"cc": "45",
			"subscriber": "21212121"
		},
		"mobile_phone": {
			"cc": "46",
			"subscriber": "31313131"
		},
		"work_phone": {
			"cc": "47",
			"subscriber": "41414141"
		},
		"billing_address": {
			"address1": "Address1",
			"address2": "Address2",
			"address3": "Address3",
			"city": "City",
			"country": "DK",
			"postal_code": "1111",
			"state_or_province": "WA"
		},
		"shipping_address": {
			"address1": "Address1",
			"address2": "Address2",
			"address3": "Address3",
			"city": "City",
			"country": "DK",
			"postal_code": "1111",
			"state_or_province": "WA"
		},
		"address_match": true,
		"account_id": "cust-212313213",
		"challenge_indicator": "preference"
	}
}

In addition to the essential data detailed information on the customer account can be provided if the customer has an account in your shopping system. The information is provided in the parameter sca_data.account_info.

Example: Account info in create session request

{
	"order": {
		"handle": "..."
	},
	"sca_data": {
		"account_info": {
			"created": "2020-01-01",
			"changed": "2020-02-02",
			"age_indicator": "more_than_60_days",
			"change_indicator": "more_than_60_days",
			"password_change": "2020-03-03",
			"password_change_indicator": "no_change",
			"purchase_count": 2,
			"add_card_attempts": 10,
			"transactions_day": 2,
			"transactions_year": 10,
			"card_age": "2020-04-04",
			"card_age_indicator": "from_30_to_60_days",
			"shipping_address_usage": "2020-05-05",
			"shipping_address_usage_indicator": "less_than_30_days",
			"shipping_name_indicator": true,
			"suspicious_activity": false
		}
	}
}

Furthermore, in addition to the essential data a risk indicator can be provided in the parameter sca_data.risk_indicator.

Example: Risk indicator object

{
	"order": {
        "handle": "..."
	},
	"sca_data": {
		"risk_indicator": {
			"delivery_email": "[email protected]",
			"delivery_timeframe": "same_day_shipping",
			"gift_card_amount": 10000,
			"gift_card_count": 2,
			"gift_card_currency": "USD",
			"pre_order_date": "2020-12-24",
			"pre_order_purchase_indicator": "future_availability",
			"reorder_items_indicator": "first_time_ordered",
			"shipping_indicator": "billing_address"
		}
	}
}

SCA status on charges and cards

The SCA status on a charge that has been authorized or instant settled can be determined by getting the charge: Get charge.

The following parameters describe the SCA status: