Корисний пакет для онбордингу відповідає на три запитання: хто веде бізнес, як платять клієнти та які процеси має підтримувати платіжна команда. Зберіть ці відповіді до звернення до PSP.
Для форекс-брокерів та інших мерчантів мета — не надіслати найбільшу папку. Потрібно дати узгоджену картину юридичної особи, сайту, ринків і платіжного сценарію. Цей чекліст із шести пунктів допомагає підготуватися; конкретні вимоги до вашого бізнесу й ринків визначає обраний PSP.
1. Підготуйте узгоджений профіль бізнесу
Почніть з односторінкового брифу, зрозумілого людині поза компанією. Вкажіть операційну юридичну особу й сайт, опишіть продукт і момент списання коштів із клієнта. Відокремте поточні країни роботи від ринків, які лише плануєте.
- Вкажіть комерційний, комплаєнс- і технічний контакти та одного відповідального за заявку.
- Окремо перелічіть потрібні платіжні методи, валюти транзакцій і валюти розрахунків із мерчантом.
- Поясніть відмінності між брендом для клієнтів, стороною договору та власником запланованого розрахункового рахунку.
2. Звірте документи з даними заявки
Запитайте PSP про прийнятні документи для вашої країни й типу юридичної особи. Перевірте читабельність, чинність і відповідність заявці. Публічна довідка Stripe показує, чому один універсальний список документів не підходить для всіх країн.
Ведіть простий реєстр: запитаний документ, відповідальний, версія та статус подання. Фіксуйте розбіжності, а не підганяйте заявку під застарілий файл. Уточніть у спеціаліста спосіб передавання документів, що посвідчують особу: використовуйте погоджений захищений канал, а не загальний командний чат.
3. Пройдіть сайт шляхом нового клієнта
Перевіряйте живий сайт, а не лише внутрішню презентацію. Людина, яка розглядає заявку, має зрозуміти пропозицію й знайти підтримку без здогадок.
- Звірте дані компанії, опис продукту та формулювання про платежі.
- Зрозуміло опишіть ціни, комісії, валюти оплати й умови регулярних списань, якщо вони застосовуються.
- Зробіть доступними порядок повернення чи скасування та контактні канали.
- Поясніть частини клієнтського сценарію за авторизацією й погодьте спосіб доступу для перевірки.
4. Відокремте історію процесингу від прогнозів
Оберіть фіксований звітний період і зазначайте його біля кожного показника. Якщо платежів ще не було, прямо скажіть про це: прогноз корисний, але він не є фактичним рівнем успішних авторизацій.
| Що підготувати | Що включити | Чого уникати |
|---|---|---|
| Профіль трафіку | Ринки, методи, валюти й типовий розмір транзакції | Одного загального середнього, яке приховує структуру трафіку |
| Історія процесингу | Обсяги за конкретні дати й чітко визначені показники авторизацій, повернень і спорів | Відсотків без чисельника, знаменника та періоду |
| Прогноз | Припущення, ринки запуску й очікуваний діапазон | Подання цільового показника як досягнутого результату |
За можливості передавайте агреговані дані. Для комерційного аналізу не потрібні номери карток клієнтів чи коди автентифікації. PCI SSC забороняє зберігати чутливі дані автентифікації, зокрема CVV, після авторизації.
5. Підготуйте план інтеграції та операцій
Розподіліть відповідальність за платіжний сценарій: API-підключення — лише частина проєкту. Опишіть поведінку системи за успішного платежу, відхилення та невідомого результату.
- Визначте відповідальних за оплату, оновлення статусів і звірку операцій.
- Погодьте обробку повернень, дубльованих запитів і перерваних клієнтських сценаріїв.
- Зазначте події, які перевірятимете до запуску, та спосіб перевірки результатів.
- Зберіть запитання про графік розрахунків, валюти, комісії та контакти для ескалації; закріпіть відповіді у відповідній угоді.
6. Додайте до пакета реєстр відкритих запитань
Короткий журнал питань корисніший за ланцюжок суперечливих вкладень. Для кожного невирішеного пункту вкажіть відповідального та інформацію, потрібну для закриття.
| Запитання | Відповідальний | Наступне підтвердження |
|---|---|---|
| Яка юридична особа укладатиме договір? | Комерційний керівник | Підтверджені дані юридичної особи |
| Як статус платежу потрапить на платформу? | Технічний керівник | Погоджений потік подій і план тестування |
| Що ще потрібно надати? | Відповідальний за заявку | Актуальний список запитаного та погоджена наступна дія |
Перед відправленням перевірте, що бриф, сайт і файли не суперечать одне одному. Запитайте, від чого залежить наступне рішення. Повний пакет допомагає зробити перевірку зрозумілішою, але не є обіцянкою схвалення чи фіксованої дати запуску.
Джерела та матеріали для читання
- Stripe — прийнятні документи для перевірки за країнами: https://docs.stripe.com/acceptable-verification-documents
- PCI Security Standards Council — FAQ 1318 про зберігання платіжних даних: https://www.pcisecuritystandards.org/faqs/1318/
Публічні джерела перевірено 13 жовтня 2026 року. Приклади провайдерів пояснюють роботу з документами, а не означають, що певний провайдер прийме ваш бізнес.