[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f1mdmbpxdjq0i":3},{"slug":4,"title":5,"published":6,"publishedAt":7,"createdAt":8,"section":9,"preview":10,"heroImage":11,"previewImage":11,"headMarkup":12,"lifecycleId":13,"bodyMd":14,"bodyHtml":15},"integratsiya-internet-magazina-s-platezhnymi-sistemami-trebovaniya-k-zakazu-i-vozvratam","Интеграция интернет-магазина с платёжными системами",true,"2024-05-03T10:00:00+03:00","2026-09-06T16:09:03.621Z","Статьи","Материал о правилах обработки платежей в интернет-магазине. Описаны статусы заказа, возвраты и технические уведомления.","\u002Fcontent-media\u002Farticles\u002Fintegratsiya-internet-magazina-s-platezhnymi-sistemami-trebovaniya-k-zakazu-i-vozvratam\u002Fassets\u002F021b1fa88c40.webp",[],"lc_731886c3b09fe9f2830213b4e5ffbbce","Покупатель оформил заказ, деньги списались, а на странице магазина остаётся статус «ожидает оплаты». Или заказ отменили, но сотрудник не понимает, требуется ли возврат и где проверить его результат. Такие ситуации возникают, когда интеграция интернет-магазина с платёжными системами ограничена подключением способа оплаты без правил для подтверждения, отмены и возврата.\n\nПлатёжный модуль связывает сайт, платёжную систему и обработку заказа. Ошибка в переходе статусов может привести к повторной оплате, заказу без подтверждённого платежа или путанице при возврате. До разработки стоит согласовать полный путь заказа: от создания оплаты до фиксации результата.\n\n## Интеграция интернет-магазина с платёжными системами после нажатия «Оплатить»\n\nПосле подтверждения корзины магазин создаёт заказ и передаёт в платёжную систему данные, необходимые для оплаты. Покупатель переходит к платёжной форме или использует другой интерфейс, предусмотренный сценарием. Затем сайт получает подтверждение результата и меняет состояние заказа по заранее определённым правилам.\n\nВозврат покупателя на сайт не подтверждает оплату. Он мог закрыть вкладку, потерять соединение или вернуться до завершения операции. Статус оплаты следует менять по отдельному подтверждению, предусмотренному технической схемой платёжной системы.\n\nДля каждого результата нужны понятные действия сайта и сотрудников:\n\n- платёж подтверждён;\n- платёж отклонён;\n- покупатель прервал оплату;\n- подтверждение пришло позднее;\n- покупатель повторно открывает ссылку на оплату;\n- у одного заказа несколько попыток оплаты.\n\nОтсутствие сценариев отмены, возврата и подтверждения оплаты приводит к ошибкам обработки заказа. Заранее стоит определить, когда доступна новая попытка, сохраняется ли прежняя ссылка и как исключаются две действующие операции по одному заказу.\n\n## Требования к заказу при подключении онлайн-оплаты\n\nКарточка заказа должна содержать данные для сопоставления с операцией в платёжной системе. Обычно определяют внутренний номер заказа, сумму, состав покупки, способ доставки и контакты покупателя — в объёме, нужном для выбранного сценария. Состав полей и формат передачи сверяют с документацией платёжной системы и требованиями проекта.\n\nОтдельно задают правила изменения заказа после создания оплаты. Например, покупатель меняет количество товаров, способ доставки или применяет промокод. Если меняется сумма, созданная операция может перестать соответствовать текущему заказу. Для такой ситуации определяют сценарий: отменить незавершённую попытку, создать новую или ограничить редактирование до окончания оплаты.\n\nСтоит выбрать источник актуальных данных о сумме и составе заказа. При расхождении сотрудники должны понимать, что сверять: данные заказа до перехода к оплате, ответ платёжной системы или журнал изменений. Это особенно нужно при нескольких попытках оплаты.\n\n## Статусы оплаты и заказа\n\nСтатус заказа и статус платежа описывают разные события. Заказ может быть создан, собран, отменён или передан в доставку. Платёж может ожидать завершения, быть подтверждён, отменён или находиться в обработке. Связь между этими состояниями определяется правилами проекта.\n\nПеред интеграцией полезно составить таблицу переходов: внешнее событие, статус платежа, действие с заказом и действие сотрудника. Подтверждённый платёж может переводить заказ в обработку, а неподтверждённый — оставлять возможность повторной попытки. У каждого состояния должны быть понятны ответственное действие и следующий допустимый переход.\n\nОтмену заказа нужно рассматривать отдельно для разных этапов: до подтверждения оплаты, после подтверждения и после передачи товара. Автоматическая отмена заказа не подтверждает возврат денег покупателю. Эти операции следует фиксировать раздельными статусами или служебными отметками.\n\n## Возвраты через платёжную систему\n\nВозврат начинается с проверки исходной операции. Для него могут потребоваться идентификатор платежа, сумма возврата, причина в учётной записи магазина и сведения о позиции заказа. Набор данных зависит от выбранного способа оплаты и правил проекта.\n\nОтдельного сценария требует частичный возврат: когда из заказа исключают одну позицию, меняют количество товара или возвращают часть покупки. Сайт должен хранить связь исходной оплаты с уже возвращёнными суммами. Иначе есть риск оформить возврат на сумму, превышающую остаток по операции.\n\nСледует разделить отмену незавершённой оплаты, возврат подтверждённого платежа и ручное решение вне автоматизированного процесса. Для каждого действия определяют исполнителя, место фиксации причины и признак завершения. Статус «заявка на возврат создана» не означает, что операция подтверждена платёжной системой.\n\n## Уведомления и обработка сбоев в платёжной интеграции\n\nВнешнее подтверждение может не попасть на сайт с первой попытки из-за временной недоступности, ошибки настройки адреса уведомлений или сбоя на стороне магазина. Повторные уведомления нужно обрабатывать безопасно: одинаковое событие не должно повторно менять остатки, создавать дубликаты документов или отправлять покупателю несколько одинаковых сообщений.\n\nВ журнале сайта не следует хранить платёжные реквизиты. Для разбора ситуации достаточно фиксировать идентификаторы заказа и операции, время события, тип ответа, результат обработки и понятную причину ошибки. Такие записи помогают сопоставить обращение покупателя с конкретной операцией без лишних данных.\n\nДо запуска нужно определить поведение системы, если сайт недоступен в момент оплаты: как обрабатываются повторные уведомления, каким способом проверяется состояние операции и что делает сотрудник, если у покупателя есть подтверждение оплаты, а заказ ещё не обновился.\n\n## Выбор платёжной системы для интернет-магазина\n\nВыбор зависит от сценариев магазина: кто оформляет заказы, нужна ли оплата по ссылке, возможна ли частичная отмена, используются ли разные способы оплаты и как оформляются возвраты.\n\nТехническая проверка включает способ интеграции, документацию по уведомлениям, тестовый контур, требования к данным заказа и порядок диагностики ошибок. Если магазин работает на «1С-Битрикс: Управление сайтом», это CMS для публичной части сайта, каталога и оформления заказа. Внутреннюю работу с обращениями и клиентами рассматривают отдельно: она не заменяет настройку платежей на сайте.\n\nВ границах работ стоит зафиксировать, кто предоставляет доступы и документацию, кто проверяет тестовые операции, какие сценарии входят в проверку и кто принимает результат. Формулировки о подключении оплаты недостаточно, если не определены отмены, возвраты и обработка сбоев.\n\n## Часто задаваемые вопросы\n### Что проверить до начала интеграции с платёжной системой?\n\nНужны схема оформления заказа, способы оплаты, правила изменения суммы после оформления, сценарии отмены и возврата. Отдельно определяют статусы для покупателя и служебные статусы для сотрудников.\n\n### Можно ли считать заказ оплаченным после возврата покупателя на сайт?\n\nНет. Возврат на сайт не всегда означает завершение операции. Статус оплаты меняют по подтверждению, предусмотренному технической схемой платёжной системы.\n\n### Что делать при двойной оплате одного заказа?\n\nПроверяют, какие операции связаны с заказом, какие из них подтверждены и доступен ли возврат по одной из них. Правило обработки повторных оплат лучше определить заранее, включая действия сотрудника и записи в заказе.\n\n### Как оформить частичный возврат за один товар?\n\nСценарий учитывает состав заказа, сумму возвращаемой позиции и ранее выполненные возвраты. До разработки уточняют, как выбранный способ оплаты обрабатывает такой вариант и как магазин контролирует доступный остаток.\n\n### Какие тесты нужны перед запуском оплаты?\n\nПроверяют успешную и неуспешную оплату, прерванную попытку, повторную оплату, повторное уведомление, отмену заказа и возврат. Если в проекте предусмотрены частичные возвраты или изменение заказа после создания платежа, эти ситуации также включают в проверку.","\u003Cp>Покупатель оформил заказ, деньги списались, а на странице магазина остаётся статус «ожидает оплаты». Или заказ отменили, но сотрудник не понимает, требуется ли возврат и где проверить его результат. Такие ситуации возникают, когда интеграция интернет-магазина с платёжными системами ограничена подключением способа оплаты без правил для подтверждения, отмены и возврата.\u003C\u002Fp>\n\u003Cp>Платёжный модуль связывает сайт, платёжную систему и обработку заказа. Ошибка в переходе статусов может привести к повторной оплате, заказу без подтверждённого платежа или путанице при возврате. До разработки стоит согласовать полный путь заказа: от создания оплаты до фиксации результата.\u003C\u002Fp>\n\u003Ch2>Интеграция интернет-магазина с платёжными системами после нажатия «Оплатить»\u003C\u002Fh2>\n\u003Cp>После подтверждения корзины магазин создаёт заказ и передаёт в платёжную систему данные, необходимые для оплаты. Покупатель переходит к платёжной форме или использует другой интерфейс, предусмотренный сценарием. Затем сайт получает подтверждение результата и меняет состояние заказа по заранее определённым правилам.\u003C\u002Fp>\n\u003Cp>Возврат покупателя на сайт не подтверждает оплату. Он мог закрыть вкладку, потерять соединение или вернуться до завершения операции. Статус оплаты следует менять по отдельному подтверждению, предусмотренному технической схемой платёжной системы.\u003C\u002Fp>\n\u003Cp>Для каждого результата нужны понятные действия сайта и сотрудников:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>платёж подтверждён;\u003C\u002Fli>\n\u003Cli>платёж отклонён;\u003C\u002Fli>\n\u003Cli>покупатель прервал оплату;\u003C\u002Fli>\n\u003Cli>подтверждение пришло позднее;\u003C\u002Fli>\n\u003Cli>покупатель повторно открывает ссылку на оплату;\u003C\u002Fli>\n\u003Cli>у одного заказа несколько попыток оплаты.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Отсутствие сценариев отмены, возврата и подтверждения оплаты приводит к ошибкам обработки заказа. Заранее стоит определить, когда доступна новая попытка, сохраняется ли прежняя ссылка и как исключаются две действующие операции по одному заказу.\u003C\u002Fp>\n\u003Ch2>Требования к заказу при подключении онлайн-оплаты\u003C\u002Fh2>\n\u003Cp>Карточка заказа должна содержать данные для сопоставления с операцией в платёжной системе. Обычно определяют внутренний номер заказа, сумму, состав покупки, способ доставки и контакты покупателя — в объёме, нужном для выбранного сценария. Состав полей и формат передачи сверяют с документацией платёжной системы и требованиями проекта.\u003C\u002Fp>\n\u003Cp>Отдельно задают правила изменения заказа после создания оплаты. Например, покупатель меняет количество товаров, способ доставки или применяет промокод. Если меняется сумма, созданная операция может перестать соответствовать текущему заказу. Для такой ситуации определяют сценарий: отменить незавершённую попытку, создать новую или ограничить редактирование до окончания оплаты.\u003C\u002Fp>\n\u003Cp>Стоит выбрать источник актуальных данных о сумме и составе заказа. При расхождении сотрудники должны понимать, что сверять: данные заказа до перехода к оплате, ответ платёжной системы или журнал изменений. Это особенно нужно при нескольких попытках оплаты.\u003C\u002Fp>\n\u003Ch2>Статусы оплаты и заказа\u003C\u002Fh2>\n\u003Cp>Статус заказа и статус платежа описывают разные события. Заказ может быть создан, собран, отменён или передан в доставку. Платёж может ожидать завершения, быть подтверждён, отменён или находиться в обработке. Связь между этими состояниями определяется правилами проекта.\u003C\u002Fp>\n\u003Cp>Перед интеграцией полезно составить таблицу переходов: внешнее событие, статус платежа, действие с заказом и действие сотрудника. Подтверждённый платёж может переводить заказ в обработку, а неподтверждённый — оставлять возможность повторной попытки. У каждого состояния должны быть понятны ответственное действие и следующий допустимый переход.\u003C\u002Fp>\n\u003Cp>Отмену заказа нужно рассматривать отдельно для разных этапов: до подтверждения оплаты, после подтверждения и после передачи товара. Автоматическая отмена заказа не подтверждает возврат денег покупателю. Эти операции следует фиксировать раздельными статусами или служебными отметками.\u003C\u002Fp>\n\u003Ch2>Возвраты через платёжную систему\u003C\u002Fh2>\n\u003Cp>Возврат начинается с проверки исходной операции. Для него могут потребоваться идентификатор платежа, сумма возврата, причина в учётной записи магазина и сведения о позиции заказа. Набор данных зависит от выбранного способа оплаты и правил проекта.\u003C\u002Fp>\n\u003Cp>Отдельного сценария требует частичный возврат: когда из заказа исключают одну позицию, меняют количество товара или возвращают часть покупки. Сайт должен хранить связь исходной оплаты с уже возвращёнными суммами. Иначе есть риск оформить возврат на сумму, превышающую остаток по операции.\u003C\u002Fp>\n\u003Cp>Следует разделить отмену незавершённой оплаты, возврат подтверждённого платежа и ручное решение вне автоматизированного процесса. Для каждого действия определяют исполнителя, место фиксации причины и признак завершения. Статус «заявка на возврат создана» не означает, что операция подтверждена платёжной системой.\u003C\u002Fp>\n\u003Ch2>Уведомления и обработка сбоев в платёжной интеграции\u003C\u002Fh2>\n\u003Cp>Внешнее подтверждение может не попасть на сайт с первой попытки из-за временной недоступности, ошибки настройки адреса уведомлений или сбоя на стороне магазина. Повторные уведомления нужно обрабатывать безопасно: одинаковое событие не должно повторно менять остатки, создавать дубликаты документов или отправлять покупателю несколько одинаковых сообщений.\u003C\u002Fp>\n\u003Cp>В журнале сайта не следует хранить платёжные реквизиты. Для разбора ситуации достаточно фиксировать идентификаторы заказа и операции, время события, тип ответа, результат обработки и понятную причину ошибки. Такие записи помогают сопоставить обращение покупателя с конкретной операцией без лишних данных.\u003C\u002Fp>\n\u003Cp>До запуска нужно определить поведение системы, если сайт недоступен в момент оплаты: как обрабатываются повторные уведомления, каким способом проверяется состояние операции и что делает сотрудник, если у покупателя есть подтверждение оплаты, а заказ ещё не обновился.\u003C\u002Fp>\n\u003Ch2>Выбор платёжной системы для интернет-магазина\u003C\u002Fh2>\n\u003Cp>Выбор зависит от сценариев магазина: кто оформляет заказы, нужна ли оплата по ссылке, возможна ли частичная отмена, используются ли разные способы оплаты и как оформляются возвраты.\u003C\u002Fp>\n\u003Cp>Техническая проверка включает способ интеграции, документацию по уведомлениям, тестовый контур, требования к данным заказа и порядок диагностики ошибок. Если магазин работает на «1С-Битрикс: Управление сайтом», это CMS для публичной части сайта, каталога и оформления заказа. Внутреннюю работу с обращениями и клиентами рассматривают отдельно: она не заменяет настройку платежей на сайте.\u003C\u002Fp>\n\u003Cp>В границах работ стоит зафиксировать, кто предоставляет доступы и документацию, кто проверяет тестовые операции, какие сценарии входят в проверку и кто принимает результат. Формулировки о подключении оплаты недостаточно, если не определены отмены, возвраты и обработка сбоев.\u003C\u002Fp>\n\u003Ch2>Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Ch3>Что проверить до начала интеграции с платёжной системой?\u003C\u002Fh3>\n\u003Cp>Нужны схема оформления заказа, способы оплаты, правила изменения суммы после оформления, сценарии отмены и возврата. Отдельно определяют статусы для покупателя и служебные статусы для сотрудников.\u003C\u002Fp>\n\u003Ch3>Можно ли считать заказ оплаченным после возврата покупателя на сайт?\u003C\u002Fh3>\n\u003Cp>Нет. Возврат на сайт не всегда означает завершение операции. Статус оплаты меняют по подтверждению, предусмотренному технической схемой платёжной системы.\u003C\u002Fp>\n\u003Ch3>Что делать при двойной оплате одного заказа?\u003C\u002Fh3>\n\u003Cp>Проверяют, какие операции связаны с заказом, какие из них подтверждены и доступен ли возврат по одной из них. Правило обработки повторных оплат лучше определить заранее, включая действия сотрудника и записи в заказе.\u003C\u002Fp>\n\u003Ch3>Как оформить частичный возврат за один товар?\u003C\u002Fh3>\n\u003Cp>Сценарий учитывает состав заказа, сумму возвращаемой позиции и ранее выполненные возвраты. До разработки уточняют, как выбранный способ оплаты обрабатывает такой вариант и как магазин контролирует доступный остаток.\u003C\u002Fp>\n\u003Ch3>Какие тесты нужны перед запуском оплаты?\u003C\u002Fh3>\n\u003Cp>Проверяют успешную и неуспешную оплату, прерванную попытку, повторную оплату, повторное уведомление, отмену заказа и возврат. Если в проекте предусмотрены частичные возвраты или изменение заказа после создания платежа, эти ситуации также включают в проверку.\u003C\u002Fp>\n"]