У магазині з підпискою платіжна логіка швидко ускладнюється. Разове замовлення просте; продовження — ні. Якщо ви розбираєтеся, як приймати криптовалюту на сайті підписки WooCommerce, то перше завдання — не платіжний шлюз. Це модель білінгу, а також вибір, чи підходять вам криптоплатежі для WooCommerce підписки.
Почніть із тих типів підписок, які ви справді продаєте. Цифрове членство з продовженням кожні 30 днів поводиться не так, як преміум-підтримка з річною оплатою, і не так, як коробка, яку можна призупинити, оновити або скасувати посеред циклу. Одному сайту може бути потрібен лише 1 шлях продовження. Іншому — 4, і це безпосередньо впливає на WooCommerce Subscriptions криптоплатежі.
1. Визначте, які саме сценарії підписок вам потрібно підтримувати
Перед тим як щось встановлювати, запишіть точні сценарії. Перша оплата. Продовження. Оновлення тарифу. Зниження тарифу. Ручне продовження після невдалої оплати. Ці 5 випадків покривають більшість магазинів підписок WooCommerce, і кожен із них змінює вимоги до криптоплатежів.
Разове оформлення легко уявити, бо клієнт платить один раз і йде. Регулярні платежі працюють інакше. Справжнє питання в тому, чи може ваш бізнес попросити клієнта діяти знову під час продовження, чи система має списувати оплату без участі клієнта щомісяця. Саме цей вибір визначає решту проєкту.
Поставте собі два практичні питання. Чи починається підписка лише після підтвердження першої оплати? Чи може користувач змінювати тариф посеред розрахункового періоду? Сайт із членством на 2 рівні може бути простим. Сервіс із 6 станами білінгу — ні.
2. Перевірте, чи може ваш плагін підписки працювати з обробкою криптоплатежів
WooCommerce Subscriptions дає вам логіку підписок, але не кожен сценарій криптоплатежів підходить до неї без проблем. Перевірте підтримку токенів платежів, хуків продовження, приміток до замовлень і оновлень статусу, перш ніж обіцяти щомісячну оплату. Якщо шлюз не може зберігати повторно використовуваний токен платежу, зазвичай вам знадобиться сценарій продовження, який ініціює сам клієнт.
Подивіться на логіку продовження простими словами. Що відбувається, коли настає дата продовження? Чи очікує плагін автоматичне списання, чи він чекає на ручне платіжне посилання? Деякі плагіни нормально працюють із відкладеним підтвердженням. Інші хочуть отримати завершену транзакцію, перш ніж позначити продовження як оплачене.
Якщо вашій команді потрібна технічна довідка, тримайте відкритими документацію для розробників, API криптоплатіжного шлюзу, поки ви моделюєте процес. Це допомагає, коли потрібно перевірити події webhook, callback-и статусу або точні назви полів, яких очікує ваш плагін підписок.
Не здогадуйтеся тут. Продовження, яке в гаманці виглядає як «оплачене», усе одно може бути невидимим у WooCommerce, якщо не надійшли примітка до замовлення, ID транзакції або оновлення статусу. Саме так і з’являються звернення в підтримку.
3. Визначте, як саме мають працювати повторні криптосписання
Є 3 практичні моделі для регулярного криптобілінгу. Перша — продовження, ініційоване клієнтом: ви надсилаєте рахунок на продовження, а клієнт оплачує його в кожному циклі. Друга — рахунок на продовження з фіксованим вікном оплати, зазвичай від 24 до 72 годин. Третя — стабільний сценарій розрахунку, коли криптовалюта приймається на касі, але конвертується до оновлення обліку підписки.
Перша модель найпростіша. Але вона потребує найбільше дій від клієнта. Друга дає клієнту трохи більше часу, що допомагає, коли перекази затримуються або комісії різко зростають. Третя може бути зручнішою для бухгалтерії, але вона залежить від вашого процесора платежів і внутрішньої політики.
Для багатьох магазинів справжня проблема — не криптовалюта сама по собі. А час. Платіж за підписку, який надійшов на 6 годин пізніше, може бути нормальним для сайту з курсами. Для хостингового тарифу така затримка може призвести до призупинення послуги. Вирішіть це до запуску, а не після першого пропущеного продовження.
Також вам може стати у пригоді криптоплатіжний шлюз для підписок SaaS, якщо ваша модель ціноутворення ближча до програмного забезпечення, ніж до роздрібної торгівлі. Там виникають ті самі білінгові питання, тільки з більшою кількістю користувачів і дат продовження.
4. Спроєктуйте шлях клієнта для першої оплати та майбутніх продовжень
Опишіть шлях клієнта так, ніби ви самі є підписником. Під час реєстрації клієнт бачить ціну тарифу, адресу гаманця або платіжний запит, мережу та дедлайн. Після оплати клієнт має побачити одну чітку сторінку підтвердження і одне повідомлення на email. Не 3 повідомлення. Достатньо одного.
Для майбутніх продовжень потрібні інші формулювання. Лист про продовження має пояснювати, що потрібно оплатити, до якої дати і що станеться, якщо платіж запізниться. Якщо клієнт повинен щомісяця надсилати новий криптоплатіж вручну, скажіть про це прямо. Приховані правила створюють проблеми для підтримки.
Корисний підхід — розділяти в тексті «першу оплату» і «оплату продовження». Це здається дрібницею, але знімає плутанину. Клієнти часто вважають, що підписка продовжується автоматично, бо саме так працюють карткові платежі. Криптопідписки не завжди працюють так само, і вдавати, що це так, означає лише отримати суперечки пізніше.
Для ширших рекомендацій щодо налаштування магазину приймайте криптоплатежі у WordPress допоможе саме з касовим рівнем. Тут корисне не стільки просування шлюзу, скільки звичка робити платіжні інструкції болісно зрозумілими.
5. Налаштуйте статуси замовлень і правила продовження для підписок, оплачених криптовалютою
Кожна підписка, оплачена криптовалютою, потребує правил зміни статусів. Очікує, підтверджено, прострочено, частково оплачено і пропущено — це не одне й те саме. Якщо платіж у статусі очікування вже 12 хвилин, це може бути нормально. Якщо він очікує 2 дні, потрібна інша реакція.
Визначте, що означає «активна». Підписка може ставати активною після підтвердження оплати або вже тоді, коли платіж відправлено в мережу й очікує підтвердження. Це не одне й те саме. Перший варіант обережніший. Другий швидший, але несе більше ризику через невизначеність мережі.
Частково оплачені продовження — це складно. Якщо клієнт надсилає менше за суму продовження, ви залишаєте підписку призупиненою, позначаєте її як прострочену чи створюєте завдання для підтримки? Оберіть одне правило і застосовуйте його щоразу. Система підписок працює найкраще, коли однаковий статус завжди запускає одну й ту саму дію.
Щодо політики ризиків платежів, кращі практики безпеки криптоплатіжного шлюзу корисні, тому що логіка статусів продовження часто перетинається з логікою безпеки. Поганий webhook або підроблене оновлення статусу можуть нашкодити не менше, ніж пропущений платіж.
6. Обробіть невдалі продовження, прострочені рахунки та пільгові періоди
Невдалі продовження — це нормально. Заплануйте їх заздалегідь. Клієнт може пропустити лист, надіслати кошти в неправильну мережу або заплатити після завершення дії рахунку. Кожен із цих випадків потребує іншої реакції, і жоден не слід закривати розмитим повідомленням «будь ласка, зверніться в підтримку».
Налаштуйте ритм повторних нагадувань. Багато магазинів використовують нагадування в день 0, друге нагадування перед закінченням строку та фінальне повідомлення після пільгового періоду. Якщо клієнт платить із запізненням, вирішіть, чи відновлюється підписка одразу, чи лише після ручної перевірки. Це одне рішення впливає на навантаження підтримки на місяці вперед.
Прострочені рахунки теж потребують чітких правил. Якщо платіжне посилання закінчує дію через 15 хвилин або 1 годину, скажіть, що клієнт має робити далі. Чи слід запросити новий рахунок? Чи можна лишити старий номер замовлення? Чи потрібно чекати нову адресу для оплати? Команда підтримки ніколи не має вигадувати відповідь на ходу.
Запізнілі платежі можна приймати, але лише якщо ви знаєте, як вони прив’язуються до запису підписки. Клієнт, який платить через 3 дні після призупинення, може заслуговувати на повторну активацію, але білінгова система все одно потребує чистого аудиторського сліду. Без цього фінанси й підтримка зрештою сперечатимуться через один і той самий ID замовлення.
7. Протестуйте весь цикл підписки перед запуском
Тестування — це не одне оформлення. Це 7 або 8 різних перевірок. Перевірте реєстрацію, підтвердження першої оплати, створення рахунку на продовження, запізніле продовження, невдалий платіж, ручне відновлення, скасування та доставку листів клієнту. Якщо зламається будь-який із цих кроків, зламається і вся історія підписки.
Зробіть принаймні один тест, у якому платіж навмисно затримується. Зробіть ще один, де клієнт оплачує неправильну суму. Спробуйте сценарій, у якому продовження скасовано до дати оплати. Потім перевірте випадок, коли продовження оплачено вже після завершення пільгового періоду. Такі тести знаходять крайні випадки, які реальні клієнти все одно зрештою знайдуть.
Під час тестування стежте за адмінпанеллю. Чи показує WooCommerce правильну примітку до продовження? Чи оновлюється статус підписки в очікуваний час? Чи в листі написано «оплачено», коли в замовленні ще стоїть «очікує»? Невеликі невідповідності пізніше обходяться дорого.
Якщо у вашого бізнесу є робочий процес розробки, шлюз криптоплатежів для WooCommerce допоможе з ширшою картиною інтеграції. Цей матеріал корисний, коли потрібно перевірити сам платіжний рівень, тоді як ця стаття зосереджена на поведінці підписок.
8. Задокументуйте внутрішні процедури підтримки для клієнтів із криптопідписками
Команді підтримки потрібен регламент, а не лише плагін. Створіть односторінковий процес для пошуку транзакції, зіставлення її із замовленням на продовження та перевірки, чи належить платіж поточному білінговому циклу, чи наступному. Без цього один і той самий запит отримуватиме 3 різні відповіді від 3 різних агентів.
Запишіть поля, які команда має перевіряти першими: ID підписки, номер замовлення, хеш транзакції, адресу гаманця, мережу та часову позначку. Цих 6 пунктів достатньо, щоб швидко вирішити багато платіжних питань. Якщо клієнт каже, що заплатив, підтримка має знати, де шукати, менш ніж за 2 хвилини.
Спори та повідомлення про відсутній платіж теж потребують зрозумілого шляху. Наприклад, якщо в гаманці видно переказ, але в WooCommerce немає відповідної примітки, команда має знати, чи запитувати хеш, перевіряти мережу ще раз або передавати випадок на технічний перегляд. Цей процес важливіший за точне формулювання відповіді клієнту.
Для виплат або партнерських сценаріїв, пов’язаних із підписками, вам також може знадобитися криптовалюта для партнерів і рефералів, якщо ваш магазин виплачує комісії або бонуси за рекомендації поверх підписок. Це окремий процес, і він має залишатися окремим у ваших нотатках підтримки.
Останнє практичне правило просте: тримайте політику підписок на видному місці в адміндокументації. Якщо пізній платіж після 48 годин скасовується, запишіть це. Якщо після часткової оплати потрібна ручна перевірка, теж запишіть. Одна сторінка краща за 20 повідомлень у Slack.
Коментарі