🧱 Payment service provider integration methods

PCI DSS compliance scope

PCI DSS compliance scope covers the systems that store, process, or transmit card data. The standard is published by the PCI Security Standards Council, the body set up by the international card networks. Scope follows the data, not the org chart. A server that the card number passes through even once is in scope for good.

The SAQ (Self-Assessment Questionnaire) is the form a merchant uses to attest to its own compliance. Which version applies depends on the path card data takes through the merchant’s setup. SAQ A applies when card data collection is handled entirely by the provider, and it has about 30 questions in version 4 of the standard, up from 22 in version 3.2.1, which it replaced. SAQ D applies as soon as the card number passes through the merchant’s systems, and it runs to several hundred questions.

In between sits SAQ A-EP, which covers merchants whose page controls the payment form while outsourcing the card data collection itself. The card number never passes through the merchant’s servers, but the merchant’s page decides where it goes. This questionnaire is much longer than SAQ A, though shorter than SAQ D. None of the five methods described here falls under it by design; a merchant slips into it by changing its own page, often without realizing it.

Scope extends beyond the payment page. It also covers channels where a card number is read out rather than typed in, the phone being the most common. The payment link addresses this case: it lets merchants get paid without a website, on a quote, over the phone, or in B2B, and card entry moves to a page fully hosted by the provider, which falls under SAQ A.

The five methods compared

The five integration methods described below cover the ways to accept card payments online. Three observable features set them apart: who serves the sensitive fields, how much freedom the merchant has over the layout, and where the checkout flow takes place. The diagram shows the four methods that fit into an online store; the payment link works outside any online checkout flow.

Four methods isolate the sensitive fields in a frame or page served by the provider. The server-to-server API is the only one that doesn’t, and the only one that falls under SAQ D. Three methods keep the cardholder on the merchant’s site: hosted fields, the drop-in component, and the server-to-server API. The redirect sends the cardholder elsewhere and then brings them back, while the payment link needs no website at all.

Checkout control vs. compliance burden

Choosing among the five methods means weighing two things. The first is control over the checkout flow: how much say the merchant has over layout, message wording, and the sequence of screens. The second is the compliance burden, measured by the questionnaire to complete and the checks that come with it. The two move in opposite directions. The payment link offers the least control with the lightest burden, and the server-to-server API maximizes both.

There is one exception to this pattern, and it explains the special place hosted fields hold. This method lets the merchant design the page down to the pixel while staying on SAQ A, because the sensitive fields are still served by the provider. The merchant builds its page around frames whose content it cannot read. The price is a longer integration than a drop-in component, and validation limited to the events the provider exposes.

A break in the checkout flow is the point where the payer leaves the merchant’s site for another domain. A hosted redirect creates one, and the cardholder can see it in the address bar. Hosted fields and the drop-in component eliminate it, since the form sits within the merchant’s page. The guide “The psychology of checkout” covers the conversion principles at stake in this continuity, each with the study behind it.

Hosted redirect

A hosted redirect sends the cardholder off the merchant’s site to a payment page served by the provider, then brings them back. It is the oldest of the five methods and underpins products such as PayZen, Worldline Sips, and Stripe Checkout. Integration takes a few hours. The merchant passes the amount and the order reference. The provider serves the page, processes the payment, and sends the cardholder back with the result.

What a redirect allows

• No card data touches the merchant’s systems, which keeps compliance to a minimum
• All payment methods are managed and kept up to date by the provider
• Authentication, wallets, and retries are handled by the hosting provider
• The logo, colors, and displayed fields can still be customized

What it rules out

• Pixel-level layout control: the design stays the provider’s
• Avoiding the break in the checkout flow that a redirect causes, and the conversion loss that comes with it
• Access to card data, even in transit
• Fine-grained A/B testing of the payment form

Providers that commonly offer this methodStripePAPayplugLYLyraWorldlineMOMollie

Hosted fields

Hosted fields replace each sensitive field with a frame served by the provider and embedded in the merchant’s page. The card number, security code, and expiration date each sit in a separate frame; the merchant sets their styles but cannot read their content. The cardholder never leaves the site. Integration takes a few days, and the questionnaire remains SAQ A.

// The provider’s SDK mounts isolated fields in the merchant’s page.
// The card number entered never touches the merchant’s server: it goes, encrypted,
// to the provider, which returns a token the server can use.
const fields = provider.fields({ locale: "en", theme: "flat" })

fields.create("cardNumber").mount("#card-number")
fields.create("expiryDate").mount("#expiry")
fields.create("cvv").mount("#security-code")

document.querySelector("#pay").addEventListener("click", async () => {
  const { token, error } = await fields.tokenize()
  if (error) return showError(error.message)
  // Only the token goes to the merchant’s server, never the card number.
  await fetch("/api/payment", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ token, amount: 4280, currency: "EUR" }),
  })
})

What hosted fields allow

• Designing the page down to the pixel around the fields, whose styles are injected
• Staying on SAQ A, since the card number only passes through the provider’s frames
• Eliminating the redirect, and with it the break in the checkout flow
• Offering wallets and local payment methods on the same page

What they rule out

• Reading or changing the content of the fields; validation is limited to the provider’s events
• Changing the internal structure of the fields, on which autofill depends
• Escaping PCI requirements 6.4.3 and 11.6.1 on the inventory of the page’s scripts
• Routing the same card entry to several providers: the field belongs to the provider that serves it

Isolating the fields leaves the page that hosts them under the merchant’s responsibility. Requirements 6.4.3 and 11.6.1 apply to exactly that page, and the last section of this guide covers them in detail. The method profile lists them among what it does not remove, along with the inability to route the same card entry to two providers.

Drop-in component

A drop-in component is a complete UI element supplied by the provider and embedded in the merchant’s page. Adyen calls it Drop-in; Stripe calls it Payment Element. It handles the form, wallets, local payment methods, and authentication, and it can be themed. The layout, however, is the provider’s. Integration takes one to two days, and the questionnaire remains SAQ A.

What the component allows

• Offering every payment method (cards, wallets, iDEAL, or Pix) in a single component
• Benefiting from the provider’s conversion optimizations, starting with the order of payment methods
• Theming colors, corner radius, and fonts without restyling each field
• Letting strong authentication run on its own

What it rules out

• Departing from the component’s fixed layout
• Building highly specific flows, such as some B2B checkouts
• Combining several providers in the same component
• Controlling the wording of error messages

Server-to-server API

With a server-to-server API, the merchant collects the card number itself and then passes it to its provider. This method is limited to large merchants, orchestration platforms, and providers that are themselves certified. The merchant’s servers then become part of the cardholder data environment. The merchant has full control. The questionnaire goes from about 30 questions to several hundred, and integration takes weeks, including the audit.

What the API allows

• Controlling the entire checkout flow, the fields, and the merchant’s own mobile apps
• Routing each transaction to the best-placed acquirer, with cascading if needed
• Tokenizing in the merchant’s own vault, which makes the tokens portable
• Using network tokens directly and fine-tuning retries

What it rules out

• Avoiding full PCI DSS validation: annual audit, quarterly scans, penetration testing
• Storing the CVV, which is prohibited in all cases
• Moving fast: compliance and security become an ongoing investment
• Shifting liability to the provider in case of a breach, since the data environment is the merchant’s own

That burden buys freedoms the other four methods don’t offer. The merchant routes each transaction to the best-placed acquirer, cascading to the next one when the first declines. It keeps its tokens in a vault it owns, which makes its stored card base portable from one provider to another. It also controls network tokens and retry settings.

Providers that commonly offer this methodAdyenCHCheckout.comWorldlineStripe

Payment link

A payment link requires no integration and no development. The merchant generates a link from its provider’s dashboard and sends it to the customer, who pays on a fully hosted page. It is available immediately, and the questionnaire remains SAQ A. This method serves quote-based sales, phone orders, and B2B transactions, where there is no online shopping cart.

What a payment link allows

• Getting paid without a website: on a quote, over the phone, or in B2B
• Tracking each receivable, with one link per invoice
• Offering cards, wallets, and bank transfers on the same page
• Automating sending and reminders through an API

What it rules out

• Fitting into the online checkout flow, since payment happens off-site
• Customizing anything beyond the logo
• Saving the card for a future purchase, since there is no customer session
• Handling high volumes without automation

Inventory of payment page scripts

Requirements 6.4.3 and 11.6.1 of PCI DSS v4.0.x cover payment page scripts, and they have been mandatory since March 31, 2025. The first covers the inventory, justification, and integrity of every script served on that page. The second covers tamper detection, for both security headers and page content as the browser receives it. The two work together: prevention limits what can run, and detection catches what slips through.

These requirements target web skimming, best known through the attacks dubbed Magecart. The injection targets the merchant’s page, not the provider. So the inventory covers the page the merchant itself serves. A frame served by the provider does not protect that page, which can be hijacked to overlay a fake form on top of the legitimate fields.

The four lighter methods move card number collection to the provider. They do not move the page that hosts it, which the merchant serves and must monitor. The trade-off ends in an asymmetry: PCI scope shrinks, but page monitoring remains.

Who handles strong customer authentication

Strong customer authentication takes place during authorization, and the integration method determines who orchestrates it. This matters at least as much as compliance scope: 3-D Secure requires handling a round trip to the issuer, resuming the transaction on return, and dealing with cases where the authentication screen fails. Four of the five methods take this off the merchant’s hands.