Чтобы лучше поддерживать быстрое развитие транзакционного бизнеса, Платежный центр Mafengwo прошел этап структурной перестройки «сокращения и сжигания» с этапа «сокращения и сжигания», который первоначально поддерживал только основные платежи и возвраты, и завершил реализация комплексной формы продуктовой платформы Эволюция стадии «осаждения и накопления».

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

1. Платежный центр 1.0

На начальном этапе, чтобы быстро реагировать на оплату, возмещение и некоторые основные потребности бизнеса, платежный центр в основном отвечает за доступ к платежным каналам (Alipay, WeChat, Lianlian и т. д.), и каждое бизнес-направление реализует кассира соответственно, а затем звонит в платежный центр для оплаты. Схема взаимодействия бизнес-системы, платежного центра и стороннего канала выглядит следующим образом:

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

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

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

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

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

2. Платежный центр 2.0

Архитектура 2.0 помещает публичные транзакции, платежи и финансы каждого бизнеса в платежный центр и в основном решает следующие три основные проблемы:

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

2.1 Основные компетенции

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

В настоящее время к основным возможностям, предоставляемым платежным центром бизнесу, относятся:

Платежная платформа: пользователи могут использовать WeChat, Alipay и другие сторонние платформы для совершения платежа.
Быстрая оплата: пользователи предоставляют данные банковской карты для удобной оплаты
Оплата по протоколу: после того, как пользователь завершит авторизацию, он может совершить удобный платеж, не прерывая работу пользователя.
Кредитный платеж: пользователи могут выбрать Huabei и другие продукты в рассрочку для оплаты овердрафта.
Платежи за рубежом: пользователи могут выбирать каналы оплаты за рубежом для совершения покупки зарубежных товаров.
Автономный платеж: пользователи могут выбрать канал ToB для совершения платежа в определенных сценариях.

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

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

2.2 Архитектурный дизайн

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

Как показано на рисунке, архитектура в основном делится на три уровня:

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

2.2.1 Уровень продукта

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

Касса

Касса включает в себя две части: кассу Н5 и кассу ПК:

Мобильный:

Сторона ПК:

Как показано на рисунке выше, касса в основном состоит из трех частей: основной информации о заказе (включая номер заказа и сумму платежа), деталей заказа (включая информацию о дате, информацию о товаре и основную информацию) и способ оплаты (оплата через платформу, оплата кредитом). , и т.д.).

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

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

(1) Настройка

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

(2) Конфигурация

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

На уровне отображения кассира выполняется различная обработка на основе внутренней маршрутизации, списка поддерживаемых каналов (WeChat, Alipay и т. д.), которые видит пользователь, а также сортировки и маркировки и т. д.
Удовлетворяйте различные сценарии и различные предприятия, чтобы получать платежи на разные счета с использованием одного и того же метода оплаты.
По разным сценариям брать разные методы расчетов и каналы расчетов и т.д.

2.2.2 Базовый уровень

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

основной порядок

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

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

(1) Один заказ VS несколько продуктов

Создание базового заказа может содержать N товаров (информация о товаре включает в себя название товара, идентификатор товара, цену за единицу, количество, скидку и т. д., а информация о заказе включает UID пользователя, номер мобильного телефона, сумму платежа, скидку на заказ и другую сводную базовую информацию). информации), а N товаров соответствует M бизнес-подзаказов (M≦N). Если бизнес-типы всех бизнес-подзаказов одинаковы, это нормальный режим, в противном случае это режим связывания; каждый бизнес заказ соответствует единице сверки (после успешной оплаты информация о платеже будет синхронизирована с системой сверки), режим создания заказа одного заказа VS нескольких товаров в основном поддерживает все текущие сценарии, включая возможный режим корзины в будущем .

(2) Один заказ VS несколько платежных поручений

Обычные пользователи заказов выбирают Alipay, WeChat и другие каналы для создания платежного поручения; когда сумма превышает 5000 юаней, они могут разделить сумму заказа для оплаты, и в это время будет создано несколько платежных поручений; для одного платежа два будут сформированы платежные поручения, в то же время раздельная оплата также приведет к частичной оплате или переплате пользователя, а мониторинг будет автоматически возвращать деньги за нештатные платежные ситуации, заказы на большие суммы имеют увеличение коэффициента конверсии более чем на 10%, один заказ по сравнению с единой моделью с несколькими платежами лучше поддерживает сценарии оплаты Mafengwo.

Управление маршрутизацией каналов

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

(1) Управление платежным счетом

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

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

(2) Управление платежными каналами

В настоящее время он подключен к сторонним каналам, таким как Alipay, Alipay International, WeChat, Jingdong Payment, Applepay, Lianlian Payment и UnionPay 2B, и в каждом канале есть несколько платежных продуктов. Формы интерфейса сторонних каналов сильно различаются, но все они предоставляют стандартные функции, такие как размещение заказа, возврат средств, запрос, уведомление об оплате и загрузка счетов. Платежный центр инкапсулирует эти платежные каналы, использует абстрактный класс в качестве базового класса, использует шаблон проектирования метода шаблона и определяет стандартный процесс в базовом классе, а конкретная реализация находится в соответствующем классе реализации канала. Клиентскому классу нужно заботиться только об общедоступных методах базового класса, независимо от конкретного канала.

2.2.3 Уровень поддержки

Уровень поддержки включает в себя такие модули, как мониторинг и оповещение, управление журналом, проверка подписи, управление конфигурацией и шина сообщений. Журналы собираются и управляются ELK, конфигурация системы управляется собственным распределенным центром конфигурации компании, а шина сообщений также использует дополнительный пакет RabbitMQ компании для распространения и потребления сообщений.

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

Система наблюдения

Чтобы обеспечить мониторинг в режиме реального времени и его эффективность, ресурсы, зависящие от мониторинга, такие как базы данных, должны быть изолированы от бизнес-библиотек (чтобы не класть яйца в одну корзину). Система мониторинга платежей охватывает мониторинг API, мониторинг производительности услуг, мониторинг баз данных и т. д. и может предоставлять унифицированные возможности оповещения, анализа и устранения неполадок. От сбора аномальных данных до активного обнаружения сбоев и анализа тенденций стабильности, он обеспечивает поддержку данных для оптимизации платежной системы.

(1) Фон мониторинга

Фон в основном включает в себя мониторинг управления пользователями и управление созданием элементов мониторинга. Пользователи могут отслеживать соответствующие элементы мониторинга в соответствии со своими потребностями. Настраиваемые параметры включают адрес запроса API, метод запроса, доступность, правильность, время отклика и другие данные о производительности, а также сигнал тревоги. методы и стратегии, подробная конфигурация выглядит следующим образом:

Мониторинг интерфейса можно привязать к фиксированному IP-адресу хоста и установить время ожидания.Запрос мониторинга поддерживает два метода: GET и POST.Метод POST может помочь, установив фиксированные параметры запроса.Частота мониторинга поддерживает два уровня конфигурации в минутах и секунд; модуль данных ответа может проверить, является ли код HTTP ненормальным, настроить тип данных ответа, сравнить и определить возвращаемое значение ключа и установить время ожидания запроса БД для мониторинга БД; модуль сигнализации в настоящее время поддерживает SMS и электронную почту, и можно установить минимальный и максимальный пороги тревоги.Тревога будет срабатывать при каждом максимальном количестве тревог, что позволяет избежать проблемы бомбардировки текстовыми сообщениями во время сбоев.

(2) Ядро мониторинга

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

(3) Мониторинг сигнализации

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

2.3 Практический опыт

(1) Согласованность данных

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

(2) Стабильность

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

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

3. Резюме и перспективы

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

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

Благодаря стратегическому обновлению Mafengwo «контент + транзакция» платежный центр также будет исследовать больше способов оплаты и возможностей, чтобы постоянно расширять возможности различных направлений бизнеса.

Автор этой статьи: Ма сотовой электронной коммерции платежей и расчетов команды.

(Исходное содержание Ma Honeycomb Technology, пожалуйста, укажите источник и сохраните изображение QR-кода в конце статьи при перепечатке, спасибо за сотрудничество.)