Чтобы подключить оплату на сайте, нужно подготовить магазин к работе с платёжным провайдером, настроить обмен данными и проверить, как заказ получает подтверждённый результат. Кнопка «Оплатить» — только видимая часть этого процесса. Владелец магазина должен понимать, кто разбирает зависшие платежи и возвраты, а разработчик — на каком основании заказ считается оплаченным.
Разберём подключение на примере ЮKassa: её документация позволяет отдельно рассмотреть подготовку магазина, тестовый режим и технические статусы. Это пример конкретного провайдера, а не рекомендация выбирать его для любого бизнеса. У другого сервиса условия подключения и протокол обмена могут отличаться.
Сначала подготовьте магазин, затем подключайте приём денег
В инструкции ЮKassa подключение включает регистрацию, передачу данных и документов для договора, подписание договора и настройку интеграции. Тестировать платежи можно до заключения договора. Успешная проверка в тестовом магазине сама по себе не означает, что настоящий магазин уже готов принимать деньги.
ЮKassa проверяет готовность сайта при подключении: он должен открываться, показывать реальные товары или услуги с настоящими ценами, объяснять получение покупки и содержать достоверную информацию о продавце и контактах. Уберите тестовые позиции и временные описания. Состав документов и применимые условия уточняйте для своего продавца и способа работы по действующей процедуре провайдера.
До разработки договоритесь с командой о конкретном сценарии:
- какие способы оплаты нужны и доступны выбранному магазину;
- списывается ли сумма сразу или сначала резервируется до подтверждения;
- кто подтверждает списание, если используется резервирование;
- кто оформляет возврат и контролирует его завершение;
- кто имеет доступ к кабинету провайдера и разбирает расхождения между платежом и заказом.
Отдельно определите, как магазин будет формировать и передавать данные для чеков в применимом ему сценарии. В документации ЮKassa это отдельный раздел настройки; проверка платежа не заменяет проверку чека. Решение о применимых требованиях и составе данных нельзя получить из универсального списка «для любого сайта».
Если магазин создаётся с нуля, эти договорённости включают в задачи разработки интернет-магазина. Тогда обработка оплаты, выдача покупки и работа сотрудников проектируются как связанный процесс.
Что передать разработчику и что настроить
Путь подключения зависит от платформы. ЮKassa предлагает инструкции для готовых решений на CMS и конструкторах; для собственного сайта — интеграцию по API. Наличие подходящего модуля стоит проверить до оценки работ. В любом случае нужны согласованный сценарий и проверка результата в вашем магазине.
Для примера с API и переходом на страницу оплаты подготовьте:
| Настройка или договорённость | Зачем она нужна |
|---|---|
Идентификатор магазина shopId и секретный ключ нужного режима | Сервер сайта обращается к конкретному магазину провайдера |
| Выбор немедленного списания или подтверждения после резервирования | Определяет, должен ли сайт отдельно подтверждать платёж |
Страница возвращения покупателя return_url | Показывает состояние заказа после выхода со страницы оплаты |
| Адрес обработчика HTTP-уведомлений и выбранные события | Сервер получает изменения состояния платежа независимо от браузера покупателя |
| Связь заказа с идентификатором платежа, суммой и валютой | Позволяет понять, какой заказ и на какую сумму оплачен |
| Сценарий возврата и ответственный сотрудник | Позволяет инициировать возврат и проверить результат отдельной операции |
По инструкции ЮKassa запросы к API отправляют с сервера сайта. Секретный ключ не должен попадать в код браузера, публичные страницы или материалы для покупателя. Рабочие и тестовые настройки разделяют, чтобы тестовый платёж не запускал выдачу настоящего заказа.
Для HTTP-уведомлений нужен доступный провайдеру обработчик с HTTPS. Это отдельный технический адрес, а не страница, на которую возвращается покупатель. Владелец магазина согласует сценарий и доступы; разработчик настраивает обработчик и проверку данных.
Когда заказ можно считать оплаченным
В сценарии с переходом на готовую страницу оплаты сервер сайта создаёт платёж и сохраняет его идентификатор у заказа. Покупатель выполняет необходимые действия на стороне провайдера. После этого сайт получает результат по уведомлению или запрашивает актуальное состояние платежа через API.
У ЮKassa есть следующие статусы платежа:
| Статус | Что произошло | Что учитывать магазину |
|---|---|---|
pending | Платёж создан, окончательный результат ещё неизвестен | Продолжать ожидание или проверку; не считать заказ оплаченным |
waiting_for_capture | Сумма авторизована и ожидает подтверждения списания | Выполнить согласованный сценарий подтверждения или отмены; это ещё не завершённый платёж |
succeeded | Платёж успешно завершён | После сверки платежа с заказом можно отметить подтверждённую оплату |
canceled | Платёж отменён | Сохранить причину отмены и показать подходящее действие покупателю |
Состояние заказа и состояние платежа хранят раздельно. Заказ может быть оформлен, но ещё не оплачен. При двухстадийной оплате резервирование суммы также требует собственного действия магазина: подтвердить списание или отменить платёж по правилам выбранного сценария.
На странице возвращения показывайте известное серверу состояние. Пока результат не установлен, подходит объяснение «Проверяем оплату», связанное с конкретным заказом. Не показывайте «Оплачено» только потому, что человек открыл эту страницу. Если он закрыл браузер и не вернулся, серверная обработка всё равно должна установить результат.
Сумму заказа проверяют на стороне магазина, а не принимают готовой из браузера. При подтверждении сверяют идентификатор платежа, принадлежность нужному магазину, сумму и валюту с сохранённым заказом. Это критерии реализации, которые стоит включить в приёмку интеграции.
Повторный запрос и повторное уведомление — разные ситуации
Представим учебный случай: покупатель оформляет заказ на кофейный набор. Сервер отправил запрос на создание платежа, но соединение оборвалось до получения ответа. Магазин пока не знает, создан ли платёж. Если сразу отправить новый запрос как новую операцию, можно создать второй платёж для той же попытки оплаты.
Для таких повторов API ЮKassa использует Idempotence-Key — ключ, по которому сервис распознаёт повторный запрос. При повторе той же операции сохраняют и ключ, и данные запроса. Другой ключ при прежних данных означает новую операцию. Документация ограничивает гарантию идемпотентности 24 часами после первого запроса: рассчитывать на неё бессрочно нельзя. После сетевой ошибки или ответа HTTP 500 сначала устанавливают результат операции; такой сбой не доказывает, что платёж не был создан.
Другая ситуация — повторное входящее уведомление. ЮKassa ждёт ответа HTTP 200, подтверждающего получение. При другом коде провайдер продолжает доставку в пределах описанного в документации периода. Поэтому обработчик должен выдерживать повтор события: не создавать ещё один заказ, не запускать повторную выдачу покупки и не отправлять сотруднику повторное поручение на отгрузку.
Входящему сообщению нельзя доверять только потому, что его данные похожи на уведомление. Документация ЮKassa предусматривает проверку подлинности, в том числе по актуальному статусу объекта. Для интеграции можно получать состояние платежа авторизованным серверным запросом и сверять его с заказом. В приёмке отдельно проверяют поддельное сообщение, неизвестный идентификатор и несовпадение суммы.
Нужен и способ восстановления: если заказ долго остаётся в ожидании, магазин должен уметь повторно проверить платёж у провайдера и исправить расхождение по подтверждённым данным. Сотруднику нужны номер заказа, идентификатор платежа и результат проверки; секретные ключи и полные карточные данные в таком журнале не нужны.
Возврат нужно проверить как отдельную операцию
Для ЮKassa отмена платежа до списания и возврат после успешной оплаты — разные действия. Платёж в waiting_for_capture можно отменить в соответствующем сценарии. Возврат создают для успешно завершённого платежа, если выбранный способ оплаты поддерживает нужный вид возврата и соблюдены ограничения провайдера.
Возврат бывает полным или частичным; частичный доступен не для всех способов оплаты. В системе сохраняют связь с исходным платежом, сумму и идентификатор возврата. Само нажатие кнопки сотрудником ещё не означает, что операция завершилась: у возврата собственный результат, и он может быть отменён.
В том же учебном заказе покупатель может отказаться от одной позиции кофейного набора. Магазину нужно проверить возможность частичного возврата, создать операцию на согласованную сумму и затем подтвердить её результат. Исходный платёж остаётся успешно завершённым; сведения о возвращённых деньгах относятся к отдельной операции. Статус заказа должен отражать эту историю без потери исходной оплаты.
Что проверить перед включением настоящей оплаты
В тестовом магазине ЮKassa деньги не списываются. Используют тестовые данные магазина и предусмотренные провайдером платёжные данные. ЮKassa рекомендует отдельный адрес для тестовых уведомлений. Товар по тестовой оплате не выдают, даже если операция успешно завершена в тестовом режиме.
Проверяйте весь путь заказа в своём магазине, включая состояния, в которых человек не видит мгновенного успеха:
- успешный платёж подтверждает нужный заказ на правильную сумму;
- отменённый платёж сохраняется как неуспешная попытка и не разрешает выдачу покупки;
- покупатель закрывает страницу оплаты, а магазин всё равно получает и обрабатывает результат;
- потерянный ответ на создание платежа восстанавливается без новой операции для той же попытки;
- повторное уведомление не повторяет действия магазина;
- при двухстадийной оплате проверены и подтверждение списания, и отмена;
- полный и, если нужен и поддерживается, частичный возврат доходят до проверенного результата;
- данные и состояние чека проверены отдельно в выбранной схеме передачи.
Это набор сценариев приёмки, а не утверждение, что тестовый режим воспроизводит любые особенности боевой работы. Доступные тестовые способы оплаты и проверки уточняют в документации конкретной интеграции. Для поддерживаемой схемы отправки чеков ЮKassa отдельно описывает тестирование передачи данных и контроль статуса чека.
Перед включением приёма настоящих денег сверяют готовность реального магазина у провайдера, его идентификатор и ключ, настройки уведомлений и порядок действий сотрудников. Заранее согласуйте контроль первой реальной операции и ответственного за разбор расхождений. Тестовый успех и готовность боевого магазина — два самостоятельных результата.
При постановке задачи на подключение онлайн-оплаты передайте исполнителю выбранного провайдера, платформу сайта, сценарий списания, способы оплаты, возвраты и критерии приёмки. Работу можно принять, когда заказ, платёж и возврат имеют проверяемое состояние, а сотрудник понимает, как восстановить результат после сбоя. Удобство самой формы покупки и ошибки корзины подробно разобраны в материале о корзине и оформлении заказа.
