Strong Customer Authentication (SCA)

Felloh handles Strong Customer Authentication (SCA) and 3D Secure (3DS) automatically on every payment. This guide explains how SCA works, why travel payments have unique requirements, and how Felloh's Fraud Shield gives you control over 3DS rules.

What is SCA?

Strong Customer Authentication is a European regulatory requirement (part of PSD2) that mandates multi-factor authentication for online payments. It applies to card-not-present transactions where both the cardholder's bank (issuer) and the merchant's bank (acquirer) are in the European Economic Area (EEA) or the UK.

SCA requires at least two of the following three factors:

Factor	Category	Example
Something the customer knows	Knowledge	Password, PIN, security question
Something the customer has	Possession	Mobile phone, hardware token, banking app
Something the customer is	Inherence	Fingerprint, face recognition

In practice, SCA is implemented through 3D Secure 2 (3DS2) — the protocol that triggers the "Verify your payment" step during online checkout, typically via a bank app notification or SMS code.

How Felloh handles SCA

Felloh handles 3DS authentication automatically. You do not need to implement the 3DS flow yourself — it's built into every payment method:

Payment method	3DS handling
Payment Links	Automatic — 3DS challenge handled on Felloh's hosted page
Ecommerce Sessions	Automatic — 3DS challenge handled within the Felloh SDK
Scheduled Payments	Exemption applied — see merchant-initiated transactions

When a customer makes a payment through a Felloh payment link or ecommerce session:

Felloh submits the payment to the card network with a 3DS2 authentication request
The issuing bank determines whether a challenge is required (based on risk, amount, and regulations)
If a challenge is required, the customer completes it (e.g. approves in their banking app)
Felloh receives the authentication result and processes the payment
Your webhook receives the transaction result — you never see the 3DS flow

Customer → Felloh payment form → 3DS2 authentication (if required) → Payment processed
                                                                          ↓
                                              Your webhook ← transaction.completed

You do not need to build any 3DS handling in your integration. Felloh manages the entire authentication flow — including fallbacks, retries, and error handling.

SCA for travel payments

Travel payments have unique SCA characteristics that make them different from typical ecommerce:

High-value transactions

Travel bookings are often high-value (£1,000+), which means they are more likely to trigger a 3DS challenge. This is expected and protects both you and the customer. Felloh handles this automatically.

Deposit and balance payments

The common travel pattern of collecting a deposit now and the balance later has specific SCA implications:

Payment	SCA required?	Why
Initial deposit (customer present)	Yes — full 3DS	Customer is actively making the payment
Balance via new payment link	Yes — full 3DS	Customer is actively making the payment
Balance via scheduled payment (saved card)	Exemption applies	Merchant-initiated transaction — see below

Merchant-initiated transactions

When you create a scheduled payment using a tokenised card from a prior transaction, this is classified as a Merchant-Initiated Transaction (MIT). MITs are exempt from SCA because the customer is not present — they previously consented when they made the initial payment and their card was tokenised.

Felloh handles the MIT flagging automatically:

Customer pays a deposit via a payment link → full 3DS authentication → card is tokenised
You create a scheduled payment for the balance using the token
Felloh flags the scheduled payment as a MIT with a reference to the original authenticated transaction
The payment processes without requiring the customer to authenticate again

The initial payment (where the card is tokenised) must be fully authenticated with 3DS. This establishes the "consent" that allows subsequent merchant-initiated charges. Felloh ensures this automatically when customers pay via payment links or ecommerce sessions.

Recurring vs one-off MITs

Travel scheduled payments are typically classified as unscheduled credential-on-file (COF) transactions rather than recurring payments. The distinction matters:

Type	Description	Travel example
Recurring	Fixed amount, fixed interval, ongoing	Subscription (not typical in travel)
Unscheduled COF	Variable amount, variable timing, finite	Balance payment 30 days before departure

Felloh classifies scheduled payments correctly as unscheduled COF, which means:

Each charge can be for a different amount
Charges can be on any date
No assumption of ongoing payments

SCA exemptions

Not every payment requires a 3DS challenge. The regulations define several exemptions that can be applied to reduce friction for the customer. Felloh and the issuing bank negotiate these automatically.

Low-value transactions

Payments under €30 (or equivalent) may be exempt from SCA. However, issuers track cumulative low-value transactions and will trigger authentication after five consecutive exempt transactions or when the total exceeds €100.

Transaction Risk Analysis (TRA)

If the acquirer's fraud rate is below regulatory thresholds, payments up to certain values can be exempt:

Acquirer fraud rate	Maximum exempt amount
Below 0.13%	€100
Below 0.06%	€250
Below 0.01%	€500

Trusted beneficiaries

Customers can mark a merchant as a "trusted beneficiary" in their banking app, exempting future payments from SCA. This is managed by the issuing bank, not by Felloh.

Merchant-initiated transactions

As described above, scheduled payments using tokenised cards from a previously authenticated transaction are exempt. This is the most relevant exemption for travel businesses.

Exemptions are requests, not guarantees. The issuing bank always has the final say on whether to apply an exemption or require authentication. Felloh requests exemptions where appropriate, but the customer may still be asked to authenticate.

Fraud Shield and 3DS rules

Felloh's Fraud Shield includes configurable 3DS rules that give you control over when additional authentication is triggered — beyond the regulatory requirements.

3DS rules

Rule	What it does
High Decline Velocity	Triggers 3DS after N declined attempts from the same IP within an hour

Configure 3DS rules in the Felloh Dashboard under Fraud Shield. These rules add an extra layer of protection on top of the issuer's own 3DS decisions.

Other Fraud Shield rules that affect SCA

While not 3DS-specific, these Fraud Shield rules work alongside SCA to protect your business:

Category	Examples
Card rules	Block prepaid/virtual cards, detect expiry guessing, block repeated CVV attempts
Customer rules	Blacklist check, disposable email detection, name-cardholder mismatch
Device rules	Device-to-card velocity, timezone-geo mismatch, VPN/proxy detection, block hosting providers
Location rules	Block high-risk card origins, card-geographic mismatch
Velocity rules	High decline velocity, high capture velocity, email-to-card fan-out

These rules can block suspicious transactions before they even reach the 3DS stage — reducing fraud without adding customer friction.

What happens when 3DS fails

If a customer fails 3DS authentication (e.g. enters the wrong code, or their bank declines the authentication), the payment will not be processed. Felloh handles this gracefully:

On payment links

The customer sees an error message on the payment page and can retry with the same or a different card. The payment link remains active.

On ecommerce sessions

The Felloh SDK returns a failure status to your application. You can display an appropriate message and offer the customer options — retry, use a different card, or switch to open banking (which does not require 3DS).

On scheduled payments

If a scheduled payment fails due to an authentication issue (e.g. the issuer requires re-authentication), Felloh will notify you via webhook. You can then send the customer a new payment link to re-authenticate and complete the payment.

Open banking payments are not subject to 3DS — they use the customer's own banking app for authentication. Offering open banking alongside card payments on your payment links gives customers an alternative if they experience 3DS issues.

SCA compliance checklist

Use Felloh-hosted payment forms — payment links, JavaScript SDK, or mobile SDKs handle 3DS automatically
Do not implement custom 3DS flows — Felloh manages the entire authentication lifecycle
Ensure initial payments are customer-initiated — the first payment on a booking should be via a payment link or ecommerce session (not a scheduled payment) to establish 3DS consent
Use scheduled payments for subsequent charges — balance payments using tokenised cards from an authenticated initial payment are MIT-exempt
Configure Fraud Shield rules — review and enable appropriate 3DS, card, device, and velocity rules in the Dashboard
Handle webhook notifications — listen for transaction.failed events to detect authentication failures and send customers alternative payment options
Offer open banking — enable open banking on payment links as a fallback for customers who experience 3DS friction