Adyen just made the embedded finance conversation significantly more concrete. After a decade of building a direct-to-network acquiring stack that now processes over €1.5 trillion annually, the company has moved decisively to layer card issuing and embedded finance capabilities directly onto that infrastructure, targeting platforms and marketplaces as the primary growth vector. This is not a product announcement you can file under "interesting but irrelevant." If you run a marketplace or B2B SaaS platform and your payments architecture still touches three or four vendors for gateway, acquiring, payouts, and issuing, Adyen's push changes your evaluation calculus today.
What Changed in Adyen's Platform Stack
- •Unified issuing and acquiring are now available on a single integration surface, meaning virtual and physical cards issued through Adyen Issuing settle against the same acquirer that handles your inbound payment volume.
- •Local acquiring now covers 50+ markets, including Japan, Malaysia, Australia, New Zealand, Hong Kong, Singapore, and the UAE, which closes a meaningful gap that used to force platforms into supplementary regional providers.
- •The embedded finance motion is already live in production ecosystems: accesso Technology Group has integrated Adyen's platform payments as a core capability in its leisure and entertainment stack, signaling that this is a go-to-market motion, not a beta roadmap item.
Why This Matters for Platform Engineering Leaders
The immediate operational question is vendor consolidation versus strategic risk. A unified issuing-acquiring stack genuinely reduces the integration surface you maintain: fewer reconciliation pipelines, fewer webhook schemas to normalize, fewer compliance postures to maintain simultaneously. For platforms that currently stitch together a gateway, a bank-sponsored issuer, a payout rails provider, and a FX layer, consolidation onto a single stack can reallocate meaningful engineering headcount from payments plumbing to product differentiation.
But the more important shift is architectural. When acquiring, issuing, and risk intelligence live on the same data substrate, the behavioral signals you can extract become coherent in ways they simply cannot be when spread across vendors. A seller's inbound payment volume, their spend patterns on an issued expense card, and their chargeback history all resolve to the same entity model. That coherence is the foundation for working-capital underwriting, automated spend controls, and self-service payout tooling, product capabilities that are increasingly how platforms compete, not just how they operate.
The risk, which you should take seriously, is single-vendor dependency at the stack's critical seams. Adyen's unified approach is compelling precisely because of how deeply integrated it is; that depth is also what makes extraction painful if Adyen's pricing, risk posture, or regional performance shifts against you. The answer is not to avoid consolidation but to architect it deliberately.
Step 1: Model Your Integration Abstraction Layer First
Before touching Adyen's platform APIs, define the domain boundaries in your own codebase. Create a `PaymentsProvider` interface that isolates your business logic from any single vendor's method signatures. This lets you adopt Adyen's unified stack at speed while preserving the seams you need if you ever introduce a secondary provider for specific regions or use cases.
1// payments-provider.interface.ts
2interface PaymentsProvider {
3 createSubmerchant(params: SubmerchantParams): Promise<SubmerchantResult>;
4 issueCard(params: CardIssuanceParams): Promise<IssuedCard>;
5 initiatePayoutToCard(params: PayoutParams): Promise<PayoutResult>;
6 getTransactionLedger(submerchantId: string): Promise<LedgerEntry[]>;
7}
8
9// adyen-platform.provider.ts — concrete implementation
10class AdyenPlatformProvider implements PaymentsProvider {
11 async createSubmerchant(params: SubmerchantParams): Promise<SubmerchantResult> {
12 const response = await this.adyenClient.platforms.createAccountHolder({
13 accountHolderCode: params.externalId,
14 accountHolderDetails: {
15 email: params.email,
16 legalEntity: params.legalEntityType,
17 },
18 processingTier: 1,
19 });
20 return { providerId: response.accountHolderCode, status: response.verification.accountHolder.checks };
21 }
22}1{
2 "providerId": "acct_seller_8f2a91c",
3 "status": [
4 { "type": "companyVerification", "status": "PASSED" },
5 { "type": "identityVerification", "status": "PENDING" }
6 ]
7}The abstraction layer pays dividends immediately: your onboarding, ledger, and payout services bind to the interface, not the Adyen SDK, which keeps your domain model clean regardless of how Adyen's API surface evolves.
Step 2: Wire Issuing to Your Seller Payout Flow
Once a submerchant account is verified, provision an issued card tied directly to their balance. The key architectural decision here is whether issued cards represent a payout mechanism (seller receives funds on a Visa/Mastercard they can spend immediately) or a controlled-spend instrument (expense card with category restrictions). Both are valid; the configuration diverges at the `balanceAccountId` binding and the `transactionRules` you attach.
1// issue-seller-card.ts
2async function issuePayoutCard(
3 balanceAccountId: string,
4 sellerDetails: SellerCardRequest
5): Promise<IssuedCard> {
6 const card = await adyenIssuing.paymentInstruments.create({
7 balanceAccountId,
8 type: "card",
9 issuingCountryCode: sellerDetails.countryCode,
10 card: {
11 formFactor: sellerDetails.preferVirtual ? "virtual" : "physical",
12 brand: "mc",
13 },
14 deliveryAddress: sellerDetails.preferVirtual ? undefined : sellerDetails.shippingAddress,
15 });
16
17 // Attach a spend rule if this is a controlled expense card
18 if (sellerDetails.spendCategory === "controlled") {
19 await adyenIssuing.transactionRules.create({
20 paymentInstrumentId: card.id,
21 type: "blockList",
22 merchantNames: sellerDetails.blockedMerchantNames,
23 status: "active",
24 });
25 }
26
27 return { cardId: card.id, last4: card.card.last4Digits, status: card.status };
28}1{
2 "cardId": "PI_1a2b3c4d5e6f",
3 "last4": "4821",
4 "status": "inactive",
5 "formFactor": "virtual",
6 "balanceAccountId": "BA_seller_8f2a91c"
7}that `status: "inactive"` is expected on creation. Cards require an explicit activation call before they can transact, which gives you a natural gate for your seller onboarding flow.
Step 3: Build Your Ledger Event Pipeline
The highest-leverage engineering investment you can make on top of a unified stack is a real-time event pipeline that materializes Adyen's webhook stream into your own ledger model. This is where the coherence advantage of unified issuing and acquiring becomes actionable: acquiring settlement events and card spend events now share a common `balanceAccountId` key, which means a single enrichment pipeline can produce a unified view of each seller's financial position.
1// adyen-webhook-router.ts
2import { AdyenWebhookEvent, LedgerService } from "./types";
3
4async function routeAdyenEvent(event: AdyenWebhookEvent): Promise<void> {
5 switch (event.type) {
6 case "balancePlatform.payment.created":
7 await LedgerService.recordInboundPayment({
8 balanceAccountId: event.data.balanceAccountId,
9 amount: event.data.amount.value,
10 currency: event.data.amount.currency,
11 merchantReference: event.data.merchantReference,
12 eventId: event.data.id,
13 });
14 break;
15
16 case "balancePlatform.issuedCard.authorizationCreated":
17 await LedgerService.recordCardAuthorization({
18 balanceAccountId: event.data.paymentInstrument.balanceAccountId,
19 amount: event.data.amount.value,
20 currency: event.data.amount.currency,
21 merchantName: event.data.merchantName,
22 cardLast4: event.data.paymentInstrument.card.last4Digits,
23 eventId: event.data.id,
24 });
25 break;
26
27 default:
28 console.warn("Unhandled Adyen event type:", event.type);
29 }
30}1{
2 "ledgerEntry": {
3 "balanceAccountId": "BA_seller_8f2a91c",
4 "type": "card_authorization",
5 "amount": -4200,
6 "currency": "USD",
7 "merchantName": "Office Supply Co.",
8 "cardLast4": "4821",
9 "runningBalance": 189500,
10 "eventId": "IC_7h8i9j0k"
11 }
12}Teams that build this pipeline properly stop asking "what's our payout lag" and start asking "what's our seller's real-time financial position," which is the data model you need before you can responsibly offer working-capital or credit products.
What to Test Before Shipping
- •Verify webhook ordering guarantees: Adyen's Balance Platform webhooks are not guaranteed to arrive in strict chronological order. Test your ledger service's idempotency handling explicitly; use `eventId` as your deduplication key and confirm your database upsert logic handles out-of-order arrivals without corrupting running balances.
- •Test card activation race conditions in your onboarding flow: Sellers who complete KYC verification and immediately attempt to use their issued card will hit the `inactive` status gate. Build an explicit activation confirmation step into your onboarding UI and test the full sequence end-to-end in Adyen's test environment with simulated verification delays.
- •Validate multi-currency settlement accuracy across your 50+ market footprint: With local acquiring now live in Asia-Pacific and the UAE, test that your FX conversion logic correctly resolves settlement currencies for each market and that your ledger model handles currency-mismatch scenarios where a seller's balance account denominated in USD receives a settlement from a JPY transaction.
The Stripe Comparison You Actually Need to Make
Adyen's unified stack is a credible competitive offer, and engineering leaders evaluating it against Stripe should do so rigorously rather than reflexively. The honest comparison comes down to three dimensions: global coverage, developer experience, and platform tooling maturity. On global coverage, Adyen's direct-to-network model in 50+ markets is genuinely differentiated for platforms with heavy Asia-Pacific or Middle East volume. Stripe Connect covers most of the same geography but routes through more third-party acquiring relationships in some markets, which affects authorization rates and settlement timing. On developer experience and platform tooling, Stripe's Connect, Issuing, and Treasury APIs have a longer runway of iteration and a larger ecosystem of reference implementations. The documentation surface, SDK support, and community tooling are more mature for most platform use cases in 2026. That gap is narrowing, but it exists.
The right framing is not "pick one and consolidate everything." It is: adopt a payments domain abstraction (Step 1 above) that lets you allocate Adyen where its direct acquiring coverage and unified issuing-acquiring economics are strongest, and leverage Stripe where developer experience and platform tooling velocity matter most for your roadmap. The platforms that treat this as a binary choice will find themselves either locked into a single vendor's roadmap or maintaining unnecessary integration complexity. The ones that architect it deliberately will extract the value from both.
What's coming next is predictable: as Adyen deepens its SMB platform motion and Stripe continues expanding Treasury-adjacent capabilities, the battleground will shift to working-capital products and real-time underwriting. The platforms that have already built coherent issuing-acquiring ledger pipelines will be first to market with those products. That pipeline is worth building now, regardless of which provider sits underneath it.
Ready to power your growth with Stripe?
Join innovators using Stripe’s platform to accept payments, automate billing, and create seamless customer experiences.
Read More Blog Posts
Stripe vs Mollie: Production-Grade Payment Infrastructure for Enterprise Workflows
Financial services teams evaluating Stripe and Mollie face a critical architectural choice: which platform's API surface best supports production-grade agent wo
Build Agentic Payment Workflows with Stripe SDK
Automating payment operations at scale requires safe tool integration, event handling, and state management without hallucination or token waste. Stripe provide