WooCommerce Subscriptions у хорошому сенсі прискіпливий. Він тримає регулярні платежі в порядку, але водночас це означає, що не можна ставитися до Payora як до звичайного плагіна для разової оплати й сподіватися, що логіка продовжень якось сама все владнає. Саме тому Payora WooCommerce Subscriptions варто налаштовувати уважно, з урахуванням усіх нюансів регулярного білінгу.
Цей посібник про одну вузьку задачу: додати Payora до вже наявного магазину WooCommerce, який уже працює з розширенням Subscriptions, і при цьому не змінювати решту магазину. Якщо вам потрібно лише, щоб нові регулярні замовлення використовували Payora, цього достатньо. Якщо ви хочете перебудувати весь платіжний процес, це не та стаття.
Спершу невелике застереження. Робота з підписками зачіпає оформлення замовлення, повідомлення про продовження, збережену платіжну поведінку та записи замовлень, тож одна пропущена настройка згодом може створити плутанину з продовженнями.
1. Перевірте точний сценарій WooCommerce Subscriptions
Почніть із того магазину, який у вас є насправді, а не з того, який хотілося б мати. Якщо WooCommerce уже працює, і WooCommerce Subscriptions уже активний, тоді завдання зазвичай полягає в тому, щоб додати Payora для нових підписок без змін у наявних товарах, податках, доставці чи шаблонах листів.
Звучить скромно, бо так і є. Мета не в тому, щоб переписати обробку замовлень для всього магазину, а лише в тому, щоб підпискові оформлення проходили через Payora для відповідних планів.
Якщо ваш магазин поки що приймає лише разові платежі, зупиніться тут і спершу змініть структуру магазину. Якщо підписки вже існують, рухайтеся далі.
Для ширшого контексту щодо Payora в ecommerce посібник із криптовалютного платіжного шлюзу для ecommerce допоможе порівняти моделі оплати перед тим, як ви торкнетеся живого оформлення замовлення.
2. Перевірте вимоги до плагінів і облікового запису
Вам потрібен доступ адміністратора WordPress. Також потрібні WooCommerce, WooCommerce Subscriptions і обліковий запис продавця Payora з обліковими даними, необхідними для продуктивного або тестового доступу.
Спочатку перевірте список плагінів, перш ніж робити щось інше. Чистий екран адміністратора не є гарантією, але він підкаже, чи базові елементи вже на місці.
Відкрийте обліковий запис Payora й перевірте дані продавця, API-ключі та будь-які значення для callback або webhook, які надає акаунт. Якщо Payora дає окремі значення для sandbox і live-режиму, запишіть їх у два різні місця.
Не пропускайте перевірку акаунта. Відсутній ключ може зробити так, що підпискове оформлення виглядатиме нормально на сайті, але збоїтиме під час повторних списань у фоновому режимі.
Також переконайтеся, що власник магазину або роль розробника має право змінювати платіжні налаштування у WooCommerce. Одного заблокованого облікового запису достатньо, щоб загальмувати весь процес налаштування.
3. Знайдіть платіжні налаштування Payora у WooCommerce
У WordPress перейдіть до WooCommerce, далі Settings, далі Payments. Зазвичай саме там з’являються платіжні шлюзи, хоча точний шлях може відрізнятися, якщо Payora встановлено як вбудований варіант, окреме розширення або через власну інтеграцію.
Знайдіть Payora у списку способів оплати. Якщо він має перемикач увімкнення та кнопку налаштувань, імовірно, ви працюєте з шлюзом, який можна конфігурувати безпосередньо у WooCommerce.
Якщо Payora взагалі не видно, перевірте, чи встановлено плагін, чи активне розширення та чи не потребує інтеграція окремого конектора. Три перевірки кращі за одну здогадку.
Звертайте увагу на формулювання щодо підписок. Деякі шлюзи підтримують звичайне оформлення, але не підтримують регулярні продовження. Ця різниця важливіша за підпис на кнопці.
Коротка адмін-порада: якщо сторінка налаштувань пропонує тестовий режим, поки що залиште його увімкненим. Одного живого кліку достатньо, щоб створити реальне підпискове замовлення ще до того, як ви будете готові.
4. Підключіть облікові дані Payora для підпискового оформлення
Введіть ідентифікатор продавця Payora, API-ключі та будь-яке секретне значення точно так, як їх надано. Одна друкарська помилка може зламати автентифікацію, а у випадку підпискового білінгу ви можете не помітити цього до першої спроби продовження.
Якщо налаштування включає callback URL або endpoint для webhook, додайте його в обох місцях: в акаунті Payora і в налаштуваннях шлюзу WooCommerce, якщо інтеграція просить заповнити обидва. Подія продовження має мати шлях назад до WooCommerce, щоб статус підписки змінювався, коли платіж проходить або не проходить.
Це найтехнічніша частина, і водночас це здебільшого уважне введення даних. Скопіюйте, вставте, перевірте, збережіть.
Для магазинів, яким потрібен глибший технічний орієнтир, посібник з інтеграції API криптоплатежів Payora стане доречним доповненням, особливо якщо ваше налаштування — не простий plug-and-play шлюз.
Є одна фраза, яку багато власників магазинів шукають і потім занадто довго обмірковують: "як підключити Payora до WooCommerce subscriptions". Процес простіший, ніж здається, якщо ваш шлюз уже підтримує логіку регулярних платежів, бо головне завдання — переконатися, що початкове оформлення і callback для продовження вказують на ті самі дані акаунта Payora.
Збережіть налаштування, потім перезавантажте сторінку й переконайтеся, що вони збереглися. Налаштування, яке зникає після оновлення сторінки, — це не налаштування.
5. Налаштуйте поведінку платежів за підпискою
Тепер відкрийте налаштування WooCommerce Subscriptions і перевірте поведінку продовжень. Найважливіші пункти — збережені способи оплати, поведінка повторних спроб списання та те, чи можуть клієнти використовувати Payora і для першого платежу, і для подальших продовжень.
Деякі магазини дозволяють Payora лише під час оформлення, а потім переводять продовження на інший метод. Інші дозволяють Payora обробляти і перший платіж, і повторні списання. Ваші правила товарів вирішують, яка модель підходить.
Якщо ваш шлюз зберігає платіжні дані клієнта так, що WooCommerce Subscriptions це розпізнає, увімкніть опцію збережених способів оплати. Якщо ні — не змушуйте систему робити те, чого вона не підтримує.
На поведінку повторних спроб варто подивитися дуже уважно. Збій продовження може запускати листи, зміну статусу або правила скасування, і ці дії мають відповідати вашій політиці підтримки, а не стандартному налаштуванню, яке ви ніколи не читали.
Слідкуйте за змішаними способами оплати в межах однієї підписки. Таке може статися, якщо клієнт починав з одного шлюзу, а потім перейшов на Payora. Змішані сценарії керовані, але вони мають бути свідомими.
Якщо хочете практичний спосіб оцінити якість платежів після ввімкнення цієї функції, прочитайте як вимірювати успішність криптоплатежів. Набагато легше виправити погані патерни продовжень на ранньому етапі, ніж після місяця звернень у підтримку.
6. Протестуйте оформлення підписки та перше продовження
Спочатку протестуйте один підписковий товар. Одного плану достатньо. Виберіть сторінку товару, оформіть замовлення на підписку і простежте шлях від кошика до підтвердження.
Якщо можливо, використайте тестовий обліковий запис клієнта. Потім перевірте, чи WooCommerce створює запис підписки, батьківське замовлення та правильний початковий статус.
Тест першого продовження важливіший за перше оформлення. Оформлення може пройти успішно, а логіка продовження потім тихо зламається.
Запустіть подію продовження у вашому тестовому середовищі або дотримайтеся того графіка продовжень, який ви налаштували. Потім переконайтеся, що WooCommerce оновлює статус підписки після того, як Payora повертає результат платежу.
Якщо вам потрібен pre-flight чекліст для цього етапу, стаття про як протестувати криптоплатіж буде корисною, бо тут застосовуються ті самі звички: спершу тестуємо платіж, а потім — результат, який іде після нього.
Запишіть точний результат тесту. Чи перейшло замовлення в active, pending або on-hold? Чи надійшов лист про продовження? Чи показав запис замовлення в адмінці очікувану примітку?
Коротка примітка: не пропускайте продовження. Ніколи.
7. Перевірте повідомлення для клієнта та обробку замовлень в адмінці
Клієнти повинні бачити правильне повідомлення про оплату під час оформлення, і формулювання має відповідати тому, що Payora фактично робить. Якщо шлюз очікує перенаправлення, так і скажіть. Якщо підтвердження платежу приходить пізніше, клієнту не слід завчасно повідомляти, що замовлення вже завершено.
Перевірте лист-підтвердження підписки. Потім перевірте лист про продовження. Потім перевірте лист про скасування, якщо ваш магазин його надсилає. Три листи — три місця, де може з’явитися невідповідна мова.
В адмінці відкрийте запис підписки та пов’язане замовлення. Ви маєте бачити назву шлюзу, статус платежу та будь-яку примітку, яка ідентифікує спробу продовження або результат callback.
Якщо співробітники підтримки обробляють повернення коштів або ручну перевірку, їм потрібно бачити ті самі дані. Чистий адмін-запис економить час у перших десяти зверненнях у підтримку, а ймовірно, і після цього теж.
Один корисний внутрішній орієнтир — як мігрувати з ручних криптоплатежів, бо деякі магазини переходять від обробки платежів вручну до підпискового білінгу й мають зберегти узгодженість внутрішніх записів.
Не залишайте текст повідомлення розмитим. "Платіж отримано" доречно лише тоді, коли продовження справді завершене. Якщо ще триває очікування мережевого підтвердження, скажіть саме це.
8. Обробіть особливі випадки для наявних підписників
Наявні підписники — найскладніша частина. Якщо вони вже платять іншим способом, вирішіть, чи мають вони лишитися на ньому, чи перейти на Payora лише під час ручного продовження або повторного оформлення підписки.
У багатьох магазинах найчистіше правило просте: нові підписки використовують Payora, а наявні підписники зберігають свій поточний спосіб оплати, доки не настане природна зміна. Це дозволяє уникнути примусових дій від клієнтів, яких ніхто не просив щось змінювати.
Якщо ви все ж хочете мігрувати чинних підписників, перевірте, чи дозволяє WooCommerce Subscriptions змінити спосіб без створення нової підписки. Якщо ні, заплануйте шлях повторного оформлення й поясніть його клієнтам простими словами.
Це пояснення має значення. Люди можуть прийняти новий спосіб білінгу, якщо розуміють, чому це відбувається. Сюрпризи вони не люблять сильніше, ніж самі зміни.
Адміністратори магазину також мають вирішити, що робити зі старими замовленнями продовжень. Залишайте їх читабельними. Зберігайте історію. Не видаляйте докази лише тому, що змінився шлюз.
Часто виникає практичне питання: що, якщо клієнт хоче змінити на Payora лише наступне продовження? У такому разі спочатку протестуйте шлях оновлення в staging, бо об’єкт підписки та запис способу оплати можуть змінюватися не в один і той самий крок.
Пов’язане питання — чи має Payora відображатися для кожного товару, чи лише для підпискових товарів. Якщо ваш магазин продає і фізичні товари, і регулярні послуги, розділіть ці правила зараз, а не пізніше.
| Перевірка | Що підтвердити | Чому це важливо |
|---|---|---|
| Видимість шлюзу | Payora відображається в налаштуваннях платежів WooCommerce | Показує, що інтеграцію встановлено і вона доступна |
| Дані акаунта | Merchant ID, ключі, callback-и | Потрібні для оформлення та продовжень |
| Тест продовження | Одна підписка правильно продовжується | Доказ того, що регулярний потік працює |
| Адмін-записи | Статус, примітки та посилання на замовлення видимі | Допомагає службам підтримки та фінансів |
Тримайте цей список поруч під час запуску. Він навмисно невеликий.
Якщо пізніше вам потрібно буде змінити саму структуру інтеграції, найкращим наступним кроком стане стаття про криптоплатіжний шлюз для фрилансерів лише в тому разі, якщо ваша модель підписки також нагадує клієнтський білінг і виставлення рахунків, бо саме там часто перетинаються очікування щодо регулярних платежів.
І остання польова примітка: якщо Payora і WooCommerce не збігаються в часі, вірте журналам до того, як вірити екрану. Екран може відставати. Журнали розповідають історію.




Коментарі