newARTix
Новичок
Хотелось бы обсудить архитектуру и технические решения сферического биллинга в вакууме на PHP.
Под биллингом понимается вторичная система учета заказов-транзакций-услуг-счетов.
То есть на нашем сайте-биллинге хранится информация об оказанных услугах (service), о заказанных услугах (orders), о транзакциях (billing) и о балансах пользователей (balance).
Все реальные финансовые операции проводятся в системах онлайн-платежей, типа робокассы. У нас в биллинге фиксируется только факт оплаты от этих систем и итоговый баланс пользователей.
Пользователь может как пополнять свой баланс (тогда в таблице БД order создается заказ на пополнение баланса и тут же помечается как оплаченный, при подтверждении со стороны платежной системы), так и напрямую заказывать товар/услугу (тогда в системе создается заказ, и в случае его оплаты - оказывается услуга, а заказ помечается как оплаченный).
В таблице биллинга хранится информация обо всех дебетах и кредитах пользователя. То есть при заказе услуги и оплате ее через платежную систему фиксируется дебет; при оказании услуги, фиксируется кредит. При пополнении баланса фиксируется только дебет. Таким образом по таблице биллинга мы можем в любой момент вычислить реальный баланс пользователя.
Рассматривается вариант, когда оказание услуги - мгновенное (генерация серийного номера), то есть резервировать средства на баллансе нет смысла, транзакции проходят в рамках одного запроса.
Архитектура адекватна задаче обычного интернет-магазина электронных услуг?
БД сделана на MySQL InnoDB, с целью повышения отказоустойчивости и транзакционности естественно. Кроме того, при оплате услуг с баланса, на время "вычисления реального баланса - списание с баланса" таблица billing блокируется, дабы не дать возможность параллельного вычисления/изменения балланса. Вся работа с базой происходит в PHP, без процедур и тригеров, только с помощью транзакций и блокировок.
В будущем, при росте нагрузки, планируется использовать партицирование.
Упустили ли мы что-нибудь? О чем стоит подумать? В чем ошибки решения?
Под биллингом понимается вторичная система учета заказов-транзакций-услуг-счетов.
То есть на нашем сайте-биллинге хранится информация об оказанных услугах (service), о заказанных услугах (orders), о транзакциях (billing) и о балансах пользователей (balance).
Все реальные финансовые операции проводятся в системах онлайн-платежей, типа робокассы. У нас в биллинге фиксируется только факт оплаты от этих систем и итоговый баланс пользователей.
Пользователь может как пополнять свой баланс (тогда в таблице БД order создается заказ на пополнение баланса и тут же помечается как оплаченный, при подтверждении со стороны платежной системы), так и напрямую заказывать товар/услугу (тогда в системе создается заказ, и в случае его оплаты - оказывается услуга, а заказ помечается как оплаченный).
В таблице биллинга хранится информация обо всех дебетах и кредитах пользователя. То есть при заказе услуги и оплате ее через платежную систему фиксируется дебет; при оказании услуги, фиксируется кредит. При пополнении баланса фиксируется только дебет. Таким образом по таблице биллинга мы можем в любой момент вычислить реальный баланс пользователя.
Рассматривается вариант, когда оказание услуги - мгновенное (генерация серийного номера), то есть резервировать средства на баллансе нет смысла, транзакции проходят в рамках одного запроса.
Архитектура адекватна задаче обычного интернет-магазина электронных услуг?
БД сделана на MySQL InnoDB, с целью повышения отказоустойчивости и транзакционности естественно. Кроме того, при оплате услуг с баланса, на время "вычисления реального баланса - списание с баланса" таблица billing блокируется, дабы не дать возможность параллельного вычисления/изменения балланса. Вся работа с базой происходит в PHP, без процедур и тригеров, только с помощью транзакций и блокировок.
В будущем, при росте нагрузки, планируется использовать партицирование.
Упустили ли мы что-нибудь? О чем стоит подумать? В чем ошибки решения?