Online choices
Our plugin aligns with Adyen’s online-payments model by combining a server-side Advanced flow with Drop-in in the main checkout and Components for Express Checkout entry points. This pairing keeps the shopper journey streamlined while preserving server-side control over payment orchestration, 3DS2 challenges, and post-redirect handling.
Server-side choice: Advanced flow
We use the Advanced flow to initialize and progress payments on the server. This provides consistent lifecycle management (including redirects/challenges and webhook outcomes), clean mapping to Sylius orders and payments, and flexibility for per-channel logic. It is the backbone for both UI surfaces described below. In practice, the backend coordinates method eligibility, starts the payment, handles redirect/challenge callbacks, and reconciles the final result through webhooks, ensuring the storefront and back office reflect the authoritative status.
Client-side choice: Drop-in and Components
Drop-in (full checkout). The fully prebuilt UI presents eligible methods, localizes the experience, and handles 3DS2 where required, delivering a cohesive "all-in-one" flow from summary to confirmation. Its presentation adapts to shopper locale and currency while remaining consistent with brand styling.
Components (Express Checkout). Method-specific Components are embedded at high-intent entry points (product/cart). They enable "buy now" interactions without bypassing compliance or server-side control, since they run on the same Advanced flow. This shortens the path to purchase while preserving the same orchestration, risk, and reconciliation rules as the full checkout.
End-to-end behavior
Eligibility & presentation: the client shows only methods that are eligible for the shopper’s context (amount, currency, locale, and channel), ensuring a clear and relevant choice set.
SCA & redirects: challenges and redirects are handled uniformly across Drop-in and Components, then resolved server-side and reflected in Sylius.
Finalization & records: outcomes (authorization, capture, refund, cancellation) are reconciled via webhooks and persisted as standard order/payment states for auditability.
Why this pairing
Conversion where it counts: Drop-in reduces friction in the main funnel; Components place instant-pay options exactly where intent is highest.
One orchestration model: both surfaces ride on the Advanced flow, minimizing duplication and keeping compliance and risk handling consistent.
Future-proofing: new or updated payment methods can be introduced in Drop-in or as Components without reworking the server pattern.
Related Adyen Documentation
Last updated
Was this helpful?