POST /woocommerce/adyen/stores/{store_id}/payments expects a paymentMethod object. This section is about how you produce that object in your checkout.
There are three ways to do it. They are not three styles of the same thing, they differ in how much of the payment form Adyen owns, how much work you do, and which PCI DSS obligations fall on you. Decide this before you write checkout code, because switching later means rebuilding the front end.
The difference that matters most is whether a card number ever enters your own page.
With Drop-in and Components, Adyen renders the card fields inside iframes it controls. The card number is encrypted inside that iframe and never touches your DOM, your JavaScript, or your server. You only ever handle an encrypted blob.
With raw fields and JWE, the shopper types the card number into an input element that you own. Even though you encrypt it before sending, the field itself is yours, which puts your checkout page in scope for a significantly larger set of PCI requirements.
In broad terms this is the difference between SAQ A and SAQ A-EP: extra requirements around change control, quarterly external vulnerability scanning, and a longer annual self-assessment. Confirm your exact obligations with your acquirer or QSA — do not treat this guide as a compliance determination.
Adyen also does not enable raw card handling by default. It has to be requested and approved.
The whole payment form, including method selection
One payment method at a time, where you place it
Full, you build the method selector and page layout
Handles redirects and 3DS for you
Collects browserInfo for you
New payment methods appear automatically
Only if you add the component
Use Drop-in unless you have a specific reason not to. It is the fastest to build and the least to maintain. When you enable a new payment method in Part 6, Drop-in renders it without a front-end change. It handles redirect flows, 3DS challenges, and browserInfo collection on its own. Most shops should stop here.
Use Components when your checkout design cannot accommodate Drop-in's layout. You mount each payment method individually and build the selection UI yourself. The security model is identical to Drop-in — card fields are still iframed — so you get design freedom without the PCI consequences. The trade-off is that enabling a new method now requires a front-end change.
Use raw fields with JWE only when you have a requirement neither of the above can meet, you have confirmed the PCI implications with your acquirer, and Adyen has approved raw card handling for your account. You will be implementing the redirect and 3DS challenge flows yourself, which Drop-in and Components otherwise handle for you. This is a substantial amount of work and a permanent maintenance commitment.
Adyen's own documentation now presents the Sessions flow as the default. That flow starts with a POST /sessions call.
Woosa Payments does not expose /sessions. You create payments with POST .../payments and finalise them with POST .../payment-details, which is Adyen's Advanced flow. When you follow Adyen's documentation, look for the Advanced flow variant of each page.
Symptom of getting this wrong: you initialise Adyen Web with a session object, have nowhere to get a session id from, and cannot proceed. If that is where you are, you are on the wrong flow.
Drop-in and Components both need three things at page load.
GET /woocommerce/adyen/stores/{store_id}/client-key
The client key is a public key that authenticates Adyen Web from the browser. It is safe to expose in your page source. It is bound to the origins it may be used from, so your checkout domain must be registered against it — including your staging and development domains.
GET /woocommerce/adyen/stores/{store_id}/checkout-payment-methods
The response of this call is exactly the shape Adyen Web expects for its paymentMethodsResponse configuration property. Pass it through unchanged.
Use the query parameters to narrow it to the shopper: country, currency, and shopper (which also returns that shopper's saved methods in storedPaymentMethods).
Every Midlayer call is signed with your woosa_secret, and putting that secret in front-end JavaScript would expose it to anyone who views source.
Your checkout page therefore calls your own backend, and your backend signs and forwards to Woosa:
Browser → your backend → Midlayer → Adyen
At minimum you need two of your own endpoints — one that creates a payment and one that submits additional details — each wrapping the corresponding Woosa call.
Whichever option you choose, the output is the same: a paymentMethod object that goes into your payment request. Everything after that point in this guide is identical for all three.
json
"returnUrl": "https://myshop.example.com/checkout/order-received/592/",
"amount": { "currency": "EUR", "value": 2800 },
"paymentMethod": { ... },
"metadata": { "wc_order_id": 592 }
What differs is only how paymentMethod gets filled in:
- hand it to you in
state.data when the shopper submits. Send state.data through to your backend as-is — it also contains browserInfo and other fields the payment needs. - means you build the object yourself from the encrypted card data, and add
browserInfo yourself.