Масові виплати: вимоги до погодження, статусів і звірки

Відокремте виплату від приймання платежу

Оплата покупцем і переказ отримувачу є різними фінансовими процесами. Наявність платіжного checkout не доводить підтримку масових виплат, а успішний вхідний платіж не означає, що відповідні кошти вже доступні для подальшої операції. Потрібно окремо підтвердити продукт провайдера, умови акаунта, можливі отримувачі та джерело фінансування.

У OrsunPay напрям виплат є запланованим. Його не слід використовувати як підтвердження того, що можна зараз завантажити список отримувачів і виконати масову відправку коштів. Ця сторінка допомагає підготувати вимоги для перевіреного зовнішнього сервісу або майбутньої реалізації. Конкретну доступність, процедури та обмеження потрібно погоджувати з відповідним постачальником і фахівцями вашої організації.

Заплановані виплати

Підготуйте реєстр зобов’язань

Для кожної позиції потрібні внутрішній номер, отримувач, підстава, сума, валюта та відповідальний працівник. Відокремте погоджену суму від чернетки. Якщо таблиця змінюється після погодження, система повинна показувати нову версію, а не непомітно підміняти попередній список. Такий контроль допомагає пояснити, чому конкретна позиція потрапила до пакета.

Наприклад, компанія готує щомісячні виплати партнерам за підтверджені роботи. Один партнер може мати кілька зобов’язань, але це не привід зливати їх без збереження деталізації. Якщо суми об’єднуються, залиште посилання на початкові позиції. Інакше підтримка не зможе відповісти, яка саме робота врахована, а яку ще перевіряють або оскаржують.

Звіти про платежі

Розділіть підготовку та погодження

Визначте ролі людей, які створюють список, перевіряють реквізити й дозволяють виконання. Для критичних змін, зокрема заміни отримувача, потрібен окремий зрозумілий порядок перевірки. Не використовуйте спільний акаунт, у якому неможливо встановити автора дії. Рівень контролю має відповідати процесам компанії та можливостям фактично обраного сервісу.

Погодження повинно стосуватися конкретної версії пакета й підсумкової суми. Якщо після нього додано новий рядок, старе погодження не має автоматично охоплювати зміну. Збережіть автора, час і підставу рішення. Не додавайте в робочі журнали надлишкові персональні чи банківські дані; забезпечте доступ лише тим працівникам, яким вони потрібні для виконання визначеної ролі.

Моделюйте статус кожної позиції

Один пакет може містити успішні, відхилені та ще незавершені позиції. Загальний статус «відправлено» не пояснює результат кожного отримувача. Для кожного рядка потрібні ідентифікатор зовнішньої операції, стан, час останнього оновлення та причина помилки, якщо її дозволено зберігати. Повторна обробка має стосуватися конкретної незавершеної дії, а не всього пакета навмання.

Документація Stripe про платежі та вебхуки корисна як приклад асинхронної взаємодії, але не підтверджує доступність виплат у вашій конфігурації. Вибраний сервіс може мати власні протоколи й статуси. Перевіряйте саме їх. Повернення відповіді на запит, прийняття до обробки та остаточне виконання потрібно розрізняти в інтерфейсі й внутрішніх інструкціях.

Передбачте помилки без повторного переказу

Тайм-аут не доводить, що операція не відбулася. Перед повторенням перевірте існуючий ідентифікатор та доступний авторитетний статус. Якщо реквізити виправлено, зафіксуйте, що попередня спроба закрита або перевірена відповідно до правил сервісу. Не видаляйте її історію: вона потрібна для пояснення повтору й можливого розслідування.

• Перевірте пакет із одним неправильним рядком серед коректних позицій.
• Відтворіть втрату відповіді після прийняття запиту.
• Змініть реквізити після погодження та перевірте повторний контроль.
• Зіставте підсумок пакета із сумою всіх підтверджених результатів.

Узгодьте звірку та межі звітності

План звірки має пов’язувати початкове зобов’язання, операцію сервісу та фактичний результат у фінансовому обліку. Операційна таблиця не замінює бухгалтерські документи чи банківські дані. Домовтеся, хто розглядає розбіжності, як фіксуються виправлення та коли пакет вважається повністю закритим. Не обіцяйте строків без підтвердження постачальника.

Поточна звітність OrsunPay охоплює дані доступних платіжних операцій, зокрема кабінет і CSV, але це не готовий реєстр майбутніх масових виплат чи повний бухгалтерський журнал. Перед розробкою зберіть кілька реальних прикладів пакетів із винятками. Вони дадуть точніші вимоги до продукту, ніж абстрактне побажання «виплатити всім», і допоможуть оцінити необхідні контролі без непідтверджених обіцянок.

Джерела

• Stripe — Платежі
• Stripe — Вебхуки