3D Secure Bookings: What Escape Room Owners Need to Know

3D Secure (3DS) is an extra identity check that a guest’s bank can run when they pay by card online. On a booking page, it either happens silently in the background or shows the guest a short prompt, such as a code or a banking app approval, before the booking is confirmed. For a US escape room, it matters for two reasons: it can move fraud liability to the card issuer, and a badly handled prompt can lose you a booking at the last step.

This guide explains how 3DS works, when guests see it, what it does and does not do for chargebacks and no-shows, and what to check with your payment processor.

TL;DR

• 3DS lets the card issuer verify the cardholder during an online payment. Low-risk payments pass without any interruption, and riskier ones get a challenge.
• Successful authentication on an eligible payment typically shifts fraud-dispute liability from you to the issuer, but it is not guaranteed for every dispute.
• 3DS2, the current version, sends far more data to the bank, so fewer guests are challenged than under the old redirect-heavy version.
• 3DS confirms who is paying. It does not make a guest turn up, so reminders and sensible booking policies still do the no-show work.
• Your processor, not your booking page design, decides how 3DS is switched on. Ask it three questions before peak season (listed below).

Table of Contents

• What 3D Secure does during an online booking
• 3DS1 versus 3DS2: why the old horror stories are outdated
• When your guests will see a challenge
• What 3DS does for fraud and chargebacks
• The cost: abandoned bookings at the challenge step
• Failed authentication is not the same as a declined card
• Does 3DS prevent no-shows?
• What to check with your payment processor
• Our view: protect the payment without punishing the guest
• How Riddlio fits in
• A short checklist before your busy season
• FAQ
• Sources

What 3D Secure does during an online booking

The “3D” refers to three domains: the merchant, the card issuer and the network between them. The idea is simple. When a guest enters card details on your booking page, you send the transaction, payment method and device data to the issuer. The issuer uses that to decide whether the person at the keyboard is likely to be the real cardholder. EMVCo, the body that maintains the standard, describes this as a data exchange between merchant and issuer, where the issuer can approve many transactions without adding friction or ask higher-risk customers to prove who they are.

In the card networks’ own description, the merchant starts the authentication, the 3DS network manages the data exchange and rules, and the issuer’s access control server (ACS) assesses the risk and authenticates the cardholder.

For a booking, the sequence looks like this:

1. The guest picks a room, a time slot and a group size, then enters card details.
2. Your payment setup asks the issuer to authenticate the payer.
3. The issuer either approves quietly (frictionless flow) or asks for proof (challenge flow).
4. Once authentication succeeds, the payment is submitted with the authentication reference, and the guest sees the confirmation page.

That last step is worth noticing. Mastercard’s gateway documentation describes the successful flow as initiating authentication, collecting the ACS method, authenticating the payer, submitting the payment with the 3DS transaction ID, and only then showing the confirmation. If authentication fails, the booking should not go through as a normal paid booking.

3DS1 versus 3DS2: why the old horror stories are outdated

If you have ever abandoned a purchase because a clunky bank pop-up appeared, you met the first generation of 3DS. Aite Group’s analysis notes that the original experience was widely seen as cumbersome, while EMV 3DS (the technical name for 3DS2) added risk-based authentication so only transactions above a risk threshold need a step-up check.

The practical differences:

Stripe’s guide on the topic adds that 3DS2 can embed the challenge inside checkout instead of relying on disruptive redirects, and that it was designed to reduce the disruption of the first version by giving the issuer more context for its risk assessment.

This matters for escape rooms because a large share of your guests book on a phone, often while chatting with the friends they are booking for. A challenge that works in a mobile browser is far less likely to end the session than one that bounces them to an unfamiliar bank page.

When your guests will see a challenge

The issuer decides, not you and not the booking software. A challenge is typically shown when the issuer’s real-time assessment says the payment is not trustworthy enough on its own. Low-risk payments can be authenticated in the background, so checkout is not interrupted.

In the challenge flow, the payer is redirected to the issuer’s access control server, shown an authentication screen, and then returned with the result. Stripe notes that 3DS may be triggered by the issuer, by regulation, or by a merchant’s own risk rules, and that not every transaction supports it, including some wallet and off-session payments.

Situations where a challenge is more likely in practice, based on how risk-based systems work:

• A guest using a card for the first time online with you.
• A large group booking or a private event with a high deposit.
• A guest paying from a new device or an unusual location.
• A card issued outside the US, where regional rules may require stronger authentication.

In the US, 3DS is generally not mandated the way it is for some European payments, so many US guests will never see a prompt. That is why you may go months without noticing it, then get a confused message from an international visitor or a corporate team-building organiser.

What 3DS does for fraud and chargebacks

This is the main commercial reason to care. According to Stripe’s documentation, successfully authenticated eligible fraud disputes typically receive a liability shift from the merchant to the card issuer. The same page is careful to say that this is not guaranteed for every payment or dispute.

There is a flip side that owners often miss. If a card does not support 3DS, or an authentication error occurs, the payment may proceed normally, but no successful authentication has happened and liability generally does not shift to the issuer. In other words, “the payment went through” and “the payment is protected” are two different things.

What 3DS covers is fraud: someone using a stolen card to book. It does not cover the other common dispute types a venue sees:

• “I didn’t get what I paid for” disputes, for example when a guest claims the room was not as described.
• Cancellation disputes, where a guest says they cancelled but your policy says otherwise.
• Duplicate charges from a double-clicked pay button.

Clear policies, instant confirmation emails and good records handle those. Our chargeback prevention guide covers the controls that matter beyond authentication.

The cost: abandoned bookings at the challenge step

Every extra step costs conversions. Adyen’s documentation covers both native 3DS2 inside a website or app and redirect authentication to the issuer’s site, and it cautions that redirects can reduce conversion because of technical errors or shopper abandonment. The in-page option is generally the safer choice for a booking page.

A few things within your control reduce the damage:

• Keep the page fast. A challenge window that loads slowly on top of a slow checkout is where guests give up. See our notes on booking page speed.
• Keep checkout short. The fewer fields before the card step, the more patience a guest has left for a bank prompt. We compare the options in two-step versus one-page checkout.
• Offer a way back. If a guest’s authentication fails, they should land on a page that lets them retry or use another card, with their chosen slot still held for a few minutes.
• Tell guests what to expect. A single line near the pay button, such as “Your bank may ask you to confirm this payment”, cuts confusion.

Failed authentication is not the same as a declined card

Support teams often lump these together, but they have different fixes. Mastercard’s gateway distinguishes outcomes such as authentication failed, rejected, pending, unavailable and successful, and says merchants should not proceed when authentication is failed or rejected.

The same documentation lists reasons authentication can fail, including:

• the cardholder fails the card authentication,
• an unknown or unsupported device,
• an expired card,
• an invalid card or transaction,
• suspected fraud,
• a timeout,
• a technical issue at the issuer,
• the cardholder simply not completing the check.

A useful way to explain it to staff: a declined payment means the bank said no to the money. A failed authentication means the bank was not convinced about who was asking, before it even considered the money. The advice differs:

For the wider recovery process, including how to follow up on abandoned payments, see our payment failure recovery playbook.

Does 3DS prevent no-shows?

No. 3DS answers one question: is the person paying the genuine cardholder? It says nothing about whether that person, or their team of six, will arrive at 7 pm on Saturday. A guest can pass authentication perfectly and still forget the booking.

What 3DS can do indirectly is cut a specific kind of lost slot: bookings made with stolen cards, which later get charged back and leave an empty room with no revenue. That is a fraud problem, not a no-show problem, but the empty room looks the same on your calendar.

The levers that actually reduce ordinary no-shows are separate:

• Taking a deposit or full payment at booking, so the guest has something at stake.
• Automated reminders by email and text. See how SMS reminders for escape room bookings work.
• A clear, visible cancellation and rescheduling policy.
• Easy rescheduling, so a guest who cannot come moves the booking instead of vanishing.

Think of 3DS as protecting the payment, and reminders and deposits as protecting the slot.

What to check with your payment processor

Because 3DS runs through your processor and its gateway, the setup questions are for them. The gateway documentation we reviewed lists the requirements for one major network: a registered acquirer, a gateway profile enabled for a supported 3DS scheme and version, and a recent API version. The integration must also submit the required payer data, handle both frictionless and challenge flows, and submit the payment with the authentication ID before confirming.

Most venues using a mainstream processor do not build any of that themselves, but you should still ask:

1. Is 3DS2 enabled on my account, and is it triggered by the issuer only, or also by my own rules?
2. Does the challenge appear inside my booking page or as a redirect?
3. Which payment methods are excluded? Wallet payments and off-session charges, such as a balance collected later, may not carry authentication.

If you take card details on your own site rather than through a hosted payment field, your compliance burden also grows. Our PCI compliance guide for escape room owners explains why hosted fields keep most of that off your plate. If you are still choosing a processor, Stripe versus Square for escape rooms lays out the practical differences.

Our view: protect the payment without punishing the guest

We build booking software for escape rooms only, so we see what a failed checkout looks like from the venue’s side: a room that sat empty because a guest gave up on a bank prompt, or a room that sat empty because a stolen card was charged back three weeks later. Both are lost revenue, and owners tend to fix only one.

Our view is that authentication should be risk-based, not universal. The standard itself is built on that idea: EMVCo’s stated aim is preventing card-not-present fraud without unnecessary checkout friction. Forcing every guest through a challenge to catch the rare fraudster is a bad trade for a venue whose typical booking is a group of friends. Letting the issuer decide, and keeping the rest of the flow quick and clear, is the better default.

We also think owners should stop treating payments as a black box. Know what your processor does, know which of your disputes are fraud and which are policy, and measure the drop-off at the payment step separately from the rest of the funnel. That is where the answer to “is 3DS costing me bookings?” lives. Our approach to payments is to connect your own processor account, charge no commission on bookings, and give you reporting so you can see the result.

— Iosif Beraru

How Riddlio fits in

Riddlio is a booking and management platform built for escape rooms. It connects to payment providers, so your guests pay through a processor you choose, while the same dashboard shows bookings, payments, reminders and analytics. You can see how this works on our escape room payment processing page.

Plans are flat monthly fees with no booking commission: Starter at $29 per month, Pro at $79 per month and Unlimited at $199 per month, plus an Enterprise plan with no published price. Authentication behaviour itself depends on your processor and your guests’ banks, so confirm the three questions above with them when you set up.

If you want to see the booking flow your guests would go through, start with our escape room booking system page.

A short checklist before your busy season

• Make a test booking on a phone with a real card and note whether a prompt appears.
• Ask your processor whether 3DS2 is on and whether challenges happen in-page.
• Separate your last six months of disputes into fraud, policy and duplicate charges.
• Check what guests see after a failed authentication: a clear message and a retry option, not a dead end.
• Brief staff on the difference between a declined card and a failed authentication, using the table above.
• Confirm your reminder messages go out automatically, because that is your no-show defence.

FAQ

What is 3D Secure authentication?

3D Secure is a protocol that lets the card issuer verify the cardholder during an online card payment. The merchant sends transaction and device data, and the issuer either approves quietly or asks the guest to confirm, for example with a code or banking app. EMVCo maintains the EMV 3DS standard.

What is 3D Secure 2 and how is it different?

3DS2 is the newer version of the protocol. It shares much more data with the bank, supports biometrics and one-time passcodes, works better on mobile, and lets the challenge sit inside checkout. Stripe’s guide to 3DS2 summarises the changes. The result is fewer interruptions for low-risk payments.

Why was my guest asked to verify a payment, and what if it fails?

The card issuer decided the payment needed extra proof, or a rule from the issuer, regulation or the merchant required it. If it fails, the guest can usually retry once, then switch cards or call the bank. A failed check is different from a declined payment, which is about funds or limits.

Does 3DS protect me from all chargebacks?

No. Successfully authenticated, eligible fraud disputes typically shift liability to the issuer, but this is not guaranteed for every dispute. It does not cover disputes about service, cancellations or duplicate charges, which need clear policies and records.

Will 3DS reduce no-shows at my escape room?

Not directly. It verifies who is paying, not whether they will attend. Deposits, automatic email and text reminders and an easy rescheduling option are what cut no-shows.

Sources

• EMV 3-D Secure | EMVCo
• 3D Secure: your guide to safer transactions | Visa
• Integration Guide: 3-D Secure authentication | Mastercard Gateway
• Authenticate with 3D Secure | Stripe Documentation
• 3D Secure 2 | Stripe
• EMV 3-D Secure: More Approvals, Fewer Losses for Merchants | Aite Group
• 3D Secure 2 authentication | Adyen Docs

Recommended

• Booking Form Design: 6 Checks That Cut No Shows for Escape Rooms
• PCI Compliance for Bookings: An Escape Room Owner’s Guide
• Stripe vs Square for escape rooms: which to pick
• Private vs Public Bookings for Escape Rooms: Which Model Fits?