Как работает интеграция платежей — простыми словами для владельца бизнеса
После того как на сайт добавили кнопку «Оплатить картой», большинство владельцев бизнеса считают вопрос закрытым — деньги приходят, заказ появляется, значит интеграция готова. Проблема всплывает в первый неудачный день: клиент пишет «деньги списались, заказа нет», или в конце месяца в выписке оказывается меньше, чем ожидалось. И тогда непонятно, к кому идти — к разработчикам сайта, к платёжному провайдеру или в банк.
Причина в том, что интеграция платежей — это не одна кнопка, а цепочка, в которой участвуют минимум три разные стороны, передающие данные друг другу. Если не знать, где именно цепочка может порваться, каждая сторона будет кивать на соседнюю. Дальше — не код, а объяснение простыми словами: что происходит в момент заказа, когда деньги реально попадают на ваш счёт и как понять, чья это зона ответственности, когда что-то пошло не так.
Путь от заказа до денег на счёте
С момента, когда клиент нажимает «Оплатить», до момента, когда деньги видны на вашем счёте, проходит три отдельных шага — и за каждый отвечает своя сторона.
1. Заказ создаётся на вашем сайте, а номер карты туда не попадает
Когда клиент подтверждает корзину, ваш сайт делает только одно — передаёт провайдеру сумму и номер заказа. Номер карты, срок действия и CVV сайт не видит и не хранит: клиент вводит их на защищённой странице или в виджете самого провайдера. Это не вопрос вкуса дизайнера — то, что данные карты не проходят через ваш сервер, заметно снижает вашу зону ответственности по стандарту PCI DSS: для бизнеса, использующего готовую платёжную страницу провайдера (Checkout, Elements и подобные), форма проверки по этому стандарту значительно проще, потому что чувствительные данные вообще не касаются вашей инфраструктуры (документ по безопасности Stripe). Если разработчик предлагает сделать «свою» форму для карты ради красивого дизайна — это решение перекладывает всю эту ответственность на вас.
2. Подтверждает банк, а не сайт
Успешна оплата или нет — решает не ваш сайт, а банк, выпустивший карту клиента. Для этого работает дополнительная проверка 3-D Secure: банк может запросить у клиента код из SMS, подтверждение в приложении или отпечаток пальца. Цель этого шага — предотвратить мошенничество при оплате без физического присутствия карты и убедиться, что картой пользуется её настоящий владелец (официальное описание EMVCo). Отсюда вывод: если клиент видит «в оплате отказано», чаще всего дело не в поломке вашего сайта, а в решении банка — просто это решение показывается на вашем экране, и вину списывают на сайт.
3. Результат приходит уведомлением, а не страницей возврата
После оплаты клиента обычно возвращают на ваш сайт, и он видит страницу «спасибо за заказ». Но в реальных системах эта страница — не главный источник подтверждения: клиент может закрыть браузер, потерять связь или выйти из приложения раньше, чем страница успеет открыться. Настоящее подтверждение приходит фоном — отдельным уведомлением от провайдера к вашей системе, которое называется webhook. Почему это уведомление критично важно, разбираем дальше.
«Я оплатил, а заказа нет» — реальная причина пропавшего уведомления
Это самая частая жалоба: деньги списались с карты клиента, а в панели заказ висит «в ожидании» или вообще не появился. Первый инстинкт владельца — обвинить сайт, но проблема обычно в другом месте.
Как описано выше, провайдер сообщает результат оплаты фоновым уведомлением. Если ваша система не приняла его один раз — сервер на секунду завис, сеть подвисла — а провайдер не повторяет отправку, оплата на стороне банка проходит успешно, но ваша система об этом так и не узнаёт. Итог: деньги ушли, заказа нет, а служба поддержки застревает между двумя сторонами.
Это стоит выяснять заранее, а не после первого инцидента — сколько раз провайдер повторяет отправку неудачного уведомления, и фиксирует ли ваша система такие уведомления для проверки. В работе PixelLabs это отдельный шаг интеграции: неудачный запрос не теряется, а запускает механизм автоматического повтора — потому что одно недоставленное уведомление означает один потерянный заказ.
Интеграция платежей — это не кнопка, а цепочка доверия между тремя сторонами, и самое слабое звено в ней обычно не в коде, а в том, что нигде не записано, кто за что отвечает.
Когда деньги реально попадают на ваш счёт
Многие представляют оплату как кассовый аппарат — клиент заплатил, деньги сразу на счёте. На деле это не так.
Сумма, которую заплатил клиент, сначала попадает на счёт провайдера, тот вычитает свою комиссию и переводит остаток на ваш банковский счёт по согласованному графику. Этот промежуточный этап — расчёт — полностью отделён от сообщения «оплата прошла», которое видит клиент на сайте: для клиента операция завершается за секунду, а для вас фактический перевод денег только начинается.
Этот график и процент комиссии нужно зафиксировать в договоре до интеграции, а не выяснять по факту, когда в первой выписке сумма меньше ожидаемой. Прозрачность здесь — тот же принцип, что и в нашей собственной работе: плата за услугу и комиссия за операцию должны быть двумя разными строками, без скрытой надбавки.
Кто должен хранить данные карты
Иногда команда предлагает собирать номер карты прямо в своей форме — «чтобы было быстрее» или «в стиле бренда».
Технически это возможно, но у решения есть цена — как только номер карты проходит через ваш сервер, вы берёте на себя полный объём самого строгого аудита безопасности в финансовой индустрии (PCI DSS): ежегодную проверку, шифрование, контроль доступа и так далее. Если вместо этого использовать готовую страницу или виджет провайдера, основная часть этой нагрузки остаётся на его стороне.
Для малого и среднего бизнеса правильное решение почти всегда одно — использовать готовое решение провайдера, а не заказывать собственную форму для карты. Потеря в «фирменном» виде минимальна, риск — нет.
К кому идти, когда что-то сломалось
Оплата не прошла, вы звоните в поддержку, ваша студия говорит «у нас всё в порядке», провайдер говорит «банк отказал», а банк с вами вообще не разговаривает.
У каждой из трёх сторон своя зона. Если ошибка возникает до создания заказа — страница не открывается, кнопка не работает — это техническая проблема вашего сайта. Если на странице провайдера видно «отказано» — это решение банка, обычно связанное с балансом, лимитом или неудачной проверкой 3-D Secure. Если уведомление вообще не приходит — это пробел в надёжности самой интеграции, и это зона ответственности вашей команды разработки, потому что именно она должна ловить такие случаи и настраивать повтор.
До запуска интеграции разделите эти три зоны письменно — кто отвечает за сайт, кто за сторону провайдера, какой у провайдера реальный канал поддержки (не форма, а человек, с которым можно поговорить). Без этого любая поломка превращается в расследование на несколько дней.
Интеграция платежей — это не разовая настройка, которую можно забыть. Если цепочка «заказ — уведомление — расчёт» не продумана заранее, один и тот же вопрос будет всплывать при каждом изменении — новый провайдер, новая служба доставки, переход на 1С. Наша услуга интеграции систем как раз собирает эту цепочку — платежи, доставку, SMS и бухгалтерию — в одном месте и заранее настраивает повтор для уведомлений, которые не должны теряться.
