How to Evaluate Payment Gateway Security for an E-commerce Store

Draw the Checkout Trust Boundary

Many merchants think their website “handles payments” because the checkout appears inside their domain. Technically, the sensitive fields may be delivered and controlled entirely by a payment provider.

That difference affects security responsibilities and PCI DSS validation.

Three Checkout Architectures Create Different Security Boundaries

The PCI Security Standards Council distinguishes these implementations when determining which Self-Assessment Questionnaire may be appropriate.

For example, eligibility for SAQ A requires all payment-page elements associated with the collection or processing of payment card data to originate directly from PCI DSS-compliant third-party service providers, along with meeting all other SAQ A eligibility conditions.

Use Seven Security Gates Before Approving a Gateway

Outsourcing Card Collection Does Not Outsource Website Security

This is one of the most important changes to understand in modern ecommerce security.

A merchant may use a fully outsourced payment flow and still operate the website that sends customers to that flow. If attackers compromise the merchant website, they may attempt to alter that path or interfere with the checkout experience.

The PCI Security Standards Council currently requires external vulnerability scanning by a PCI Approved Scanning Vendor for applicable SAQ A ecommerce webpages under PCI DSS v4.x, including merchant webpages that redirect customers to a third-party payment provider or embed the provider’s payment form.

The PCI SSC’s June 2026 clarification specifically confirms that those ASV scan requirements still apply when payment processing itself has been outsourced.

Payment-Page Scripts Deserve Their Own Review

Modern checkout pages often execute scripts for analytics, tag management, chat, advertising, experimentation, fraud detection and payment functionality.

A malicious or compromised script that can affect a payment flow creates a different risk from an ordinary styling error.

For merchants using an embedded third-party payment page or form and validating with SAQ A, the PCI SSC introduced an eligibility criterion requiring the merchant to confirm that its site is not susceptible to script attacks that could affect the ecommerce system.

The Council explains that this can be addressed using relevant payment-page protection techniques or, in qualifying situations, through confirmation from the PCI DSS-compliant payment provider that its embedded solution includes suitable protections when implemented correctly.

Redirect and Embedded Checkout Are Not Identical

Current SAQ A guidance makes an important distinction.

The specific SAQ A script-attack eligibility criterion introduced in 2025 applies to ecommerce merchant webpages containing an embedded third-party payment page or form, such as an iframe.

PCI SSC states that this particular eligibility criterion does not apply in the same way when customers are redirected from the merchant site to the payment provider or when payment functions are otherwise fully outsourced.

That does not mean redirected sites are free from security requirements. As noted above, applicable SAQ A ecommerce sites can still have requirements such as external vulnerability scanning.

Understand What Hosted Fields Actually Change

Some payment providers offer components where the sensitive card fields appear visually inside the merchant’s checkout but are actually hosted by the payment provider.

Braintree’s current Hosted Fields documentation, for example, states that its sensitive input fields are rendered inside provider-hosted iframes and the customer’s raw card information is sent directly to Braintree rather than passing through the merchant’s server.

The merchant receives a single-use payment-method reference instead of the raw payment credentials for subsequent server-side payment operations.

That architecture can reduce PCI scope when implemented according to provider requirements, but the merchant should still verify its exact validation obligations.

Secure Payment Collection Does Not End at the Card Fields

Use EMV 3-D Secure as an Authentication Layer, Not a Security Slogan

EMVCo describes EMV 3-D Secure as a technology that allows payment information and contextual data to be exchanged between merchants and card issuers so the issuer can authenticate the consumer during card-not-present transactions.

Whether authentication is required, frictionless or challenged can depend on issuer decisions, regulation, provider configuration and transaction context. Do not advertise 3-D Secure as a universal guarantee against fraud or chargebacks.

Evaluate the Gateway With a Test Environment Before Production

Security Claims That Should Trigger More Questions

The Final Selection Should Be an Architecture Decision

A small merchant that does not need deep payment customization may prefer an architecture where sensitive payment collection is strongly isolated from merchant systems.

A larger operation may legitimately need more customization, but it should understand the additional technical and compliance responsibilities that come with controlling more of the payment flow.

Before signing with a provider, document:

• which system collects card data;
• whether card data ever reaches merchant-controlled servers;
• the payment provider’s current PCI DSS status;
• the merchant’s applicable PCI validation path;
• which scripts can affect checkout;
• how merchant administrator access is protected;
• how server credentials and webhook authentication work;
• whether appropriate customer-authentication tools are supported;
• how security incidents and suspicious transactions are investigated;
• how the integration will be kept current after launch.