ServEaseDocumentation

31 серпня 2026

Зведене оновлення за період з 5 липня: безпечніша робота з обліковими даними платіжних провайдерів, захищені email для входу та численні виправлення надійності платежів, повернень і бронювань.

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

Платіжні провайдери

  • Щойно ви зберігаєте облікові дані Stripe, PayPal, Przelewy24, Tpay, eService чи іншого шлюзу, ServEase більше ніколи їх не показує — навіть адміністраторам. Редагування інших налаштувань провайдера більше не вимагає повторного введення облікових даних.
  • Окрема дія Замінити облікові дані дозволяє замінити облікові дані провайдера на новий набір, не зачіпаючи решту його налаштувань.
  • Перемикання підключеного онлайн-провайдера на офлайн-спосіб (готівка, банківський переказ, чек) тепер коректно видаляє збережені облікові дані попереднього провайдера, з попередженням перед збереженням.

Див. Платіжні шлюзи.

Безпека облікового запису та входу

  • Електронна пошта для входу клієнтів і співробітників тепер захищена — змінити її може лише сам власник облікового запису, у власному профілі, а не через картку клієнта або співробітника в застосунку адміністратора. Це захищає від випадкового перенаправлення однією компанією спільної облікової ідентичності людини, яка має акаунти в кількох компаніях ServEase.
  • Посилено застосування багатофакторної автентифікації (MFA) під час входу через email/magic-посилання.
  • Призупинені та деактивовані акаунти тепер надійно залишаються заблокованими в усіх сценаріях входу, підтвердження email і повернення після оплати.

Див. Деталі клієнта і Деталі співробітника.

Платежі, повернення та білінг — надійніше

Широкий набір виправлень коректності в ланцюжку платежів і повернень:

  • Повернені та частково повернені платежі тепер коректно відображаються в непогашених залишках, а статус платежу більше не можна змінити так, щоб це створювало розбіжність із фактичними поверненнями.
  • Виправлено кілька рідкісних проблем із затримками, коли відкладене повідомлення від платіжного провайдера (зокрема Przelewy24 і eService) могло помилково повторно відкрити вже врегульований платіж, позначити успішно оплачене замовлення як невдале або спрямувати повернення не на той платіж — тепер гарантується, що повернення стосується лише платежу, для якого воно було авторизоване, і при перериванні роботи сервера під час повернення воно більше не може бути надіслане двічі або втрачене. Також виправлено помилку округлення суми повернення Przelewy24.
  • Виправлено помилку, через яку кредит клієнта міг застосовуватися некоректно, якщо для того самого клієнта відбувалося кілька платежів майже одночасно.
  • Екран Add Charge у розділі «Транзакції» більше не пропонує промокод для платежу, пов'язаного з бронюванням, — промокоди доступні лише для самостійних платежів. Див. Сторінка транзакцій.
  • Промокоди з максимальним лімітом знижки тепер коректно застосовуються всюди, зокрема для платежів, створених напряму (не лише через бронювання).

Бронювання

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

Що нового для адміністраторів

  • Безпечніше керування обліковими даними платіжних провайдерів завдяки новій дії «Замінити облікові дані»
  • Електронна пошта для входу клієнтів і співробітників захищена від редагування в застосунку адміністратора
  • Посилена безпека облікового запису щодо входу, MFA та призупинених акаунтів
  • Численні виправлення надійності платежів, повернень і білінгу
  • Надійніший статус бронювань за підпискою/членством і врегулювання платежів
  • Постійні виправлення помилок і покращення стабільності платформи

On this page