3-D Secure was designed for e-commerce, not parking. Most parking transactions are card-present — a tap or a chip insert at a pay station where the cardholder is physically present with the card — and 3-D Secure has no role in those flows. But the parking industry has quietly become a card-not-present business on the side: mobile parking apps, monthly subscription billing, and cardholder-initiated reservations all generate CNP transactions that fall squarely inside the 3DS perimeter. 3-D Secure 2.0 (often written 3DS2) changes the cost, user experience, and liability of those transactions in material ways.

What 3-D Secure 2.0 Is

3-D Secure is an authentication protocol that lets the issuer verify a cardholder during a CNP transaction. The “three domains” are the issuer, the acquirer, and the interoperability domain that connects them. The current version — 3DS2, maintained by EMVCo — replaces the static-password experience of the original protocol with a risk-based authentication flow that only challenges cardholders when risk is elevated.

Under 3DS2 the merchant’s platform sends 10 to 100 data elements about the transaction and device to the issuer. The issuer’s Access Control Server (ACS) scores the risk and either approves the transaction frictionlessly or challenges the cardholder with a biometric, app-push, or OTP step. The vast majority of low-risk transactions are approved without any cardholder interaction.

Where 3DS2 Matters for Parking

Mobile Parking App Payments

When a driver opens a parking app and pays for a session by entering a card, that transaction is card-not-present. In the EU and UK, PSD2 strong customer authentication requires 3DS2 on most such transactions — though low-value and recurring exemptions can apply. In the U.S., 3DS2 is optional but increasingly adopted for its liability shift.

Monthly Parking Subscriptions

The first transaction when a new monthly parker enrolls and saves a card is card-not-present. After that, subsequent monthly charges are merchant-initiated transactions (MITs) against a stored credential — a different flow with different authentication rules. The first enrollment charge is the one where 3DS2 is most commonly applied.

Online Reservations

Airport parking reservations, event parking pre-booking, and similar patterns all run through 3DS2 at the point of booking. A successful authentication usually produces a reservation confirmation; a failed or abandoned challenge means no reservation.

In-app Wallet Top-ups

Parking wallets where drivers pre-fund a balance are CNP transactions. Some operators apply 3DS2 on every top-up; others authenticate once at enrollment and skip 3DS2 on reloads by relying on the stored credential framework.

Liability Shift

The commercial reason operators adopt 3DS2 is the liability shift. When a 3DS2 authentication succeeds and the transaction is flagged as authenticated to the acquirer, the liability for a subsequent fraud chargeback moves from the merchant to the issuer. Without 3DS2, CNP fraud chargebacks (dispute category “fraud — card-not-present”) fall on the merchant.

The shift only applies when the authentication actually occurs — an attempted-only response usually does not carry liability protection, and a frictionless approval without any liability-shift flag leaves the merchant exposed.

Exemptions and Low-friction Flows

3DS2 supports exemptions that let the merchant request no challenge even when SCA would otherwise apply:

  • Low-value transaction (LVT) — under EUR 30 in most European markets, with cumulative spend caps.
  • Transaction risk analysis (TRA) — the acquirer’s fraud rate is below a defined threshold.
  • Trusted beneficiary — the cardholder has whitelisted the merchant.
  • Merchant-initiated transaction (MIT) — recurring charges against a stored credential.
  • Corporate cards — cards issued to corporate travel programs with approved purchase-card frameworks.

For parking operators the MIT exemption is the most relevant: monthly subscription charges should be flagged as MIT, not as new CNP transactions, to avoid unnecessary SCA friction and to signal the correct liability model.

Implementation Considerations

  • Which acquirer handles 3DS2 (most require a specific plug-in or API endpoint).
  • How the app or web platform passes device-fingerprint data to the 3DS2 server.
  • Whether the cardholder experience is an in-app biometric challenge, a banking-app push, or an SMS OTP fallback.
  • Whether declined authentications retry on the non-authenticated path (a liability-shift giveback) or hard-decline.
  • How the transaction is tagged for reconciliation and chargeback defense.

The technical complexity is why most parking platforms outsource 3DS2 to their payment gateway rather than implementing the full protocol in-house.

FAQ

Do I need 3DS2 for transactions at the pay station?

No. Card-present chip and contactless transactions are outside the 3DS2 scope. 3DS2 applies only to card-not-present flows.

Will 3DS2 reduce my chargebacks?

It will reduce CNP fraud chargebacks on transactions where the authentication succeeded and liability shifted. It does not reduce non-fraud disputes such as service-not-rendered or duplicate-charge complaints.

What happens if a cardholder fails the 3DS2 challenge?

The authentication is declined and the transaction cannot proceed under the authenticated path. Some merchants attempt a non-authenticated authorization as a fallback, accepting full chargeback liability for that attempt.

Is 3DS1 still supported?

Card schemes have retired 3DS1 in most markets. New implementations should use 3DS2 exclusively.