В последние годы, благодаря богатым сценариям и удобным сервисам, общее количество пользователей мобильных платежей и частота платежей продолжали быстро расти, и мобильные платежи стали привычкой людей. Однако за удобством скрываются скрытые опасения.Отчет об исследовании («Отчет об исследовании пользователей мобильных платежей за 2017 г.») показывает, что отсутствие поддержки у продавцов и риски безопасности стали наиболее тревожными проблемами для пользователей мобильных платежей, за которыми следуют сбои платежей и другие проблемы. вопросы.
Tencent Cloud Payment — это услуга мобильного эквайринга SaaS, запущенная Tencent Cloud и WeChat Pay с использованием технических возможностей, накопленных TEG за многие годы, с целью предоставить продавцам безопасную, стабильную, эффективную, простую в использовании и недорогую решение для доступа к решениям WeChat Pay, чтобы помочь быстрому и здоровому развитию индустрии мобильных платежей.
--введение
1. Что такое облачный платеж
1.1 История проекта
Проблемы, с которыми сталкивается WeChat Pay:
Качество независимых поставщиков программного обеспечения варьируется:Качество независимых поставщиков программного обеспечения, разработанных для доступа продавцов к платежной системе WeChat, неравномерно, стабильность и безопасность системы невысоки, а обычные пользователи имеют плохой опыт при оплате с помощью платежа WeChat, что снижает доверие пользователей к платежу WeChat.
Проблемы, с которыми сталкиваются обычные поставщики услуг:
Высокий технический порог:Большинство поставщиков услуг не имеют возможности разработать систему эквайринга, которая подключается к WeChat Pay.
Высокая стоимость системы:На рынке имеется небольшое количество высококачественных систем, которые дороги и не могут быть предоставлены поставщиками услуг.
1.2 Позиционирование проекта
CloudPay стремится предоставить сквозные (от пользователей до WeChat Pay и другие сторонние платежные каналы) безопасные, стабильные, эффективные, простые в использовании и недорогие коммерческие платежные решения, улучшая последнюю милю от пользователей до каналы оплаты.
Для WeChatPay:Повысьте безопасность и стабильность процесса оплаты, повысьте доверие пользователей и уменьшите жалобы пользователей.
Для поставщиков услуг:Предоставьте безопасное, простое в использовании, недорогое и многофункциональное коммерческое платежное решение, чтобы поставщики услуг могли сосредоточиться на продвижении WeChat Pay.
Для пользователей:Улучшите пользовательский опыт и повысьте готовность и доверие пользователей к использованию платежей WeChat.
1.3 Место облачных платежей в платежной цепочке
2. Безопасность облачных платежных средств
Для платежных систем безопасность относится к безопасности средств, которую можно разделить на два уровня: достоверность данных и согласованность. В следующих трех разделах они будут представлены: общие сценарии платежей и бизнес-модели, обеспечение безопасности данных и стратегии согласованности.
2.1 Общие сценарии оплаты и бизнес-модели
Ⅰ Оплата кредитной картой
Ⅱ Официальная оплата аккаунта (оплата одним кодом)
Ⅲ Оплата скан-кодом
2.2 Безопасность данных
Проблемы безопасности данных и соответствующие решения можно анализировать с трех точек зрения: передача данных, хранение данных и манипулирование данными.
передача информации
Подслушивание: зашифрованная передача (https)
Фальсификация: подпись (RSA2)
Атака «человек посередине»: сертификаты
Поддельный сервер: подпись (RSA2), сертификат
хранилище данных
Библиотека перетаскивания: зашифрованное хранилище
Фальсификация: Подпись
Потеря: база данных master-slave, моментальный снимок + журнал операций, избыточность данных
манипуляция данными
Незаконный доступ, незаконная модификация: контроль разрешений, проверка целостности данных
Логическая ошибка: регулирование запроса, очистка трафика
Вышеупомянутое содержимое можно условно разделить на четыре типа проблем: утечка данных, фальсификация данных, потеря данных и незаконные операции.
2.3 Проблемы согласованности
согласованность данных
Внутреннее исключение: вызывает прерывание потока выполнения.
Ненормальный платежный канал: поток выполнения прерван, и статус неизвестен.
Сетевые аномалии: Доступ к платежным каналам обычно осуществляется через общедоступную сеть, и сетевые аномалии встречаются чаще.
Конкуренция сообщений: ссылка логики платежа длинная. В случае плохой сети логика повторных попыток приведет к конкуренции сообщений.
Сообщения не по порядку: существует много логических процессов оплаты, и, как правило, поток операций делится на несколько этапов, и сообщения не по порядку неизбежны; использование CMQ для надежной отправки сообщений, когда несколько процессов отправляют сообщения одновременно. в то же время, также приведет к беспорядку сообщений.
Интерфейс платежного канала не реентерабельный: логика восстановления исключений сложная, подвержена ошибкам, период восстановления длительный.
Выбор схемы согласованности данных:
Когда дело доходит до согласованности данных, следует избегать теории CAP:
Сцена, на которой находится облачная платежная система, имеет свои особенности:
1. Восходящие и нисходящие отношения между облачной платежной системой и платежными каналами приводят к естественным разделениям, и P должно быть удовлетворено;
2. Платежные системы предъявляют высокие требования к непротиворечивости данных, и C также должен быть удовлетворен;
3. Облачный платеж должен иметь стабильность 99,99%, поэтому A также должен попытаться удовлетворить ее.
Сильная согласованность жертвует доступностью, а слабая согласованность жертвует согласованностью, поэтому ни один из них не может быть использован. В конечном итоге можно выбрать только конечную согласованность. Согласно теории BASE окончательная непротиворечивость является неким компромиссом в трех аспектах CAP.В случае обеспечения доступности системы большую часть времени и непротиворечивости данных существование промежуточного состояния (краткосрочное , небольшая несогласованность данных) допускается, пока это промежуточное состояние не имеет доступа к внешней системе (внешнее представление непротиворечиво), и в то же время есть надежда, что состояние несогласованные данные могут быть восстановлены как можно быстрее (в конечном итоге непротиворечивые) с помощью быстрого восстановления.
Воплощение BASE теории в облачной платежной системе:
Сериализация: использование распределенных блокировок (Статья в общедоступном номере: Ядерная боеголовка базы данных в эпоху облачных вычислений — Tencent MySQL
(TXSQL) расширение системы блокировки), сериализовать внешние запросы, чтобы решить проблему неупорядоченных сообщений.
Упорядочивание: процесс оплаты имеет конечный автомат состояния строгого порядка (FSM), который может упорядочивать сообщения через FSM, чтобы решить проблему неупорядоченных сообщений.
Транзакционный: при использовании схемы возможной согласованности каждый полный шаг в потоке выполнения платежа кажется независимой и завершенной транзакцией извне системы.
Реентерабельность: когда нереентерабельный интерфейс вызывает сбой, необходимо записать местоположение текущего потока выполнения и контекст потока выполнения. что вызовет логику Чрезвычайно сложная. Благодаря реентерабельному дизайну и реализации всех интерфейсов облачные платежи избавляют от необходимости записывать точку сбоя при возникновении сбоя и повторно выполнять его непосредственно с самого начала, так что поток выполнения может быть переведен в обычный процесс, который упрощает логику проектирования восстановления после отказа.
Без сохранения состояния: аналогично роли повторного входа, при реентерабельном дизайне все процессы разрабатываются как без состояния (или с меньшим количеством состояний), насколько это возможно.При проектировании восстановления после сбоя нет необходимости записывать контекст потока выполнения, что упрощает сбои. Разработка логики восстановления.
Благодаря этому дизайну частота отказов при облачных платежах на данный момент составляет менее 1 заказа на миллион заказов, а время восстановления промежуточного состояния обычно составляет 10 секунд.
Логическая согласованность представления
Каналов оплаты много: облачный платеж сейчас подключен к 8 каналам оплаты, и поля между разными каналами сильно отличаются, и способы запроса разные.
Непоследовательные представления логики интерфейса: Возьмем, к примеру, WeChat Pay. WeChat Pay имеет три интерфейса, которые могут возвращать, казалось бы, полную информацию о заказе (проведите платеж картой, чтобы разместить заказ, запросите заказ и перезвоните, когда платеж будет завершен), но поля возвращаемые тремя интерфейсами, не совпадают (например, отсутствует информация, связанная с ваучером), и в разных ситуациях с одним и тем же интерфейсом (например, интерфейс оплаты кредитной картой) возвращаемые поля различаются (например, , payment_total_fee возвращается только при использовании ваучера без пополнения, что повлияет на статистику расчетной суммы).
Без повторного входа: взяв в качестве примера оплату кредитной картой, заказ, который был успешно оплачен, сообщит об ошибке (заказ уже был оплачен), когда заказ будет размещен снова, но в особых случаях (если сеть задерживается и сообщение потеряно), запрос несвоевременный (или нормальный). ) возвращается, затем выполняется повторная попытка. Видно, что первый запрос был неудачным, а при повторной попытке было сообщено, что заказ оплачен. Эта ситуация делает обработку исключений очень сложной.
Существует много нештатных ситуаций: например, внутренняя аномалия, сбой банковского перевода, пользователь закрывает платежную клавиатуру, недостаточный баланс и т. д. Таким образом, платеж не прошел, по сути, заказ все еще может быть оплачен, но из-за многие типы ошибок и WeChat Payment делает логику обработки исключений чрезвычайно сложной для определенных условий ошибки (таких как закрытие платежной клавиатуры) как прекращение платежа. Взяв в качестве примера облачный платеж, в случае, когда пользователь выключает платежную клавиатуру, если пользователю нужно только продолжить, облачный платеж должен использовать исходные данные заказа, изменить номер заказа и изменить код авторизации платежа, чтобы попытаться опять таки.
решение:
Сглаживание различий: за счет завершения полей, компенсации запросов, слияния полей и т. д. семантика интерфейса упрощается и унифицируется, а несогласованность логического представления интерфейса устраняется.
Повторный вход в интерфейс: повторный вход во внутренние интерфейсы очень прост, эта концепция должна быть предусмотрена в начале проектирования системы, иначе повторный вход в систему после ее формирования будет дорогостоящим и рискованным. Реентерабельность внешнего интерфейса требует тщательного рефакторинга логики, но это не невыполнимая задача. После реентерабельности интерфейса сложность согласованности логического представления на этапе восстановления после сбоя в основном решена.
Согласованность представления пользователя
Пользователь успешно оплатил. Продавцу не удалось получить платеж: например, квитанция об оплате/обратный вызов потеряны, что привело к незавершенному процессу оплаты на стороне продавца.
Пользователь не может успешно оплатить - мерчант считает, что платеж прошел успешно: например, при оплате картой долгое время не приходит квитанция об успешном платеже, а результат, полученный при запросе статуса заказа, также оплачивается. в случае успешной оплаты отмена заказа приведет к возврату средств.В прошлом возврат платежей через WeChat обычно происходил с большой задержкой, иногда даже на несколько дней). Если пользователь успешно оплачивает в тот момент, когда мерчант вызывает отмену заказа, платеж считается неудачным в глазах мерчанта, но платеж проходит успешно в глазах пользователя, и возврат средств в связи с фактической отменой заказа заказ был успешно применен, что может быть периодом после того, как пользователь ушел.В течение времени возврат средств был успешным, что привело к убыткам продавца.
решение:
Откажитесь от неоднозначных интерфейсов: Внутри облачной платежной системы больше не вызывается интерфейс отмены заказа, чтобы не возникало непредвиденных возмещений. WeChat Pay также оптимизировал интерфейс оплаты кредитной картой.Если платеж не будет завершен в течение 1 минуты, заказ будет автоматически отменен, а успешно оплаченный заказ не будет отменен, что полностью исключает случайные возвраты и случайные платежи ( оплата за несколько дней).предыдущие старые заказы).
Быстрое восстановление после сбоев: повторная попытка (для восстановления простых сбоев, таких как перебои в сети) и аварийное восстановление порядка (для восстановления заказов с серьезными ошибками), сокращение времени восстановления ненормальных заказов примерно до 10 секунд, даже при возникновении исключений. также выполняйте устранение неисправностей как можно скорее, и пользователям нужно всего лишь немного подождать, чтобы получить правильный результат, тем самым уменьшая возникновение споров.
3. Резюме
С помощью вышеуказанного ряда мер в принципе можно предоставить поставщикам торговых услуг простые, легкие в использовании, согласованные представления данных, согласованные логические представления и согласованные представления пользователей на основе обеспечения безопасности данных. платеж уменьшается, частота ошибок снижается, доверие пользователей повышается, а безопасность средств пользователей и продавцов гарантируется.