Короткий ответ: на статическом сайте не работает оплата картой, потому что платить некому. Статический сайт — это набор файлов, которые хостинг просто отдаёт браузеру. У него нет программы, которая работала бы на сервере: приняла заказ, сходила в банк, дождалась подтверждения и записала, что оплачено. Не «не настроено», а физически нет места, где это могло бы выполняться.
Это разбор без маркетинга: что именно ломается, почему это нельзя обойти и какие есть честные варианты.
Что такое «нет бэкенда» на практике
На конструкторе ваш магазин — это витрина плюс серверная часть на стороне конструктора. Когда покупатель жмёт «Оплатить», браузер отправляет заказ на серверы платформы. Там код принимает заказ, обращается к платёжному шлюзу, ждёт от банка ответа, помечает заказ оплаченным и присылает вам уведомление.
При переносе вы забираете витрину: карточки, каталог, корзину, оформление. Всё, что видел покупатель, — переносится. Но код, который жил на серверах конструктора, вам никто не отдаёт: он не ваш и не лежит в HTML.
Отсюда вещь, которая многих удивляет: корзина после переноса продолжает выглядеть рабочей. Товары добавляются, количество считается, сумма меняется — это всё JavaScript в браузере, он переносится нормально. Не работает только последний шаг: отправить заказ туда, где его примут.
Почему это нельзя «просто настроить»
Приём карт — это не кнопка, а связка:
- Сервер, который принимает заказ. У статического сайта его нет по определению.
- Секретный ключ платёжного шлюза. Его нельзя положить в файлы сайта: файлы отдаются любому, кто откроет страницу. Ключ в JavaScript = ключ у всех.
- Приём webhook'а от банка. Банк подтверждает оплату отдельным запросом на ваш сервер. Принимать его некому.
- Место, где хранится статус заказа. Иначе непонятно, оплачен он или нет.
Каждый пункт требует работающего кода на сервере. Поэтому «прикрутить оплату к статике» — это на самом деле «перестать быть статикой».
Отдельно: любой, кто предлагает вам «оплату на статическом сайте» без внешнего сервиса, либо кладёт секретный ключ в открытый доступ, либо просто рисует форму, которая ничего не принимает. Обе истории заканчиваются плохо.
Что делаем мы: корзина превращается в заявку
Мы не притворяемся, что оплата работает. Вместо этого корзина честно становится заявкой на заказ.
Как это выглядит для покупателя: он собирает корзину как обычно, жмёт «Оформить», заполняет имя и телефон. Дальше вместо перехода на оплату он видит сообщение, что заказ принят и продавец свяжется, чтобы подтвердить и договориться об оплате. Не «спасибо за покупку», не «оплачено» — именно то, что произошло на самом деле.
Как это выглядит для вас: на почту (и в Telegram, если настроите) приходит письмо с составом корзины, количеством, суммой и контактами покупателя. Дальше вы связываетесь и берёте деньги как вам удобно — переводом, счётом, ссылкой на оплату, наличными при получении.
Технически: скрипт в экспорте перехватывает обращения к платёжным адресам конструктора и разворачивает их на ваш form-handler.php. Перехват идёт по границе имени домена, а не по куску строки, — чтобы случайно не поймать чужой запрос, который просто похож.
Формулировку подтверждения мы держим отдельным правилом именно потому, что соблазн написать «Спасибо за покупку!» велик, а это была бы ложь: денег вы не получили, покупатель уверен, что заплатил. Один такой «успех» стоит дороже любой конверсии.
Честные варианты принимать деньги
Если заявки достаточно — ничего делать не нужно, оно уже работает. Если нужен именно приём карт на сайте, вот варианты по возрастанию сложности.
Встраиваемый магазин (Ecwid, Snipcart). Витрина остаётся вашей и статической, а корзину и оплату берёт на себя внешний сервис — у него есть и сервер, и лицензии, и ключи. Вставляется скриптом на страницу.
Платёжная ссылка или счёт. ЮKassa, Тинькофф и другие умеют выставлять ссылку на оплату. Вы получаете заявку, отправляете ссылку в ответ. Ноль изменений на сайте, деньги приходят на счёт. Для небольшого потока заказов — часто лучший вариант по соотношению «усилия/результат».
Свой бэкенд. Небольшой сервис, который принимает заказы и общается со шлюзом. Полный контроль, но это уже разработка и поддержка, а сайт перестаёт быть статическим.
А Webrelay сделает оплату?
Честно: настоящий приём платежей — с вашими ключами и обработкой подтверждений от банка — это отдельная функция, которая в планах. Мы не будем изображать её раньше, чем она появится: фальшивая оплата хуже, чем её отсутствие, потому что о ней узнаёшь от рассерженного покупателя.
Мы пишем про это так подробно, потому что честность про ограничения экономит вам время и деньги: лучше знать про заявку заранее, чем ждать оплат, которых не будет.
Часто задаваемые вопросы
Почему на статическом сайте не работает оплата картой?
Потому что для приёма карт нужен код, работающий на сервере: принять заказ, сходить в банк, получить подтверждение, сохранить статус. Статический сайт — только файлы, у него нет серверной части. Это не настройка, а устройство.
Корзина после переноса вообще работать не будет?
Будет. Добавление товаров, подсчёт суммы, оформление — всё это происходит в браузере и переносится нормально. Меняется только финал: вместо оплаты вы получаете заявку с составом заказа и контактами покупателя.
Покупатель поймёт, что он не оплатил?
Да, и это принципиально. Сообщение говорит, что заказ принят и продавец свяжется для подтверждения и оплаты. Мы намеренно не пишем «спасибо за покупку» — покупатель не должен уйти с мыслью, что заплатил.
Можно ли просто вставить ключ платёжного шлюза в JavaScript?
Нет. Файлы статического сайта доступны любому посетителю — вместе с ключом. Секретный ключ в JavaScript означает, что он есть у всех, кто открыл страницу.
Что выбрать, если магазин небольшой?
Чаще всего — заявку плюс платёжную ссылку в ответ: ноль доработок сайта, деньги на счёт. Если заказов много и хочется автоматизации — встраиваемый магазин вроде Ecwid.
Как перенести магазин с Тильды?
Витрина и каталог переносятся статикой, корзина становится заявкой. Подробный разбор — в статье перенос интернет-магазина с Тильды. Что переносится в целом — что переносится с конструктора.