Adyen Guide: Features, Onboarding Requirements and Real Costs

Adyen Guide: Features, Onboarding Requirements and Real Costs

Adyen was founded in the Netherlands in 2006, and its positioning is clear: it puts acquiring, payment processing, risk and settlement into a single platform for merchants of meaningful scale. Its reputation in cross-border circles rests on two things, higher approval rates through local acquiring and the breadth of payment method coverage. Equally clear is that it is not a sign-up-and-go tool.

This guide follows the order in which a real project moves: eligibility first, then account and settlement structure, then integration and capability trade-offs, and finally go-live validation and cost accounting. Each section aims to give a decision rule rather than a feature list.

1. Onboarding: confirm eligibility first

Adyen serves legitimate businesses with steady volume, and onboarding reviews company documentation, business model, website compliance information and expected processing volume. Typical requirements include a verifiable legal entity, a clear product or service description, published refund and privacy policies, and expected volume that matches the business.

For teams outside the supported regions, the entity question remains the gating item; a Hong Kong, Singapore, European or US entity is usually needed, and the exact list of supported regions and documents should be confirmed with the Adyen commercial team. If your monthly volume is still early-stage, run the business on a general-purpose acquirer first and revisit migration once volume justifies it.

Understanding what the review is actually testing matters more than assembling documents. The question behind every request is whether this money flow can go wrong: is the product legal, is delivery verifiable, could buyers refund at scale, could the account be used to cash out. Every document maps back to one of those questions.

Four common reasons onboarding stalls

• A vague business model description: writing "cross-border e-commerce" or "digital services" on the form is close to writing nothing. The reviewer needs to know who pays, under what name, what is delivered and how refunds are handled. The vaguer the description, the more likely you are to be sent back for more information.
• A high-risk category: some categories are treated as dispute-prone by default, requiring extra licensing documents and tighter risk configuration; a few are out of scope entirely.
• Missing refund and privacy pages: the easiest item to overlook and the easiest to fix. Policy pages must match the real products, payment options and contact details; pasting template clauses tends to raise new questions during review.
• Expected volume that does not match the model: a number far above current scale invites requests for evidence, while a number far below may fail the provider's own threshold. A defensible estimate lines up with recent statements, media plans and repeat-purchase structure.

Two fallback paths if you are declined

The first is to run volume through a general-purpose acquirer, accumulate real statements, refund rates and dispute records, and come back months later, when "expected volume" is evidence rather than a guess. The second is to launch through a merchant-of-record model, where the platform sells in its own name and carries acquiring and tax responsibility, so you can validate market and conversion before deciding whether to build your own acquiring stack. The cost structures and conditions differ; see the Merchant of Record Platforms Guide.

A quick way to tell where you stand: can you produce several consecutive months of statements, describe your refund and chargeback process, and lay out next year's market expansion order. If you can, negotiation has a foundation. If you cannot, more documents will not help.

2. Accounts, settlement and currency structure

Many teams treat account structure as a one-off form at signup, when it is actually the foundation for every reconciliation, report and permission design that follows. Changing it later costs far more than changing code, so it deserves time before integration starts.

2.1 Planning the three account layers

Adyen accounts are usually structured as company, merchant account, and store or channel. The first layer is the contracting entity, set by the legal entity and rarely changed; the second carries transactions and settlement, with fees, payouts and reporting attached to it; the third is the traffic entry point, mapping to a website, an app or a physical store.

There are three common ways to split the second layer, with different trade-offs:

In practice, almost nobody uses a single split. A workable order is: split by contracting entity first, then by settlement currency or region under each entity, and use store or channel only to separate traffic sources. Business-line reporting is better handled through order fields and report dimensions than by opening another account layer; the finer the split, the higher the cost of maintaining permissions, fees and reconciliation rules.

2.2 Settlement cycle and settlement currency are two decisions

The cycle decides when money arrives; the currency decides what money arrives. They are configured independently, and treating them as one thing is the most common misunderstanding at integration time.

The cycle drives cash flow and float planning. The longer it is, the more working capital you need for refunds, chargebacks and operating costs, and that cost rarely appears on a fee schedule. The currency drives FX exposure: if you earn in several currencies but settle in one, you convert involuntarily at every settlement point, with the cost hidden in the rate rather than the fee.

A practical exercise is to write out three columns, buyer currency, acquiring settlement currency and company bookkeeping currency, then check where conversion happens, who bears it, and whether timing is a choice. Every extra conversion in that chain adds a layer of cost that is easy to miss.

2.3 Three changes multi-currency settlement makes to reconciliation

First, the unit of reconciliation moves from amount to amount plus currency. A single order can touch three currencies across payment, settlement and booking, so comparing amounts alone will never balance.

Second, the exchange rate becomes a field that must be recorded. Without the rate and the conversion timestamp, refunds cannot be validated against the original charge, monthly variances cannot be explained, and the work falls back to guesswork.

Third, period-cut problems multiply. Settlements that cross month-end, refunds landing in the next cycle and chargebacks deducted in reverse all create swings that look anomalous in a single month's report. The process has to express attribution period, not just occurrence date, or the gap keeps growing.

3. Integration

3.1 Commercial discussion and pricing

Adyen pricing typically uses interchange++ (cost-plus) or negotiated rates, and a quote requires a volume forecast. That means the first step is commercial, not technical.

Before the conversation, prepare three things: transaction mix by market and card type, recent statements, and a twelve-month growth outlook. The first two make the quote credible; the third determines how much support you get. Negotiating room usually comes from the quality of the transaction mix, not from raw volume alone.

3.2 Account structure and test environment

The account hierarchy is covered in section 2, so this section focuses on three sandbox traps. Test and production environments are isolated, with test card numbers and payment methods available in the sandbox; before launch, run refunds, partial refunds and chargeback responses end to end there.

The first trap is a mismatched payment method list: methods visible in the sandbox are not necessarily enabled for your entity and settlement currency in production. The second is that the sandbox does not simulate real settlement or fees, so accounting logic needs a second pass during small-volume production. The third is that sandbox callbacks behave perfectly, with no duplicates and no reordering, while exception paths only appear under real traffic.

3.3 Three integration paths

API-first suits teams with an existing front end who want full control of checkout. Hosted components let the platform handle the checkout page and compliance, launching faster. In-person terminals let physical stores share systems with online. All three can coexist under one account structure.

The deciding factor is team shape, not technical taste. With a dedicated payments team and a checkout page that is itself a conversion lever, API-first is worth the investment. With a small team where payments are one module among many, hosted components launch faster and leave less to maintain. For brands running both channels, confirm early that terminals and online share the same accounts, risk rules and reconciliation views, or unified commerce is unified in name only.

4. Core capabilities

4.1 Local acquiring

This is Adyen's most valuable differentiator. Local acquiring means transactions clear in the acquirer's country, which usually improves authorisation rates and reduces cross-border fees and currency friction. For multi-country European sales, the gain from local acquiring often exceeds what fee negotiation can deliver.

Three signals tell you whether you need it: the share of orders coming from a given market, whether cross-border declines cluster around specific issuing regions, and whether cross-border surcharges have drifted clearly above local traffic. If two of the three hold, the business case is worth modelling. The payment habits behind each European market are covered in the Europe Local Payment Guide.

4.2 Payment method coverage

Beyond international cards, European methods such as iDEAL, Bancontact and SEPA, plus regional wallets and buy-now-pay-later options, are generally available through the same interface. The exact list depends on merchant entity and settlement currency.

Broad coverage does not mean you should enable all of it. Every added method adds a refund path, a reconciliation rule and a dispute flow, and support and finance absorb that load. Method selection should be driven by order data, not by the length of the list.

4.3 Tokenisation and recurring charges

Stored cards and network tokens are two different things. A stored card is card data encrypted and held by the acquirer, and later charges are still initiated by that acquirer. A network token is issued within the card scheme ecosystem and represents the relationship between a card and a merchant, so it may remain usable when the connection or the acquiring arrangement changes.

For subscription and membership businesses, tokenisation determines renewal success and recovery room. Expired, replaced and blocked cards invalidate the original card data, and tokens catch that failure before the charge attempt; without a token layer, dunning can only retry a card that is already dead, and every failure burns buyer patience.

One thing to know up front: tokens generally do not migrate freely between acquirers. Switching acquirers usually means collecting tokens again, so the cost of a move includes rebuilding the existing subscriber base, not just adapting code. That is why subscription businesses should choose an acquirer as a long-term relationship rather than on the lowest rate.

4.4 Enabling payment methods market by market

Enabling every method at once is the most common mistake. The immediate effects are a longer checkout page, diluted conversion, approval rates dragged down by low-volume methods, and an operations team that has to maintain a refund and dispute flow for each one.

A steadier approach is to phase by market: pick the top three markets by order volume, enable only the dominant local methods there, watch authorisation rate, refund rate and dispute rate for a while, then decide whether to move on. Change one variable at a time, or you will not be able to attribute the result.

The same principle applies to risk rules. Tighten everything at once and you block good orders; open everything at once and fraud and disputes surface weeks later. Small adjustments and gradual traffic shifts are the only reliable tuning method this system has.

4.5 Risk and chargeback management

Built-in risk rules allow allow or block decisions based on rules and risk signals, and chargeback evidence submission happens in the same back office. For dispute-sensitive sectors, connecting risk rules to business data reduces losses materially.

The hard part of risk control is never whether you can block, but whom you block by mistake. Rules that are too tight reject loyal customers and cost repeat purchases; rules that are too loose let fraud and disputes surface late, costing funds and account health. A workable pattern is segment-specific thresholds plus writing chargeback reason codes back onto orders, so the rules get a feedback loop.

4.6 Unified online and offline commerce

With physical stores, online orders and in-person card payments enter one dataset, so returns and reconciliation do not run through two systems. Pure online acquirers rarely offer this.

Its value shows up most in returns and membership: buy online and return in store, or the reverse, only works when both sides share the same order and payment records. If online and offline are separate businesses with little customer overlap, the gain is limited and there is no reason to redraw your system boundaries for it.

4.7 Settlement and reconciliation

Settlement cycles, currencies and fee breakdowns are visible in the dashboard, which keeps multi-currency reconciliation manageable. For finance teams, standardised reporting matters more than raw capability.

Three things are worth confirming: whether reports split by merchant account and currency, whether fees are itemised by type (interchange, scheme fees, markup, cross-border and currency conversion), and whether data exports into your own accounting system for further processing. The first two decide whether you can self-audit; the third decides whether you need to build a reconciliation script.

5. Rollout order and engineering checklist

The real risk in integration is not writing code; it is believing the integration already works. Split the rollout into four stages and write the pass criteria for each before you start.

5.1 Sandbox, small-volume production, canary, full traffic

Stage one is the sandbox: get the main paths working and confirm request and response shapes, state machine and callback format. Stage two is small-volume production with real cards and real amounts, checking that settlement, fees and callbacks behave as expected in the live environment. Stage three is a canary, routing part of the traffic to the new connection and comparing approval rates and error distribution against the old one. Stage four is full traffic.

Write the pass criteria down in advance and do not move them mid-flight. The specific checks for the sandbox stage are in the Payment Gateway Sandbox Testing guide.

5.2 Seven flows that must work end to end

• Authorisation: success, soft decline and hard decline, each with a defined buyer message and retry policy.
• Capture: timing for full and delayed capture, and what happens when a capture never arrives.
• Partial capture: how order state is expressed after multiple captures, and what happens to the remainder.
• Full refund: initiation, arrival confirmation and status write-back must all be observable.
• Partial refund: cumulative validation across multiple partial refunds to prevent over-refunding.
• Chargeback response: evidence upload window, status transitions and how reversed funds are recorded.
• 3DS challenge flow: challenge trigger, redirect, timeout, failure fallback, and the frictionless path.

What these seven share is asynchronous state. Engineering has to solve two things: order number and idempotency key design (see Order Number and Idempotency Design), and one-way state transitions; no flow should move an order from a terminal state back to an intermediate one.

5.3 Webhook replay and out-of-order delivery

In production, duplicate and out-of-order callbacks are normal, not exceptional. Duplicates trigger double fulfilment or double booking; out-of-order delivery lets stale events overwrite newer state.

Three rules cover most of it: deduplicate by event ID and assume every callback can arrive more than once; compare event timestamps or versions and accept only newer state; treat callbacks as notifications, with final state taken from active queries and periodic reconciliation as the backstop. A full callback framework design is in the Payment Callback Framework Guide.

6. Fee structure

Adyen costs usually combine interchange, scheme fees, the acquirer markup, cross-border and currency conversion costs, and separately priced alternative payment methods. Because pricing is cost-plus or negotiated, total cost depends heavily on your transaction mix: card types, regions, currencies and average ticket. Actual figures follow the official documentation and your contract.

One reminder: a low rate is not the same as a low total cost. The approval-rate gain from local acquiring is often worth more than a few basis points. Pricing conventions also differ, since some providers quote a flat rate per transaction while others tier by card type and region, so ranking headline rates against each other tells you very little.

Two further judgements are easy to miss.

First, cross-border and currency conversion fees have to be pulled out and read separately. Both are usually percentage-based and get hidden inside an overall rate: the headline looks reasonable until you split it and find that a meaningful share comes from cross-border and FX. Those two lines are often compressible by changing settlement currency, adding local acquiring or repricing in a different currency, and none of that is visible if you only track the total.

Second, separate per-transaction unit price from annual total cost. Per transaction, you compare percentage plus fixed fee, which is fine for judging a single order. Annually, the cost also includes chargebacks and dispute handling, refunds, currency conversion, reconciliation work and engineering time. Enterprise procurement has to use the second lens, because the first systematically understates true cost. A full self-audit method is in the Payment Fee Audit Guide.

7. Advantages and limitations

Advantages: broad local acquiring coverage with clear approval-rate and cost benefits; complete payment method and regional coverage; unified online and offline commerce; mature risk and chargeback tooling; rigorous settlement and reconciliation suited to strict finance functions; one account structure that can carry several markets and channels, which keeps the operating boundary clear over time.

Limitations:

• Onboarding and volume thresholds are high, and early-stage teams rarely get in.
• Pricing is negotiated, and both the quote and the support depend on transaction mix, so it is a poor fit for small pilots.
• Integration and operations need engineering effort; state machines, callbacks and reconciliation are largely yours to build.
• Self-service is limited. Many actions route through an account manager, so your schedule depends on theirs.
• Documentation and error messages are mostly in English, so the team needs people who can read technical English or troubleshooting slows down noticeably.
• Some advanced capabilities, including local methods in specific markets, custom risk rules and special settlement arrangements, are unlocked commercially rather than switched on with the account.

8. Who it fits

Good fit: companies already processing meaningful volume, selling across multiple countries, needing local payment methods and local acquiring, running both online and offline channels, with strict finance and compliance requirements.

Weaker fit: small teams still validating a business; single-market operations with limited volume; independent developers without engineering resources who want configuration-only setup.

When to hold off

• The business model is still moving: category, pricing and delivery may all change, and locking in a heavy integration now means paying the migration cost repeatedly.
• You only need a working checkout button: if volume cannot yet support local acquiring and a negotiated rate, a general-purpose acquirer is better value.
• There is no payments engineering capacity: accounts, tokens, callbacks and reconciliation all need ongoing ownership, and a hosted arrangement is more realistic without it.

9. Working alongside other platforms

The common arrangement is layered rather than either-or. A concrete three-layer example:

• Local acquiring for core markets: use Adyen for local acquiring where orders concentrate, such as Europe, and take the approval-rate and cross-border cost gains.
• A general-purpose acquirer for the long tail: bring smaller markets live quickly with a platform such as Stripe, skipping per-market acquiring negotiations.
• A wallet as a buyer option: list a wallet such as PayPal at checkout for buyers who prefer balance payments, and to lower the trust barrier on a first order.

Define the boundaries in advance. Split traffic between local acquiring and the general acquirer by market and share, and write routing rules for who takes which traffic and how failures fall back. Keep the wallet as a payment option rather than a primary channel, or a flood of small orders will complicate reconciliation and dispute handling.

Routing and fallback design across the layers is covered in the Payment Stack Architecture Guide, and the positioning differences between providers are mapped in the Cross-Border Payment Selection Matrix.

Source: 16IDC original. Capabilities, eligibility and pricing follow https://www.adyen.com official documentation and contract terms.