Article

Fraud API vs embedded fraud tools: what UK businesses should consider

Choosing between a fraud API and an embedded fraud tool? Learn the trade-offs, how each approach works, and why context across the payment flow can improve fraud prevention and conversion.

March 16th, 2026
 ·  6 minutes
woman checking the customer area

If you're looking at fraud APIs or embedded fraud tools, at least one of these will sound familiar: 

  • Chargebacks are climbing

  • Your fraud team is writing reactive rules that never quite catch up

  • You've outsourced fraud management, losing visibility into how decisions are being made

The pressure runs in both directions. Leadership wants fraud reduced, but an overly aggressive approach creates friction that damages the customer experience and quietly erodes revenue through lost legitimate sales.

When evaluating your options, you’re usually faced with a decision between a standalone fraud API or an embedded solution within your payments platform. Both can work well, but they operate very differently. And the choice can influence not only fraud rates but also conversion, operational complexity, and long-term scalability. 

To help you make the right choice for your business, this article will cover:

  • Why fraud has become harder to manage

  • The difference between fraud APIs and embedded fraud tools

  • How to evaluate a fraud solution

  • How Adyen approaches fraud defence

  • How Merlin Entertainments reduced fraud notifications by 40%

Why fraud management is becoming more complicated

Fraud today looks very different from even a few years ago. Attacks are more automated, more coordinated, and AI-driven tools make them faster to adapt when defences change. Card testing, account takeovers, and friendly fraud have all become more sophisticated, and the window to catch them before damage is done has shortened. Fraudsters increasingly rely on bots to probe for weaknesses at scale, making real-time fraud detection a necessity.

At the same time, the cost of getting it wrong runs in both directions. An increase in fraud causes chargebacks to rise, schemes take notice, and dispute handling becomes a burden. But false positives carry their own cost: every legitimate customer incorrectly declined is lost revenue and a damaged relationship, not just an avoided fraud risk.

Most fraud teams are managing this with tools that weren't built for it. Static rules and manual review queues require constant upkeep, struggle to keep pace with new fraud patterns, and don't scale as transaction volumes grow. And because fraud patterns are rarely confined to a single business or region, a tool that only sees your own data will always be working with an incomplete picture.

Are you ready to explore Adyen’s embedded fraud tool? Get in touch to learn more.

Fraud APIs vs embedded fraud tools: what’s the difference?

A fraud detection API evaluates risk and returns a decision: approve, review, or decline. It integrates with your checkout page and backend services, receives transaction data via API calls, and applies rules, machine learning algorithms, or both to produce a fraud score for each event. Many providers also extend decisioning to account creation, refunds, and promotional abuse (although these capabilities are often extensions of solutions originally designed for payment fraud).

An embedded fraud tool works differently. Rather than sitting alongside your payments infrastructure as a separate service, it operates within the payment flow itself. This gives it access to the full context of a transaction, including payment method, issuer responses, authentication signals, and behaviour across channels and regions. Because fraud sits within the same platform as authorisation, routing, and settlement, risk decisions are made with a richer picture of what a legitimate transaction looks like, across your business and others on the same platform. Signals such as device fingerprinting and cross-channel activity feed directly into risk scoring, without requiring separate integrations to collect them.

The core difference comes down to context and integration. A fraud API works with the data you send it. An embedded tool views the entire payment lifecycle and aligns fraud decisions with conversion and authorisation goals, rather than fraud prevention metrics in isolation.

Pros, cons, and how to choose

When evaluating fraud solutions, the decision is usually between standalone APIs or embedded fraud tools. The right choice depends on your setup and goals.

Summary table: Standalone API vs embedded tool

Integration

Standalone fraud APIs

Separate service integrated via API

Embedded fraud tools

Built directly into the payments platform


Fraud decisioning

Standalone fraud APIs

A standalone function

Embedded fraud tools

Part of the payment flow


Data used for decisions

Standalone fraud APIs

Data you send plus patterns observed across the provider’s customer base

Embedded fraud tools

Full payment context, including payment methods, issuer responses, cross-channel activity, and patterns across businesses and regions


View of the payment lifecycle

Standalone fraud APIs

Limited visibility beyond the transaction or event being assessed

Embedded fraud tools

End-to-end visibility across authorisation, routing, authentication, and settlement


Approach to fraud vs conversion

Standalone fraud APIs

Optimised for fraud metrics

Embedded fraud tools

Optimised for full funnel performance


Integration effort

Standalone fraud APIs

Requires separate build and ongoing maintenance 

Embedded fraud tools

No separate fraud integration; lives within the existing payments setup


Operational overhead

Standalone fraud APIs

Additional vendor, contracts, integrations, and upkeep

Embedded fraud tools

Fewer systems and vendors to manage


Decisioning beyond payments

Standalone fraud APIs

May extend to account creation, refunds, and promotional abuse

Embedded fraud tools

Typically focused on payment transaction risk

Standalone fraud APIs

Standalone fraud tools integrate via API and focus on risk decisioning. Here’s where they work well: 

  • They are highly specialised: Fraud is the only product, so investment and knowledge are focused. 

  • They might cover your entire sales funnel:  Some fraud APIs also assess risk across account creation, refunds, and promotional abuse.

  • They have various pricing models: Some offer chargeback guarantees or fixed pricing.

However, there are also trade-offs to consider: 

  • Their data can be limited: Decisions rely on the transaction data you send and patterns across the provider’s customers, which may not align with your business. They typically do not see issuer behaviour, routing outcomes, or full payment lifecycle signals without significant engineering investment. They are also typically limited to ecommerce transaction data, often excluding in-store purchases and other trust-relevant signals such as banking records or identity verification data.

  • Ongoing integration and maintenance effort: You need to keep integrations in sync with checkout changes, refunds, and chargebacks. Most standalone fraud APIs provide SDKs and developer documentation to support the initial build, but the ongoing maintenance burden remains regardless of how straightforward the setup is. Engineering effort and vendor management add up over time, and maintaining workflows across multiple systems introduces ongoing overhead.

  • Conservative incentives: Chargeback guarantees encourage providers to pursue higher decline rates, and performance guarantees are often defined vaguely in contracts, with limited financial accountability if targets are missed.

  • Lack of control: Many fraud APIs operate as black-box solutions, offering minimal transparency into risk signals, the rationale for fraud scoring, or model tuning. As a result, you may face challenges explaining performance internally, and you’re fully dependent on vendor intervention when rapid adjustments are needed during emerging fraudulent activities.

Typically suits: High-margin businesses or teams that want to fully outsource fraud detection, even if that means more engineering and operational maintenance work.

Embedded fraud tools

Embedded fraud tools sit within the payments platform and combine identity verification with full-funnel payments data for real-time risk decisioning. Where they work well:

  • They have access to the full payment context: Decisions factor in payment methods, issuer responses, cross-channel activity, device fingerprinting, geolocation, IP address data, and fraud patterns across businesses and regions.

  • Incentives aligned with payment performance: Risk sits alongside authorisation, routing, and authentication. The goal is to reduce fraud while maintaining healthy card approval rates. Because risk decisions are made within the payment flow rather than alongside it, the user experience remains smooth for genuine customers, with friction applied only where the risk profile warrants it.

  • Faster implementation: No separate fraud integration to build or maintain. 

  • Lower operational overhead: Fewer vendors and fewer systems to maintain.

Trade-offs to consider include: 

  • Focus on payment fraud: Embedded tools typically focus on payment transaction risk, not broader abuse like rewards, promotions, or loyalty.

  • Not always strongest on narrow fraud-only metrics: Stand-alone fraud tools may outperform on metrics like chargeback rate or fraud loss when optimised in isolation.

  • Vendor consolidation: Payments and fraud sit with the same provider, which may not suit every organisation.

Typically suits: Businesses whose use cases centre on payment transaction risk and who prioritise speed, operational simplicity, and balanced outcomes across fraud and conversion.

Five questions to ask before choosing a fraud solution

Before selecting a fraud tool, it’s worth considering the following:

1. What data is actually informing the risk decision?

Some tools assess only the data you pass for a single transaction. Others factor in how similar payments behave across channels, regions, issuers, and businesses. The more context a tool has, the better it can distinguish unusual behaviour from genuine customers.

2. Is its decisioning machine learning or rules-based?

Rule-based systems rely on predefined conditions and thresholds, which can be effective but require constant manual updates as fraud patterns change. Machine learning models can adapt more quickly by learning from large volumes of data, but they should not operate as a black box. The most practical setups combine machine learning with configurable rules, so you can handle edge cases, flag high risk transactions for additional scrutiny, and adjust thresholds to match your risk appetite and seasonal patterns.

3. What ongoing integration work will this require?

Fraud tools are rarely “set and forget.” Beyond the initial build, you may need to maintain integrations for refunds, chargebacks, new checkout flows, payment methods, or regional launches. Over time, this maintenance can consume more engineering effort than expected.

4. Who benefits when a transaction is declined?

Some providers are incentivised to minimise fraud at all costs, even if that means declining more legitimate customers. Chargeback guarantee models are a good example: when a provider absorbs the cost of fraud losses, the rational response is to decline more aggressively. That protects their margin, but it can quietly erode yours through lost revenue on legitimate orders. Providers measured on a balance between fraud prevention and payment acceptance have different incentives and typically produce different outcomes on the same traffic.

5. Do we want full outsourcing or internal control with support?

Full outsourcing removes day-to-day fraud management but also limits visibility and flexibility. A hybrid approach allows teams to rely on automation while still adjusting risk appetite, rules, or thresholds as the business changes. The right choice depends on how much control you want to retain.

How Adyen approaches fraud defence

Adyen is a global payments provider with an embedded suite of optimisation tools designed to balance fraud defence, conversion, and cost.

We work with digital businesses like Uber and Spotify, retailers like Burberry and Fortnum & Mason, and platforms like Epos Now and Fresha. Across the Black Friday weekend, we processed $43 billion of GMV. That scale helps train our models and improve decisions across all our customers.

Here’s what you can expect if you partner with us:

Benefit from fraud decisions that are based on behaviour over time, not one-off checks

Adyen's decisions are informed by user behaviour over time, including repeat transaction patterns, how payment details or devices appear across channels and regions, and how similar payments perform across the platform. This builds a richer picture of what genuine activity looks like, making it easier to spot anomalies without penalising customers whose behaviour falls outside a narrow definition of normal.

This makes it easier to approve genuine customers who look unusual in isolation, such as last-minute bookings, payments from abroad, or a new device, without lowering fraud thresholds across the board.

Get the speed and efficiency of machine learning without handing over total control

Adyen uses AI-powered machine learning trained on global payment data to adjust decisions as behaviour changes, without forcing you to give up control. You can test, tune, and combine machine learning with configurable rules to align with your risk appetite, seasonality, and business model. This lets you scale fraud defence without constant manual intervention while retaining visibility.

Fight fraud without adding friction to legitimate transactions

Some fraud tools reduce losses by adding friction, such as higher declines, more challenges, or more manual reviews, which can hurt conversion.

Adyen treats fraud as part of the payment journey. Risk decisions are made alongside authorisation, routing, and authentication, so fraud prevention does not operate in isolation. The objective is to stop fraudulent activity early while allowing legitimate customers to pay as quickly and easily as possible, all without requiring complex development work.

Customer example: how Merlin Entertainments reduced fraud by 40%

Merlin Entertainments wanted to move away from a reactive, rules-based approach that was difficult to manage at scale. With Adyen, it replaced manual rule-writing with machine learning informed by platform-wide payment behaviour.

This allowed the team to catch fraud earlier in the payment flow while approving more genuine customers who previously looked risky under static rules. The results: 

  • 40% fewer fraud notifications, reducing chargeback handling and operational workload

  • 2% increase in authorisation rates, even while blocking more fraud

  • Fewer customer support calls caused by blocked or failed checkouts

Beyond the numbers, Merlin's team gained valuable time back. As Carl Mason, Head of Global Payment Risk, put it: "With Adyen Protect's machine learning, the system adapts by itself without us having to pinpoint it and create manual rules. This is a huge time-saver."

Read the full story → More thrills, fewer spills: How Merlin reduced fraud notifications by 40%

When businesses outgrow their fraud API

Standalone fraud APIs can be effective tools. For businesses that want to outsource fraud detection entirely, they offer specialised risk scoring and straightforward integrations.

However, their decisions are typically based on the data available at a single moment in time. They often operate separately from the rest of the payment flow and optimise primarily for fraud metrics.

As payments become more complex, many businesses look for a broader approach. Embedded fraud tools bring risk decisions into the payment infrastructure itself, combining fraud detection with authorisation, routing, and authentication signals.

This wider context can help teams strike a better balance between preventing fraud and approving genuine customers.

Merlin Entertainments’ experience illustrates this shift in practice. By moving from static rules to machine-learning-driven fraud protection informed by platform-wide payment behaviour, the company reduced fraud notifications while improving authorisation rates.

Want to explore whether our approach to fraud defence fits your business? Let’s talk.

If you’d like to learn more about how we approach full-funnel payments optimisation (including fraud defence), click below to get started.

[Get in touch]

Fraud API FAQs

What is the difference between a fraud API and an embedded fraud tool?

A fraud API is a standalone service that receives transaction data, applies rules or machine learning models, and returns a risk decision. An embedded fraud tool operates within the payment flow itself, giving it access to the full payment lifecycle, including issuer responses, authentication signals, and cross-channel behaviour. The core difference is context: a fraud API works with the data you send it, while an embedded tool sees the entire transaction picture and aligns fraud decisions with authorisation and conversion goals, not fraud metrics alone.

How does machine learning improve fraud detection?

Machine learning models can identify fraud patterns across large volumes of transaction data far faster than static rules, and they adapt as fraud behaviour changes without requiring constant manual updates. The most effective setups combine machine learning with configurable rules, so businesses can automate the majority of decisions while retaining control over edge cases, seasonal variations, and risk appetite. The quality of the underlying data matters significantly: models trained across a wider network of businesses and regions will generally outperform those trained on a single merchant's data.

How do I reduce false positives without increasing fraud risk?

False positives, where legitimate customers are incorrectly declined, are one of the most underreported costs of fraud prevention. Reducing them without increasing fraud exposure requires more than a single point-in-time check. Effective validation of whether a transaction is genuine draws on a richer context, including how a customer's payment details, device, and behaviour have appeared over time and across channels, rather than assessing each event in isolation. Embedded fraud tools that sit within the payment flow tend to perform better on this balance because their risk scoring draws on a fuller picture of what a genuine transaction looks like.

Fresh insights, straight to your inbox

Subscribe to email alerts