Experience the difference of "Elite".

Getting Started

Core Concepts

Overview

Bookings & Quotes

Damage Protection

Data Management

Deposits

Email Template Library

Fields

Guests

Integrations

Listing Site Integration

Messaging

My Account

Payment Processing

Privacy & Security

Properties

Property Management

Quotes

Rates

Renter Agreements

Reporting

Reviews

Rules

Security Deposits

Suppressed Email Addresses

Tags

Taxes

Team Access

Technical Stuff

Travel Insurance

Triggers

Verified Email Domains

Channel Management

Channel Management

API Integrations

Calendar Import/Export

Channel Bridge

Integrations

OwnerRez APIs

Payment Processing

Testing

Websites

Change Log

2024

2023

2022

2021

2020

2019

Staff Reference

Payment Processing - 3-D Secure 2.0 (3DS2)

3-D Secure 2.0 (3DS or 3DS2) is a protocol that allows merchants (e.g., owners, PM's, hosts) to securely transmit detailed transaction information to issuing banks, allowing the merchant to take advantage of the bank's more advanced fraud analysis tools.

Developed by Arcot Systems and Visa, this technology supports improved transmission security, and it has been adopted and implemented by all the major card networks under different names, including ProtectBuy and SafeKey.

What is 3-D Secure 2.0?

3-D Secure is a security protocol that aims to prevent fraudulent use of credit cards by authenticating cardholders in card-not-present (CNP) transactions. “3-D” stands for “3 Domain”, which includes the issuer domain, acquirer domain, and interoperability domain. These are the 3 domains in which the protocol operates in. The protocol is developed and managed by EMVCo, an organization jointly owned by major card brands Visa, Mastercard, American Express, Discover, JCB, and UnionPay.

How did 3-D Secure 1.0 work?

The first version of 3-D Secure technology had some limitations. As 3dsecure2.com puts it, "3D Secure 1 was ridiculously non-user friendly." The most significant limitation was the system for confirming the customer's identity when the bank's fraud analysis showed that the transaction was potentially risky, which was clunky and caused increases in cart abandonment. The original version also only supported transmission of 15 types of transaction data, limiting the analysis that could be done.

In the original version, customers had to opt into the program with their issuing bank, and a PIN was assigned to the customer to use the card online in a secure manner. This created two major issues for merchants:

  • Transactions were declined if the customer forgot the pin.
  • Customers were redirected to the card network websites from the merchant checkout page to approve the transaction, increasing the order approval time.

In the United States, where ease of use is always a key factor, 3-D Secure 1.0 was not a welcome addition, even though it was widely used and appreciated by European and Asian merchants. 3-D Secure 1.0 is still in use by merchants outside the U.S., and have seen a significant decline in the rate of fraud.

How does 3-D Secure 2.0 work?

Frictionless 3-D Secure 2.0 allows merchants to verify a transaction with the cardholder’s issuing bank in real time, using two-factor authentication to confirm the customer's identity when necessary.

Rather than static passwords, 3DS2 uses dynamic authentication methods such as biometrics and token-based authentication.

The 2.0 version of the technology enables a real-time, secure, information-sharing pipeline that merchants can use to send an unprecedented number of transaction attributes attempting to authenticate customers more accurately.

Where it matters

It is up to each merchant to decide whether to implement 3-D Secure 2.0 or not. However, 3DS2 is mandated in some countries/regions and is becoming more required as anti-fraud measures are heightened and as 3-D Secure 1 (3DS1) is deprecated.

OwnerRez Payment Processors supporting 3DS2

Process Implications

The purpose of 3DS2 is to add additional security and verification to online purchases.  Unfortunately, security and convenience are inherently at odds, so by its nature, the 3DS process still adds friction and delay to guest bookings.

  1. When guests wish to make a booking online, in the middle of the process they must wait for notifications from their bank, generally via text message but sometimes via email, which may be delayed or lost.
  2. Once the bank's notification has been received by the guest, they must approve it.  However, every bank does this differently, and not all of them may do this in an obvious or even functional way.  When guests run into problems with this stage, they'll naturally reach out to the merchant they're trying to make a purchase from, but the merchant isn't able to see or materially assist since the issue is with the guest's bank.
  3. The approval has to be transmitted back around to the payment processor, which as with the initial verification request, does not always take place promptly or at all.

The result is frequent incomplete checkouts, multiple attempts, delays, and general confusion and chaos.

There are internal operational implications as well.  By the nature of the 3DS requirement, payment approval tokens are not interchangeable between payment processors.  This means that, if a client decides to change to another processor, they must reach out to all existing guests and get them to re-enter their card information in order to process any scheduled payments or security deposit holds.  Naturally, guests are reluctant to do this.

In exchange, 3DS2 offers additional security and verification as a defense against chargebacks. And that's true - if you are using 3DS secure, a guest cannot fraudulently claim "unauthorized payment" in their chargeback.  However, most vacation rental chargebacks aren't this type - instead, the guest claims "product not delivered / not as advertised", which 3DS has no relevance to.

It is well documented that every additional required action by an online customer, increases the likelihood that they'll abandon their cart. By its nature, 3DS increases their burden by something like an order of magnitude. While we don't have any solid statistics on this, we'd estimate that the lost sales due to 3DS2 overhead would far exceed any possible chargebacks avoided.

Conclusion

At the present time, we do not recommend for 3DS2 to be used unless it is a legal requirement to do so.  As all technical standards do, 3DS2 will continue to improve over time and many of the remaining drawbacks/issues will surely be addressed in the future.  We'll keep an eye on these developments, and as things evolve, so will OwnerRez.