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:

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

Strong Customer Authentication 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 was usually performed without SCA and customer interaction. Reepay offers 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.

For details on PSD2 see: https://blog.reepay.com/psd2-strong-customer-authentication/

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 short-comings 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. See below on providing data to the 3D Secure step. 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 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 Reepay 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 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 Reepay 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 is configured on the specific acquirer agreements in the Reepay 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 Reepay 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 Reepay 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.
  • scafallback- SCA is required if a first attempt without SCA fails with error indicating SCA required. Relevant exemptions will be applied to the first attempt, e.g. Low Value exemption. See https://blog.reepay.com/psd2-strong-customer-authentication/ Notice that SCA fallback should not be used when saving a card for future use, that is Checkout recurring sessions and charge sessions with the recurring flag set.

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

Notice that payment type settings can also be defined on Checkout Configurations in the Reepay 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 Reepay, 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 own 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, Reepay 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 Reepay 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:

Parameter................................

Description

name

Cardholder name. If not provided it will be taken from customer entity or invoice addresses. Length 2-45 characters.

email

Cardholder email. If not provided information will be taken from customer or invoice addresses. Length max 254 characters.

home_phone

Cardholder Home Phone number. If not provided information will be taken from customer or invoice addresses. Object of country code and subscriber number.

mobile_phone

Cardholder Mobile Phone Number. Object of country code and subscriber number.

work_phone

Cardholder Work Phone Number. Object of country code and subscriber number.

challenge_indicator

Not essential as such. It can be used to control whether the cardholder should be posed with a challenge instead of a potential frictionless authentication flow. This could e.g. be used the first time a new customer makes a purchase to make sure they are strongly authenticated. Two values can be used:

preference - cardholder should be given a challenge if issuer supports challenges
mandate - cardholder must be given a challenge and the authentication should be declined if the issuer does not support challenges.

If not provided a frictionless flow will be used if granted

accountId

Cardholder Account Identifier. Customer id from own system. If not provided, the customer handle will be used. Can be used by issuing banks to tie multiple transactions with the same card and account id together. If multiple already exist, the risk can be assessed as low. Length max 64 characters.

address_match

Indicate if Shipping Address and Billing Address are the same.

billing_address

Cardholder Billing Address. If not provided it will be taken from the invoice billing address or customer. For the exact object structure see example and API documentation.

shipping_address

Cardholder Shipping Address. If not provided it will be taken from the invoice shipping address or customer. For the exact object structure see example and API documentation.

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.

Parameter................................................

Description

created

Date that the cardholder created the account. Format: yyyy-MM-dd

age_indicator

Length of time that the cardholder has had the account. One of:

this_transaction - Created during this transaction,
less_than_30_days - Less than 30 days,
from_30_to_60_days - 30−60 days
more_than_60_days - More than 60 days

changed

Date that the cardholder’s account was last changed, including Billing or Shipping address, new payment method, or new user(s) added. Format: yyyy-MM-dd

change_indicator

Length of time since the cardholder’s account information was last changed, including Billing or Shipping address, new payment account, or new user(s) added. One off:

this_transaction - Changed during this transaction
less_than_30_days - Less than 30 days,
from_30_to_60_days - 30−60 days
more_than_60_days - More than 60 days

password_change

Date that cardholder's account had a password change or account reset. Format: yyyy-MM-dd

password_change_indicator

Indicates the length of time since the cardholder’s account had a password change or account reset. One off:

no_change - No change
this_transaction - Changed during this transaction
less_than_30_days - Less than 30 days
from_30_to_60_days - 30−60 days
more_than_60_days - More than 60 days

purchase_count

Number of purchases with this customer account during the previous six months.

add_card_attempts

Number of Add Card attempts in the last 24 hours.

transactions_day

Number of transactions (successful and abandoned) for this cardholder account (across payment methods) in the previous 24 hours

transactions_year

Number of transactions (successful and abandoned) for this cardholder account (across payment methods) in the previous year

card_age

For customer initiated card-on-file sessions, the date that the used card was added. Provided by Reepay but can be overridden. Format: yyyy-MM-dd

card_age_indicator

For customer initiated card-on-file session, indicates the length of time that the card was enrolled in the cardholder’s account. Provided by Reepay but can be overridden. One off:

this_transaction - Changed during this transaction
less_than_30_days - Less than 30 days
from_30_to_60_days - 30−60 days
more_than_60_days - More than 60 days

shipping_address_usage

Date when the shipping address used for this transaction was first used. Format: yyyy-MM-dd

shipping_address_usage_indicator

Indicates when the shipping address used for this transaction was first used. One off:

this_transaction - During this transaction,
less_than_30_days - Less than 30 days,
from_30_to_60_days - 30−60 days
more_than_60_days - More than 60 days

shipping_name_indicator

Indicates if the Cardholder Name on the account is identical to the shipping Name used for this transaction

suspicious_activity

Indicates if there has been experienced suspicious activity (including previous fraud) on the cardholder account

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.

Parameter................................................

Description

delivery_email

For Electronic delivery, the email address to which the merchandise was delivered.

delivery_timeframe

Indicates the merchandise delivery timeframe:

electronic - Electronic Delivery
same_day_shipping - Same day shipping
overnight_shipping - Overnight shipping
two_day_or_more_shipping - Two-day or more shipping

gift_card_amount

For prepaid or gift card purchase, the purchase amount is the total of prepaid or gift card(s) in major units (for example, USD 123.45 is 123).

gift_card_count

For prepaid or gift card purchase, total count of individual prepaid or gift cards/codes purchased.

gift_card_currency

For prepaid or gift card purchase, currency code of the gift card.

pre_order_date

For a pre-ordered purchase, the expected local date that the merchandise will be available. Local date on the form yyyy-MM-dd

pre_order_purchase_indicator

Indicates whether the cardholder is placing an order for merchandise with a future availability or release date. Either:

merchandise_available
future_availability

reorder_items_indicator

Indicates whether the cardholder is reordering previously purchased merchandise. Either:

first_time_ordered
reordered

shipping_indicator

Indicates shipping method chosen for the transaction. The Shipping Indicator code that most accurately describes the cardholder’s specific transaction must be used, not the general business. If one or more items are included in the sale, use the Shipping Indicator code for the physical goods, or if all digital goods, use the Shipping Indicator code that describes the most expensive item. Possible values:

billing_address - Ship to cardholder’s billing address,
verified - Ship to another verified address on file
non_billing_address - Ship to address that is different than the cardholder’s billing address,
ship_to_store - Pick-up at local store (Store address shall be populated in shipping address fields)
digital_goods - Digital goods (includes online services, electronic gift cards and redemption codes)
travel_and_event_tickets - Travel and Event tickets, not shipped
other - Other (for example, Gaming, digital services not shipped, emedia subscriptions, etc.)

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: https://reference.reepay.com/api/#get-charge

The following parameters describe the SCA status:

Parameter................................................

Description

source.strong_authentication_status

Status for strong customer authentication. Possible values:

threed_secure - 3D Secure authenticated
threed_secure_not_enrolled - 3D Secure authentication not performed as card not enrolled
secured_by_nets - Secure by Nets authenticated

source.three_d_secure_status

If 3D Secure authenticated the 3D status will either be Y (fully authenticated) or A (attempted authenticated). An attempted authentication means that card issuer (e.g. bank) does not support 3D Secure so no full authentication has been performed. Attempted authentication normally means liability shift, but this can differ for acquirers.