Payment Page Redirect

What Is a Payment Page Redirect?

A payment page redirect is a checkout integration pattern where a merchant's website sends the customer to a page hosted by a payment service provider (PSP) to collect payment credentials. Instead of rendering a credit card form on the merchant's own domain, the browser navigates to the provider's secure URL. After the customer enters their details and the payment is processed, the browser redirects back to the merchant's confirmation or failure page.

This pattern emerged as one of the earliest ways to accept online payments. Before embedded iframes and JavaScript-based tokenization became widespread, redirecting to a bank or processor's page was the standard approach. The model persists today because it offers the simplest path to PCI compliance: if card data never enters the merchant's environment, the merchant's security obligations shrink dramatically.

Common examples include Stripe Checkout (hosted mode), PayPal's standard checkout flow, Adyen's hosted payment page, and regional processors that offer a branded redirect page as their primary integration.

How It Works

The redirect flow involves three parties: the customer's browser, the merchant's backend, and the PSP. The merchant never handles raw card numbers.

1. The customer clicks "Pay" on the merchant's checkout page
2. The merchant's server makes an API call to the PSP, passing order details (amount, currency, line items) along with a success URL and a cancel URL
3. The PSP creates a payment session and returns a unique hosted-page URL
4. The merchant's server sends an HTTP redirect (302) or renders a link that sends the customer's browser to that URL
5. The customer enters card details on the PSP's domain, which may trigger 3-D Secure authentication if required by the issuer
6. The PSP processes the payment, then redirects the browser back to the merchant's success or cancel URL
7. In parallel, the PSP sends a server-to-server webhook to the merchant's backend confirming the payment outcome

Session Creation

The merchant initiates the flow by creating a checkout session through the PSP's API. A typical request includes the payment amount, currency, return URLs, and optional metadata like order IDs or customer references:

POST /v1/checkout/sessions
Host: api.psp-provider.com
Content-Type: application/json

{
  "amount": 4999,
  "currency": "usd",
  "success_url": "https://shop.example.com/order/confirm?session={SESSION_ID}",
  "cancel_url": "https://shop.example.com/cart",
  "metadata": {
    "order_id": "ORD-20261113-0042"
  }
}

The PSP responds with a session ID and a redirect URL. The merchant stores the session ID for later reconciliation and sends the customer to the redirect URL.

Return and Confirmation

When the customer completes (or cancels) the payment, the PSP redirects the browser back to the corresponding URL. However, the browser redirect alone is not a reliable confirmation: the customer might close their browser before the redirect completes, or the return URL could be spoofed.

The authoritative payment status comes from the PSP's webhook: a server-to-server POST request containing a signed payload with the payment result. The merchant's backend should treat the redirect as a display hint and fulfill orders only after verifying the webhook signature:

// Webhook handler (pseudocode)
app.post("/webhooks/payment", (req, res) => {
  const signature = req.headers["x-signature"];
  if (!verifySignature(req.body, signature, WEBHOOK_SECRET)) {
    return res.status(401).send("Invalid signature");
  }

  const { session_id, status } = req.body;
  if (status === "paid") {
    fulfillOrder(session_id);
  }
  res.status(200).send("OK");
});

PCI DSS Compliance Benefits

The primary advantage of redirect-based checkout is a reduced PCI DSS scope. Because card data is entered entirely on the PSP's domain, the merchant's systems never store, process, or transmit cardholder data. This qualifies the merchant for SAQ A: the simplest PCI self-assessment questionnaire, with roughly 30 requirements instead of the 300+ in SAQ D.

Under PCI DSS v4.0, merchants using a full-page redirect (HTTP 302, meta refresh, or JavaScript redirect) are exempt from the script-integrity requirements in sections 6.4.3 and 11.6.1 that apply to iframe-based integrations. This is because the payment form loads on the PSP's domain, so the merchant's page scripts cannot interact with cardholder data fields.

This distinction matters for engineering teams: an iframe integration embeds the PSP's form inside the merchant's page, which means scripts running on that page could theoretically be compromised to intercept keystrokes. A redirect avoids this attack surface entirely.

Redirect vs. Other Integration Models

Payment page redirects are one of three common checkout integration patterns. Each trades off compliance burden against user experience control:

Embedded iframes and hosted fields (such as Stripe Elements or Braintree Hosted Fields) keep the customer on the merchant's page while isolating card data in a provider-controlled iframe. This preserves the checkout flow but adds PCI requirements around page script integrity under v4.0.

Direct API integration gives the merchant full control over the payment form but significantly increases PCI scope, requiring SAQ A-EP or the full SAQ D assessment.

Use Cases

• Small and mid-size e-commerce: merchants without dedicated security teams use redirects to avoid PCI audit complexity while still accepting card-not-present payments
• Multi-currency and regional checkout: PSPs that handle local payment methods (iDEAL, Bancontact, PIX) often surface these options natively on their hosted page, saving the merchant from building a complex payment method selector
• Subscription and SaaS billing: redirect flows work well for initial payment capture where the PSP stores a token for recurring billing, since the customer only needs to visit the hosted page once
• Marketplace disbursement: platforms using a payment facilitator model often redirect sellers to the PSP for onboarding and payout setup, keeping sensitive financial data off the platform's servers
• Crypto on-ramp providers: fiat-to-crypto on-ramps frequently use redirect flows to handle card payments and KYC on a provider-hosted page before delivering cryptocurrency to the user's wallet

Why It Matters for Crypto Payments

The redirect model highlights a broader tension in payment design: simplicity and security versus conversion and control. In traditional payments, redirects trade abandonment risk for PCI scope reduction. Crypto payments sidestep this tradeoff entirely.

With cryptocurrency and stablecoin payments, there is no cardholder data to protect: the customer authorizes a transfer from their wallet, and the transaction settles on-chain or through a layer-2 network like Spark. No redirect is needed because no sensitive credentials are entered on the merchant's page. The payment is push-based rather than pull-based, eliminating the PCI compliance question altogether.

For merchants evaluating checkout architecture, understanding redirects and their limitations helps frame why crypto checkout flows can achieve lower friction: they replace the credential-entry step with a wallet signature, removing the need for hosted pages, iframes, or tokenization layers.

Risks and Considerations

Cart Abandonment

Leaving the merchant's site introduces friction. The Baymard Institute reports an average online cart abandonment rate of roughly 70% across 50 studies, with a complex or unfamiliar checkout process cited as a factor by 18% of abandoning shoppers. While abandonment is not caused solely by redirects, the visible domain change can erode trust: customers may hesitate when they see an unfamiliar URL, particularly on mobile where address bars are prominent.

Limited Brand Control

PSPs typically allow some customization of their hosted pages (logo, colors, custom fields), but the merchant cannot control layout, error messages, or interaction patterns at the level that an embedded integration permits. For brands where checkout experience is a competitive differentiator, this limitation is significant.

Mobile Experience

Redirects on mobile can trigger app-switching behavior, browser tab proliferation, and back-button confusion. If the PSP's page is not fully optimized for mobile viewports, the payment form may render poorly. Mobile shoppers already show higher abandonment rates (roughly 80% compared to 70% on desktop), and a redirect adds another potential drop-off point.

Webhook Reliability

Because the browser redirect is unreliable as a payment confirmation, merchants must implement webhook handlers with proper signature verification, idempotency, and retry tolerance. If the webhook endpoint goes down, orders may not be fulfilled even though payment succeeded. Robust implementations include a reconciliation job that polls the PSP's API to catch any missed webhooks.

Redirect Tampering

If the merchant's page that initiates the redirect is compromised, an attacker could change the destination URL to a phishing page that mimics the PSP's payment form. Merchants should serve the redirect from their backend (server-side 302) rather than relying on client-side JavaScript, and use Content Security Policy headers to restrict where the page can navigate.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.