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

От модулей к услугам

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

Это называетсяМонолитное приложениеВремена, когда продуктовые линейки компании начали диверсифицироваться, каждая продуктовая линейка должна использовать платежные услуги. Если платежный модуль скорректирует код, он будет везде изменен, везде протестирован. С другой стороны, данные о транзакциях компании разнесены по разным системам и не могут быть эффективно объединены для унифицированного анализа и управления.

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

Эволюция системы:

Подводя итог, преимущества разделения платежей на услуги заключаются в следующем:

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

возможности системы

Если мы возьмем на себя это требование, нам нужно построить платежную систему для компании с нуля. С чего начать? Какими возможностями должна обладать такая система?

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

Чтобы инициировать платеж, мы называем:/gopay
Чтобы инициировать возврат, мы называем:/refund
Интерфейс асинхронного уведомления, назовем его:/notify/支付渠道/商户交易号
Уведомление о синхронизации интерфейса, назовем его:/return/支付渠道/商户交易号
Для запросов о транзакциях мы называем:/query/trade
Для запросов на возврат мы называем:/query/refund
Приобретение Билла, мы назвали:/query/bill
Реквизиты расчетов, которые мы называем:/query/settle

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

Далее описывается, как использовать эти интерфейсы и некоторую внутреннюю логику в соответствии с размерностью системы.

Операционная система

Общий платежный шлюз предоставляет два способа доступа к приложению:

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

Чтобы прояснить идею дизайна ниже, мы следуемРежим шлюзаОбъяснять.

Для прикладной системы она должна иметь возможность запрашивать оплату, то есть вызыватьgopayинтерфейс.这个接口会处理商户的数据，完成后会调用第三方网关接口，并将返回结果统一处理后返回给应用方。

Здесь следует отметить, что у третьей стороны примерно следующие ситуации для платежного интерфейса по моему опыту:

При оплате нет необходимости вызывать третье лицо, достаточно сгенерировать данные по правилам;
При оплате вам нужно вызывать несколько сторонних интерфейсов для завершения логики (это может быть медленным, и вам нужно учитывать текущее ограничение/понижение для масштабных событий);
Возвращаемые данные представляют собой URL-адрес, который можно напрямую передать третьему лицу для завершения платежа (станция wap/pc);
Возвращаемые данные представляют собой структуру xml/json, которую нужно собрать или передать в ее sdk (приложение) в качестве параметра.

Здесь из-за несогласованности структуры стороннего возврата нам необходимо его единообразно оформить в единый формат и вернуть мерчанту. Я рекомендую использовать формат json.

{
    "errno":0,
    "msg":"ok",
    "data":{

    }
}

Мы инкапсулируем все изменения вdataСтруктура. Например, если возвратный URL. Нужно только запустить приложениеGETпросить. Мы можем вернуться так:

{
    "errno":0,
    "msg":"ok",
    "data":{
        "url":"xxxxx",
        "method":"GET"
    }
}

Если это возвращаемая структура, приложение должно непосредственно инициироватьPOSTпросить. Мы можем вернуться так:

{
    "errno":1,
    "msg":"ok",
    "data":{
        "from":"<form action="xxx" method="POST">xxxxx</form>",
        "method":"POST"
    }
}

здесьformполе, создается форма формы, и приложение может напрямую отображать ее, а затем автоматически отправлять после ее получения. Конечно, этап инкапсуляции в форму from также может быть выполнен на стороне продавца.

Приведенный выше формат данных является только ссылкой. Каждый может настроить в соответствии со своими потребностями.

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

система примирения

Для примирения, как правило, существует два типа:сверка транзакцийиУрегулирование и примирение

сверка транзакций

Основными моментами сверки транзакций являются:Проверяйте правильность каждой транзакции. Его основная цель — увидеть, согласуется ли каждая транзакция в нашей системе с каждой транзакцией третьей стороны.

Логика этой проверки очень проста, она сравнивает данные двух счетов. В основном используется/query/billинтерфейс для получения данных транзакции, завершенных третьей стороной. Затем сравните с нашими данными об успешности транзакций. Проверьте на ошибки.

Эта логика очень проста, но следует отметить несколько моментов:

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

Для решения таких ситуаций требуются соответствующие средства обработки. В моем опыте встречались вышеперечисленные ситуации.

неправильная сумма: В основном из-за сторонней проблемы, возможно, сбоя обновления системы или неправильной суммы биллингового интерфейса;

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

У меня нет торговых данных:Это может быть результатом того, что стороннее уведомление не отправляется или не обрабатывается должным образом.

Большинство перечисленных выше проблем можно решить, полагаясь наquery/trade query/refundдля завершения автоматизированной обработки.

Урегулирование и примирение

Затем с вышеизложеннымсверка транзакцийЗачем нам нужноУрегулирование и примирениеШерстяная ткань? Для чего эта система? Давайте сначала разберемся со значением поселения.

Расчет означает, что сторонний шлюз переводит сумму T+x или другое согласованное время на счет компании в фиксированный момент времени.

Ниже мы предполагаем, что платежный цикл:T+1. Основной интерфейс, используемый для расчетов и сверки:/query/settle, основной контент, получаемый этим интерфейсом: какие транзакции состоят из каждого расчетного платежа (данные об успешности транзакции и возмещении). И сколько плата за обработку вычитается из этого урегулирования.

Его логика на самом деле очень проста. Начнем с нашей собственной системыT+1, и подсчитайте, сколько другая сторона должна перевести нам. Затем сравните его с объемом данных, только что полученным интерфейсом:

Сумма, полученная банком + плата за обработку = сумма, рассчитанная нашей системой

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

Биллинговая системасильная зависимостьсистема примирения. Если сверка ненормальна, то и сумма расчетов точно будет ненормальной. Кроме того, некоторые вопросы, на которые следует обратить внимание при расчете:

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

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

Финансовая система

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

Одним из основных моментов взаимосвязи между финансовой системой и платежами является проверка транзакций и возврат средств. Здесь можно использовать проверочную транзакциюquery/trade query/refundЭти два интерфейса завершены. Этот логический процесс не нужно сказать. Следующее сосредоточено на возврате.

Я видел, что многие системные возвраты размещаются непосредственно в приложении, и пользователи, подающие заявку на возврат, напрямую вызывают интерфейс возврата для возврата. Риск очень высок. Интерфейс платежной системы в отношении движения средств должен быть осторожным, и он не может слишком сильно подвергаться прямому воздействию извне, что несет риски.

Функция возмещения должна выполняться в финансовой системе. Таким образом, вы можете пройти внутренний процесс утверждения (независимо от того, должен ли он быть основан на бизнесе), и вы можете сделать больше проверок в финансовой системе, чтобы решить, следует ли немедленно возместить или начать процесс ожидания, отклонения, и Т. Д.

сторонний шлюз

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

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

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

GitHub: https://github.com/skr-shop