← All articles · May 3, 2026 · CheckoutProof

The PCI Responsibility Matrix: What to Ask Stripe, Shopify, and Other Processors

If you tried to claim SAQ A at your last attestation and your acquirer asked for your Responsibility Matrix, this article explains what they wanted, why it’s now mandatory, and how to extract one from your payment processor.

What a Responsibility Matrix is

A Responsibility Matrix (sometimes called an “RMF” or “Responsibility Assignment Matrix”) is a written document — usually one to three pages — that lists every PCI DSS requirement and identifies who is responsible for satisfying each one: the processor, the merchant, or both.

The format is rough. There’s no PCI Council template. A typical row looks like:

The point is to make explicit who handles which control — and, importantly, to flag the controls that the merchant still owes even when “the processor handles payments.”

Why January 2025 made it mandatory

Pre-2025, SAQ A merchants could just attest that their processor was PCI-validated and wave at the relationship. The PCI Council watched a decade of SAQ A merchants miss client-side controls, then watched the same merchants get hit by Magecart-style attacks, and concluded the abstraction was too loose.

The January 2025 amendment to SAQ A added a hard requirement: the merchant must obtain and retain a Responsibility Matrix from each TPSP (“third-party service provider” — the processor’s term for itself) whose services the merchant relies on for PCI compliance.

Translation: if you’re going to claim “Stripe handles that for me,” you need a written document from Stripe saying exactly which “thats” they handle.

If you can’t produce that document, you can’t claim SAQ A. You’re SAQ A-EP — and your auditor will tell you so.

Why processors don’t always volunteer it

Most large processors (Stripe, Shopify, PayPal, Braintree, Adyen, Worldpay) have a Responsibility Matrix available, but they don’t proactively send it. You have to ask.

A few reasons:

• Liability. A specific written assignment of responsibility is a thing legal departments write carefully. Generic AOCs (Attestations of Compliance) don’t pin them to specifics; matrices do.
• Scale. Stripe has millions of merchants, each in a slightly different setup. The matrix differs depending on whether the merchant uses Stripe Checkout (hosted), Stripe Elements (embedded iframe), or the lower-level Payment Intents API. They have multiple matrices for multiple products.
• Awareness gap. Many merchant-support reps haven’t been trained to recognize the request. You may have to escalate.

How to ask for it (and from whom)

The exact language to use, in an email to your processor’s support:

Subject: Request for PCI DSS Responsibility Matrix for [your merchant ID]

Hi,

Our acquirer has requested our PCI Responsibility Matrix per the January 2025 SAQ A eligibility amendment. We use [Stripe Elements / Stripe Checkout / Shopify Payments / etc.] in our checkout.

Could you provide the most current Responsibility Matrix for our specific integration, indicating which PCI DSS v4.0 requirements you cover on our behalf and which remain merchant responsibilities?

Thanks.

Address it to whoever your processor’s “Compliance” or “Risk” team is. If you only have a generic support address, escalate any first-line response that says “we’re a PCI Level 1 service provider, here’s our AOC” — that’s not what you asked for. You asked for the Matrix.

For specific processors, here’s where the matrices currently live:

• Stripe — request via the Dashboard’s “Compliance & PCI” section, or email compliance@stripe.com. Stripe maintains separate matrices for Stripe Checkout, Stripe Elements, and Payment Intents. Make sure you get the one for your integration.
• Shopify — Shopify Plus merchants can request via their Merchant Success Manager. Standard Shopify merchants on Shopify Payments can find a generic version in the Shopify Help Center under “PCI compliance,” though for SAQ A attestation you may want the merchant-specific version.
• PayPal / Braintree — request through your account manager, or if you don’t have one, via the PCI compliance form on PayPal’s developer portal.
• Square — available via their compliance documentation portal once you log in.
• Adyen — request via your dedicated implementation manager. Adyen typically provides a comprehensive matrix as part of onboarding for new accounts but you may need to ask for an updated version.
• Worldpay / FIS — through your account team. Worldpay’s matrix is usually attached to your master service agreement.

What a good matrix actually contains

A useful Responsibility Matrix has, at minimum:

1. Identification. Which integration product, which version of PCI DSS the matrix maps to (you want v4.0, not v3.2.1).
2. Date. When the matrix was issued and when it expires. Renewal cadence is usually annual.
3. The grid. Each PCI DSS requirement (or sub-requirement, for the granular ones), with who handles it.
4. Scope of coverage. Which environments / products the matrix applies to.
5. Exclusions. Things explicitly not covered. (“Provider does not perform vulnerability scanning of merchant infrastructure,” etc.)
6. Contact. Who to escalate to if a control listed as “shared” needs clarification.

A weak matrix that won’t fly with auditors:

• Generic boilerplate that doesn’t mention your specific product.
• Vague language (“Provider supports compliance with applicable requirements”). The whole point is who is responsible.
• No date, or a date older than 12 months.
• Missing 6.4.3 and 11.6.1. (These are the new v4.0 requirements; older matrices haven’t been updated.)

If you receive a weak one, ask for a current, version-specific document.

Common surprises in the matrix

Reading a real Responsibility Matrix is sobering for merchants who assumed “the processor handles it.”

6.4.3 (script inventory) — almost always the merchant’s responsibility for any embedded-iframe integration. The processor is responsible for what’s inside their iframe (js.stripe.com); the merchant is responsible for what’s on the page around the iframe. Most merchants don’t realize this.

11.6.1 (tamper detection) — same split. Stripe monitors js.stripe.com; you monitor your checkout page.

Network controls (1.x, 2.x) — typically merchant for your storefront infrastructure, processor for the payment infrastructure. Your hosting provider may cover most of it.

Vulnerability scanning (11.3.x) — usually merchant. You hire an Approved Scanning Vendor (ASV) for quarterly external scans. Doesn’t matter who your processor is.

Encryption in transit (4.x) — shared. Processor handles their endpoints; you handle TLS on your storefront.

Logging (10.x) — shared. Processor logs payment-related events; you log your storefront events.

Access control (7.x, 8.x) — usually merchant for your storefront admin. Processor for their dashboard. Your team’s access to either is yours.

The single most common reaction to reading the matrix carefully for the first time is “wait, that’s me?” There’s a good chance some control you assumed was outsourced is actually shared or fully yours.

What to do once you have the matrix

Three things, in order:

1. Read it. Identify every control listed as “merchant” or “shared.” For each, decide: do you currently satisfy it? If not, that’s a gap to close.
2. Map it to your existing controls. For each merchant-side requirement, what’s the evidence you’d hand a QSA? If the answer is “we’d have to scramble,” scope the work to fix it.
3. File it. The matrix is part of your PCI evidence pack. Put it in the same folder as your AOC, your last SAQ submission, your ASV reports. When you renew next year, ask for a current version.

If you do this annually, it’s 30 minutes. If you skip it for three years and then have an audit, it’s a fire drill.

What this looks like for SAQ A-EP merchants

If you’re SAQ A-EP rather than SAQ A — most merchants on Stripe Elements, headless Shopify, or any custom checkout — the matrix is still useful but less load-bearing. SAQ A-EP doesn’t have the “you must have a matrix to be eligible” eligibility criterion. But the matrix is still the cleanest way to identify which controls your processor covers and which remain on you.

For SAQ A-EP merchants, the gap most likely to surprise you is the 6.4.3/11.6.1 client-side controls. Those are mandatory in v4.0 and almost always entirely the merchant’s responsibility — even when you’re using a hosted payment iframe.

Read our SAQ A-EP article if you’re not sure which questionnaire you fall under, and run a free scan on your checkout to see your current state on 6.4.3 and 11.6.1. The matrix tells you what’s owed; the scan tells you whether you’re paying.

Run a free PCI 6.4.3 scan of your checkout page. Get the script inventory and a one-page PDF report. Try it now →