Outsourced payments and PCI DSS: what your business still owns.

Outsource processing with a clear account of what remains

Moving card entry and processing to a specialist provider can reduce the payment data your business handles and the systems you need to protect directly. The important follow-up is to establish what remains your responsibility. A provider’s payment service, your website, and your staff’s everyday procedures are different parts of the same customer journey. A secure arrangement depends on understanding the connections between them.

Consider a fictional regional retailer selling equipment online and taking occasional telephone orders. Its website currently redirects customers to a provider’s checkout. The marketing team wants an embedded payment form so customers stay on the retailer’s page, while staff enter telephone orders through a separate payment process. This is a planning example, not an SPS customer or a claimed compliance outcome. The retailer needs to understand how those choices affect its responsibilities before approving the redesign.

PCI SSC states that outsourcing all payment processing does not remove a merchant’s responsibility for protecting account data through its providers or validating compliance. Many requirements may no longer apply directly to the merchant’s environment, but provider oversight and shared responsibilities remain. [1] Start by identifying the actual payment arrangement. Treat the provider’s assurance as evidence to evaluate alongside your implementation, rather than assuming the service’s status answers every question about your business.

Trace each payment channel from collection to follow-up

Walk through a normal transaction with the people who run it. Record where card information is entered, what receives it, what the merchant receives back, and which systems can change that path. For a website, distinguish a redirect to the provider’s page from a provider form embedded inside the merchant’s page. Include the shop platform, relevant plugins, administrative access, and the configuration controlling the payment destination. A provider logo does not describe those connections.

The fictional retailer’s telephone orders need their own walkthrough. Establish what the employee hears or sees, which device or application is used, and whether call recordings, notes, screenshots, or support tickets capture account data. Review refunds, failed payments, and customer assistance as well as successful checkout. A carefully designed website flow does not explain what happens when a caller asks an employee to finish an order manually.

Document information leaving the provider, such as order references, tokens, receipts, and reports, without assuming they all contain the same data. Receiving a token does not describe how the original card information was collected or what another system retained. For each channel, record the business owner, provider service, systems involved, and unresolved questions. Use representative test transactions and approved test data so the discovery exercise does not create unnecessary copies of real payment information.

Confirm the validation path before selecting a form

A Self-Assessment Questionnaire, or SAQ, is a way to report a self-assessment for an eligible environment. Its suitability follows the actual implementation and complete eligibility criteria. Do not choose the shortest questionnaire and reshape the description of your business around it. Explain all payment channels to the acquirer, the merchant bank, or other organization that accepts your compliance submission, and confirm what it expects you to validate and submit.

PCI SSC’s guidance on multiple processing environments says that separate SAQs may be possible for different channels, or one questionnaire may address the combined environment. Separate questionnaires depend on each channel meeting its eligibility criteria and adequate segmentation isolating the channels. The approach should be confirmed with the acquirer or payment brand. [2] Neither a provider recommendation nor a diagram with separate boxes settles that decision.

For the fictional retailer, prepare a short decision record covering the current redirect, proposed embedded form, telephone workflow, provider services, and any uncertain data handling. Identify the proposed validation method and the assumptions it depends on. Keep the response from the compliance-accepting organization with that record. If the business needs a different reporting method or further assessment, resolve it before building a large evidence package for the wrong path.

Keep the merchant website in the conversation

An embedded payment form does not make the surrounding merchant page irrelevant. The retailer should know who can change that page, which scripts and plugins it loads, and how payment integration settings are protected. Review the provider’s implementation instructions with the web team. A theme change, tag-management update, or new customer-support widget can alter the page without anyone thinking of it as a payment project.

For SAQ A, PCI SSC identifies a script-attack eligibility criterion for merchant webpages containing a provider’s embedded payment form. The merchant can use appropriate protective techniques or obtain confirmation from the compliant embedded-form provider that its solution provides protection when implemented according to its instructions. That particular criterion does not apply to redirects or fully outsourced payment links; all other applicable eligibility criteria still need consideration. [3]

This distinction does not remove other website duties. PCI SSC confirms that SAQ A merchants with webpages redirecting payments or embedding provider iframes retain the applicable external vulnerability-scanning requirements. The required ASV scans use a listed PCI Approved Scanning Vendor and its approved scan solution. [4] A redirect should therefore not be translated into a general conclusion that the merchant website needs no security work.

The retailer’s redesign decision should identify the protection approach, the implementation conditions, the person checking those conditions, and the evidence retained. Ask the provider to explain exactly which embedded solution its confirmation covers. Make any unanswered question visible before launch. The business needs a defensible account of its actual page, not an assurance statement copied from a different integration guide.

Check that provider evidence covers the service you use

Request the provider’s applicable Attestation of Compliance, or AOC, and enough supporting information to connect its assessed services to your arrangement. PCI SSC expects provider evidence to cover the services relevant to the customer and the requirements performed on its behalf. Where no applicable AOC exists, the provider is expected to supply specific evidence for the relevant requirements so the customer or assessor can evaluate them. [5]

For the fictional retailer, check the service name, responsible legal entity, assessment information, and described coverage against the contract and integration. A provider might offer hosted checkout, embedded forms, a telephone-payment service, and unrelated business tools. Evidence concerning one offering should not silently be extended to the others. Ask about any dependencies or customer configuration duties that affect the service being relied upon, and record the answer where the payment owner can find it.

Keep commercial and technical questions connected. Procurement may hold the agreement while the web team holds the implementation guide and finance holds the provider correspondence. Bring those records together for the specific payment arrangement. If the evidence is unclear, record what is missing and who will resolve it. A familiar provider name or a sales assurance is not a substitute for understanding the coverage of the supplied evidence.

Assign the shared work to named owners

Turn the division of responsibility into an operating record. For each applicable activity, identify what the provider does, what the merchant does, which configuration is required, and what evidence demonstrates the result. PCI SSC identifies a responsibility matrix as one way to document this division. [5] A row marked “shared” still needs a clear explanation of the handoff and the owner on each side.

In the retailer’s example, the provider may operate the covered checkout service while the retailer manages website administrators, approved integrations, and its telephone-order procedure. Someone must confirm that an integration still follows the provider’s instructions after a change. Someone must obtain the provider evidence and resolve exceptions. Assign these tasks to roles that exist in the business, with a backup and a route for escalating unanswered questions.

PCI SSC also identifies written agreements acknowledging provider responsibilities and monitoring the provider’s compliance status at least annually among the merchant’s remaining duties. [1] Build that review into the vendor calendar, and add practical triggers such as a service replacement or change in contractual coverage. Include how the parties will communicate about suspected payment-security issues. A provider contact that nobody can locate during an incident is a weak operational handoff, even when the agreement is well written.

Collect evidence about the working arrangement

Build a compact evidence index around the confirmed scope and applicable requirements. Useful records may include current payment-flow diagrams, provider coverage evidence, responsibility agreements, implementation settings, access reviews, and required scan or test results. Record the date, owner, environment, and question each item answers. The index should make gaps easier to see; filling a folder with screenshots does not resolve an uncertainty about the payment flow.

For the fictional retailer, verify that approved test transactions reach the expected provider and that relevant settings match the documented design. Review which people can change checkout configuration and how those changes are approved. Check the actual telephone workflow with staff rather than relying only on a written procedure. These are practical readiness checks, and their scope should be agreed so they do not disrupt processing or expose real account data.

Select testing for the question it must answer. An application penetration test can investigate access-control or workflow weaknesses in the merchant application. It does not replace a required ASV scan or by itself establish SAQ eligibility. If scope reduction depends on segmentation, identify the applicable validation work for that boundary. Document what each activity covered, the issues found, and any follow-up evidence needed instead of treating one report as assurance for the whole arrangement.

Review changes against the assumptions behind your scope

Payment scope can drift through ordinary business changes. A new plugin, checkout redesign, call-recording feature, refund process, or provider service can change where information travels or who can affect it. Put a payment-impact question into the existing change process. The purpose is to recognize changes that challenge a documented assumption and route them for review before relying on the old conclusion.

The fictional retailer’s move from a redirect to an embedded form is a clear review trigger. Compare the old and proposed flows, obtain the relevant provider instructions and evidence, and evaluate the merchant page’s responsibilities. Confirm any effect on the validation path with the compliance-accepting organization. Then check the implemented configuration and refresh the evidence. The fact that the processor stays the same does not establish that the merchant’s arrangement stayed the same.

Assign the review to the payment owner and the people who can explain the change. A cosmetic adjustment may leave the important assumptions intact, while a small script or workflow change may not. Record the reasoning and any unresolved conditions. Keep a rollback or operational fallback appropriate to the release, and ensure it follows an understood payment process rather than introducing an improvised route for customers to send card information.

Prepare a clear readiness handoff

A useful readiness result explains the payment environment, the validation path to confirm, the responsibilities on each side, and the gaps still requiring action. Give each gap an owner and a practical next step. Separate an unanswered scope question from a known control weakness or missing evidence. Leadership can then decide what needs to be resolved before a redesign, provider migration, or compliance submission proceeds.

SPS PCI DSS Readiness maps payment data flows, connected and security-impacting systems, and relevant boundaries. The work supports validation-path confirmation with the acquirer, assesses applicable requirements, prioritizes fixes, and organizes an evidence index and readiness memo. Where segmentation is part of the agreed scope, the engagement can include testing of those boundaries. This prepares the business for its validation process; SPS does not sign the PCI DSS assessment report or attestation.

For the fictional retailer, the immediate next step is a coordinated review of the website redesign and telephone-payment process, supported by the actual provider documentation. The goal is a payment arrangement the business can explain and maintain: fewer unnecessary places handling account data, clear operating responsibilities, and evidence tied to the services and configurations in use. Outsourcing is most useful when those remaining duties are visible and owned.