A hosted payment page is a checkout form run entirely by a third-party payment provider, so your servers never touch the customer’s card number. When the shopper clicks pay, they are handed off to the provider’s secure environment to enter card details, then returned to your confirmation page with a token representing the transaction. That architecture cuts your obligations under the Payment Card Industry Data Security Standard (PCI DSS) and shrinks the surface area for a breach. Getting one live comes down to four pieces of work: choosing between a redirect and an embedded iFrame, meeting the current PCI DSS v4.0 requirements, opening a merchant account, and testing in a sandbox before real money moves.
How the Hand-Off Works
Your server sends an API request to the payment provider to create a secure session. The provider replies with either a URL for a full-page redirect or the code needed to embed an inline frame on your checkout page. Either way, the fields where the customer types card details live on the provider’s servers, not yours.
Full-Page Redirect
A redirect sends the customer to a separate URL hosted by the provider. They fill in card information there, the provider processes the transaction, and the customer comes back to your site with a confirmation token. This is the simplest PCI path because your website has zero involvement with cardholder data. The visible URL change during checkout can feel abrupt to some shoppers, which is the trade-off.
Embedded iFrame
An iFrame keeps the customer visually on your site by displaying the provider’s form inside a window on your checkout page. Card data still goes directly to the provider, but the experience feels seamless because there is no URL change. The catch is a slightly higher compliance burden: you have to demonstrate your site environment cannot tamper with the iFrame or intercept keystrokes through malicious scripts.
Tokenization on the Return
The provider never sends raw card data back to your server. You receive a token, a randomized string that represents the customer’s card for that transaction. Store the token in your database and use it for refunds, recurring charges, or lookups. Because the token is meaningless outside the provider’s system, a breach of your database exposes no usable payment information.
PCI DSS v4.0 Requirements
Any business that stores, processes, or transmits cardholder data must comply with PCI DSS, and that mandate reaches merchants using hosted payment pages because your environment can still affect the security of card data handling.1PCI Security Standards Council. PCI Security Standards Council – Standards Version 4.0 is now the only active version, with all future-dated requirements fully mandatory as of March 31, 2025.2PCI Security Standards Council. Coffee with the Council Podcast: Guidance for PCI DSS E-Commerce Requirements Effective After 31 March 2025
Which Self-Assessment Questionnaire Applies
PCI DSS uses Self-Assessment Questionnaires (SAQs) to match validation scope to the risk your integration creates. Hosted payment pages generally land in one of two places:
- SAQ A applies when all payment page elements come directly from a PCI DSS-compliant third-party provider and your systems never electronically store, process, or transmit account data. A pure redirect model typically qualifies.3PCI Security Standards Council. PCI DSS v4.0 SAQ A
- SAQ A with added iFrame requirements applies when you embed a provider’s iFrame on your own checkout page. You still file SAQ A, but you also have to satisfy Requirement 11.6.1 for change and tamper detection on the hosting page.3PCI Security Standards Council. PCI DSS v4.0 SAQ A
If your servers directly handle card data through an API rather than hosting a provider’s form, you are in SAQ D territory with the full set of PCI DSS requirements. That is a direct integration, not a hosted page.
Script Integrity and Tamper Detection
Two requirements that became mandatory on March 31, 2025 directly affect how your checkout page behaves in the customer’s browser. Requirement 6.4.3 covers script management: you must maintain an inventory of all scripts running on your payment pages, confirm each script is authorized, verify their integrity, and alert when unauthorized changes appear. Requirement 11.6.1 covers change and tamper detection: a mechanism must monitor your payment pages and HTTP headers for unauthorized changes and alert authorized personnel when modifications occur.4PCI Security Standards Council. Scaling 6.4.3 and 11.6.1 Browser Script Management These rules exist because attackers inject malicious JavaScript into checkout pages to skim card data in the browser even when the merchant’s server never sees the data. If you use an iFrame, 11.6.1 applies to you under SAQ A. If you use a full-page redirect and your site carries no payment page elements at all, these requirements generally don’t apply to your environment.
What Non-Compliance Costs
PCI DSS is not a law. The card networks enforce it through contracts with acquiring banks, and when a merchant falls out of compliance, the network fines the acquirer, which passes the cost to you. Reported fines range from $5,000 to $100,000 per month depending on transaction volume and how long the violation persists. Acquirers can also revoke your ability to accept cards entirely, and a breach tied to non-compliance opens the door to lawsuits from affected cardholders.
Setting Up a Merchant Account
Before configuring any payment page, you need a merchant account through an acquiring bank or payment processor. This account lets funds from card transactions flow from the network to your business bank account.5Office of the Comptroller of the Currency. Merchant Processing – Comptroller’s Handbook
What Documents You Need
Expect to provide your federal Employer Identification Number (EIN), a business bank account for settlement, your business type and location, and personal identification for principal owners.5Office of the Comptroller of the Currency. Merchant Processing – Comptroller’s Handbook For corporations, LLCs, and similar entities, the bank must also identify each person who owns 25% or more of the company plus one individual with significant management control, collecting name, address, date of birth, and Social Security number for each.6Financial Crimes Enforcement Network. Exceptive Relief from Requirement to Identify and Verify Beneficial Owners at Each Account Opening Most processors also want recent bank statements, your website URL, a description of what you sell, and any prior processing history. High-risk categories such as online gambling, supplements, and subscription products with elevated chargeback rates face longer underwriting and may be required to hold a reserve fund.
What It Costs
Per-transaction fees for online payments generally land between 2.5% and 3.5% of the amount plus a flat fee of $0.15 to $0.30, depending on the processor and plan tier. Fixed costs include monthly account fees, annual registration fees commonly in the $100 to $300 range, and sometimes a monthly PCI compliance fee. Some processors bundle these into one rate; others itemize. Read the full fee schedule before signing, because the headline transaction rate is rarely the whole picture.
Configuring the Payment Form
Once the merchant account and provider are in place, actual configuration happens in the provider’s dashboard.
Fields to Collect
At minimum, the form takes cardholder name, card number, expiration date, and card verification value (CVV). Most providers let you toggle additional fields: billing address, phone, email, shipping information. Turn on Address Verification System (AVS) fields so the issuer can compare the billing address the customer enters against records on file. Keep the form as short as your risk tolerance allows. Every extra field lifts abandonment. If you sell digital goods and ship nothing, requiring a full shipping address adds friction for no reason.
Branding and Language
Providers let you upload your logo, set colors, and customize button text so the page doesn’t look like a generic third-party form. Branding matters most for redirect-based pages, because the customer has left your site and needs visual reassurance. Configure supported currencies and default language too; if you sell internationally, matching the local currency and language of major markets reduces confusion and abandoned carts.
Accessibility
Where the provider gives you control over form customization, the page should meet at least WCAG 2.2 Level AA. For payment forms that means every input needs a programmatically associated label, input errors must be identified in text with suggested corrections, and the form must let the customer review and confirm before final submission.7World Wide Web Consortium (W3C). Web Content Accessibility Guidelines (WCAG) 2.2 That last item, error prevention for financial transactions, is a Level AA criterion applying to any page causing financial commitments. Accessibility lawsuits targeting inaccessible checkout flows have increased steadily, so an inaccessible payment page carries both customer loss and legal exposure.
Fraud Prevention Layered on Top
A hosted page handles data security. Fraud prevention is a separate job, and most of it happens through provider settings and a protocol called 3D Secure.
3D Secure 2
3D Secure 2 (3DS2) adds an authentication step where the card issuer verifies the cardholder’s identity during checkout. The issuer may approve the transaction silently based on device data and purchase history (a frictionless flow) or prompt the customer for a one-time code or biometric confirmation (a challenge flow). In the United States, 3DS2 is not legally required the way it is in Europe under Strong Customer Authentication rules, but it comes with a real incentive: when a customer completes 3D Secure authentication successfully, liability for fraud-related chargebacks shifts from you to the card issuer.8Adyen Docs. 3D Secure for Regulation Compliance If someone uses a stolen card and passes 3DS, you don’t eat the loss.
Most hosted payment providers support 3DS2 as a toggle or API parameter. You can request a challenge on every transaction, prefer frictionless flows to minimize checkout friction, or let the issuer decide. The right balance depends on your chargeback rate and how much extra friction your customers tolerate.
AVS and CVV
AVS and CVV checks are the first line of defense and come standard with virtually every hosted page. AVS compares the numeric portion of the billing address and zip code against the issuer’s records. CVV confirms the customer has the three- or four-digit code printed on the card. Neither is foolproof alone, but together they filter out most opportunistic fraud. Configure the provider to auto-decline transactions where both AVS and CVV fail, rather than flagging for manual review, unless your business model needs a more lenient approach.
Integration and Testing
With configuration done, the technical integration connects the payment page to your storefront and ensures the two systems talk correctly after each transaction.
Wiring It Into Your Site
For a redirect, your developer inserts the provider-generated URL into your checkout button. Clicking pay sends the customer to the provider’s page with encrypted session data (order amount, currency, reference ID). For an iFrame, the developer embeds a script tag that loads the provider’s form inside a container on your checkout page. Either way, the entire checkout page must be served over HTTPS. Serving any part of a page over an insecure connection when a payment iFrame is present creates a vulnerability and will fail PCI validation.
Handling the Response
After the customer submits payment, the provider sends two things: a browser redirect returning the customer to your confirmation page, and a server-to-server webhook with the transaction result. The webhook is the authoritative source for success or failure. Don’t rely on the browser redirect alone, because customers can close their browser mid-redirect and the webhook will still arrive.
Verify every webhook before acting on it. The standard approach uses HMAC (hash-based message authentication code) signatures: the provider signs each webhook with a shared secret key, and your server recalculates the signature to confirm the message is authentic. Skipping this step means an attacker could send a fake “payment successful” webhook and receive goods without paying. This is where most implementation shortcuts come back to bite.
Sandbox Testing Before You Go Live
Every major provider offers a sandbox that simulates real transactions without moving money. Before going live, run these scenarios at minimum:
- A successful payment, confirming the token returns, the webhook fires, and your order system records the transaction correctly.
- A declined card, verifying the customer sees a clear error and can retry without restarting checkout.
- A 3D Secure challenge, testing that the prompt appears and the liability shift indicator comes back in the response.
- A refund, processed through your dashboard or API and confirmed against the test account.
- A webhook delivery failure, simulated to verify your system retries or queues the notification rather than silently dropping it.
Providers supply test card numbers for sandbox use (4111 1111 1111 1111 is a standard Visa test number across most providers). When you’re ready, switch your API endpoint from sandbox to production, set transaction mode to live, and run one real low-dollar transaction end to end before opening the page to customers.
After Launch: Reconciliation and Chargebacks
Going live is not the finish line. Your provider dashboard becomes daily operations for tracking payments, managing disputes, and catching problems early.
Every successful transaction generates a unique transaction ID tying the payment to your internal order number. Use these IDs to reconcile the provider’s records against your accounting system at the end of each business day. Discrepancies usually point to failed webhooks, duplicate charges, or refunds that didn’t process. Catching them within 24 hours is far easier than sorting them out a month later during bank reconciliation.
Refunds are straightforward: find the transaction, issue a full or partial refund, and the provider reverses the charge. Chargebacks are adversarial. When a cardholder disputes a charge with their bank, you get a notification and a window, usually 7 to 21 days depending on the network, to submit evidence that the transaction was legitimate. Keep order confirmations, shipping tracking, and customer communications organized, because a chargeback you can’t respond to in time is one you lose by default.
Watch your chargeback ratio. Card networks flag merchants who exceed roughly 1% of transactions as chargebacks, and crossing that threshold can trigger enrollment in a monitoring program with higher fees, required remediation, or eventual termination of your merchant account. A hosted payment page with 3D Secure, AVS, and CVV handles the fraud side. Product quality, clear billing descriptors, and responsive customer service handle the rest.