Интеграция с платёжными системами: как не пролить слёзы, даже если ты чайник

Системный аналитик Intaro Кристина о том, как создавать эффективные интеграции и на что обратить внимание при проектировании. Внутри — чек-лист для самопроверки.

В этой статье мы также обсудим, стоит ли использовать готовые модули или лучше разработать собственное решение.

Основные способы оплаты на сайте

• СБП — сервис для межбанковских переводов по номеру мобильного телефона;
• Интернет-эквайринг — прием электронных платежей за товары и услуги;
• Платежные агрегаторы — посредники с разными способами приема платежей для компаний и предпринимателей;
• Электронные кошельки — это онлайн-сервис для хранения и управления финансами, а также проведения финансовых операций через интернет. Это виртуальный счет, куда пользователи вносят средства из разных источников и используют их для онлайн-покупок.

Кредиты/рассрочки:

• Через банки — оплата заказа в рассрочку или кредит через банк позволяет покупателям оплачивать товары и услуги частями в течение определенного времени. При оформлении рассрочки покупатель заключает договор с банком, который оплачивает покупку, а затем клиент возвращает средства банку;
• Оплата заказа в рассрочку или кредит через кредитного брокера — услуга финансирования от кредитных посредников или брокеров, которые предоставляют доступ к кредитам и рассрочкам от разных кредитных организаций. Брокеры выступают посредниками между покупателями и кредиторами, а процесс расчетов аналогичен оформлению рассрочки или кредита через банк;

• Оплата частями — это возможность покупать товары или услуги, оплачивая их стоимость постепенно. Покупатель получает товар сразу, а платит за него частями по условиям рассрочки от интернет-магазина или с помощью кредита.

Теперь обсудим варианты настройки интеграции платежных систем с вашими системами.

Рассмотрим несколько подходов к интеграции

При интеграции платежной системы и в других подобных задачах необходимо выбрать между готовым интеграционным решением и разработкой индивидуального. Готовые решения могут обеспечить быстрый запуск и уменьшение первоначальных расходов, однако они также могут влечь за собой риски и ограничения. Интеграционные модули не всегда доступны публично, поэтому не стесняйтесь обращаться к представителям платежной системы за информацией о наличии подходящих решений.

Чтобы принять решение, важно составить перечень требований к интеграционному модулю. Это позволит оценить, насколько хорошо готовое решение соответствует специфике проекта. Требования могут включать:

• Совместимость с вашей платформой и технологическим стеком;
• Поддержка необходимых способов оплаты и валют;
• Гибкость настройки и возможность кастомизации;
• Уровень безопасности и соответствие стандартам защиты данных;
• Наличие поддержки и регулярных обновлений от разработчика модуля.

Если вы склоняетесь к использованию готового интеграционного модуля, необходимо учитывать потенциальные риски и недостатки:

• Прекращение поддержки. Разработчики модуля могут в любой момент прекратить его обновление и поддержку, что оставит вашу платежную систему уязвимой для безопасности или несовместимой с новыми версиями вашей платформы;
• Ограниченная совместимость. Готовые модули могут не полностью соответствовать уникальным требованиям вашего проекта, особенно если у вас есть специфические настройки или кастомизация;
• Трудности с кастомизацией. Без доступа к исходному коду или поддержки разработчиков, дополнительная настройка модуля может быть сложной.

При необходимости кастомизации модуля, важно оценить свои ресурсы и возможности:

• Сотрудничество с разработчиками модуля. В некоторых случаях разработчики могут предложить услуги по кастомизации модуля под ваши требования;
• Разработка собственных решений. Если кастомизация критична, возможно, стоит рассмотреть разработку собственного модуля;
• Покупка и кастомизация. В случае, если модуль полностью открыт и доступен для покупки, вы можете перенести его на свой сервер и внести необходимые изменения самостоятельно, учитывая, что у вас есть соответствующие права и возможности для этого.

Далее мы подробнее рассмотрим создание собственного интеграционного модуля. Обсудим различные подходы к взаимодействию между системами, рассмотрим вопросы, на которые следует обратить особое внимание, а также выявим перечень настраиваемых параметров модуля.

Разработка собственного интеграционного модуля

Интеграционный контур может быть выстроен по нескольким принципам:

• Интеграция с платежной системой настроена в одной системе;
• Интеграция с платежной системой настроена в нескольких системах.

Рассмотрим подробнее каждый принцип.

Интеграция с платежной системой настроена в одной системе

Самая упрощенная схема взаимодействия, когда у вас есть только одна система, которая будет обрабатывать платежи. В таком случае, интеграционный контур выглядит следующим образом:

Здесь представлены 3 ключевых типа операций:

• Заявка на оплату: это инициирующее действие, когда «Система 1» посылает запрос в платежную систему на проведение оплаты. Это может сопровождаться передачей деталей платежа, таких как сумма, валюта, и идентификационные данные плательщика;
• Обмен статусами: это двунаправленный обмен информацией, в ходе которого платежная система сообщает «Системе 1» о статусе обработки платежа. Это может включать статусы, такие как «в обработке», «оплачено», «отклонено» и т.д;
• Отмены/возвраты: если транзакция должна быть отменена или средства возвращены, то предусмотрен соответствующий процесс. Это может потребоваться в ситуациях, когда происходит отмена или возврат заказа или ошибка в транзакции.

На изображении могут быть отмечены не все потоки данных, так как они могут меняться в зависимости от документации платежных систем и требований к бизнес-процессам.

А как быть, если в контуре несколько систем, в которых должна быть реализована возможность оплаты, но, при этом, построить полную интеграцию нужно только в одной из систем?

Рассмотрим следующий подход, когда в интеграционном контуре «Система 2...N» представляет собой набор систем (CMS, OMS, мобильное приложение), каждая из которых обладает функциональностью инициации оплаты заказа. При таком подходе «Система 2..N» производят сбор и передачу данных для оплаты в «Систему 1», которая, в свою очередь, интегрирована с платежной системой.

Процесс обработки оплаты выглядит следующим образом:

• Инициация платежа: Клиент выбирает оплату заказа в любой из систем (2...N), будь то CMS для управления контентом, OMS для обработки заказов, или мобильное приложение для покупателей;

• Передача данных: Системы 2...N собирают необходимую информацию о платеже и передают ее в «Систему 1» через событие создания заказа;

• Обработка оплаты: «Система 1» получает данные от систем 2...N и генерирует запрос на оплату. В этой системе происходит интеграция с платежной системой, и она выступает в качестве центрального узла, обрабатывающего все платежи;

• Предоставление ссылки на оплату: После создания запроса «Система 1» передает ссылку для оплаты непосредственно клиенту через SMS, email, или push-уведомления. Клиент использует эту ссылку для проведения платежа в платежной системе. (В целом, можно рассматривать передачу полученной ссылки на оплату обратно в «Системы 2...N», но есть риски возникновения временного лага и долгого ожидания покупателя с момента оформления заказа до момента перехода на платежную систему);

• Обратная связь от платежной системы: После осуществления платежа платежная система отправляет статус платежа обратно в «Систему 1», которая может затем информировать системы 2...N об успешной оплате или необходимости дальнейших действий в случае неудачи.

Важно отметить, что при таком подходе «Система 1» может действовать как микросервис, интегрированный с различными платежными системами, и обеспечивать централизованную обработку платежей для всех систем 2...N. Микросервис для платежных систем представляет собой независимый компонент, который специализируется на определенной функциональности — обработке платежей.

Подведем итоги такого подхода к интеграции:

Плюсы

• По большей части, доработки потребуются только в одной системе. Трудозатрат на реализацию будет меньше, чем если бы интеграция настраивалась бы в нескольких системах;
• У вас не возникнут вопросы или проблемы с доступами к платежному сервису так как только одна из систем обращается в платежную систему.

Минусы

• Если покупатель получит ссылку на оплату заказа через коммуникации:

1. Пользователь может передумать и отказаться от покупки, так как он переходит не сразу на страницу для оплаты заказа, а получает ее чуть позже;
2. Вам придется потратиться на коммуникации с клиентом в случае.

• Если системы 2...N зависят от получения платежной ссылки от «Системы 1», существует опасность, что из-за возможных сбоев «Система 1» не сможет своевременно предоставить эту ссылку. В качестве решения этой проблемы можно установить временной лимит для ожидания платежной ссылки. Если в установленный срок ссылка не была получена, пользователи должны получить уведомление о том, что платежная ссылка будет отправлена им по SMS/Email.

Если минусы критичны, предлагаем рассмотреть другой вариант, когда интеграция с платежными сервисами строится в нескольких системах или платежная система предоставляет виджет или SDK для инициализации платежа.

Интеграция настроена в нескольких системах или у нас встроен виджет для оплаты

В нашем случае, системы 2...N могут сами сформировать заявку на оплату и переадресовать пользователя в платежную систему для оплаты заказа или производят оплату с помощью виджета. В системе 1 происходит обработка заказа (OMS система) и все следующие обмены данными по заказу и оплате происходят в ней.

Процесс обработки заказа выглядит следующим образом:

• Системы 2...N – Это могут быть различные системы, такие как веб-платформы, мобильные приложения или различные торговые точки, которые могут самостоятельно создавать заявки на оплату. Эти заявки содержат указание типа оплаты и идентификатор оплаты. После создания заявки системы способны направлять пользователя непосредственно в платежную систему через редирект или позволяют осуществлять платеж через встроенный платежный виджет;

• Система 1 – Это централизованная система управления заказами, которая занимается обработкой заказов. Все дальнейшие операции, связанные с данными по заказу и оплате, проходят через эту систему. Это включает обмен статусами с платежной системой, чтобы отслеживать состояние платежа, а также управление отменами и возвратами, если это необходимо;

• Платежная система – Отвечает за обработку финансовых транзакций. Она принимает запросы на оплату от «Системы 2...N» или «Системы 1», проводит транзакции и сообщает об итогах (статусах оплаты, отменах, возвратах) обратно в «Систему 1».

Подведем итоги такого подхода к интеграции:

Плюсы

• Возможность «Систем 2...N» напрямую взаимодействовать с платежной системой для проведения оплаты;
• Пользователи могут совершать импульсивные покупки, а это рост среднего чека покупателя;
• Эта схема позволяет распределить нагрузку по обработке платежей между разными системами, при этом сохраняя централизованное управление в «Системе 1». Это обеспечивает гибкость пользовательского опыта и упрощает процессы управления заказами и платежами внутри компании.

Минусы

• Интеграция занимает больше времени, так как нужно вставить виджет, реализовать API-методы для обмена данными систем с платежной системой;
• Нужно рассмотреть такие альтернативные сценарии:

1. при которых системы 2…N не смогли сформировать ссылку на оплату. В таком случае система, в которой настроена полная интеграция, должна формировать ссылку сама в случае, если в заказе не был указан идентификатор оплаты или он не был получен в заказе в течение времени N;
2. предусмотреть разделение логики, если у вас производится отправка ссылки на оплату. Решение аналогично описанному решению выше;
3. уточнить возможности платежного сервиса на возможность осуществлять запросы с двух систем (будут ли запросы происходить с одним ключом доступа или для каждой системы будет выдан свой ключ для запросов).

Требования к интеграции

Требования к интеграции с платежными системами могут отличаться в зависимости от выбранного типа оплаты, который планируется внедрить. В своей работе мы группируем их по нескольким типам:

• Группа 1

СБП;
Интернет-эквайринг;
Платежные агрегаторы;
Электронные кошельки.

• Группа 2

Кредиты от банков и брокеров;
Оплата частями.

• Группа 3

Рассрочки от банков и брокеров.

В нашей работе мы часто создаем интеграционные модули для процесса оплаты. Интеграционный модуль представляет собой ключевой компонент, который мы разрабатываем, чтобы настроить взаимодействие между различными системами согласно определенным настройкам. Это позволяет системам успешно обмениваться данными и взаимодействовать друг с другом в рамках процесса оплаты. Настройки могут отличаться в зависимости от платежной системы и системы, в которую мы интегрируем модуль, но основные этапы работ:

• Получение доступов к тестовой среде для отладки интеграции;
• Реализация нового модуля и его настройка;
• Проведение настроек на стороне платёжного сервиса;
• В качестве важного, зачастую обязательного этапа, следует разместить на вашем сайте или в приложении четкие инструкции по проведению оплаты, а также логотип платежной системы.

Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

Заполнить заявку 13261 тендер
проведено за восемь лет работы нашего сайта.

В следующих разделах мы подробнее рассмотрим список вопросов, на которые необходимо обратить внимание при проектировании собственного интеграционного модуля, а также возможный список настроек модуля.

Группа 1. Интеграция с СБП, Интернет-эквайринг, Платежные агрегаторы, Электронные кошельки

Интеграция предполагает настройку основных процессов по созданию/отмене и возврате платежей. В данной группе оплат прорабатываются базовые вопросы и требования.

Вопросы, которые необходимо проработать:

• Как настроить аутентификацию для множества систем, обращающихся к платежной системе? Необходимо ли использовать уникальные учетные данные для каждой системы, или возможно применение единого набора данных для аутентификации?

• Должны ли стоимость услуг, таких как доставка, подъем на этаж или сервисное обслуживание, быть интегрированы в общую стоимость заказа, отправляемую в платежную систему, или эти услуги будут оплачиваться отдельно?

• Можно ли организовать создание нескольких заявок на оплату в рамках одного заказа в платежной системе, чтобы позволить клиентам оплачивать товары и услуги раздельно? (Например, первой заявкой покупатель оплачивает стоимость товаров, а второй заявкой оплачивает услуги по доставке и т.п.)

• Возможно ли формирование нескольких заявок на оплату до момента погашения предыдущих? Это актуально в случае, если клиенты могут совершать несколько покупок одновременно.

На одном из наших проектов при использовании платежной системы «Долями» мы столкнулись с подобной проблемой: если покупатель уже имел одну неоплаченную заявку и мы инициировали создание новой, первая заявка автоматически отклонялась системой. Это приводило к автоматической отмене заказов из-за отсутствия оплаты. Чтобы решить этот вопрос, нам пришлось разработать дополнительную логику, которая позволяла выявлять неоплаченные заказы в системе «Долями» и делать данный тип оплаты недоступным для покупателей.

• Нужно ли в платежную систему передавать ссылки на страницы успешной и неуспешной оплаты или логика отображения страниц будет на стороне продавца?

• Каковы возможности платежной системы по холдированию средств и в какой момент следует подтверждать их списание? Важно определить, будет ли списание средств осуществляться автоматически или вручную, в зависимости от определенных событий.
• Какие бизнес-требования существуют к ограничению доступности определенных типов оплаты, и по каким параметрам определять их доступность для конкретного заказа?

• Нужно ли выводить в интерфейс данные об оплате и если нужно, то какие? (например, ID платежа в платежной системе, дата оплаты в платежной системе и т.п.). При определении данных, которые могут быть вынесены в интерфейс, следует опираться на документацию API.

• В случае, если по интеграции возникнут проблемы, необходимо ли уведомлять ответственных лиц об ошибках? Какой механизм уведомлений об ошибках интеграции предпочтителен, и через какие каналы связи следует их передавать (Email, уведомления в мессенджерах и т.д.)?

• Как будет происходить синхронизация статусов оплаты между платежной системой и вашими системами, и в какой момент заказ будет считаться оплаченным?

• Кто будет отвечать за печать чеков — это будет входить в функционал платежной системы или необходимо наладить печать на стороне продавца?

• Как будет происходить оплата в случае полной или частичной отмены по заказу?

Минимальный список настроек в интеграционном модуле

• Активность интеграционного модуля. Позволяет управлять настройками доступности обмена данными между вашей системой и платежным сервисом;

• Авторизационные данные для запросов API.Тут могут быть указаны идентификаторы кабинетов или токены для запросов к API;

• Ссылки на страницу успешной/неуспешной оплаты заказа. Опционально, необходимо в случае, если со стороны платежного модуля необходимо эти ссылки передавать в запросе API;

• Настройки с ограничениями доступности типа оплаты (опционально). Данная настройка подойдет, если в интеграционном модуле вы захотите реализовать возможность управления доступностью типа оплаты по минимальной и максимальной стоимости заказа, признакам товара/заказа для которых будет доступен или недоступен данный тип оплаты и другие требования бизнеса;

• Список почт, на который будет отправляться уведомление об ошибке (опционально);

• Маппинг статусов оплаты в платежной системе и маппинг статуса оплаты в вашей системе. Тут стоит остановиться и разобрать настройку подробнее.

Представим, что у нас в платежной системе есть несколько статусов оплаты: «Ожидает оплаты» с символьным кодом «new», «Завершена» с символьным кодом «completed» и «Отклонена» с символьным кодом «Declined». У нас в системе есть два статуса оплаты, это оплачен с символьным кодом «paid» и не оплачен «not paid». Мы по своим процессам понимаем, что только для статуса «Завершена» в заказе должен присваиваться статус оплаты «Оплачен», а в остальных случаях заказ считается неоплаченным и в обработку дальше не идет.

Теперь разберемся со статусами заказа. Представим, что у нас автоматическая смена статусов должна происходить по заказу и смена статусов зависит от статуса оплаты. Для оплаченных заказов, по нашим бизнес-процессам, заказ должен отправляться на сборку и в нашей системе это статус заказа «Требуется сборка».

Группа 2. Кредиты банков. Кредиты брокеров, оплата заказа частями

При проработке интеграций с банками-кредиторами, банками-агрегаторами и банками, принимающими оплату по частям, важно учитывать вопросы и настройки модуля, описанные в разделе с интеграцией для первой группы платежных систем. Кроме того, необходимо учитывать дополнительные детали, описанные ниже.

Вопросы, которые необходимо проработать:

• Как происходит подписание кредитного договора между покупателем и банком или покупателем и брокером? Кто берет на себя затраты на отправку смс с договором или отправку курьера для подписания договора? (тут стоит отметить тот факт, что банк не одобрит кредит, пока покупатель не подпишет договор, а у вас на этом процессе может остановиться обработка заказа)

• Может ли продавец управлять доступностью банков и кредитных программ через личный кабинет или API при интеграции с кредитным брокером? Если возможность настройки доступности банков и кредитным программ по API существует, нужно ли эту настройку выносить в интеграционный модуль?

• Существуют ли у банка определенные ограничения по минимальной и максимальной сумме кредитуемых заказов или категориям товаров, которые не могут быть оплачены в кредит? Каковы решения для сценариев, когда стоимость заказа превышает максимальный лимит кредита установленный банком?

К примеру, банк установил предел в 100 000 рублей как максимально допустимую сумму для кредитной покупки, тогда как ваш клиент сделал заказ на сумму 105 000 рублей. В таком случае банк немедленно откажет в кредитовании, из-за чего покупатель может остаться недоволен из-за невозможности оплатить покупку кредитом. Чтобы предотвратить подобную ситуацию, можно предусмотреть введение ограничений, которые будут исключать кредитный способ оплаты для покупателя при превышении установленной суммы заказа или заблокировать возможность выбора этого способа оплаты для сотрудников-операторов.

• Возможно ли изменение деталей заказа после того, как заявка уже была создана в банке, и какие данные подлежат корректировке? Необходимо определить процесс согласования изменений с банком в случае отсутствия товара или ошибок в контактных данных.

• Если вы только начинаете работать с кредитами, необходимо подумать, будет ли обработка заказа с типом оплаты в кредит отличаться от обработки заказов с другими способами оплат? Например, нужно ли в ваших системах использовать статусы, которые отображают текущее состояние работы с кредитной заявкой, например, «В процессе оформления кредита» , «Ожидаем оплаты кредита», «Отказ банка» и т.п.

Минимальный список настроек в интеграционном модуле

Дополнительных настроек в модуле вводить не требуется, достаточно общих настроек, описанных в группе 1.

Группа 3. Рассрочки от банков и брокеров

В рамках рассрочки гораздо больше подводных камней, чем с другими типами оплат, все они связаны с тем, что процент за рассрочку платит продавец, а не покупатель. Аналогично с предыдущим пунктом, важно учитывать вопросы и настройки модуля, описанные в разделе с интеграцией для первой и второй группы платежных систем. Кроме того, необходимо учитывать дополнительные детали, описанные ниже.

Вопросы, которые необходимо проработать:

• Какие критерии определяют возможность оформления покупки в рассрочку? Рассмотрим, например, ситуацию, когда продавец несет затраты по процентам рассрочки, как это отразится на стоимости недорогих товаров, таких как салфетки стоимостью 100 рублей, при оформлении рассрочки на 12 месяцев под 7% годовых.

• Нужно на этапе обсуждения с платежной системой обсудить, как производится расчет скидки на товары и заказ у банка/брокера и в вашей системе. Разные расчеты скидок могут привести к тому, что округление будет в двух системах реализовано по-разному, а следовательно и итоговая сумма по заказу/перечисленная от банка будет отличаться.

Что нужно выяснить и согласовать в рамках данного блока вопросов:

1. Как считать скидку, на каждый товар отдельно в составе заказа или на всю позицию?
2. Как считается округление, на каждый товар или на позицию в заказе?
3. Округление после применения скидки считать в большую или в меньшую сторону?

Рассмотрим пример:

В заказ добавлен товар А с ценой 73879 рублей в количестве 2 штуки и товар Б с ценой 320 рублей в количестве 9 штук. Скидка на рассрочку по заказу составляет 9%. Логика округления в системе настроена следующим образом:

- скидка считается на каждый товар отдельно – округление скидки идет в пользу продавца, т.е. скидка округляется в меньшую сторону

Произведем расчет скидки на товар с учетом настроенного округления:

Для товара А:
73879 * 9 ÷ 100 = 6 649,11 округляем до 6649 - это цена одного товара с учетом скидки по рассрочке и логики округления.(73879 - 6649) * 2 = 134460 - стоимость товара в заказе с рассрочкой.

Для товара Б:
320 * 9 ÷ 100 = 28(320 - 28) * 3 = 876

Сумма
134460 + 876 = 135336

• Следует ли внедрить механизм проверки соответствия итоговых расчетов стоимости, которую должен выплатить банк, с суммой, указанной в заявке, отправленной через API? Такая валидация позволит своевременно выявлять расхождения и корректировать их, например, при обнаружении несоответствия установленных процентных ставок между вашей системой и банком.

Минимальный список настроек в интеграционном модуле

В дополнение к базовым настройкам, упомянутым в 1 группе, для управления рассрочками рекомендуем вывести параметр настройки, где будут указываться длительность рассрочки в месяцах и процентная ставка. При работе с брокером, который взаимодействует с различными банками, имеющими свои условия кредитования, целесообразно детализировать эту настройку для каждого банка отдельно.

Успешная интеграция требует глубокого понимания как технических аспектов, так и бизнес-процессов. От выбора между готовым модулем и разработкой собственного решения до проработки деталей интеграционного контура и управления рисками – каждый шаг имеет значение.

Ключ к эффективной интеграции лежит через тщательное планирование, учет индивидуальных потребностей проекта и гибкость в принятии решений. В конечном счете, правильно выполненная интеграция не только оптимизирует процессы оплаты, но и вносит значительный вклад в удовлетворенность клиентов и финансовую стабильность компании.

А чтобы ничего не упустить при проработке интеграции, держите чек-лист для самопроверки. Он является скорее отправной точкой, чем исчерпывающим руководством. В зависимости от специфики ваших проектов и процессов, этот список может потребовать дополнений или изменений.