Why Acquirer Due Diligence Extends Beyond an AOC
Payment-brand programmes place responsibilities on acquirers to oversee merchant compliance, while acquirers must also manage underwriting, fraud, operational and data-security risk. An Attestation of Compliance is therefore important evidence, but it may not answer every onboarding question. The exact review depends on your merchant level, payment-facilitator or service-provider role, geography, processing agreement and the acquirer's risk model.
The Acquirer Onboarding Review: What Gets Checked
During onboarding or periodic review, an acquirer may request a documentation pack, follow-up answers and supporting technical evidence. The list below is a preparation framework, not a universal acquirer checklist. Confirm the current payment-brand programme, your processing agreement and the acquirer's own instructions.
Stage 1: Documentation Pack Review
Stage 2: Technical Due Diligence
An acquirer may request questionnaires, test reports or additional evidence about the live environment. Some checks may be performed by the acquirer or a third party; others may be satisfied by your existing assessment evidence. Treat the examples below as readiness checks and confirm what your own acquirer requires:
| Check | Method | Evidence of readiness | Common failure |
|---|---|---|---|
| Transport security on payment endpoints | Configuration evidence or an authorised scan of in-scope endpoints | Supported protocols, certificates and cipher configuration meet your documented security policy and current risk assessment | A legacy endpoint is omitted from the inventory and retains an obsolete or unintended configuration |
| Certificate and domain management | Certificate inventory, ownership and renewal evidence | Payment domains and certificates have named owners, monitored expiry and a tested renewal process | A payment-facing certificate or domain depends on an unowned manual renewal |
| External attack surface | Asset inventory reconciled with authorised external scans and exposure reviews | Internet-facing assets and services are known, authorised, hardened and included in testing | An administrative or data service is reachable externally but missing from the asset inventory |
| Account data in web traffic | Checkout-flow review and inspection of URLs, logs and analytics payloads | PAN and sensitive authentication data are excluded from URLs, referrers, telemetry and unauthorised logs | A tag, log or analytics integration receives account data outside the documented flow |
| Payment-page script security | Script inventory plus evidence for PCI DSS Requirements 6.4.3 and 11.6.1 | Payment-page scripts are authorised, integrity is justified and monitored, and unauthorised changes can be detected | The team cannot explain why a script is present or how tampering would be detected |
| SCA and 3-D Secure readiness, where relevant | Documented flow tests against applicable regional, scheme and contractual requirements | Authentication flows, exemptions and failure handling match the markets and agreements in scope | A regional assumption is treated as a global rule or fallback behaviour is untested |
PayFac-Specific Requirements
Payment facilitators can face additional review because they onboard and support sub-merchants within an acquirer and payment-brand programme. Responsibilities vary by programme and contract, so the PayFac should be able to show how it performs oversight and how responsibilities are allocated:
- Sub-merchant onboarding controls: Can the PayFac show a documented, risk-based onboarding process aligned with its acquirer agreement and programme obligations?
- Sub-merchant monitoring programme: Can the PayFac demonstrate how it monitors relevant risk indicators, investigates exceptions and escalates issues?
- Breach-notification flow: Do contracts and procedures route suspected compromises to the right parties within the deadlines that actually apply?
- Responsibility matrix: Is responsibility for PCI DSS requirements and supporting evidence clear across the PayFac, sub-merchant, TPSPs and acquirer?
- Validation-status oversight: Where the programme requires it, can the PayFac track the appropriate validation documents, dates, exceptions and follow-up actions?
Ongoing Monitoring: What Triggers an Acquirer Deep-Dive
Readiness does not end at onboarding. Depending on the agreement and risk programme, events such as these may trigger questions, remediation actions, additional evidence requests or a change in processing conditions:
Build the Evidence Pack Before the Request Arrives
Your compliance, security and payment teams can assemble the following alongside the applicable PCI DSS validation documents. A QSA can review assessed controls, but your organisation still owns the accuracy, currency and contractual context of the submission:
| Deliverable | Why it helps | Evidence gap to avoid |
|---|---|---|
| Plain-language scope and controls summary | Lets reviewers understand the business model, payment flow, in-scope environment, validation route and open risks before reading detailed reports | The summary conflicts with the diagrams, AOC or responsibility matrix |
| Scoping justification and diagrams | Explains why systems and services are in or out of scope and where segmentation is relied upon | Diagrams are stale, exclusions are unexplained or a new payment flow is missing |
| TPSP and responsibility register | Connects each provider to its service, compliance evidence, responsibilities, owner and review date | Evidence has expired, shared responsibilities are unassigned or the provider list is incomplete |
| Findings and remediation evidence | Shows the status, accountable owner, target date and retest or closure evidence for material findings | A plan is presented as proof of closure, or unresolved findings are hidden rather than governed |
| Notification and escalation matrix | Maps incidents to the correct acquirer, processor, payment-brand, legal and regulatory contacts and deadlines | Generic contact labels are used without verified recipients, triggers or out-of-hours escalation |
Readiness principle: A control and its evidence are different things. If scope, ownership, testing or remediation cannot be demonstrated, the reviewer may need follow-up information before reaching a decision. Keep every assertion traceable to current evidence, and label open gaps honestly rather than implying certification.
Payment Architecture & Evidence Workspace
Turn this guidance into a structured decision
Open the relevant workspace tool to apply the article to your payment environment. Eligible membership access may be required; the tool page shows access before you begin.