Українська
Հայերեն
ქართული
English
Қазақша
Español
Français
Deutsch
Italiano
فارسی
В фокусе статьи
Tilda checkout должен передавать заказ в платежный backend
Custom payment gateway - это не просто redirect на банк, а договор между витриной, backend и платежным провайдером.
В Tilda заказ часто создается на стороне витрины, а оплата уходит во внешний сценарий. Чтобы не потерять заказ, нужно заранее определить, какие поля передаются в платежный backend: order id, сумма, валюта, товары, контакты, return URL и служебный request id.
Backend должен создать платежную сессию, сохранить внутренний payment id и вернуть клиенту контролируемый переход на оплату. После этого статус заказа нельзя считать финальным только по тому, что покупатель вернулся на success page.
- передавать в backend стабильный order id;
- проверять сумму и валюту до создания платежа;
- сохранять payment attempt до redirect;
- разделять статус заказа и статус платежа.
Обязательные требования к сайту для VPOS
До production review нужно закрыть публичные legal pages, цены, контакты и языковые версии сайта.
Платежная интеграция не пройдет нормально, если сайт выглядит технически готовым, но не содержит обязательных правил для покупателя и банка. Эти страницы лучше подготовить до тестовой оплаты и заявки на production-доступы.
Если услуга или товар не подлежит отмене или возврату, это нужно прямо написать в политике отмены и возврата. Для Армении обязательна армянская версия сайта; если есть другие языки, та же информация должна быть опубликована и на них.
- политика конфиденциальности;
- политика обработки персональных данных;
- политика отмены и возврата, включая non-refundable правила;
- Terms and Conditions: условия продажи, доставки или предоставления услуги;
- цены на товары или услуги до оплаты;
- контактные данные: телефон, e-mail, мессенджеры или другой рабочий канал;
- армянская версия сайта и одинаковая информация во всех доступных языках.
Подписи и валидация защищают от подмены заказа
Платежный endpoint должен fail-closed принимать только валидные запросы и не доверять произвольным параметрам из браузера.
Если endpoint принимает сумму, валюту и заказ без проверки подписи или merchant settings, злоумышленник может попытаться изменить параметры до создания платежа. Поэтому request нужно проверять до вызова провайдера, а ошибки отдавать безопасно и без раскрытия секретов.
Даже если подпись валидна, backend должен сверить обязательные поля, формат валюты, сумму, merchant id и повторное использование request id. Повторный запрос не должен создавать несколько независимых платежей для одного заказа.
- проверять подпись и merchant configuration;
- не доверять сумме только из frontend;
- использовать idempotency для повторных запросов;
- логировать invalid signature и validation errors.
Как возвращать статус в Tilda, CRM и учет
Покупателю нужен понятный результат, а операторам - проверенный статус, provider reference и список исключений.
После оплаты provider callback или server-side status check должен обновить внутренний платеж, а затем передать нормализованный результат в Tilda-контекст, CRM, ERP или фискальный сервис. Если интеграция ограничится redirect, часть successful оплат может остаться в подвешенном состоянии.
Для поддержки важно видеть paid, pending, failed, expired, refunded и manual review. Для сверки нужны provider reference, order id, amount, currency, paidAt, fiscal status и история повторных попыток доставки события.
- не закрывать заказ без server-side verification;
- отдельно хранить fiscal status и payment status;
- создавать CRM-задачи только по исключениям;
- включать Tilda-заказы в ежедневную сверку.
FAQ
Можно ли считать Tilda-заказ оплаченным после перехода на success page?
Нет. Success page подтверждает пользовательский сценарий, но финальный статус лучше ставить после server-side проверки платежа или доверенного callback от провайдера.
Что делать, если покупатель закрыл платежную страницу?
Заказ должен остаться в pending payment. Backend должен дождаться callback, выполнить повторную проверку статуса или перевести случай в manual review.
Нужно ли передавать Tilda-заказы в CRM?
Если менеджеры обрабатывают заказы или услуги в CRM, лучше передавать нормализованный статус оплаты, provider reference и историю попыток, а не только комментарий.
