Prepare a high-risk merchant account application in two stages: a concise business brief to establish whether the provider can assess you, followed by a secure evidence pack only when the provider's identity, process and requirements are clear. A complete application cannot guarantee approval, but it can prevent avoidable delays and mismatched offers.
This checklist is for an established business seeking card or EUR bank processing in Europe. It separates the facts a sales desk needs from documents that belong in an agreed secure onboarding channel. It also gives you questions to ask the provider before paying for setup or committing payment volume.
Start with the payment problem you actually need solved
“High risk” is not a single acceptance category. A lawful adult business, a licensed betting operator and a supplements seller can have very different products, markets, delivery obligations and processing needs. Describe the actual activity, not just an industry label.
Write one sentence covering what is sold, to whom, where, when it is delivered, and whether payments repeat. For example: “We sell an allowed product category to adult customers in named EU markets, dispatch within three business days, and take one-off EUR payments.” This is a fictional structure, not a claim that a provider accepts the category.
If an earlier provider ended the relationship, explain the stated reason and what changed. Keep the notice and supporting evidence for underwriting. A new provider needs an accurate history; renaming the activity does not resolve the original issue.
The first-enquiry brief: facts that establish fit
The downloadable brief and review checklist below use the same core business questions as PayRequest's high-risk payments sales form.
| First-enquiry field | Give this information | Why it matters |
|---|---|---|
| Company and website | Actual trading name and live sales URL | Connects the request to the visible business |
| Sector and activity | Products, delivery model and relevant restrictions | An industry headline alone is insufficient |
| Company country | Where the contracting business is established | Distinct from the customer's location |
| Customer countries | Actual markets and approximate split if known | “Europe” may conceal important exclusions |
| Monthly payment volume | Actual recent volume; separate forecasts | Sets the scale without inventing history |
| Average and maximum ticket | Both values, not just an average | Reveals whether transaction limits fit |
| Payment route and frequency | Cards, bank transfer or both; one-off or recurring | Determines the required processing capability |
| Existing provider and blocker | Current position and reason for changing | Makes the review about a concrete problem |
Send business information in the initial form. Do not attach identity documents, card data or customer records. An optional explanation of licensing or unusual requirements can flag what a provider should review without exposing the documents themselves.
Build the evidence pack after the process is clear
The exact document list belongs to the provider. Stripe's high-risk merchant account guide describes possible requests for business licences, financial and bank statements, processing history and a business plan. These are examples of underwriting evidence, not a universal checklist or an indication that Stripe approves your activity.
Prepare an index so the provider can ask for the right evidence through an agreed secure channel:
- Company registration and ownership information, with the responsible legal representative identified.
- Licences or permissions relevant to the actual products and customer markets, where applicable.
- Recent processing statements when available, retaining the processor name, dates, currency, volume, refunds and dispute measures.
- Business bank and financial evidence requested for the contracting entity.
- Fulfilment evidence: delivery times, suppliers or service provision, cancellation terms and refund handling.
- A description of fraud controls, customer support and how disputes are reviewed.
Do not fabricate processing history. If trading is new, label projections as projections and explain the basis for them. When a document is unavailable, name the gap and ask what alternative evidence the provider will consider.
Make your website and your application tell the same story
Before review, check the website as a buyer would. Are product descriptions, total prices, recurring terms where relevant, fulfilment timing, contact information and refund or cancellation terms easy to find? Does the trading name match the application, or is the relationship between brand and company explained?
This is a consistency exercise, not a promise of acceptance. A polished policy page cannot make an unsupported product acceptable. Equally, a provider should not have to infer whether a displayed price is one-time or monthly.
For subscriptions, explain the agreement, renewal frequency and cancellation process. Ask whether the proposed route supports that precise recurring model. A one-off card or bank-transfer offer does not prove automatic renewals are included.
Ask the provider to answer these questions in writing
| Area | Evidence or answer to request |
|---|---|
| Identity and roles | Contracting legal entity, company details and who acts as broker, processor, acquirer or payout provider |
| Exact acceptance | Your products, merchant location, customer countries, ticket sizes and recurring model |
| Money flow | Who receives the customer's EUR, who owes the merchant payout and which reports connect the two |
| Fees and reserves | Full tariff, chargeable events, reserve cap and release rules, changes and termination conditions |
| Settlement | First payout, cadence, minimum, currency, conversion and any blockchain network |
| Operations | Refund/dispute handling, support route, technical documentation, testing and reconciliation |
Ask who appears on the customer's payment statement and whether the contract describes the same entity and activity you discussed. A friendly sales contact or a working demo is not evidence of every party's role in the eventual funds flow.
For the pricing discussion, use the high-risk processing fees and rolling reserve guide. Its worked comparison shows why the lowest headline percentage can require more working capital.
Check which “SEPA” or “crypto” service is being offered
The ECB's SEPA explanation distinguishes a credit transfer initiated by the payer from a direct debit initiated by the payee under a mandate. An offer labelled “SEPA processing” should name the actual method. Do not infer recurring collection or card-style dispute rules from the label alone.
For stablecoins, distinguish EUR pay-in followed by a stablecoin payout from a customer paying directly with a crypto wallet. Confirm the conversion and exact network. Circle's USDC risk disclosure also makes clear that third-party-market values can differ from one dollar; a USD-linked asset is not a guaranteed EUR amount.
Neither route should be described as universally risk-free. Ask the proposed provider about fraud handling, recall or return requests, compliance holds and reserve obligations for the exact arrangement.
A practical go / clarify / stop decision
Proceed to an individual review when the provider's identity and proposed role are clear, your actual activity can be assessed, and you have a defined route for sharing the required evidence. You are agreeing to a review, not assuming approval.
Clarify before committing when the fee base, reserve release, customer-country coverage, recurring capability or party responsible for payout remains vague. Add the unanswered item to the brief rather than treating silence as confirmation.
Stop the process if you are asked to misdescribe the business, use another merchant's identity or send payment credentials through an inappropriate channel. Keep the factual history and evaluate a legitimate alternative.
Send a focused sales enquiry
Use the prepared brief to complete PayRequest's sales review form. Include what is missing or uncertain; that makes the next conversation more useful than a generic “can you accept us?” message.
Submitting the form saves an enquiry for the PayRequest Sales Team to assess. It does not create a merchant processing account, confirm a partner integration, grant paid access or guarantee acceptance. A PayRequest subscription is not required to make the enquiry.
Editorial note: prepared by the PayRequest Team with AI assistance, including the illustrative cover. Official sources and the PayRequest enquiry fields were reviewed on 4 November 2026. The downloadable brief and review checklist are original preparation tools, not provider underwriting rules, legal approval or a tested acceptance score.
