Strong Customer Authentication
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
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. Billwerk+ payments 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.
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 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 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 is 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 un-enrolled cards.
Notice that 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 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, 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:
Parameter | Description |
|---|---|
name | Cardholder name. If not provided it will be taken from customer entity or invoice addresses. Length 2-45 characters. |
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
JSON
{
"order": {
"handle": "..."
},
"sca_data": {
"name": "John Doe",
"email": "doe@example.com",
"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 transactionless_than_30_days - Less than 30 daysfrom_30_to_60_days - 30−60 daysmore_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
JSON
{
"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
JSON
{
"order": {
"handle": "..."
},
"sca_data": {
"risk_indicator": {
"delivery_email": "mail@mailer.com",
"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. |