При разработке биллингового и рейтингового решения есть важный шаг в конце процесс "котировка-заказ-касса. После оценки событий использования и покупок и выставления счетов клиентам, следующим шагом является обработка платежей. Этот шаг обычно происходит с помощью провайдеров платежных шлюзов, позволяющих обрабатывать способы оплаты и инкассации через различные платежные процессоры.
A Платежный шлюз Включение в биллинговую и рейтинговую систему может быть очень мощной функцией, поскольку обработка платежей закрывает последний разрыв в потоке "заказ - деньги". Использование платежного шлюза - это тот подход, которого мы решили придерживаться при поддержке сбора платежей в Tridens MonetizationИ мы добились этого, разработав собственный платежный шлюз Tridens.
Оглавление
Схема процесса оплаты
Существует несколько существующих способы оплаты, такие как банковские переводы, платежи наличными, SEPA и платежи по картам. В данном объяснении мы сосредоточимся на последних, поскольку платежи по кредитным и дебетовым картам являются одним из наиболее часто используемых методов оплаты при обработке платежей.
Некоторые детали могут отличаться в отдельных отраслях, но схема процесса оплаты остается достаточно простой для любого случая:
- У клиента есть счет с причитающейся суммой, который он решает оплатить с помощью карты
- Зашифрованная информация о карте проходит через платежный шлюз к платежному процессору
- Платежный процессор проверяет, возможна ли такая продажа, связываясь с банком-эмитентом
- Банк-эмитент может либо одобрить запрос, либо отклонить его, если у клиента недостаточно средств
- Платежный процессор сообщает Вам, что продажа прошла успешно, и информирует Ваш торговый банк о зачислении средств на Ваш банковский счет
- Единственное оставшееся действие - это расчет, в ходе которого эмитент карты клиента завершает фактическое перечисление средств на Ваш счет.
Продажа состоит из двух действий - авторизации средств и инкассации средств. В некоторых отраслях и случаях использования мы рассматриваем эти два действия отдельно. Например, клиент хочет зарядить свой электромобиль на 30 евро. Платежный шлюз связывается с платежным процессором для авторизации этой суммы на карте клиента.
Когда сессия заканчивается, происходит ссылочная транзакция для получения этих средств (завершение продажи). Собранная сумма не обязательно должна составлять 30 евро. Она может быть меньше из-за того, что электромобиль клиента заправляется до достижения лимита.
Проектирование платежного шлюза
Мы быстро поняли, что для поддержки обработки платежей в нашем решении нам необходимо взаимодействовать с платежными процессорами, или, как мы их называем, провайдерами платежей. Эти компании хорошо известны своими услугами по обработке платежей, которые их клиенты ежедневно используют для обработки онлайновых платежей. Среди таких компаний - Paypal, Stripe, Authorize.Net, Braintree (решение Paypal), Wirecard, Cybersource и др.
Эти провайдеры иногда сильно различаются по предлагаемым ими услугам, что привлекает клиентов с различными потребностями и запросами. Когда речь идет о работе с карточными платежами, необходимо поддерживать всего несколько основных операций. Принимая во внимание процесс карточных платежей, нам необходимо охватить следующее:
- Токенизация: Преобразование карты в зашифрованный токен. Преобразование происходит через защищенное соединение с платежным шлюзом или с помощью формы пользовательского интерфейса. Клиент непосредственно заполняет форму пользовательского интерфейса, сгенерированную в приложении
- Авторизация (Authorization): Резервирование средств на карте - иногда также используется для Токенизации
- Депозит: Собирает зарезервированные средства посредством транзакции с отсылкой на предыдущую авторизацию
- Условное депонирование - Продажа: Комбинирует авторизацию и депонирование - повышает скорость обработки, когда это возможно
- Void (аннулирование): Аннулировать неурегулированную сделку
- Возврат: Аннулировать выполненную транзакцию
На приведенном ниже рисунке показан высокоуровневый обзор того, как наш Платежный шлюз работает с обработкой платежей, с учетом описанных операций.
Обработка платежей с помощью платежного шлюза Tridens
В одной из наших предыдущих статей мы рассказывали об интеграции Oracle BRM с различными платежными провайдерами (Интеграция Oracle BRM с поставщиками платежей) для обработки платежей. Решение Tridens Payment Gateway, которое мы использовали, изначально было разработано как часть нашего собственного решения Tridens Monetization.
Платежный шлюз Tridens - это отдельный компонент для взаимодействия с различными провайдерами, предлагающими услуги по обработке платежей. Он поддерживает все необходимые операции для взаимодействия со сторонними службами, предоставляющими услуги по обработке кредитных карт, дебетовых карт и других методов оплаты, предлагая унифицированный набор запросов и ответов и транслируя их в соответствии со спецификациями каждого провайдера.
В Tridens Monetization токены платежных методов хранятся в зашифрованном виде в мобильном приложении или через интегрированную форму до входа в нашу систему, что в то же время работает на достижение 12 требований для соответствия стандарту PCI-DSS. Каждый из наших клиентов Tridens Monetization может настроить свою систему на работу с различными провайдерами платежей - Wirecard, Braintree (решение для Paypal), Paypal, Stripe, Authorize.Net, Cybersource и т.д.
Ниже приведен пример процесса коммуникации.
Заключение
Разработав Платежный шлюз Tridens как отдельный компонент для обработки платежей, мы можем использовать его и как самостоятельный сервис, и интегрировать в другие системы. Подход, основанный на унифицированных запросах и ответах, позволяет быстро разрабатывать специфические функции платежных провайдеров, и даже добавление новых платежных провайдеров не является сложной задачей. Возможность быстрой разработки интеграций с дополнительными платежными процессорами крайне важна, когда у Вас есть такой продукт, как Tridens Monetization. Tridens Monetization обслуживает клиентов из различных отраслей с индивидуальными потребностями и требованиями. Разнообразие потребностей и требований обусловлено либо различными вариантами использования, либо местными особенностями, поскольку не все платежные провайдеры предоставляют услуги в одних и тех же странах.
Хотите получить больше информации о наших решениях? Оставьте комментарий ниже или Запланируйте демонстрацию!
