3D Secure 2

3D Secure 2

3D Secure 2 Introduction

What is it all about?

Introduced in 2001 3D Secure is an authentication protocol for online card payments. It is designed to provide more security to online payments and to deliver a better and smoother user experience to the consumer.

After 2 decades, the EMVCo has published a new standard for payment card transactions: 3D Secure 2 (3DS2). The new authentication protocol meets the new requirements (Strong Customer Authentication) set by the EU with the Payment Services Directive (PSD 2) for online payments.

The name 3D Secure refers to the three domains: the merchant/acquirer, the issuer, and the card scheme/interoperability domain. As a PSP we want to overtake the most difficult processes about handling 3D Secure for you. It is our mission and duty to minimise your effort of implementation regarding 3D Secure 2, so we cover all necessary steps in this guide from a merchant perspective.

What is Strong Customer Authentication (SCA)?

SCA is a new European regulatory requirement to combat and reduce fraud and make online payments more secure in every aspect. Merchants have to set new authentication parameters within the checkout to fulfil the new SCA requirements. At least two of the following elements (for two-factor authentication) have to be considered to verify the identity of the consumer:

  • Knowledge: something only the customer knows (e.g. PIN or password)

  • Possession: something only the customer has (e.g. a smartphone)

  • Inherence: something only the customer is (e.g facial scan or fingerprint)

These elements must be strictly independent from one another.

When do I need Strong Customer Authentication?

SCA relies to “customer-initiated” online payments within Europe. Therefore most card payments and bank transfers must be done by SCA. Technically recurring transactions are defined as “merchant-initiated” and do not need a SCA, but it is up to each bank to decide whether authentication is needed for each transaction.

Why should I use 3D Secure 2?

3D Secure 2 not only improves security and reduces fraud, it also enhances the consumer experience within the checkout workflow through the following points:

  • Users won’t be redirected to authentication pages (e.g. from issuers) which have no responsive designs

  • The new authentication mechanism provides more consumer-based information to the issuers to prevent declines executed unintentionally by the customer

  • Smoother experience and better conversation rate due the fact of a faster checkout workflow

  • To make the experience more enjoyable, the mechanism to get through the Two-Factor-Authentication can be easily completed by e.g. a token and facial scan.

As already done with 3DS1, 3D Secure 2 also protects the merchant from liability in cases of fraud.

Which brands are supported?

3D Secure 2 has been developed, and is supported, by Mastercard, VISA, American Express, UPI, Diners Club, Discover, and JCB.

3D Secure 2 Request Parameters

Parameter Within fingerprint Data type Short description

consumerEmail

Required if used.

Alphanumeric with special characters and a variable length of up to 256.

Mandatory Field for 3D Secure 2. E-mail address of consumer.

consumerBillingFirstname

Required if used.

First character has to be alphabetic, any other characters ASCII, with a variable length of up to 32 bytes.

Mandatory Field for 3D Secure 2. First name of consumer.

consumerBillingLastname

Required if used.

First character has to be alphabetic, any other characters ASCII, with a variable length of up to 32 bytes.

Mandatory Field for 3D Secure 2. Last name of consumer.

isoTransactionType

Required if used.

Enumeration

It identifies the type of ISO transaction. The values are derived from ISO 8583. This field is required in some markets (e.g. for Merchants in Brazil). Otherwise optional. Accepted values: 01 = Goods/ Service Purchase. 03 = Check Acceptance. 10 = Account Funding. 11 = Quasi-Cash Transaction. 28 = Prepaid Activation and Load.

consumerMerchantCrmId

Required if used.

Alphanumeric with special characters and a variable length of up to 64.

Consumer identifier in your shop. Requests from the same consumer must contain the same identifier.

consumerAuthenticationMethod

Required if used.

Enumeration

Type of consumer login in your shop. Accepted values: 01 = Guest checkout (i.e. the consumer is not logged in). 02 = Login to the consumer’s account in your shop with shop-own authentication credentials. 03 = Login with Federated ID. 04 = Login with card issuer credentials. 05 = Login with third-party authentication. 06 = Login with FIDO authenticator.

consumerAuthenticationTimestamp

Required if used.

timestamp

Date and time of the consumer login to your shop. Accepted format: YYYY-MM-DDThh:mm:ssZ. The values are derived from ISO 8601. For guest checkout, the timestamp is now.

consumerCardProvisionDate

Required if used.

Numeric with special characters and a fixed length of 10.

Date that the consumer’s card was added to their account in your shop for card-on-file payments (one-click checkout). Accepted format: DD.MM.YYYY. For all other types of checkout (e.g. guest checkout, regular checkout, the first transaction with one-click checkout), the date is now.

consumerCardProvisionAttemptsPastDay

Required if used.

Numeric with a variable length of up to 9.

Number of cards the consumer has attempted to add to their account in your shop for card-on-file payments (one-click checkout) in the past 24 hours.

consumerChallengeIndicator

Required if used.

Enumeration

Specifies whether this transaction shall be subject to Strong Customer Authentication (SCA). Accepted values: 01 = No preference. 02 = No challenge requested. 03 = Challenge requested. (3DS Requestor preference). 04 = Challenge requested (Mandate). If the element is not provided, the ACS will interpret this as 01 = No preference.

consumerSuspiciousActivity

Required if used.

Boolean

Suspicious activities by the consumer. Indicates if you have experienced suspicious activities by the consumer (including previous fraud).

consumerDeliveryTimeframe

Required if used.

Enumeration

Delivery time frame. Accepted values: 01 = Electronic Delivery. 02 = Same day shipping. 03 = Overnight shipping. 04 = Two-day or more shipping.

consumerPreorderDate

Required if used.

Numeric with special characters and a fixed length of 10.

The expected date that the item will be available for a pre-ordered purchase. Accepted format: DD.MM.YYYY.

consumerReorderItems

Required if used.

Enumeration

Indicates if the consumer is reordering previously purchased items. Accepted values: 01 = First time ordered. 02 = Reordered.

consumerAccountCreationDate

Required if used.

Numeric with special characters and a fixed length of 10.

Registration date of the consumer’s account in your shop. Accepted format: DD.MM.YYYY. For guest checkout, do not send this field.

consumerAccountUpdateDate

Required if used.

Numeric with special characters and a fixed length of 10.

Date that the consumer last made changes to their account in your shop, e.g. changes to billing and shipping address, new payment account, new email address. Accepted format: DD.MM.YYYY. For guest checkout, do not send this field.

consumerAccountPasswordChangeDate

Required if used.

Numeric with special characters and a fixed length of 10.

Date that the consumer last changed/reset their password in your shop. Accepted format: DD.MM.YYYY. For guest checkout, do not send this field.

consumerAccountPurchasesPastSixMonths

Required if used.

Numeric with a variable length of up to 9.

Number of successful orders by the consumer in your shop within the past six months.

consumerAccountTransactionsPastDay

Required if used.

Numeric with a variable length of up to 9.

Number of transactions (successful, failed, and canceled) that the consumer has attempted in the past 24 hours. Does not include merchant-initiated transactions.

consumerAccountTransactionsPastYear

Required if used.

Numeric with a variable length of up to 9.

Number of transactions (successful, failed, and canceled) that the consumer has attempted in the past year. Does not include merchant-initiated transactions.

consumerBillingAddress1

Required if used.

Alphanumeric with a variable length of up to 100 bytes.

Name of street and optionally the house number.

consumerBillingAddress2

Required if used.

Alphanumeric with a variable length of up to 100 bytes.

The house number if not already set in consumerBillingAddress1.

consumerBillingAddress3

Required if used.

Alphanumeric with a variable length of up to 100 bytes.

Further details regarding consumer’s address.

consumerBillingCity

Required if used.

Alphanumeric with a variable length of up to 32 bytes.

Billing city.

consumerBillingState

Required if used.

Alphabetic with a fixed length of 2.

Billing state.

consumerBillingCountry

Required if used.

Alphabetic with a fixed length of 2.

Billing country code (ISO 3166-1).

consumerBillingZipCode

Required if used.

Alphanumeric with a variable length of up to 12.

Billing zip code.

consumerBillingPhone

Required if used.

Alphanumeric with a variable length of up to 20.

Phone number of consumer.

consumerBillingMobilePhone

Required if used.

Alphanumeric with a variable length of up to 18.

Mobile phone number of consumer.

consumerShippingItemAvailability

Required if used.

Enumeration

Indicates whether consumer is placing an order for an item which is not yet available (released in the future) or which is currently available. Accepted values: 01 = Currently available 02 = Future availability

consumerShippingMethod

Required if used.

Enumeration

Shipping method chosen by the consumer. Use the shipping indicator value that applies most accurately to the shipping method. If the consumer checks out two or more items, use the shipping indicator value for physical goods. If all goods are digital goods, use the shipping indicator value that matches the most expensive item. Accepted values: home_delivery: Ship to consumer’s billing address. verified_address_delivery: Ship to another address which you know and have verified. other_address_delivery: Ship to an address that differs from the consumer’s billing address. store_pick_up: "Ship to Store" / Pick-up at local store (store address in shipping address fields). digital_goods: Digital goods (includes online services, electronic gift cards, and redemption codes). digital_tickets: Travel and event tickets, not shipped. other_verified: Other (e.g. gaming, digital services, e-media subscriptions).

consumerShippingAddressFirstUseDate

Required if used.

Numeric with special characters and a fixed length of 10.

Date that the consumer first used this shipping address in your shop. Accepted format: DD.MM.YYYY. For guest checkout, do not send this field.

3DS2 Use Cases

One-Time Payment

Generally One-Time Payment is one of the most frequently used workflows regarding checkout processes. Every transaction is executed by the consumer (consumer initiated - CI). Therefore Strong-Customer-Authentication (SCA) based on PSD2 is required.

Example Workflow:

  1. consumers open the shopping basket which contains the previously selected items

  2. consumers enter the personal data and the shipping address into the provided input fields of a form

  3. consumers select one of the available payment methods, enter the required payment method specific data, confirm and commit the payment

  4. payment is processed and merchant receives status

Integration:

To start the payment process a request must be sent to a specific URL containing 3D Secure 2 request parameters.

You can find the information how to start the payment workflow in each integration guide for each product.

Follow-Up Operations:

Don’t forget to deposit your transaction. You can do that in the Payment Center, by the backend operation Deposit or by the request parameter Autodeposit.

One-Click-Checkout

To execute One-Click-Checkout transactions, merchants have to store credit card data as a token in their web shops for recurring payments. The advantage of One-Click-Checkout transactions is that consumers do not have to re-renter their credit card data, they can initialize the transaction just in a few steps with the stored credit card details in the shop. Before this workflow can be done, merchants have to ask consumers about their consent to accept One-Click-Checkout transactions in the future. Please consider, that each transaction in this model is executed by the consumer (consumer-initiated - CI). Therefore Strong-Customer-Authentication (SCA) based on PSD2 is required.

Example Workflow:

  1. consumers registers themselves in the web shop with address and personal data

  2. merchants ask about the consent to execute One-Click-Checkout transactions in the future

  3. consumers open their shopping basket which contains the previously selected items and commit the payment

  4. payment is processed and merchant receives status

  5. Later, consumers have the possibility to pay again with the same (already stored) credit card details

According to the new PSD2 requirements, each One-Click-Checkout transaction falls under the SCA requirements because it is executed by the consumer in session.

Integration:

To start the payment process a request must be sent to a specific URL containing 3D Secure 2 request parameters.

You can find the information how to start the payment workflow in each integration guide for each product.

Since Card-On-File Flagging must be considered in this step, Strong Customer Authentication is required.

You have to set the following parameters with their values in the first request:

  • consumerBillingFirstname, consumerBillingLastname and consumerEmail (mandatory parameters)

  • consumerChallengeIndicator must be set to “04”

  • merchantTokenizationFlag must be set to “true”

You can find the list of 3DS Secure 2 parameter above.

We recommend to send optional parameter like consumerAuthenticationMethod and consumerShippingItemAvailability. If you submit more optional parameters, it is more likely that the issuer authenticates the consumer without requesting Strong Customer Authentication.

If the payment is done and you receive the result, the 3D Secure 2 process is also completed for the first payment.

If the consumer wants to pay again, the checkout has to be initialized once again as above by the consumer (CI) via QPAY or QMORE. The only difference is, as it is still a recurring payment, to set the parameter sourceOrderNumber with the orderNumber value from the previous payment in the new request. If you do that by QMORE, you do not have to reference to any datastorage session again. Just proceed to the frontend init.

Follow-Up Operations:

Don’t forget to deposit your transaction. You can do that in the Payment Center, by the backend operation Deposit or by the request parameter Autodeposit.

Subscription Model

When it comes to recurring payments, the subscription model with the same processed amount within periodical intervals is a popular payment solution for online shops. If you choose this model, you have to consider that consumers must be informed regarding terms of the agreement when setting up the recurring payment plan and the first transaction needs a Strong Costumer Authentication (SCA) since recurring payments are basically executed by the merchant (merchant-initiated transaction - MIT).

Example Workflow:
  1. consumers register themselves in the web shop with address and personal data

  2. merchants asks about the consent to execute recurring transactions in the future

  3. consumers open their shopping basket which contains the previously selected items and commit the payment

  4. payment is processed and merchant receives status

  5. merchants execute payment again on a specific day (specific fixed interval) with the same (already stored) credit card details and same amount

Integration:

To start the payment process a request must be sent to a specific URL containing 3D Secure 2 request parameters.

You can find the information how to start the payment workflow in each integration guide for each product.

Since Card-On-File Flagging must be considered in this step, Strong Customer Authentication is required.

You have to set the following parameters with their values in the first request:

  • consumerBillingFirstname, consumerBillingLastname and consumerEmail (mandatory parameters)

  • consumerChallengeIndicator must be set to “04”

  • merchantTokenizationFlag must be set to “true”

You can find the list of 3DS Secure 2 parameter above.

We recommend to send optional parameter like consumerAuthenticationMethod and consumerShippingItemAvailability. If you submit more optional parameters, it is more likely that the issuer authenticates the consumer without requesting Strong Customer Authentication.

If the payment is done and you receive the result, the 3D Secure 2 process is also completed for the first payment.

Follow-Up Operations:

The merchant has to use the recurPayment backend operation (MIT) with the sourceOrderNumber, the merchantTokenizationFlag with the value "true" and the periodicType with the value "recurring". The sourceOrderNumber is the orderNumber from the last recurring transaction. If the last transaction was the initial transaction, use this orderNumber for the sourceOrderNumber instead.

Don’t forget to deposit your transaction. You can do that in the Payment Center, by the backend operation Deposit or by the request parameter Autodeposit.

Recurring Payment with different amounts by each payment

Unlike the subscription model where recurring payments happen with the same amount on a fixed date, some payment solutions in online shops require irregular intervals. Regarding PSD2 merchants also have the possibility to execute unscheduled merchant-initiated transactions (UCOF). The payment amount can be variable for each recurring payment. Merchants have to consider that consumers must be informed regarding terms of the unscheduled credential on file. The first transaction needs a Strong Costumer Authentication (SCA) since recurring payments are basically executed by the merchant (merchant-initiated transaction - MIT).

Example workflow:

  1. consumers register themselves in the web shop with address and personal data

  2. merchants ask about the consent to execute unscheduled recurring transactions in the future

  3. consumers open their shopping basket which contains the previously selected items and commit the payment

  4. payment is processed and merchant receives status

  5. merchants execute payment again (irregular interval) with the possibility to set a variable amount

Integration:

To start the payment process a request must be sent to a specific URL containing 3D Secure 2 request parameters.

You can find the information how to start the payment workflow in each integration guide for each product.

  1. QPAY: here

  2. QMORE: here

Since Card-On-File Flagging must be considered in this step, Strong Customer Authentication is required.

You have to set the following parameters with their values in the first request:

  • consumerBillingFirstname, consumerBillingLastname and consumerEmail (mandatory parameters)

  • consumerChallengeIndicator must be set to “04”

  • merchantTokenizationFlag must be set to “true”

You can find the list of 3DS Secure 2 parameter above.

We recommend to send optional parameter like consumerAuthenticationMethod and consumerShippingItemAvailability. If you submit more optional parameters, it is more likely that the issuer authenticates the consumer without requesting Strong Customer Authentication.

If the payment is done and you receive the result, the 3D Secure 2 process is also completed for the first payment.

Follow-Up Operations:

The merchant has to use the recurPayment backend operation (MIT) with the sourceOrderNumber, the merchantTokenizationFlag with the value "true" and the periodicType with the value "ucof". The sourceOrderNumber is the orderNumber from the last recurring transaction. If the last transaction was the initial transaction, use this orderNumber for the sourceOrderNumber instead.

Don’t forget to deposit your transaction. You can do that in the Payment Center, by the backend operation Deposit or by the request parameter Autodeposit.