Checkout integration methods. 6 chapters and a final quiz.

Chapter 1. The checkout: where conversion is won or lost.

The payment page is the most profitable part of an online store, and the most fragile. It is where final conversion happens, where PCI DSS applies, and where attacks concentrate (skimming, phishing). Choosing an integration method means balancing three forces: the user experience you want to deliver, the compliance scope you can take on, and the engineering capacity you have.

Every integration method comes down to the same question: who handles the card data. The closer the merchant gets to that data, the more control it has over the experience, and the heavier its PCI DSS scope becomes. The resulting self-assessment questionnaire (SAQ) ranges from about 30 questions (SAQ A) to several hundred (SAQ D). The technical choice is first and foremost a compliance choice.

Chapter 2. Hosted redirect: the fast track.

The redirect is the original method, and the simplest. At checkout, the customer is redirected to a page hosted by the PSP (or to the wallet of their choice, such as PayPal or Wero). They enter their card there, complete 3-D Secure if required, then return to the merchant's site. Card data never comes near the merchant's servers or the merchant side of the browser session, so PCI scope is cut to the bare minimum.

• Advantages: integration in a few days, SAQ A scope, a page maintained by the PSP (3DS, new methods, translations, accessibility); ideal without a dedicated front-end team
• Limitations: a break in the customer journey (domain change), limited customization (logo, colors, rarely more), dependence on the PSP's UX, and a return URL that has to be made reliable
• Classic trap: treating the browser return as proof of payment, when confirmation must come from the webhook

On conversion, redirects have a bad reputation: “we lose the customer along the way.” The reality is more nuanced. For a small merchant, a polished, fast, reassuring PSP page often converts better than a rough in-house form. The real cost shows up on mobile (slow redirects, failed returns from banking apps) and for strong brands, whose identity disappears at the decisive moment.

Chapter 3. Iframes and hosted fields: customization within guardrails.

With hosted fields, the customer never leaves the site. The payment form belongs to the merchant, but each sensitive field (card number, expiration date, security code) is actually an iframe served from the PSP's domain. Keystrokes go straight to the PSP, which returns a token to the merchant. Visually integrated, technically isolated: this compromise dominates modern e-commerce (Stripe Elements, Braintree Hosted Fields, Adyen Components…).

<form id="payment-form">
  <label>Card number</label>
  <div id="field-pan"></div>   <!-- iframe injected by the PSP -->
  <label>Expiration date</label>
  <div id="field-exp"></div>
  <label>Security code</label>
  <div id="field-cvc"></div>
  <button id="pay" type="button">Pay €49.90</button>
</form>

<script src="https://js.psp.example/v3/fields.js"></script>
<script>
  const fields = Psp.fields("pk_live_xxx", {
    style: { base: { fontFamily: "Inter", fontSize: "16px", color: "#1a1a2e" } }
  });
  fields.mount("#field-pan", "cardNumber");
  fields.mount("#field-exp", "cardExpiry");
  fields.mount("#field-cvc", "cardCvc");

  document.querySelector("#pay").addEventListener("click", async () => {
    // The PAN goes straight from the iframes to the PSP:
    // only a token comes back to the merchant.
    const result = await fields.tokenize();
    await fetch("/api/pay", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ token: result.token })
    });
  });
</script>

On conversion, hosted fields offer the best of both worlds: a seamless journey, an intact visual identity, and error messages in the brand's voice. The watch points are technical: iframe load times (preload them), careful handling of tokenization errors, and compatibility with password managers and mobile autofill. Handled poorly, these details make the form perform worse than a good hosted page.

• PSP examples: Stripe Elements, Braintree Hosted Fields, Adyen Web Components (fields mode), Checkout.com Frames, Mollie Components
• Integration effort: a few weeks, with real front-end work (states, errors, accessibility)
• Good fit: a merchant with a strong brand, a front-end team, and a need to control the journey without taking on SAQ D

Chapter 4. Drop-in: the all-in-one component.

The drop-in takes the hosted fields approach one step further. Instead of individual fields, the PSP provides a complete checkout component (cards, wallets, bank transfers, BNPL, local methods) that renders in the merchant's page and configures itself. It decides which methods to show based on country, device, currency, and amount: Apple Pay on an iPhone, Wero for a French customer, Pix in Brazil, without a single extra line of code.

• Dynamic methods: adding a payment method is a configuration change at the PSP, not a development task for the merchant
• Automatic updates: new 3DS versions, new wallets, and security patches delivered through the PSP's script
• Built-in optimizations: method ordering, saved cards, localization. The PSP runs the A/B tests for you
• Time to market: a polished multi-method checkout in a few days

From a PCI DSS standpoint, the drop-in inherits the iframe model. Sensitive data is entered in frames served by the PSP, and the merchant generally remains eligible for SAQ A, with the same obligation to monitor the scripts on its page (PCI DSS v4.0). For the vast majority of merchants, it currently offers the best effort-to-result ratio. Once a merchant has adopted a drop-in, the open question is when its customization needs will justify moving off it.

Chapter 5. Direct API: full control at the cost of PCI scope.

The last option is for the merchant to collect card data itself (native form, mobile app, call center) and send it to the PSP's API from its own servers. It gets absolute control over the experience and complete architectural freedom: an in-house card vault, multi-PSP routing, smart retries. The tradeoff is as steep as it gets. The merchant's systems fall squarely within PCI DSS scope, with the SAQ D questionnaire and, above 6 million transactions a year, an on-site audit by a QSA.

The direct API makes sense for companies that treat payments as a competitive advantage: large platforms running their own vault and multi-PSP orchestration (routing to the best authorization rate, failover during outages), phone sales (MOTO), or sectors with highly specific customer journeys. For everyone else, there is a middle path: tokenization proxies (VGS, Basis Theory…) that intercept card data on the fly. Multi-PSP routing becomes possible without bringing the PAN into your systems, and therefore without SAQ D.

Chapter 6. Choosing a method: the full comparison.

There is no best method in absolute terms, only a method suited to a given merchant profile at a given time. The table below condenses the previous five chapters. Revisit it at each stage of growth, because the answer changes as your team, volume, or international ambitions change.

• Mistake #1: choosing the direct API “to stay in control” without budgeting for SAQ D compliance. Control costs hundreds of person-days
• Mistake #2: integrating iframes, then leaving the surrounding page without script monitoring. That page is the favorite target of Magecart skimming, and monitoring it is a v4.0 requirement
• Mistake #3: deploying a redirect with a poorly configured PSP page (language, logo, missing methods) and concluding that “redirects don't convert”
• Mistake #4: not instrumenting the funnel. Without measuring checkout completion rates by method and device, every conversion debate is just opinion