Настройка срока действия счета в Payora

1. Найдите точное место, где Payora хранит настройки срока действия счета

Первый шаг прост: нужно понять, где в вашей конфигурации Payora хранится срок действия счета. В большинстве систем оформления заказа это одно из трёх мест: глобальная настройка checkout, панель правил для монет или экран переопределения для сети. Если в панели есть боковое меню настроек, начните с него. Если checkout работает через API, проверьте объект конфигурации, который backend отправляет при создании счёта.

Ищите подписи вроде “expiry”, “timeout”, “valid for” или “payment window”. Один продавец может держать стандартное значение 15 минут на уровне аккаунта, а затем позже переопределять его для Litecoin или Tron. Другой может хранить всё в одной таблице правил. Важна не формулировка, а место, где система решает, когда неоплаченный счёт перестаёт быть действительным.

Если вы используете плагин или собственную интеграцию, проверьте три места по порядку. Сначала глобальное значение по умолчанию. Затем набор правил на уровне монеты. Затем любое переопределение для сети, которое стоит выше или ниже правила монеты — в зависимости от того, как был построен checkout. Для технических деталей документация для разработчиков, API криптоплатёжного шлюза — подходящее место, чтобы подтвердить названия полей и структуру запроса.

Не гадайте. Одно скрытое значение по умолчанию может перекрыть всё остальное. А это быстро становится дорогим, особенно когда вы ищете, как изменить срок действия счета в Payora, и не хотите пропустить скрытый уровень переопределения.

2. Сопоставьте поддерживаемые монеты и сети до любых изменений

Прежде чем что-либо редактировать, составьте список всех монет, которые принимает ваш checkout, и сети, в которых работает каждая монета. Запишите это в таблицу или таблицу Excel с четырьмя колонками: монета, сеть, тип платёжного адреса и текущий срок действия. Это звучит просто, потому что это и правда просто, а простая работа помогает избежать неправильных настроек.

Одна и та же монета может быть доступна в нескольких сетях. USDT может предлагаться в Ethereum, Tron и иногда в другой цепочке — в зависимости от вашей архитектуры. ETH может существовать только в mainnet, тогда как другие активы распределяются по нескольким сетям. Значит, решение по сроку действия счета — это не совсем “для USDT” или “для ETH”; оно относится к паре монета-сеть, и именно здесь полезна настройка expiry invoice Payora.

Составьте список комбинаций, которые ведут себя по-разному. Checkout, который принимает BTC, LTC и USDT в двух сетях, уже имеет шесть комбинаций, и каждая из них может сломаться по-своему, если время задано неверно. Если ваш магазин также принимает повторяющиеся платежи, прочитайте крипто-платёжный шлюз для SaaS-подписок — там есть полезная параллель по таймингу и обработке состояния.

Следите за дубликатами. Если одна и та же монета в админ-панели отображается под двумя названиями, объедините эти записи до редактирования правил срока действия. Три ярлыка для одного актива — верный способ получить противоречивые настройки.

3. Задайте базовый срок действия счета для всего checkout

Начните с одного значения по умолчанию, которое применяется ко всем счетам, если другое правило его не переопределяет. Это ваш запасной вариант. Оставьте его простым. Если не уверены, выберите срок, который соответствует обычному времени принятия решения в вашем checkout, а не самому нетерпеливому пользователю на сайте.

Хорошая базовая настройка выполняет одну задачу: даёт каждому новому счёту предсказуемый срок жизни. Если служба поддержки видит, что большинство клиентов завершают оплату за 10 минут, стандартного значения в 10 минут может быть достаточно. Если в checkout есть дополнительные шаги, например проверка адреса или вход в аккаунт, стандартному значению может понадобиться больше времени. Число важно, потому что сам процесс оформления заказа создаёт задержку.

В Payora сначала задайте значение по умолчанию в основных настройках checkout или платежей, а затем убедитесь, что правило действительно применяется к новому тестовому счёту. Когда вы уточняете Payora срок действия счета для монет и сетей, значение по умолчанию должно быть скучным. Если оно не скучное, скорее всего, оно слишком умное.

Здесь же стоит решить, должны ли просроченные счета оставаться видимыми для сотрудников после истечения срока. Некоторые команды сохраняют запись для сверки, но помечают её как просроченную на стороне клиента. Такое разделение полезно, когда финансам нужна история, а поддержке — текущий статус.

4. Добавьте отдельные правила срока действия для монет с разным поведением оплаты

Когда базовое значение задано, добавьте отдельный срок действия для монеты там, где нужен другой временной интервал. Формулировка звучит технически, но логика проста: одни монеты двигаются быстро, другие медленнее, а за некоторые часто платят из кошельков, которым требуется больше времени на финальное подтверждение действия. Если для одной монеты обычно нужно 20 минут, а для другой — 5, у них не должен быть один и тот же лимит.

Используйте отдельный срок действия для монеты, когда пользовательский сценарий заметно отличается. Например, монета, за которую часто платят с мобильных кошельков с большим числом шагов, может нуждаться в более долгом времени жизни счёта, чем монета, которую обычно оплачивают с биржевого кошелька. С другой стороны, если монету чаще отправляют с кошелька с быстрой верификацией и минимальными препятствиями, более короткое окно вполне подойдёт.

Называйте правила по монете, а не по бизнес-цели. “USDT on Tron: 15 минут” проще проверить, чем “правило быстрого токена”. Понятные названия особенно важны, когда через полгода настройки будет читать кто-то другой.

Не создавайте отдельное правило для монеты без конкретного различия в поведении. Если вы не можете объяснить разницу одним предложением, правило, скорее всего, декоративное.

5. Переопределяйте срок действия по сети, если одна и та же монета ведёт себя по-разному

Для некоторых монет нужны переопределения на уровне сети, потому что один и тот же актив ведёт себя по-разному в разных цепочках. Именно здесь вопрос о том, как настроить срок действия счета по монете и сети в крипто-оформлении заказа, становится практическим, а не просто настройкой. В одной сети монета может чаще использоваться из биржевых кошельков, а в другой — из пользовательских кошельков, где действий больше. Checkout не интересует, почему возникла задержка; ему важно лишь, что счёт всё ещё действителен, когда платёж приходит.

Задавайте переопределение сети только после того, как подтвердили правило на уровне монеты. Затем решите, нужен ли сети более короткий или более длинный срок, чем у значения монеты по умолчанию. Если ваша система поддерживает приоритеты, задокументируйте их: глобальное значение по умолчанию, затем правило монеты, затем переопределение сети. Если порядок в вашей сборке другой, тоже запишите это. Одно неверное предположение здесь может сделать весь набор правил хаотичным.

Практический пример помогает лучше всего. Допустим, один и тот же токен принимается в Сети A и Сети B. Сеть A может закрываться быстро и хорошо работать с окном в 10 минут. В Сети B может быть больше переключений кошельков, поэтому окно в 20 минут помогает избежать ненужного истечения срока. Это не теория. Это выбор поведения checkout. Сетевой тайминг важнее всего там, где отличаются поведение кошельков, скорость подтверждений или путь пользователя.

Если вы поддерживаете интернет-магазины с большим количеством способов оплаты, полезно также посмотреть принимайте криптоплатежи на WordPress, потому что слои плагинов иногда добавляют собственные тайм-ауты. Два таймера в одной системе — это уже на один таймер слишком много, если оба не задокументированы.

6. Проверьте срок действия счета в тестовом checkout перед запуском

Никогда не меняйте правила срока действия в production без предварительного теста в staging. Создайте тестовый счёт для каждой монеты и каждой сети, для которой есть отдельное правило. Затем подождите, пока истечёт окно действия, и убедитесь, что статус checkout меняется именно так, как ожидается. Один тестовый счёт на правило — это минимум; два лучше, если у вашей системы есть история ошибок с таймингом.

Используйте часы. Действительно используйте их. Самый простой способ пропустить плохое правило — предположить, что страница обновилась вовремя, хотя это не так. Запишите время начала, подождите до минуты до истечения, затем ещё раз после истечения и проверьте и клиентский, и административный вид.

Проверяйте три вещи для каждого правила: счёт перестаёт принимать оплату, панель помечает его как просроченный, а поздняя оплата обрабатывается согласно вашей политике. Некоторые команды разрешают позднее зачисление, если платёж всё же приходит на адрес; другие отклоняют его и требуют ручной проверки. Выберите один вариант поведения и тестируйте его каждый раз.

Держите список тестов коротким, но полным. Если у вас 4 монеты и 3 сети, проверьте те комбинации правил, которые отличаются. Не нужно повторять один и тот же результат 12 раз, если у 8 из этих комбинаций одинаковые настройки. Но для исключений вам нужны доказательства.

7. Проверьте сообщение для клиента, когда срок действия счета истекает

Покупатель должен понимать, что произошло. Если срок счёта истёк, страница должна сказать об этом простым языком и показать следующий шаг в одну строку, а не в 4 абзаца. Нечёткое сообщение создаёт обращения в поддержку. Понятное — уменьшает их число.

Хорошее сообщение о просроченном счёте включает лимит времени, статус и дальнейшее действие. Например: “Срок действия этого счёта истёк через 10 минут. Пожалуйста, создайте новый checkout, чтобы продолжить.” Такое сообщение говорит клиенту, что изменилось, и что делать дальше. Оно также избегает обвинительного тона, а это важнее, чем признаёт большинство команд.

Сделайте изменение состояния заметным. Затените QR-код, отключите кнопку оплаты и не оставляйте сумму выглядящей активной, если счёт уже недействителен. Если покупатель видит неизменившуюся страницу после истечения срока, он может всё равно попытаться оплатить, и это приведёт к путанице с обеих сторон.

Если ваша служба поддержки обрабатывает обращения по просроченным счетам, добавьте рядом с сообщением одну короткую ссылку на помощь. Одной строки достаточно. Длинный текст помощи редко помогает в тот момент, когда клиент раздражён.

8. Поддерживайте и регулярно проверяйте правила срока действия счета

Настройки срока действия со временем “уплывают”. Это нормально. Добавляются новые монеты, сети переименовываются, а одно старое правило продолжает жить намного дольше, чем меняется поведение checkout. Поставьте проверку в календарь каждые 30 или 60 дней и убедитесь, что текущие правила по-прежнему соответствуют тому, как клиенты действительно платят.

Проводите аудит набора правил после каждого запуска новой монеты. Один этот шаг помогает поймать самую распространённую ошибку: копирование старого срока действия на новый актив без проверки того, как этот актив ведёт себя на самом деле. Если позже добавляется сеть, повторите ту же проверку перед запуском. Одна монета с двумя сетями — это уже два решения, а не одно.

Ведите журнал изменений с датой, монетой, сетью, старым сроком действия и новым сроком действия. Четырёх полей достаточно. Если кто-то из команды спросит, почему правило изменилось, журнал должен отвечать меньше чем за 30 секунд. Хороший журнал также помогает поддержке объяснить, почему один счёт истёк, а другой — нет.

Возвращайтесь к настройкам после любого редизайна checkout, обновления платёжного плагина или расширения списка валют. Checkout может меняться быстрее, чем правила. Так и начинается дрейф.

Если ваш checkout также производит выплаты партнёрам или аффилиатам, та же дисциплина полезна и там; см. крипто для глобальных партнёрских программ для похожего операционного подхода. Одно правило для всех типов выплат кажется удобным. Две минуты проверки обычно экономят два дня исправлений.

Делайте правила срока действия понятными для человека, который не присутствовал при их создании. В этом и есть настоящий стандарт. Через шесть месяцев ваша будущая версия скажет вам спасибо за скучные, но нужные детали.