AUT-0290· Фінанси
Контроль дозволу на списання SEPA Direct Debit
Дозвіл клієнта на банківське списання пов’язують із належним одержувачем платежу та контролюють його відкликання.
Чернетка · Оцінка потребує перевірки
01 / Проблема
Команда використовує старий або чужий дозвіл на списання й продовжує готувати платежі після повідомлення клієнта про відкликання.
02 / Результат
Клієнт і одержувач платежу мають простежуваний дозвіл, джерела його стану та перевірений маршрут припинення або нового підтвердження.
03 / Процес
ТригерПотрібно підтвердити дозвіл клієнта на списання SEPA Direct Debit або отримано повідомлення про його відкликання чи неактивність.
Пов’язати клієнта, одержувача платежу, акаунт провайдера й зовнішній ідентифікатор дозволу; мандат означає згоду на банківське списання.
Перевірити фактичну доступність схеми й погоджений маршрут отримання згоди; повні банківські реквізити та секрети не збирати в CRM.
Передати клієнта до дозволеної платіжної форми й отримати підтвердження прийнятого дозволу з джерелом; відправлене посилання не вважати згодою.
Звірити належного одержувача й обсяг дозволу; дозвіл іншого акаунта не переносити автоматично.
Фіксувати стан провайдера та повідомлення клієнта окремо; відсутність події провайдера не спростовує повідомлене відкликання.
Після повідомлення про відкликання заблокувати нові ініціації в керованому маршруті й передати припинення уповноваженому відповідальному; звірити результат у платіжному джерелі.
Вже подані платежі перевірити окремо; відкликання дозволу не означає автоматичного повернення коштів або скасування боргу.
Для наступних списань після скасування отримати новий належний дозвіл; зберегти попередню історію й не відновлювати старий стан за застарілою подією.
04 / Реалізація1 варіант
Приклад · Контроль дозволу за клієнтом і одержувачем
Клієнт повідомив про відкликання через банк, але провайдер ще показує active. Нові ініціації в керованому маршруті зупинили й передали запит відповідальному. Уже поданий платіж лишився на окремій перевірці. Для відновлення запросили новий дозвіл; старе повідомлення active не повернуло попередню згоду.
Спосіб реалізації
- Проєктна модель PlanFix: клієнт, одержувач, зовнішній ID дозволу, джерела станів, відкликання й перевірені дії; згоду та банківські дані приймає захищений платіжний провайдер.
Що потрібно для реалізації
- Є дозволений провайдер, схема та погоджений маршрут прийняття згоди.
- Визначено відповідального за відкликання, джерела станів і керовані маршрути ініціації списань.
- Є захищений маршрут згоди й підтвердження.
- Визначено всі керовані ініціації й маршрут відкликання.
Обмеження
- Не є універсальною моделлю всіх банківських списань; SEPA Core та інші схеми перевіряють окремо.
- Стан active у провайдера не доводить відсутності відкликання через банк, про яке провайдер ще не знає.
- Не створює платіж і не повертає кошти; чинність дозволу й результат конкретної оплати мають різні докази.
- Не гарантує припинення вже поданої операції та не закриває борг автоматично.
- Доступність Stripe, країни, тарифи й правила повідомлень перевіряють перед реалізацією; для України готову доступність не заявлено.
- Не зберігає повний IBAN, платіжні секрети або текстові копії захищених форм у CRM.
- Години попередні; юридична перевірка мандату, банківські платежі та зовнішні тарифи не включені.
- Не ігнорує повідомлення клієнта через запізнілий стан провайдера.
- Не називає відкликання поверненням уже списаних коштів.
Що потрібно уточнити (2)
- Чи потрібно отримувати підтвердження дозволу та зміни стану від провайдера?
Перевірте дозволений доступ, зовнішні ID і запізнілі події; стан провайдера зіставляють із повідомленням клієнта.
- Чи потрібно вести дозволи для кількох одержувачів платежу або акаунтів?
Погодьте відповідності клієнта й одержувача; дозвіл одного акаунта не клонують автоматично іншому.