A useful onboarding pack answers three questions: who operates the business, how customers pay, and what the payment team needs to support. Organize those answers before you request a PSP review.
For forex brokers and other merchants, the aim is not to send the largest folder. It is to give the reviewer a consistent picture of the operating entity, website, markets and payment flow. This six-part checklist is a preparation framework; your chosen PSP sets the actual requirements for your business and markets.
1. Write one consistent business profile
Start with a one-page brief that someone outside your company can understand. Name the operating entity and website, describe the product, and explain when a customer is charged. Separate the countries you serve today from the markets you are considering.
- Identify the commercial, compliance and technical contacts, with one person responsible for the submission.
- List requested payment methods, transaction currencies and settlement currencies separately.
- Explain any difference between the customer-facing brand, contracting entity and intended settlement account.
2. Check documents against the application
Ask the PSP for its accepted document list for your country and entity type. Check legibility, validity and consistency with the application. Stripe’s public verification reference illustrates why a single document checklist cannot be assumed to work in every country.
Keep a simple document register: requested item, owner, version and submission status. Record discrepancies instead of silently changing the application to match an outdated file. Ask the reviewer how identity documents should be delivered; use the agreed secure channel, not a general team chat.
3. Walk through the website as a new customer
Review the live site, not only an internal presentation. Someone following your application should be able to understand the offer and reach the support team without guessing.
- Check that the company identity, product description and payment wording are consistent.
- Make pricing, fees, billing currencies and any recurring-payment terms understandable where relevant.
- Make the applicable refund or cancellation process and contact routes easy to find.
- Explain login-only parts of the customer journey and arrange review access through the agreed process.
4. Separate processing history from forecasts
Use a fixed reporting period and name it on every figure. If you have not processed payments yet, say so: a forecast is useful, but it is not an observed approval rate.
| Prepare | Include | Avoid |
|---|---|---|
| Traffic profile | Markets, methods, currencies and typical transaction size | One global average that hides the traffic mix |
| Processing history | Dated volumes and clearly defined authorization, refund and dispute figures | Percentages without their numerator, denominator or period |
| Forecast | Assumptions, planned launch markets and an expected range | Presenting a target as achieved performance |
Share aggregated evidence where possible. A commercial review does not need customers’ card numbers or authentication codes. PCI SSC prohibits storing sensitive authentication data such as CVV after authorization.
5. Prepare the integration and operating plan
Assign owners for the payment flow rather than treating the API connection as the whole project. Describe what your application will do when a payment succeeds, is refused or has an unknown outcome.
- Identify who implements checkout, status updates and reconciliation.
- Agree how refunds, duplicate requests and interrupted customer journeys will be handled.
- Define which events will be tested before launch and how their results will be checked.
- List operational questions about settlement schedules, currencies, fees and escalation contacts; confirm the answers in the appropriate agreement.
6. Send an open-questions register with the pack
A short issue log is more useful than a chain of contradictory attachments. Give each unresolved item an owner and the evidence needed to close it.
| Question | Owner | Next evidence |
|---|---|---|
| Which entity will contract? | Commercial lead | Confirmed legal-entity details |
| How will a payment status reach the platform? | Technical lead | Agreed event flow and test plan |
| What remains outstanding? | Submission owner | Current requested-item list and agreed next action |
Before sending, check that the brief, website and supporting files tell the same story. Ask the reviewer what the next decision depends on. A complete pack supports a clearer review; it is not a promise of approval or a fixed launch date.
Sources and further reading
- Stripe — Acceptable verification documents by country: https://docs.stripe.com/acceptable-verification-documents
- PCI Security Standards Council — FAQ 1318 on storage of payment data: https://www.pcisecuritystandards.org/faqs/1318/
Public references checked on 13 October 2026. Provider examples illustrate documentation practices, not a statement that a particular provider accepts your business.