Low-Value Transaction Exemptions

Low-Value Transaction Exemption: How It Works Under SCA

A €20 ecommerce payment can be small enough to qualify for the low-value Strong Customer Authentication exemption and still end up requiring authentication.

That is not a contradiction. Low transaction value creates potential exemption eligibility; it does not give the merchant a permanent right to bypass SCA. The applicable payment service providers must also account for cumulative value or transaction-count limits, and the payer's issuer can still require Strong Customer Authentication when it considers authentication necessary.

For merchants processing large volumes of small purchases—digital goods, games, subscriptions, marketplaces, low-ticket retail, or other high-frequency ecommerce—the practical question is therefore not simply “Is this transaction below the SCA limit?”

It is:

Is the individual transaction below the applicable threshold, have the relevant cumulative controls remained within their limits, is the exemption being applied through the appropriate payment-service-provider flow, and will the issuer accept it?

This article focuses on those practical mechanics of the low-value transaction exemption, including the threshold, cumulative controls, issuer involvement, and what merchants should actually implement.

The figures below reflect the current EEA and UK rules reviewed in August 2026. Authentication regulation can change, so thresholds and provider implementation should be reconfirmed before relying on them in production.

What is the low-value SCA exemption?

The low-value transaction exemption allows payment service providers, under specified conditions, not to apply Strong Customer Authentication to a remote electronic payment transaction initiated by the payer.

Under the current EEA regulatory technical standards, the individual transaction must not exceed €30. The rules also impose cumulative controls based on payments made since SCA was last applied.

The UK's post-Brexit SCA framework uses its own values. Under the current FCA technical standards, the individual remote electronic transaction threshold is £25, together with separate UK cumulative controls.

So the first important distinction is:

EEA low-value threshold: €30

UK low-value threshold: £25

These are not global SCA limits.

Nor should a merchant assume that simply staying below €30 or £25 means every transaction will proceed without authentication.

Which transactions can qualify?

The exemption concerns remote electronic payment transactions initiated by the payer under the applicable SCA framework.

For an ecommerce merchant, a typical candidate might be a customer actively making a small online purchase.

For example:

Customer selects a €12 digital product → customer initiates checkout → payment is submitted electronically

The transaction value is below the EEA's €30 individual threshold.

That makes it potentially eligible for the low-value exemption.

It does not tell us whether the exemption can actually be used.

The cumulative controls still matter.

It is also important not to confuse low-value exemption treatment with transactions that have a different SCA classification altogether.

For example:

•a genuine merchant-initiated transaction may be treated differently because the payer is not initiating that subsequent payment;

•a qualifying recurring-payment series has its own SCA treatment;

•another exemption, such as Transaction Risk Analysis, may potentially be used in an appropriate payment flow.

The low-value exemption should therefore be analyzed as one SCA exemption, not as a general rule for every small payment.

For the broader exemption framework, see SCA Exemptions.

What is the EEA low-value transaction threshold?

Under Article 16 of the current EEA SCA regulatory technical standards, payment service providers may refrain from applying SCA to a remote electronic payment where the individual transaction does not exceed €30, provided the applicable cumulative conditions are also satisfied.

The important word is and.

Being at or below €30 satisfies the individual-value condition.

It does not by itself establish that the transaction can proceed without SCA.

€29 can potentially qualify

If the relevant cumulative conditions have not been reached, a €29 remote electronic payment could potentially use the exemption.

€31 does not qualify for this exemption

A €31 remote electronic payment is above the individual limit and therefore cannot rely on the EEA Article 16 low-value exemption.

That does not mean it automatically requires an interactive authentication challenge.

Another SCA exemption or treatment may be available depending on the circumstances and payment-provider implementation.

The correct conclusion is only:

The €31 payment cannot use the low-value exemption.

How do the EEA cumulative limits work?

The EEA rules add two controls based on activity since the last application of SCA.

Article 16 specifies:

•an individual transaction limit of €30;

•a cumulative-value control of €100 since the last SCA; and

•a consecutive-transaction control involving five previous remote electronic transactions since the last SCA.

These controls exist because otherwise a cardholder could potentially make an unlimited sequence of unauthenticated €29 transactions.

The exemption is designed for low-friction small payments, not permanent authentication avoidance.

The practical concept

Think of SCA as resetting the relevant low-value history.

After SCA is applied, a new sequence of potentially exempt low-value transactions can begin.

As more qualifying transactions are successfully initiated, the relevant payment service provider tracks the applicable cumulative value and/or transaction count.

When the applicable cumulative control is reached, SCA needs to be applied before the exemption can again operate from a newly authenticated starting point.

The EBA has clarified that PSPs may establish how they apply the cumulative controls and, when applying the exemption on a transaction-by-transaction basis, must monitor the relevant limits and require SCA once the applicable limit is reached. PSPs may also request SCA before reaching those limits on the basis of their fraud-management procedures.

That last point is important:

The cumulative limit is a ceiling for exemption use, not a promise that every transaction before the ceiling will be exempted.

The UK uses different cumulative values

The UK's current technical standards retain the same general structure but use different monetary values.

For remote electronic payments, the individual amount must not exceed £25. The relevant cumulative-value figure is £85, with the provision also referring to five previous consecutive remote electronic payment transactions since the last SCA.

That means a merchant serving both EEA and UK payments should not write one global rule such as:

if transaction < 30 → request low-value exemption

Apart from ignoring cumulative controls and currency differences, that design would treat separate regulatory regimes as if they were identical.

Keep thresholds and provider behavior configurable by the applicable payment flow.

Who tracks the cumulative amount and transaction count?

This is where merchant implementations can easily go wrong.

The regulation places the exemption mechanics on payment service providers, not on the merchant independently calculating a definitive SCA allowance from its own order database.

For remote card payments, the EBA has clarified that both the payee's PSP—the acquiring side—and the payer's PSP—the issuer side—can apply the Article 16 exemption. The payer's PSP ultimately decides whether to accept or apply the exemption; if it does not accept an exemption sought on the acquiring side, it can require SCA or, where authentication cannot technically be performed, decline the payment.

That matters because the merchant does not necessarily know the payer's complete relevant payment history.

Imagine a customer makes:

•€20 purchase at Merchant A;

•€25 purchase at Merchant B;

•€15 purchase at Merchant C;

•€25 purchase at your store.

Your store knows about the final €25 transaction.

It does not necessarily know what the payer has done elsewhere since their last SCA.

A merchant-side counter therefore cannot reliably represent the issuer's complete view.

What should the merchant track?

Merchants should still monitor their own payment and authentication outcomes for operational purposes.

But they should distinguish:

merchant analytics

from:

the regulatory counter used by the PSP applying the exemption.

Your PSP or acquirer should explain how its low-value exemption implementation works and what merchant-side configuration or transaction indicators it expects.

Do failed transactions count toward the cumulative limits?

The EBA has clarified that, for Article 16, the cumulative amount and count concern transactions that have been successfully initiated.

Unsuccessful authentications or declined transactions therefore do not necessarily increase the Article 16 counters in the same way as successfully initiated transactions, although a PSP is not prevented from using a more conservative approach that includes all authorized transactions.

This is another reason merchants should not try to reverse-engineer the regulatory counter solely from checkout attempts.

A merchant may see:

payment attempted

while the PSP's relevant counter logic may distinguish:

payment successfully initiated

from:

authentication failed

or:

authorization declined.

Can an issuer require SCA before the cumulative limit is reached?

Yes.

The thresholds describe when the low-value exemption may be applied.

They do not prohibit a PSP from requiring authentication earlier.

The EBA has explicitly stated that the Article 16 exemption does not prevent PSPs from requesting SCA before the cumulative limits are reached based on their fraud-management procedures.

For card payments, the issuer also retains the ultimate decision over whether to accept or apply an exemption.

So a merchant should expect this flow:

€15 transaction

→ appears potentially eligible for low-value exemption

→ acquiring side requests/applies supported exemption

→ issuer accepts

→ transaction continues without SCA

But this outcome is also possible:

€15 transaction

→ low-value exemption requested

→ issuer requires SCA

→ customer must authenticate

Neither outcome means the €15 threshold changed.

The second simply means the exemption was not accepted for that transaction.

A low-value exemption is not the same as a guaranteed frictionless checkout

This distinction deserves to be explicit.

Eligibility

The transaction appears to satisfy the conditions for the low-value exemption.

Exemption request or application

The appropriate PSP attempts to use that exemption within the payment flow.

Issuer decision

The issuer determines whether it will proceed without SCA or require authentication.

Authorization

Even if authentication is not required, the issuer still separately decides whether to authorize the payment.

Therefore:

Exempt from SCA does not mean guaranteed payment approval.

A low-value payment can be exempt from SCA and still be declined for ordinary authorization reasons.

Similarly, a payment can require successful SCA and still subsequently be declined by the issuer.

Merchants should keep authentication outcome and authorization outcome separate in their reporting.

What happens after SCA is performed?

The Article 16 cumulative controls are measured from the last application of Strong Customer Authentication.

Operationally, that means SCA creates a new starting point for the PSP's relevant cumulative calculation.

Consider this simplified conceptual sequence:

SCA performed

↓

low-value transaction

↓

low-value transaction

↓

low-value transaction

↓

relevant cumulative control reached

↓

SCA required/applied

↓

new low-value sequence begins

The exact point at which SCA occurs depends on the applicable regulatory limit, how the PSP applies its counters, and whether SCA is requested earlier for risk reasons.

What merchants should not do is treat the exemption as:

Customer authenticated once when the card was first saved, therefore every future small transaction is exempt forever.

The low-value exemption has its own cumulative mechanism.

Example: how a sequence can reach the cumulative-value control

Consider a simplified EEA example following the €100 cumulative-value condition.

Assume SCA has just been successfully applied.

Then the customer initiates:

Transaction

Amount

Running low-value total since SCA

1

€20

€20

2

€20

€40

3

€20

€60

4

€20

€80

5

€20

€100

Each individual payment is below €30.

But the exemption is not based only on each individual value.

The cumulative history matters as well.

The next payment cannot simply be treated as “another €20 payment, therefore no authentication.”

The PSP needs to account for the applicable cumulative rule and the customer's SCA history.

This example is deliberately simplified. PSP implementation can also involve the transaction-count condition, risk controls, and issuer decisions.

Transaction count matters independently of the amount spent

The rules also prevent an unlimited number of tiny transactions from continuing without SCA.

Imagine:

€3 → €3 → €3 → €3 → €3

The total is only €15.

But the number of consecutive transactions is itself relevant under Article 16.

This prevents the exemption from effectively becoming:

“Anything under €30 can remain unauthenticated indefinitely as long as the total stays small.”

The framework considers both transaction size and the sequence since the last SCA.

For developers, this is the reason the individual amount cannot be the only input into exemption logic.

Should merchants request the low-value exemption on every payment below the threshold?

Not automatically.

There are at least four reasons.

•Value alone does not establish eligibility

The PSP must also account for cumulative conditions.

•The issuer can still require SCA

An attempted exemption does not control the issuer's final authentication decision for card payments.

•PSP fraud controls can cause earlier authentication

The EBA expressly allows PSPs to require SCA before the exemption's cumulative ceiling is reached based on fraud-management procedures.

•Another exemption strategy may sometimes be more appropriate

Depending on transaction characteristics and the merchant's PSP/acquirer configuration, another exemption—such as Transaction Risk Analysis—may be the relevant route.

The merchant should therefore implement the exemption strategy actually supported by its PSP/acquirer rather than create an unconditional:

amount below threshold → bypass authentication

rule in checkout.

Low-value exemption versus Transaction Risk Analysis

Both can reduce unnecessary authentication, but they operate differently.

Low-value exemption

Transaction Risk Analysis exemption

Main basis

Small transaction amount + cumulative conditions

Transaction assessed as low risk under regulatory TRA conditions

Individual amount limit

Yes

Different value/fraud-rate conditions apply

Cumulative low-value counter

Yes

Not the defining mechanism

Fraud-rate dependency

Not the primary eligibility mechanism

Central to TRA eligibility

Merchant decides alone?

No

No

Issuer can still require SCA?

Yes

Yes

A merchant processing many €5 digital purchases may make frequent use of low-value exemption capabilities.

A merchant handling a broader range of transaction values may care more about its acquirer's TRA capabilities.

These are complementary concepts, not interchangeable labels.

For the detailed risk-based exemption framework, see Transaction Risk Analysis Exemptions.

What merchants need to implement

The low-value exemption should require relatively little merchant-owned regulatory logic.

That is a feature, not a weakness.

A merchant implementation should generally focus on the following.

Support SCA even for low-value payments

A low-value transaction can still require authentication.

The checkout therefore needs a working authentication path even if most of its payments fall below €30 or £25.

Use your PSP/acquirer's supported exemption mechanism

Do not invent a proprietary exemption flag or assume transaction value alone is sufficient.

Understand:

•whether the provider supports low-value exemption requests;

•which transactions it will submit using the exemption;

•what information the merchant needs to send;

•what happens when the issuer requires SCA instead.

Do not make the merchant database the regulatory source of truth

Tracking your own customer's low-value purchase history can be useful analytically.

It does not necessarily tell you what the relevant issuer or other PSP has counted since the customer's last SCA.

Handle authentication-required responses

Your payment flow needs to survive:

low-value attempt

→ issuer requires SCA

→ authentication

→ authorization

without forcing the customer to start the purchase from the beginning.

Separate SCA results from payment approval

Track:

•exemption requested;

•exemption accepted where observable;

•SCA requested;

•authentication completed;

•authentication failed;

•authorization approved;

•authorization declined.

This makes it possible to tell whether low-value transactions are failing because of authentication, issuer authorization, technical integration, or another cause.

Common merchant implementation mistakes

“Anything below €30 is exempt”

Incorrect.

€30 is the EEA individual transaction ceiling for this exemption. Cumulative controls and PSP/issuer decisions still matter.

Applying the EEA threshold in the UK

The current UK individual threshold is £25, not €30, with its own cumulative monetary value.

Building the exemption entirely from merchant-side order history

The merchant does not necessarily have the information necessary to reproduce the relevant PSP counters.

Assuming five payments always means the sixth will challenge

The regulatory mechanism needs to be interpreted through the PSP's implementation of the count/value controls, and SCA may also be requested earlier. Avoid building customer-facing promises around an exact challenge sequence.

Treating the exemption as guaranteed

The issuer can require SCA even where the acquiring side seeks to apply the exemption.

Treating every small payment as the same

A €10 customer-initiated purchase, €10 subscription renewal, and €10 genuine merchant-initiated transaction can have different SCA classifications even though their monetary value is identical.

A practical low-value exemption decision flow

For merchants, the architecture is better understood like this:

Customer initiates remote electronic payment

↓

Could SCA rules apply to the payment?

↓

Individual amount within local low-value threshold?

No

→ low-value exemption unavailable

→ evaluate normal SCA/other exemption route

Yes

↓

PSP/acquirer determines whether supported low-value exemption conditions are satisfied

↓

Low-value exemption submitted/applied where appropriate

↓

Issuer accepts?

Yes

→ proceed without SCA

→ authorization decision

No / SCA required

→ perform SCA

→ authorization decision

That is much closer to reality than:

price < threshold → skip 3DS.

What should merchants verify before launch?

If low-value transactions represent a meaningful share of your payments, ask your PSP or acquirer:

•Do you support the low-value SCA exemption?

•In which jurisdictions?

•How do you distinguish EEA and UK thresholds?

•Does the exemption require a merchant request or configuration?

•Which side applies the exemption in our card flow?

•How are the relevant cumulative controls managed?

•What response indicates that the issuer requires SCA?

•Can the checkout step up to authentication without restarting payment?

•What reporting shows exemption use and authentication outcomes?

•How should we distinguish low-value exemption attempts from TRA or other exemptions?

•What happens when thresholds or regulatory rules change?

For developers, one final question is equally important:

Are the thresholds configurable, or have we hard-coded today's regulatory values into payment logic?

The latter creates unnecessary rework when regulation, provider behavior, or market coverage changes.

Key takeaway

The low-value transaction exemption is designed to let qualifying small remote electronic payments proceed without Strong Customer Authentication when the applicable conditions are met.

Under the current EEA framework, the individual transaction threshold is €30, together with cumulative value and consecutive-transaction controls measured from the last SCA. The current UK framework uses £25 and its own £85 cumulative value, while retaining a consecutive-transaction control.

But those numbers are only the beginning of the implementation.

The merchant should remember four things:

Below the threshold does not automatically mean exempt.

The relevant payment service providers manage the cumulative exemption logic.

The issuer can still require SCA.

Once SCA is applied, the relevant low-value sequence starts again from a newly authenticated point.

The practical merchant architecture is therefore:

support the exemption, but always support authentication too.

That keeps small payments as frictionless as the applicable rules and risk decisions allow—without building a checkout that breaks the moment the issuer asks the customer to authenticate.

🙂 🙂 🙂 🙂 🙂

SEO, EDITORIAL & VISUAL GUIDANCE — NOT PART OF THE ARTICLE

Yes. For this page, I would make the SEO and reader experience revolve around one very clear proposition:

The low-value SCA exemption is not simply a transaction-value threshold. It is a threshold + cumulative controls + PSP/issuer decision.

That is the article’s strongest differentiator and directly matches the brief’s requirement to explain why a payment below the monetary threshold can still require authentication.

Recommended SEO metadata

Element

Recommendation

Low-Value SCA Exemption: €30, £25 & Cumulative Limits

Alternative SEO title

Low-Value Transaction Exemption: How SCA Limits Work

H1

Low-Value Transaction Exemption: How It Works Under SCA

Slug

/low-value-transaction-exemption/

low-value transaction exemption

Secondary keywords

SCA low value exemption, low value SCA exemption, PSD2 low value transaction, SCA transaction limit

Search intent

Specific practical/informational

Meta description

Learn how the low-value SCA exemption works, including EEA and UK thresholds, cumulative value and transaction-count limits, issuer decisions, and merchant implementation.

The current H1 is good. I would not overload it with PSD2, €30, £25, and SCA simultaneously. Use the SEO title to expose threshold-related search intent while keeping the article headline cleaner.

Add a direct-answer box immediately after the introduction

This would be my first editorial addition:

What is the low-value SCA exemption?

The low-value exemption can allow qualifying remote electronic payments to proceed without Strong Customer Authentication when the individual transaction and applicable cumulative conditions are satisfied. Under the current EEA rules, the individual limit is €30; the UK currently uses £25. A payment below the threshold is not automatically exempt because cumulative limits and the PSP or issuer’s authentication decision still matter.

That creates a highly extractable answer for search and AI retrieval.

Own the query “SCA transaction limit” carefully

A reader searching SCA transaction limit probably expects one number.

The article should deliberately correct that expectation:

There is no single “SCA transaction limit” above or below which authentication always applies. €30 in the EEA and £25 in the UK are individual transaction limits for the low-value exemption—not universal thresholds for SCA itself.

This is an excellent SEO passage because it answers the query while correcting the misconception rather than just repeating the keyword.

Original editorial framework: The Low-Value Exemption Test

I would formalize the article into a four-stage model:

Test

Question

•Transaction value

Is the individual payment within the applicable local threshold?

•Cumulative history

Have the relevant value/count controls since the last SCA remained within limits?

•PSP application

Can the relevant PSP/acquirer apply or request the exemption in this payment flow?

•Issuer decision

Does the issuer accept the non-SCA path or require authentication?

Then put this sentence immediately beneath it:

Passing Test 1 does not mean the transaction has passed Tests 2–4.

That may be the most useful original asset on the entire page.

Visual asset 1 — Low-value exemption decision tree

This should be the hero instructional graphic.

Customer initiates remote payment

↓

Could SCA apply?

↓

Below applicable low-value threshold?

No

→ low-value exemption unavailable

→ evaluate SCA / another applicable route

Yes

↓

Cumulative controls permit exemption?

↓

PSP/acquirer applies or requests exemption

↓

Issuer accepts?

Yes

→ continue without SCA

→ authorization

No

→ SCA required

→ authenticate

→ authorization

Suggested caption:

Low value establishes possible eligibility. It does not determine the final authentication outcome.

Suggested alt text:

“Low-value SCA exemption flow showing transaction-value threshold, cumulative controls, PSP exemption handling, issuer decision, authentication and authorization.”

Visual asset 2 — EEA versus UK thresholds

A very compact comparison card would perform well for readers scanning for numbers.

EEA

UK

Individual remote transaction

€30

£25

Cumulative monetary control

€100

£85

Consecutive transaction control

5 previous transactions

5 previous transactions

Authentication guaranteed to be skipped?

No

No

Add underneath:

These are low-value exemption conditions, not universal “SCA limits.”

That qualification needs to stay physically attached to the table wherever it is reused.

Visual asset 3 — “Threshold alone” versus “actual decision”

A before/after graphic:

Incorrect mental model

Payment = €15

→ below €30

→ No SCA

Better mental model

Payment = €15

→ below €30

→ cumulative controls

→ PSP exemption handling

→ issuer decision

→ SCA may or may not be required

Caption:

Amount is one input—not the entire decision.

This is simple enough to use as an inline graphic, social card, or explainer asset.

Visual asset 4 — How cumulative controls reset

This is especially useful because prose can make the counter logic feel abstract.

Use a conceptual timeline:

SCA

→ €18

→ €22

→ €15

→ €24

→ cumulative/count controls continue

→ SCA

→ counter/history begins again from new authenticated point

Do not try to present a sequence as though the merchant can predict precisely which payment will always challenge.

Add:

Illustrative only: PSPs and issuers manage the applicable controls, and SCA may be required earlier.

This caveat matters.

Visual asset 5 — Two independent cumulative controls

A split graphic:

VALUE CONTROL

€20

•€20

•€20

•€20

•€20

→ cumulative monetary condition becomes relevant

COUNT CONTROL

€3

→ €3

→ €3

→ €3

→ €3

→ consecutive transaction condition becomes relevant even though total spend remains small

Caption:

The low-value exemption limits both repeated value and repeated transaction count.

This is probably the best visual for explaining why five tiny payments can matter even when they are nowhere near €100 cumulatively.

Visual asset 6 — Who tracks what?

This would prevent one of the biggest implementation errors.

Merchant

PSP / acquirer

Issuer

Sends accurate transaction information

Supports/applies relevant exemption flow

Has payer-side transaction/authentication context

Configures supported exemption use

Manages applicable acquiring-side controls

Can require SCA

Handles authentication-required response

Returns exemption/auth results

Makes issuer-side authentication decision

Tracks merchant analytics

Operates regulated payment logic

Tracks its relevant SCA history

Then:

Your order database is useful for analytics. It is not automatically the regulatory source of truth for the payer’s low-value counter.

That is a very strong editorial callout for developers.

Visual asset 7 — Exemption outcome versus payment outcome

Show a 2×2 conceptual matrix:

Payment approved

Payment declined

No SCA required

Possible

Possible

SCA performed

Possible

Possible

Caption:

Authentication and authorization are different decisions.

This is small, but extremely valuable.

It prevents readers from thinking:

exemption accepted = payment succeeds

or:

SCA completed = authorization guaranteed

Add a “developer warning” box

I would add this close to the implementation section:

Do not implement the exemption like this

if amount < 30 then skip authentication

That ignores jurisdiction, currency, cumulative controls, PSP implementation and the issuer’s ability to require SCA.

Then:

Build for this instead

transaction context → provider exemption handling → issuer response → step-up authentication where required

This is highly memorable for technical readers.

Editorially separate regulation from merchant implementation

Use subtle callout labels where helpful:

REGULATORY RULE

What the RTS/FCA standards actually establish.

PSP / ISSUER MECHANIC

How the regulated payment-provider flow operates.

MERCHANT IMPLEMENTATION

What checkout and backend systems need to support.

RECOMMENDATION

Good architectural practice, not itself a legal requirement.

For example:

REGULATORY RULE: EEA individual limit €30.

MERCHANT IMPLEMENTATION: Do not hard-code €30 = no SCA.

That distinction would materially improve credibility.

Use the example sequence carefully

The current €20 × 5 sequence is useful, but I would title it:

Illustrative cumulative-value example — not a guaranteed challenge sequence

That protects against readers interpreting it as:

“The sixth transaction will always challenge.”

The article already correctly says provider implementation and issuer decisions matter; the visual framing should preserve that nuance.

Internal-link recommendations

This page should link outward aggressively enough to avoid becoming the general SCA exemptions pillar.

Current concept

Destination article

Suggested anchor

General SCA background

Strong Customer Authentication Explained

how Strong Customer Authentication works

Broader exemption framework

SCA Exemptions

other SCA exemptions and when they may apply

Risk-based alternative

Transaction Risk Analysis Exemptions

how the TRA exemption differs from low-value treatment

Merchant implementation

SCA Requirements for Merchants

how merchants should implement SCA and exemption recovery

3DS recovery

3D Secure Compliance

how EMV 3-D Secure supports authentication when SCA is required

The brief explicitly positions this article as the deep dive on low-value conditions rather than the general SCA or TRA page.

Search-intent subsections worth preserving

Make sure these questions remain explicit H2/H3 headings because they map well to what readers actually search:

•What is the low-value SCA exemption?

•What is the €30 SCA limit?

•What is the UK low-value SCA threshold?

•How does the €100 cumulative limit work?

•How many low-value transactions can occur before SCA?

•Who tracks the SCA cumulative limit?

•Can an issuer still require SCA below €30?

•Does the low-value counter reset after SCA?

•Should merchants request the low-value exemption automatically?

Those are preferable to manufacturing a repetitive FAQ block at the bottom.

Recommended snippet-oriented answer for “how many transactions?”

Be particularly careful with this query.

I would use:

Under the current EEA low-value exemption, the rules consider five previous consecutive remote electronic transactions since the last SCA alongside the cumulative monetary condition. That should not be interpreted as a guarantee that every first five low-value transactions will avoid SCA: PSPs and issuers can require authentication earlier.

That answers the query without creating the dangerous “every sixth transaction challenges” simplification.

A highly useful reader asset: Low-Value SCA Launch Checklist

Place this close to the conclusion.

Regulatory configuration

•EEA and UK thresholds are treated separately.

•Current thresholds have been reconfirmed.

•Values are configurable rather than permanently hard-coded.

Provider integration

•PSP/acquirer supports low-value exemption handling.

•Team knows whether merchant configuration is required.

•Exemption outcome is available in reporting where supported.

Authentication fallback

•Checkout can step up to SCA when issuer requires it.

•Customer does not need to restart checkout.

•Authentication and authorization outcomes are tracked separately.

Monitoring

•Low-value exemption attempts are measurable.

•Authentication-required responses are measurable.

•Payment declines are not automatically classified as SCA failures.

•EEA and UK performance can be analyzed separately.

This would make the article considerably more bookmarkable for payment teams.

Recommended structured data

Use Article plus your normal BreadcrumbList implementation.

For this page, visible freshness information matters more than adding elaborate schema:

Last regulatory review: August 2026

Regulatory coverage: EEA and UK low-value SCA exemption

Review note: Thresholds and rules should be reconfirmed before implementation

Because numeric regulatory content can become stale, I would schedule this page for a higher review frequency than a conceptual page such as “Strong Customer Authentication Explained.”

Recommended hero visual

Avoid a generic padlock/credit-card image.

Use:

Headline

€20 does not automatically mean “no SCA”

Visual

€20 transaction

↓

Below threshold ✓

↓

Cumulative controls ?

↓

PSP exemption path

↓

Issuer decision

↙ no SCA

↘ authenticate

Subline

Low value creates eligibility. It does not guarantee an exemption.

That communicates the article's entire value proposition immediately.

Best reusable social/editorial graphic

For LinkedIn, article previews, or cluster promotion:

The €30 SCA myth

Myth: “Payments below €30 do not require authentication.”

Reality: €30 is the EEA individual limit for one exemption. Cumulative controls and issuer decisions still matter.

This is strong because it corrects a real conceptual mistake without becoming clickbait.

Highest-priority additions

If you implement only five:

•Low-Value Exemption Test four-stage framework.

•EEA vs UK threshold comparison card.

•Value control vs transaction-count control visual.

•Merchant vs PSP/acquirer vs issuer responsibility map.

•Low-Value SCA Launch Checklist.

And I would protect these three lines during future editing:

Below the threshold means potentially eligible—not automatically exempt.

The merchant sees its own order history; the issuer may see a much broader authentication history.

Support the exemption, but always support authentication too.

Those are the statements that turn this from a threshold-definition article into a genuinely useful merchant implementation guide.