PCI validation and merchant eligibility answer different questions

Card acceptance defines a PCI merchant; it does not decide eligibility

PCI SSC defines a merchant for PCI DSS by its acceptance of participating payment brands' cards for goods or services. That definition describes the entity's card-acceptance role. It does not say that every entity meeting the definition is acceptable to every payment provider, nor does it decide whether a particular questionnaire is the correct one.

Keep that distinction when reading a security request inside an onboarding conversation. A document headed with PCI terminology may concern payment security, while a separate message asks about products, business activity or countries. Receiving both messages from the same company does not turn them into one decision. Classify each request by what it asks you to establish, not by the logo on the email.

Track the security request through its own recipient

Start with the actual request. Record the exact document named, who requested it, the business or payment setup it refers to, the version or date requested if stated, and where the requester says to submit it. Ask that recipient to clarify a missing document requirement. This comparison does not select a Self-Assessment Questionnaire or interpret PCI DSS requirements.

Then distinguish preparation, submission and the recipient's response. A completed file on your computer is not a submission receipt. A receipt is not a statement that the recipient accepted the evidence as satisfying its request. If the reply identifies a remaining condition, preserve that condition and its owner. Do not describe form submission as certification.

Find the separate answer about the business and service

Eligibility evidence needs to identify the business activity the provider considered. Compare the catalog, legal entity, sales channels and geography you disclosed with the scope of the written reply. Record whether the reply is a request for more information, a conditional decision or a decision covering the service you intend to use. A security document containing the business name does not fill a gap in that reply.

Stripe illustrates why service scope matters. Its prohibited and restricted businesses policy separates prohibited activity from restricted businesses requiring further review; approval is specific to a service and may be modified or revoked. The policy also prohibits misleading business information and processing for undisclosed products. These are Stripe's rules, not a universal eligibility rule for research-only merchants or for your separate approved payment rail.

If the security request has been answered but the business decision remains open, record exactly that. If an eligibility reply exists but security evidence remains outstanding, retain both statuses. Neither document should silently inherit the other's date, scope or outcome.

Use the comparison to assign the next action

The finished table should show which requirement has an explicit response and which still lacks one. A missing recipient requires a routing question. A missing scope requires clarification of what the reply covers. A stated outstanding condition requires an owner and the date from the request, rather than a blanket label that the account is approved.

For a Prism processing consultation, summarize the two requests, what each response actually says and the unresolved question. The processing consultation page explains how Prism can help organize an accurate business description and provider questions; scope, responsibilities, fees and terms are agreed before work. Prism's terms say reviews are informational and do not certify compliance or guarantee account approval. Keep full security files and identity documents out of the public inquiry.

Security versus eligibility responsibility table

Use the original requests and replies to complete the blank column. Keep security and eligibility statuses separate even if one provider sent both requests. A blank response means the issue remains unresolved; it does not mean approval. Use non-sensitive document references, not attached security or identity files.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.