Document Your Payment Flow Before Choosing an SAQ

Record what happens from payment entry to support

Walk through each payment channel with its owner. Include the standard customer journey and the less visible activities: refunds, recurring payments, telephone orders, troubleshooting, administrative access and changes to checkout.

Use field names and synthetic examples when discussing the flow. Do not put live card numbers, card verification codes, credentials or production exports into a general planning document or a booking form.

A fictional online shop might redirect normal purchases to a hosted payment page but handle telephone orders through a different tool. Label both channels in its record. The description of the hosted checkout does not explain what happens during a telephone order or support interaction.

Separate eligibility from the request to validate

Record who requested validation, the document requested, the service or merchant account covered, the deadline and the contact able to resolve questions. Keep the selected SAQ version and the evidence for each eligibility condition alongside that request.

Check the current SAQ A conditions for your integration

PCI SSC FAQ 1588 explains that this particular script eligibility condition applies to merchant webpages containing a provider's embedded payment page or form, such as an iframe. It does not apply to the redirect and fully outsourced payment arrangements described in that FAQ. Other SAQ eligibility conditions still apply.

A Shopify example: identify the actual customization surface

Make a proposed scope change reviewable

If the team proposes a hosted payment page, tokenization, a listed P2PE solution or segmentation, create a before-and-after record rather than treating the technology's name as the conclusion.

Describe the proposed change, the systems expected to remain relevant, the evidence needed to support any exclusion, the operational owner and the decision still required. Include the migration period if old and new flows will coexist. Ask how refunds, exports, provider administration and support will work after the change.

For example, if the proposed design returns only tokens to an application, ask what the application can do with those tokens and whether another route exposes account data. Keep the answer and supporting design evidence with the scope decision. Do not mark the system excluded merely because one database field changed its label.

Treat claimed savings as a question to evaluate. Compare the implementation cost, operating responsibilities, third-party fees and evidence work before approving a change. A smaller proposed boundary is not, on its own, proof of a cheaper engagement or an accepted validation result.

Turn retained responsibilities into an evidence plan

Use a responsibility record with one row per applicable activity: what the merchant does, what the provider does, what is shared and what evidence demonstrates each part. Avoid a single “provider handles PCI” entry. Link the provider's relevant assurance material to the service and period it covers, and record unanswered questions.

Then build a working calendar from the actual applicable requirements and validation program. For each recurring activity, record its owner, required frequency or trigger, planned date, evidence location and handling of failures. Keep vulnerability scanning, penetration testing and segmentation testing as separate items where applicable. The service responsible for each activity and the person reviewing its results should be explicit.

A test report with open findings needs a next step, an owner and any required retesting. A signed questionnaire needs an accountable signatory and supported answers. A readiness plan can organize those dependencies; it does not prove that testing occurred or that validation was accepted.

Recheck the record before submission and after change

Before submitting, compare the current payment-flow record with the scope described in the evidence. Investigate differences, stale reports and unsupported answers. Escalate a disagreement about the path to the appropriate acquirer, payment brand, provider or assessor rather than filling the gap with an assumption.

Keep a short decision log after validation: what changed, which scope assumptions were affected, who reviewed the change and what follow-up is required. A new integration, acquisition, administrator connection or payment channel should prompt the team to check whether the earlier record still describes the service.

For the next readiness discussion, bring the validation request, a channel list, current diagrams and a summary of unresolved responsibility questions. Those records help define the work before agreeing a timetable or fee.