Gateway Selection
Part of Payment gateways and processors
Comparing gateway integration options
Compare hosted pages, embedded forms and configurable components using documented limits, merchant work and order handoff needs.
Compare gateway integrations by the control your store needs over the payment step and the work your team can maintain. A provider-hosted page, an embedded form and configurable components differ in where payment details are entered, how the interface is changed and how payment outcomes reach the order system. Check the exact product and account configuration before choosing.
Compare the work behind each option
| Option | Useful when | Merchant work to examine |
|---|---|---|
| Provider-hosted page | The provider’s page covers the required buying journey. | Create a payment session, handle the redirect and return, and receive a reliable outcome. |
| Embedded provider form | Payment should appear within the store’s page with a largely prebuilt form. | Maintain the surrounding order summary, mobile layout, errors and external returns. |
| Configurable components | The store needs more control over page composition. | Build and maintain the surrounding interface, component integration and payment-state handling. |
These are design patterns, not promises that every provider offers every option. A shopper may still leave an embedded page for an external payment method or authentication step. Ask what happens when the amount changes, a session expires or a buyer cancels, and which event the order system should use to confirm payment.
Check documented product limits
Stripe Checkout Sessions. Stripe’s API reference describes ui_mode values for Checkout Sessions, including embedded_page and elements. Check the current API reference for the exact modes and where the payment interface is presented.
For Checkout Sessions with ui_mode: embedded_page or ui_mode: elements, Stripe’s API reference states that return_url applies. Check the selected API version and enabled payment methods before designing the order handoff.
Adyen standard integration. Adyen documents Hosted Checkout and Drop-in as its two prebuilt standard options. Hosted Checkout redirects to an Adyen page; Drop-in renders a prebuilt interface on the merchant page.
Adyen’s feature table lists capabilities such as updating the payment amount after starting the payment session and customising styling elements of individual payment methods. Check the current table to confirm which features apply to Hosted Checkout or Drop-in for your account. Both options require a merchant payment server and webhook server. Confirm that the required methods and controls are available for the proposed account and integration.
These are documentation examples, not product-test results or a ranking.
Key product limits and requirements for Stripe and Adyen integrations
- Stripe Checkout Sessions - ui_mode: embedded_page or elementsRequires `return_url` configuration; check API version and enabled payment methods
- Adyen Hosted CheckoutRedirects to Adyen page; requires merchant payment server and webhook server
- Adyen Drop-inRenders prebuilt interface on merchant page; requires merchant payment server and webhook server
- PCI Compliance (SAQ A eligibility)Requires iframe with third-party-supplied payment elements; implementation must meet current PCI standards
Check card-data scope and payment state
An embedded provider element is different from a card form supplied by the merchant. PCI Security Standards Council guidance says an iframe seeking SAQ A eligibility must contain the elements involved in collecting card data, with the relevant payment-page elements supplied by a validated third party.
Its script-related SAQ A eligibility guidance also applies to embedded third-party payment pages or forms. Review the actual implementation against the current requirements; the integration label does not assign a PCI category.
Map the store’s order reference to the provider’s payment reference. A buyer reaching a success or return page is not, by itself, proof of the final payment outcome. For example, Adyen’s Hosted Checkout documentation directs merchants to use webhooks for payment outcomes.
For each candidate, propose the same permitted test: use a representative basket, change a delivery charge or discount before payment, cancel an attempt, follow any external return and inspect the resulting order and provider records.
Check a phone-sized screen if mobile sales matter. Record what was shown and what needs live-account confirmation. Choose the integration whose required buyer journey and payment-state handling your team can support.
