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