Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
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;
- разделять статус заказа и статус платежа.
Подписи и валидация защищают от подмены заказа
Платежный 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 и историю попыток, а не только комментарий.
