Authorize.Net

Custom Storefront PCI Scope Reduction With Hosted Payment Fields

E-commerce 4 Internet Marketers Editorial

Developer drafting a mobile checkout wireframe with a Hosted Fields card panel and SAQ A vs SAQ A-EP sticky notes
Illustration of a developer planning hosted payment fields to reduce PCI scope on a custom storefront.

By E-commerce 4 Internet Marketers Editorial

Explainer. This article explains documented tradeoffs between Payment Card Industry (PCI) Self-Assessment Questionnaire (SAQ) A and SAQ A-EP when custom or headless storefronts use Authorize.Net Accept.js, Authorize.Net Accept Hosted, or NMI Collect.js. Vendor documentation statements about SAQ eligibility are attributed as vendor claims. Official PCI Security Standards Council (PCI SSC) eligibility criteria are labeled separately. This is not a PCI assessment, legal advice, or a guarantee that any specific merchant qualifies for SAQ A or SAQ A-EP.

Why hosted fields matter on custom frontends

High-risk and regulated catalog sellers often leave platform-native checkout because native payments decline the category, or because acquiring already sits on Authorize.Net or NMI. Custom React, Vue, Next.js, and other headless carts then need a way to collect card data without putting Primary Account Number (PAN) and Card Verification Value (CVV) on the merchant origin.

Wrong SAQ assumptions show up late. Underwriters ask which SAQ the checkout maps to. A breach investigation asks whether card data ever touched merchant-controlled page elements. Hosted fields and tokenization reduce that exposure when implemented as the processor documents, but they do not automatically finish PCI validation for every site.

What PCI SSC says about SAQ A vs SAQ A-EP

Documented eligibility (PCI SSC facts)

PCI SSC FAQ guidance states that to be eligible for SAQ A, all elements of the payment pages must originate only from PCI DSS compliant service provider(s), and no single element of a payment page can originate from the merchant’s website.

For SAQ A-EP, the same FAQ states that each individual element of the payment page must originate from either the merchant website or a PCI DSS compliant service provider. If any element originates from some other source, the implementation is not eligible for SAQ A-EP.

PCI SSC also reminds merchants that all eligibility criteria for a given SAQ must be met. Payment-page origin alone is not enough if other SAQ criteria fail.

For e-commerce merchants that embed a third-party payment page or form (for example, one or more iframes), PCI DSS v4.0.1 SAQ A includes a criterion that the merchant has confirmed the site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s). PCI SSC’s February 28, 2025 blog on FAQ 1588 says that confirmation can come from implementing techniques such as those in Requirements 6.4.3 and 11.6.1, or from obtaining confirmation from the PCI DSS compliant TPSP or payment processor that, when implemented per its instructions, the solution includes techniques that protect the merchant’s payment page from script attacks. That script criterion applies to embedded payment pages or forms. It does not apply to pure redirects away from the merchant page or to fully outsourced payment links that never embed a form on the merchant site.

Interpretation (not a merchant guarantee)

SAQ A is the lighter questionnaire when the card-capture UI is wholly provider-delivered and other SAQ A criteria hold. SAQ A-EP still assumes the merchant does not electronically store, process, or transmit account data on its systems, but it covers sites whose own page or scripts can affect how payment data is captured or sent. Custom checkout branding that uses merchant-owned card inputs or merchant-delivered payment scripts typically lands in A-EP territory under those rules. Final SAQ selection belongs to the merchant’s acquirer or payment brand process, not to a blog post or a marketing line in gateway docs.

Authorize.Net Accept.js on a custom storefront

Documented product behavior (Authorize.Net facts)

Authorize.Net’s Accept.js docs describe a JavaScript library that sends payment data from the browser to Authorize.Net and returns a one-time-use payment nonce (opaque data). The merchant server later calls createTransactionRequest (or related APIs) with that nonce instead of raw card or bank data. The nonce is valid for 15 minutes.

Accept.js offers two workflows:

  1. Host your own payment form. Authorize.Net documents this path as a PCI DSS SAQ A-EP solution and says the merchant retains complete control of the customer payment experience. The library must intercept form submission, dispatch card or bank data to Authorize.Net, place dataDescriptor and dataValue into the form, and clear sensitive fields before the form posts to the merchant server.
  2. Embed Authorize.Net’s hosted payment information form (AcceptUI). Authorize.Net documents this path as PCI DSS SAQ A compliant. The merchant page supplies a button in the AcceptUI class. Card number, expiration, card code, and optionally name and postal code are collected on Authorize.Net’s hosted form.

Authorize.Net’s Accept feature overview matrix lists Accept.js (own form) as SAQ A-EP, Accept.js with UI as SAQ A, and Accept Hosted as SAQ A. Libraries must be loaded from Authorize.Net’s servers (production or sandbox matching the environment). Accept.js error codes include requirements for HTTPS and for loading the library from the Authorize.Net CDN rather than a local copy.

Accept Hosted (Authorize.Net facts)

Accept Hosted is a separate hosted form. Docs say merchants call getHostedPaymentPageRequest for a form token (valid 15 minutes), then redirect or embed a POST to Authorize.Net’s payment endpoint. Authorize.Net documents Accept Hosted as maintaining SAQ A level PCI compliance when used as described.

Vendor SAQ claims vs assessor caveats

Authorize.Net points merchants to a Coalfire SAQ eligibility overview and white paper for Accept solutions. Those materials state that Accept Hosted, Accept Customer, or Accept UI, when properly implemented and when no other cardholder-data input is present, can utilize SAQ A, and that Accept.js (own form) or Accept Mobile can utilize SAQ A-EP. The same white paper states that use of the product does not guarantee security or compliance because environments vary. Treat that as a third-party assessor’s product mapping, not as certification of any one merchant’s storefront.

NMI Collect.js on a custom storefront

Documented product behavior (NMI facts)

NMI’s Collect.js documentation describes a JavaScript framework that collects sensitive payment information without exposing the merchant website to that sensitive information, while letting merchants control checkout look and feel. Collect.js returns a payment_token used with NMI’s Payment API in place of card or ACH fields. Tokens are single-use and expire after 24 hours if unused.

Collect.js supports two integration styles with the same basic security model per NMI’s docs:

  1. Lightbox. Sensitive fields appear in a pop-up hosted experience over the merchant page.
  2. Inline. Collect.js inserts iframes into merchant-chosen containers for fields such as ccnumber, ccexp, and cvv (or ACH equivalents). Field contents are hosted by the gateway. Style sniffer or custom CSS can match the surrounding form within documented CSS property limits.

Authentication uses a public tokenization key from the merchant control panel. NMI warns that this key is visible in page source and must be a tokenization key, not a private API key.

NMI’s newer frontend integration guide for the Payment Component likewise states that tokenization keeps sensitive card data off the merchant server and that merchants can qualify for the simplest level of PCI compliance (SAQ A). NMI’s marketing materials describe Collect.js as a PCI SAQ-A compliant tokenization solution. Those statements are NMI product claims.

Interpretation for Collect.js SAQ mapping

NMI’s inline model places card-entry elements in gateway-hosted iframes, which aligns in architecture with the kind of embedded TPSP payment fields PCI SSC discusses for SAQ A when all payment-page capture elements originate from the compliant provider and other SAQ A criteria are met. Lightbox is also a provider-hosted capture surface in NMI’s description. Merchants still must confirm implementation against current SAQ A eligibility (including the script-susceptibility confirmation for embedded forms under v4.0.1) with their acquirer. This article does not assert that every Collect.js deploy is SAQ A for every merchant.

SAQ A vs SAQ A-EP tradeoffs for operators

When SAQ A is usually the goal (tradeoff discussion)

Teams chase SAQ A when underwriting questionnaires expect the lightest e-commerce path, when engineering capacity for continuous script integrity and payment-page change detection is limited, or when brand control of the card fields themselves is less important than reducing questionnaire scope. Practical Authorize.Net options that Authorize.Net maps to SAQ A include AcceptUI (hosted payment information form) and Accept Hosted. Practical NMI options that NMI maps toward SAQ A include Collect.js lightbox or inline iframes and NMI’s Payment Component tokenization approach, subject to correct implementation and acquirer confirmation.

Tradeoffs include less control over card-field markup, dependency on provider iframes or lightboxes, and the need to follow provider instructions exactly so merchant scripts do not recreate card inputs on the merchant origin.

When SAQ A-EP may be accepted (tradeoff discussion)

SAQ A-EP fits teams that insist on fully custom card inputs styled as native HTML on the merchant page, then rely on Accept.js (or similar direct-to-processor JavaScript) so PAN never posts to the merchant server. Authorize.Net explicitly maps that Accept.js own-form path to SAQ A-EP. The upside is UX control. The downside is a longer SAQ and more controls aimed at websites that can affect payment security even without storing account data.

A-EP is still far lighter than handling raw card data on merchant servers. It is not “almost SAQ A.” PCI SSC treats merchant-origin payment-page elements as a different eligibility bucket.

Shared failure modes that cancel the intended SAQ

Regardless of vendor:

  • Collecting card data in merchant-owned <input> fields and posting them to the merchant server expands scope beyond tokenization products.
  • Loading a stale or self-hosted copy of Accept.js when Authorize.Net requires its CDN can break the documented security model (Accept.js documents related errors).
  • Leaving a second “test” card form on the same checkout that posts PAN to the merchant origin undermines hosted-field intent.
  • Ignoring embedded-form script protections called out for SAQ A under PCI DSS v4.0.1 can leave an otherwise iframe-based checkout outside the merchant’s assumed questionnaire.
  • Confusing gateway marketing language with an Attestation of Compliance for the merchant’s own site.

Practical decision checklist for custom frontends

  1. Draw the payment-page data flow. List every DOM element that can accept PAN, expiry, or CVV, and note whether it is served from the processor or from the merchant origin.
  2. Match the processor path to the documented SAQ mapping. For Authorize.Net, own-form Accept.js is documented as SAQ A-EP. AcceptUI and Accept Hosted are documented as SAQ A. For NMI, Collect.js and Payment Component docs claim SAQ A when card data never touches the merchant server.
  3. Confirm with the acquirer or qualifying payment brand which SAQ they will accept for that exact architecture before promising SAQ A in an underwriting packet.
  4. For embedded iframes aimed at SAQ A under PCI DSS v4.0.1, plan how the merchant will meet the script-susceptibility confirmation (own controls consistent with 6.4.3 and 11.6.1 techniques, or documented TPSP confirmation per FAQ 1588).
  5. Keep server-side keys private. Use only public client or tokenization keys in browser code, as both Authorize.Net and NMI document.
  6. Retest after every checkout redesign. A React re-render that swaps iframes for native inputs can change SAQ eligibility overnight.

What this explainer does not claim

It does not assign SAQ A or SAQ A-EP to any named merchant, MCC, or vertical. It does not invent PCI outcomes for CBD, supplements, telehealth, firearms accessories, nicotine, or other regulated catalogs. It does not replace a Qualified Security Assessor (QSA), Internal Security Assessor (ISA), or acquirer validation. Product docs and PCI SSC FAQs change. Verify against the current SAQ documents and processor instructions before go-live.

Sources