Регулярні платежі: що визначити до запуску підписки

Розділіть підписку, рахунок і платіж

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

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

Рахунки за програмне забезпечення

Визначте відповідальний сервіс

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

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

Платіжні вебхуки

Зафіксуйте календар і правила зміни суми

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

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

Обробляйте невизначений результат обережно

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

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

Перевірте скасування та повернення окремо

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

• Перевірте припинення підписки перед наступною датою оплати.
• Відтворіть повторну доставку повідомлення про успішний платіж.
• Перевірте зміну тарифу за наявності незавершеної спроби.
• Переконайтеся, що повернення не створює нову підписку автоматично.

Підготуйте звірку й підтримку

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

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

Джерела

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