What changed in Adyen Web v6?
The change that costs you time is the removal of the generic
checkout.create(type) factory. In v6 every payment method is its own
exported class, so you instantiate Card, Ideal or
Klarna directly rather than asking the SDK to resolve a string.
Drop-in absorbs this internally. A Components integration has to be rebuilt around it.
The factory is gone
In Adyen Web v5 you could write checkout.create('ideal') and the SDK
worked out which class to build. That shortcut does not exist in v6. Each method is
exported separately, and you call the one you need.
In practice a Components integration now needs a resolver: a map with the method type on one side and the class that renders it on the other. You build it once from whatever the SDK exports, then look up each type as you mount it.
The fallback that hides a broken checkout
Plenty of payment methods do nothing more than send the shopper to an external page and
bring them back. Those can fall back to the Redirect class when your map
has no specific entry, and that works fine.
The trap is applying that fallback to everything. Methods with a real form, like ACH
Direct Debit, Bacs, SEPA and gift cards, need to collect account details before anything
is submitted. Send those to Redirect and you get a checkout that renders
without error and collects nothing. Nobody notices until a shopper cannot pay.
Exclude form-based methods from the fallback explicitly and let them throw instead. An error at mount time is found in minutes; a silently empty payment method is found by a customer.
What this means for the upgrade
If you are on Drop-in, the v6 upgrade is comparatively uneventful, because the mapping happens inside the component and you never wrote it.
If you are on Components, budget properly. Every mount point has to change, the resolver has to be written and tested against your live method mix, and the form-based exclusions have to be right. This is the reason the two integration styles have very different upgrade costs, which is worth factoring into the choice between them in the first place.
See the resolution live
The Components playground resolves each available method to its v6 class at runtime and prints the mapping in its API log, including the methods that resolve to nothing. It is the clearest way to see the shape of the problem without building it yourself.
Questions, feedback, or work in payments?
I'm always happy to hear from fellow payments people.
Personal project by Elie Joseph. Not affiliated with, endorsed by, or officially connected to any payment service provider. All product and company names, logos and brands referenced on this site are property of their respective owners. Playgrounds run against test environments only. No real payments are processed. Use only test data. Never enter real card numbers, real personal information, or any genuine payment details on this site or in any linked test environment.