Documents Needed for PSP Approval: What Merchant Evidence Actually Proves A merchant document has almost no value merely because it exists. Its value comes from the question it helps answer. A certificate of incorporation can help establish that a legal entity exists. It does not establish who ultimately controls that company, whether its website describes the same business that applied for payments, whether it can fulfil what it sells, whether previous processing produced excessive disputes, or whether the bank account designated for settlement belongs to the expected entity. This is why asking for “the list of documents needed for PSP approval” can produce a misleading answer. There is no single packet that proves everything a payment service provider, acquirer, bank, risk team, or compliance team may need to understand about every merchant. Instead, think of merchant documentation as an evidence map: Merchant claim → question to verify → evidence → consistency check → underwriting decision That framing explains both why certain documents may be requested and why another merchant applying to the same provider can receive a different request.
Visa's current Acceptance Risk Standards require acquirers to maintain risk-based merchant onboarding processes. The standards describe merchant underwriting as including areas such as business activity, creditworthiness, business location, previous processing history, identity, ownership, registration, and additional information for ecommerce merchants. The practical lesson for merchants is straightforward: Do not organize your onboarding package around document names. Organize it around the claims your business needs to substantiate.
Why there is no universal PSP document list PSP onboarding is not simply an exercise in confirming that a company has been incorporated. The evidence required can depend on factors including: * Legal structure * ownership structure * merchant country * acquiring country * business model * products or services * website * transaction model * expected volume * processing history * fulfilment model * suppliers * settlement arrangements * licenses or regulatory status * provider and acquirer risk policies Visa's current framework explicitly requires risk-based onboarding rather than treating all merchants identically. It also distinguishes merchant categories and circumstances that can warrant different levels of underwriting. Mastercard likewise describes merchant digital onboarding as involving different verification capabilities, including KYC, KYB, business-document verification, identity checks and other controls used by acquiring partners. That is why: “What documents does a PSP require?” is less useful than: “What does this PSP still need to establish about this merchant?”
1. Company evidence: does the business legally exist? The first evidence category usually concerns the legal entity itself. Possible evidence can include, depending on jurisdiction and provider: * Certificate of incorporation * Certificate of registration * Company registry extract * Articles or formation documents * Business license * Tax registration information * Other official company records These documents can help establish facts such as: * Legal entity name * registration number * incorporation jurisdiction * registration status * business address * directors or officers where shown * legal form Visa's current acquirer standards specifically contemplate business-license or registration information as part of merchant verification. But company evidence has a limit. A registration certificate can prove: “XYZ Commerce Ltd exists.” It does not necessarily prove: “XYZ Commerce Ltd owns this website, sells these products, controls this bank account, has these shareholders, and can fulfil these orders.” Those are separate questions.
Information is not always the same as supporting evidence An application might ask: Company name: XYZ Commerce Ltd That is information supplied by the merchant. A registry extract may independently support that claim. The distinction matters because merchant onboarding frequently involves both: Merchant-declared information What the merchant tells the provider. and: Verification evidence Information or documents used to corroborate what the merchant declared. A merchant can therefore complete every field in an application and still receive document requests. The missing issue may not be information. It may be verification.
2. Ownership and control evidence: who is actually behind the company? A company can be legally registered without making its ultimate ownership immediately obvious. That becomes especially relevant when the structure contains: * Parent companies * holding companies * subsidiaries * nominee arrangements * several shareholder layers * entities in multiple jurisdictions Possible evidence may include: * Shareholder registers * ownership charts * capitalization records * corporate registry records * director information * beneficial-owner declarations * identity documents where applicable The Financial Action Task Force emphasizes the importance of adequate, accurate, and up-to-date beneficial-ownership information and distinguishes legal ownership from the natural persons who ultimately own or control a legal person. Visa's current standards similarly require acquirer KYC/KYB processes to collect and verify principal/director information and ownership information, subject to applicable law. The deeper mechanics of beneficial ownership, UBO identification and personal identity verification belong in dedicated KYC & KYB content. For merchant onboarding, the key principle is simpler: The reviewer needs to understand who owns and controls the entity that will receive payment-processing services.
Company evidence and ownership evidence are not the same thing This distinction causes unnecessary confusion. A merchant sends: Certificate of incorporation and asks: “Why do you still need shareholder information? The company is already verified.” But two different questions are being answered. Company document Helps establish: What legal entity exists? Ownership evidence Helps establish: Who ultimately owns or controls it? A document resolving the first question does not automatically resolve the second.
3. Business evidence: does the application match a real operating business? A payment provider is not evaluating the legal entity in isolation. It also needs to understand what the merchant actually does. Evidence can include: * Website * Product catalog * Pricing * Customer-facing terms * Refund policy * cancellation policy * delivery information * sales invoices * customer contracts * business plan where relevant * product descriptions Visa's current acquirer standards describe business-activity review as including the merchant's business plan, website URLs where applicable, goods or services offered, delivery methods, return policies, and business history. For ecommerce merchants, Visa also calls for additional verification relating to URLs used to promote the business, sell products, and accept payments.
The underlying question is: Does the customer-facing business correspond to the merchant that is applying for payment acceptance?
A website is evidence, not merely a marketing asset During payment onboarding, the website can tell a reviewer things that incorporation documents cannot. For example: * What is actually being sold? * What does it cost? * Is the customer buying once or subscribing? * When is delivery expected? * What happens if the customer requests a refund? * Which entity appears to operate the business? * How does the customer contact the merchant? A beautifully designed website does not guarantee approval. But a website that materially contradicts the application can create questions that another corporate document will not solve.
4. Payment-history evidence: what has happened when this merchant processed before? An established merchant may be asked for previous payment-processing information. Possible evidence can include: * Processor statements * Acquirer statements * Transaction summaries * Processing-volume reports * Refund reports * Dispute or chargeback reports * Historical payment-performance information Visa's current underwriting framework identifies prior merchant accounts and processing history among the information that can form part of merchant review. This evidence can help answer questions such as: * How much has the merchant processed? * How many payments does that represent? * What is the typical transaction value? * How quickly has volume grown? * What refund activity exists? * What dispute activity exists? * What markets are involved? * How does historical activity compare with the new application? That is very different from a bank statement.
Processing statements versus bank statements These documents are often treated as substitutes when they are not. Processing statement May help establish: * Payment volume * transaction count * refunds * disputes * processing history * previous provider relationship Bank statement May help establish different facts, potentially including: * Account ownership * banking relationship * account details * balances or cash activity where relevant to the review A bank statement showing deposits does not necessarily answer: What was the merchant's dispute rate? A processing statement does not necessarily answer: Does the proposed settlement bank account belong to the applicant? Use the document that answers the question.
What if the merchant has never processed payments before? A new merchant cannot provide processing history that does not exist. That does not mean it should manufacture an equivalent. It means the reviewer has to assess the business using other available evidence. Depending on the circumstances, that could involve: * Existing commercial history * Sales history * customer contracts * financial information * fulfilment capability * supplier relationships * funding * realistic forecasts * operational capacity The correct response to: “Please provide six months of processing history” when none exists is not to create it. It is to explain clearly: “We are a new-to-payments merchant and do not have prior processing history. What evidence would help you assess the underlying question instead?” The dedicated Processing History Requirements article should address that situation in depth.
5. Supply evidence: can the merchant obtain what it sells? For merchants selling physical goods—or other businesses dependent on third-party supply—the reviewer may need evidence that the merchant has credible access to the inventory or service capacity it represents to customers. Possible evidence can include: * Supplier agreement * Distributor agreement * Manufacturer relationship * Supplier invoices * Purchase orders * Inventory information * Purchase history The purpose is not necessarily: “Show us a supplier contract because PSPs like supplier contracts.” The purpose may be: “Help us understand whether this merchant has a credible supply chain for the products it is taking payment for.” That distinction matters.
A supplier contract is not universally required Some merchants: * Manufacture their own products * own their inventory * sell digital products * provide services directly * use multiple spot suppliers * operate another legitimate sourcing model For those merchants, a standard long-term supplier agreement may not even exist. The correct evidence depends on the business. The dedicated Supplier Agreement Requirements article should explain how supply credibility can be demonstrated under different models.
6. Fulfilment evidence: can the merchant deliver after receiving payment? Supply and fulfilment are closely related, but they answer different questions. Supply evidence asks: Can the merchant obtain the product? Fulfilment evidence asks: Can the merchant actually deliver what the customer paid for? Possible fulfilment evidence might include: * Shipment records * tracking information * delivery confirmations * warehouse records * digital-delivery logs * account-provisioning records * service-completion evidence * booking records Visa's underwriting framework expressly includes delivery methods and the merchant's ability to fulfil goods or services among business-activity considerations. This becomes particularly relevant when payment precedes fulfilment. The larger the gap between: customer payment and: merchant performance the more important it can become to understand how the merchant actually delivers. That does not mean long fulfilment automatically prevents approval. It means the evidence question changes.
Supply evidence versus fulfilment evidence A merchant sends a supplier invoice showing: 1,000 units purchased. That can help support inventory access. It does not prove: 950 customer orders were delivered successfully. Likewise, delivery tracking can show completed fulfilment without necessarily proving the long-term stability of the supply relationship. These evidence types complement one another. They are not the same.
7. Financial evidence: can the merchant support its payment obligations? Depending on the merchant, business model, exposure and underwriting arrangement, a reviewer may also consider financial information. Potential evidence can include: * Financial statements * management accounts * balance-sheet information * cash information * bank records * funding documentation * credit information Visa's current merchant-underwriting guidance explicitly includes credit history, financial statements, performance, debts, and public records among the information acquirers can use to assess merchant creditworthiness. Why might that matter to payment processing? Because a merchant can create financial obligations after a successful transaction. Examples include: * Refunds * disputes * advance sales * delayed fulfilment * cancellations * future service commitments Financial evidence should therefore be understood in relation to the exposure being evaluated. Not every merchant should assume it will be asked for the same financial package.
8. Settlement and bank evidence: where should merchant funds go? A provider may need to establish the destination and ownership of the account used for settlement. Potential evidence can include: * Bank statement * bank letter * account confirmation * other bank-account ownership evidence The key questions may include: * What is the beneficiary account? * Who owns it? * Does that owner match the merchant? * If it belongs to another group company, what is the relationship? * Is the settlement arrangement supported?
This distinction is useful beyond one provider: Settlement evidence proves something different from company-registration evidence.
9. Licensing and regulatory evidence: is the activity permitted? Some businesses operate in sectors where licenses, registrations, authorizations or other regulatory evidence can become relevant. Examples vary heavily by: * Jurisdiction * product * service * payment flow * customer type Do not assume that a merchant license in one country resolves regulatory questions everywhere the business operates. Similarly, do not assume that every PSP request for commercial evidence originates in legislation. A requirement can arise from: * Law * regulation * card-network rules * payment-method rules * acquirer policy * PSP policy * underwriting policy These should not be conflated. Visa's current standards themselves distinguish applicable laws and regulations, Visa rules and acquirer risk policies within the onboarding framework.
10. Why one document often creates another request Merchant onboarding can feel circular: 1. Submit document. 2. Reviewer asks for another. 3. Submit second document. 4. Another question appears. Sometimes this is unnecessary duplication. But sometimes the first document reveals information that legitimately changes the evidence map. For example: A merchant submits a bank statement. The bank account belongs to: XYZ Holdings Ltd while the merchant application is: XYZ Commerce Ltd The bank statement has answered one question and created another: What is the relationship between XYZ Holdings and XYZ Commerce, and why should merchant settlement be directed there? The second request is not necessarily asking for more evidence of the bank account. It may be asking for evidence of the relationship between entities.
Document consistency matters as much as document completeness A merchant can submit every requested file and still leave the reviewer with unresolved questions. Typical inconsistencies can include: * Legal entity names differ * trading name is used where legal name was requested * address differs * shareholder information is outdated * ownership percentages do not reconcile * website names another entity * settlement account belongs to another company * supplier contract belongs to an affiliate * processing statements belong to another legal entity * forecast volume contradicts current business scale * products described in the application differ from the website FATF's beneficial-ownership guidance emphasizes adequacy, accuracy, verification and keeping ownership information up to date; it also discusses discrepancies between information sources as a meaningful verification issue. The operational lesson for merchants: Review the evidence package horizontally, not document by document. Ask whether all the documents tell the same business story.
Currentness matters A document may once have been correct and still be unsuitable for a current review. Examples: * Ownership changed * director changed * address changed * bank account changed * license expired * supplier relationship ended * processing history is too old for the requested period Do not assume that because a document was accepted in a previous PSP application it will automatically answer today's question. Use current information where requested, and verify the provider's specific age requirements rather than relying on a universal rule.
More documents are not necessarily better One of the least useful onboarding strategies is sending an enormous folder and hoping the reviewer finds the answer. More evidence can create: * Duplicate versions * conflicting dates * obsolete ownership data * different company names * unnecessary personal data * uncertainty over which document is authoritative A stronger package is question-oriented. For example: Question Who owns the applicant? Primary evidence Current ownership chart. Supporting evidence Current shareholder or registry information. Explanation Brief note describing any holding-company layers. That is easier to review than: “Shareholders.zip — 74 files.”
The PSP Document Evidence Map The following framework is not a universal submission list. It is a way to organize the evidence a merchant may need depending on its provider, acquirer, jurisdiction, business model and risk profile. Evidence category Example evidence Question it may help answer Common mismatch Why additional evidence may arise Company Registry extract, incorporation record Does the entity legally exist? Legal/trading name mismatch Entity changed or registry data is incomplete Ownership Ownership chart, shareholder record Who owns or controls it? Missing holding-company layer Complex or changed ownership People Director/owner information Who manages or ultimately controls the merchant? Person does not match corporate records Identity/control requires verification Website/business Website, terms, product information What does the merchant actually sell? Application differs from customer-facing activity Business model needs clarification Processing Processor statements How has payment activity behaved? Wrong entity or period History is incomplete or activity changed Supply Supplier contract, invoices, purchase orders Can the merchant obtain what it sells? Supplier contracts another entity Supply model or capacity is unclear Fulfilment Tracking, delivery logs, service records Can customers receive what they pay for? Evidence covers only a few unusual orders Delivery model or future exposure needs clarification Financial Financial statements, bank information Can the merchant support relevant obligations?
Records cover wrong entity or period Exposure exceeds what available evidence explains Settlement Bank ownership evidence Where should merchant funds be paid? Bank account owner differs from applicant Group-company relationship needs evidence Licensing Applicable license or registration Is regulated activity appropriately authorized? License covers different activity/entity/market Jurisdiction or business activity differs The point of the map is not: collect everything. It is: know what each document is supposed to establish.
A stronger way to prepare documents for PSP approval Before submitting an onboarding package, run five checks. 1. Identify the exact applicant Write down: * Legal entity name * trading name * registration number * registered address * operating address * website domains * settlement-account holder If these are not identical, document the relationships.
2. Map ownership before the PSP has to reconstruct it If ownership is straightforward: show it simply. If ownership is layered: show the chain from applicant to the relevant ultimate owners and controllers. Do not make the reviewer infer ownership from ten unrelated corporate documents.
3. Match each piece of evidence to a question Instead of maintaining a folder called: PSP Documents use categories such as: Entity Ownership Business Processing Supply Fulfilment Financial Settlement Licensing The file structure itself can become an onboarding control.
4. Run a consistency review Compare: * Company name * addresses * directors * shareholders * bank-account holder * website * supplier entity * processing entity * product description * countries * forecast volume Resolve inconsistencies before submission or explain legitimate differences clearly.
5. Answer the unresolved question—not merely the wording of the request If the PSP asks: “Please send proof of fulfilment.” do not immediately send every logistics file the company has. Ask internally: What evidence most directly demonstrates that our customers actually receive the product or service they pay for? If the request remains unclear, ask the reviewer which verification or underwriting question needs to be resolved. That can reduce unnecessary evidence cycles far more effectively than sending additional files indiscriminately.
What merchants should not do Reducing onboarding friction does not mean manipulating the evidence. Never: * Alter processing statements * change corporate records * hide ownership * omit material business activity * fabricate supplier relationships * manufacture fulfilment records * use another legal entity to conceal the actual merchant * misrepresent processing history * submit outdated evidence as though it were current A document package is valuable precisely because it gives the reviewer a reliable basis for making a decision. Destroying that reliability defeats its purpose.
Its publicly accessible Business Profile guidance says merchants provide business information and payout information, after which the system displays verification documents based on those inputs. The page itself was last updated in 2020, so the live Merchant Account should be treated as the source of truth for current merchant-specific document requests.
For a merchant applying today, the practical approach is therefore:
The question behind the document When a PSP requests another file, the most productive merchant response is not always: “Why do you need more paperwork?” Try: “What specific verification or underwriting question does this document need to resolve?” That question changes the entire onboarding exercise. It turns: documents into: evidence. And it makes several seemingly repetitive requests much easier to understand. Corporate records establish the company. Ownership records establish who controls it. The website helps establish commercial reality. Processing statements establish payment history. Supplier evidence supports supply credibility. Fulfilment records support delivery capability. Financial information can support an assessment of financial resilience. Bank evidence supports settlement. Licenses can support regulated eligibility. No single document does all of those jobs. That is why there is no universal “PSP approval packet.” The merchant's objective should not be to submit the largest document package. It should be to submit the smallest complete, current and internally consistent body of evidence that resolves the questions relevant to the merchant being underwritten. That is what makes documentation useful. The exact evidence requested depends on the merchant, provider, acquirer, jurisdiction, business model, and risk profile.
This article provides general information and does not constitute legal, regulatory, financial, tax, or compliance advice. Merchant onboarding and underwriting requirements vary by jurisdiction, provider, acquirer, business model, and individual circumstances. Merchants should confirm applicable requirements with qualified advisers and the relevant payment providers, acquirers, banks, regulators, and authorities. 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂
This draft follows the uploaded brief’s core framing: PSP documentation should be explained as an evidence map, not as one universal checklist.
SEO & EDITORIAL NOTES SEO title: Documents Needed for PSP Approval: Merchant Evidence Guide Meta title: Documents Needed for PSP Approval | Merchant Guide Meta description: Learn which documents a PSP may request during merchant onboarding, what company, ownership, processing, fulfilment, supplier, financial and bank evidence actually proves, and how to prepare a consistent application. Suggested slug: /documents-needed-for-psp-approval/ The article intentionally avoids a title such as “Complete PSP Document Checklist” because that would undermine the central thesis and create an unsupported implication of universality. The primary keyword appears directly in the H1 and early discussion, while the body naturally incorporates the important secondary concepts from the brief. Recommended internal links Use contextual links to Payment Onboarding Checklist when the article shifts from explanation to preparation; Processing History Requirements from the payment-history section; Proof of Fulfilment Requirements and Supplier Agreement Requirements from their respective evidence categories; and the KYC & KYB pillar from the ownership section. This keeps this article in its assigned territory—the overall evidence landscape—rather than cannibalizing the specialist pieces. Supporting visual: PSP Document Evidence Map The visual should be an evidence-flow diagram rather than a pile of document icons: MERCHANT CLAIM ↓ WHAT MUST BE ESTABLISHED? ↓ EVIDENCE CATEGORY ↓ EXAMPLE DOCUMENT ↓
CONSISTENT WITH OTHER EVIDENCE? ↓ QUESTION RESOLVED / ADDITIONAL EVIDENCE NEEDED Around the central flow, use nine evidence categories: Company · Ownership · Business · Processing · Supply · Fulfilment · Financial · Settlement · Licensing Recommended alt text: “PSP Document Evidence Map showing how company, ownership, business, processing history, supplier, fulfilment, financial, settlement and licensing evidence answers different merchant onboarding questions.” Sources and research references The strongest external authority for the underwriting logic is Visa's Acceptance Risk Standards, which currently requires risk-based acquirer onboarding and describes merchant review across creditworthiness, business activity, history, KYC/KYB, registration and ecommerce information. FATF's beneficial-ownership guidance provides the strongest conceptual support for treating ownership evidence as a distinct, accuracy- and verification-sensitive category rather than assuming company registration establishes ultimate ownership. Mastercard's current merchant-digital-onboarding materials independently support the role of KYC/KYB and official business-document verification in acquiring-partner onboarding.
Claims requiring legal/compliance/risk review Review any final statements about licensing requirements, beneficial-owner thresholds, mandatory identity documents, sanctions screening, reserves, financial-statement requirements, processing-history periods, or evidence age limits before publication. The current draft intentionally avoids universal numerical thresholds.
Editorial differentiation This article should remain the cluster's evidence landscape. It should not become: * the preparation checklist—that belongs to Payment Onboarding Checklist; * the deep processing-statement guide—that belongs to Processing History Requirements; * the fulfilment article; * the supplier-contract article; * or the detailed beneficial-ownership guide. Its distinctive question is: What does each category of merchant evidence actually establish, and why can the evidence required differ from one merchant to another? That makes it materially more useful than a conventional SEO article consisting of “10 documents your payment processor will ask for.”
Not sure which payment solution fits?
Use the merchant matching prototype to understand the types of providers to evaluate.
Explore matching ↗