Merchant Account Underwriting: Evidence, Exposure and the Review Process

Record the legal entity seeking the service, trading brands, websites, relevant ownership and authorized representative. Explain associated companies where they affect the operation. If the website names one operator, the application another and the payout account a third, provide the relationship and supporting explanation instead of leaving the reviewer to infer it.

The financial product also matters. A platform enabling third-party sellers may require information about those sellers and its own role. A merchant selling only its own products has a different relationship with customers. Adyen’s verification documentation ties requirements to country or region, entity type and financial products, and discusses the main legal entity and associated owners. That source concerns Adyen for Platforms and Issuing; it is not a universal direct-merchant checklist. [1]

Request the receiving provider’s current document requirements and secure submission process. Avoid collecting every conceivable identity document before establishing relevance. Keep a document index with the entity concerned, issue date, expiry where applicable and any unresolved mismatch. A clear explanation is more useful than a large unlabelled file bundle.

Explain the product or service, the paying customer, delivery timing, refund obligations and revenue model. Include subscriptions, advance payments, deposits, platform sellers and third-party beneficiaries. Trace who contracts with the customer, who collects the payment, who fulfils the promise and who receives the proceeds.

Distinguish processing requirements from distribution of funds. Acceptance of a customer’s card payment does not establish permission to pay any unrelated beneficiary or aggregate payments for other businesses. Ask the provider to assess the actual structure and the service you need.

For regulated or territory-limited activities, identify the relevant permissions and markets and record questions requiring specialist review. A registration number should not be treated as a substitute for confirming applicable scope. Published provider restrictions can be checked early: Stripe separates prohibited and restricted activities, including categories that require further information. Its classification is specific to its service and does not decide another acquirer’s appetite. [2]

An activity can be commercially attractive yet outside a particular route’s permitted scope. Conversely, an activity that may be considered can still require controls because payments precede fulfilment, volumes are concentrated or refunds could exceed the merchant’s available cash. A low anticipated fraud rate cannot resolve an unsupported activity or missing mandatory permission.

Present the timing of the customer promise. A downloadable product, a year of future access and a travel booking made months ahead do not leave the same outstanding obligations at payment time. Explain what happens if the merchant stops trading or a supplier fails after money has already been collected.

Shopify Payments describes reserve risk indicators including extended delivery periods, refund activity and volume surges. That is a published example of how exposure can influence controls, not a formula applied by every underwriter. [3] Ask which proposed conditions address which concern, who can review them and what evidence would support a change. Keep these questions separate from negotiation of an ordinary processing rate.

For every important question, identify the evidence that answers it and what remains outstanding. A simple register can show the item, the entity it concerns, its date and the next person who needs to act. Distinguish information you have declared from information someone has checked independently.

The table below starts with the reviewer’s question. This is more useful than collecting documents without knowing why they are needed. A company certificate can identify the registered entity; it cannot establish that every product on the website may be sold in every advertised country.

Keep the register current when the business changes. If you add a marketplace, change the operating company or enter another customer market, identify which earlier findings need to be revisited. A document may still be valid while no longer answering the question raised by the new arrangement.

State the period, currency and source for historical volume, transaction counts, refunds and disputes. Use compatible periods wherever possible and define each measure. A forecast is useful when clearly labelled, particularly for a pre-launch merchant; it should not be presented as an actual processing statement.

Check internal consistency before submitting. For a fictional business projecting $60,000 monthly volume from 2,000 transactions, the implied average ticket is $30. If the stated average ticket is $100, explain the difference or correct the forecast. If 40% of expected sales are in a particular customer market, show how that fits the total rather than supplying country estimates that add up to more than the business forecast.

Discuss cash capacity alongside sales. Identify delivery costs, the timing of supplier payments and how refunds will be funded while reserves or settlement delays restrict access to receipts. These calculations help explain operational readiness. They do not produce an approval probability or establish that a specific reserve should be reduced.

A reviewer should be able to connect the application to the actual checkout experience: what is sold, the price, relevant terms, delivery, cancellation, refunds and support. Explain staging environments and planned features honestly. If the final product is not yet live, ask what can be assessed now and what must be checked before activation.

Technical readiness also needs defined responsibility. Establish which party hosts checkout, handles payment data, processes notifications, reconciles payouts and responds to incidents. Outsourcing does not remove every merchant obligation. PCI SSC specifically retains responsibility for checking service-provider compliance and understanding shared responsibilities; validation requirements should be confirmed with the applicable compliance-accepting entity. [4]

Test the permitted transaction lifecycle, not only a successful charge. Include failure, authentication where relevant, refund, duplicate notification and reconciliation. Technical success is evidence about the test performed, not approval of the business’s legal scope. Keep the test record separate from the underwriting decision so one is not used as a substitute for the other.

Separate an information request, preliminary commercial indication, conditional acceptance and final activation. A sales discussion may identify a possible route before authorized reviewers have completed the evidence checks. Ask which conditions remain and which party has authority to clear them.

For each follow-up, record the question, requested evidence, responsible person and date supplied. If an item cannot be produced, state why and ask whether an alternative is acceptable. Do not submit a substitute as though it were the original document. Resolve contradictions directly, including changes to the operator, ownership, product or bank details.

A useful condition is specific enough to assess. “Further compliance checks” may be an accurate interim status, but the merchant still needs an explanation of the next action and communication channel. Timelines can depend on external verification and partner decisions. Treat an estimated review range as an estimate, not a guaranteed approval date, and avoid irreversible launch commitments until the actual authorization and operating conditions are clear.