Идеи архитектуры для нескольких подключаемых платежных систем в одном приложении? - PullRequest
1 голос
/ 15 ноября 2011

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

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

1 Ответ

0 голосов
/ 15 ноября 2011

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

  • reserve() для резервирования кредита на ограниченный срок, т. Е. Для проверки успешности платежной транзакции.
  • commit() для запуска фактического денежного потока, зарезервированного ранее.

Бизнес-логика будет

  1. reserve() платеж до выполнения операции, подлежащей оплате
  2. выполнить действие (например, доставить контент, ...)
  3. commit() оплата

Большинство платежных систем должны вписываться в эту схему.

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

...