Как спроектировать real-time списывание денег со счета пользователя?
Прямо посекундная тарификация?
Если не секрет, то расскажите, пожалуйста, что за сервис.
Аналог из отрасли где это все стандартизировано и отработано.
В связи существует 2 метода оплаты: postpaid и prepaid. Postpaid — это грубо говоря счет, который может уходить в минус, в данном случае мимо.
Prepaid. Это тот способ который берет деньги до начала услуги, поэтому при приблежении к 0 отключает сервис. К примеру в ряде стран законодательно запрещено уводить препейдного абонента в минус, но это лирика.
Так вот, prepaid бывает двух типов (основных, на самом деле есть еще)
IEC — Immediate Event Charging и ECUR — Event Charging with Unit Reservation.
В первом случае, при возникновении события, происходит запрос к счету, счет проверяется и от него отпиливаетя стоимость услуги, после чего возвращается положительный ответ и событие продолжается. Проблема, завязка на единицу тарификации, если выбрать маленькую (секунду) — то очень ресурсоемко получается, а если квоту увеличить (до минуты) — то при отказе от услуги на 35й секунде средства за 25 секунд пропадут. Знакомая ситуация наверное…
Второй метод интереснее.
Выбирается 2 параметра. Размер квоты и единица тарификации, допустим 1 минута и 5 секунд. Событие инициируется, происходит запрос к счету, на счете блокируется сумма, и возвращаеся ответ, который содержит объем доступный для услуги (в примере время, а могут быть байты, клики, слоны...) И услуга начинает предоставляться. Как только заканчиваются ресурсы, к счету опять происходит обращение, в котором говорится о том, что ресурсы израсходованы, и хочу еще (ну или не хочу), в этом случае со счета списывается разервированная сумма, и резервитуется следующая квота. Если услуга прекращается до исчерпания квоты, то время округляется ввепх до единицы тарификации (с 32 секунл до 35) и списываются деньги только за 35 секунд, за 25 возвращаются.
Это как организуется работа со счетом.
Совсем подробно можно почитать вот тут www.3gpp.org/ftp/Specs/archive/32_series/32.299/32299-700.zip Пункт 6.3.2, пугаться не надо, картинки понятные.

Ух расписался. Это половина, вторая часть — то как контролировать каждое событие. А тут без примера не могу ничего сказать.
Достаточно при каждом запросе, который имеет отношение к объявлению (старт\стоп\показ) запускать функцию, которая проверяет текущий баланс и, если он больше нуля, то рассчитывает новый баланс и показывает объявление. Как-то так, вроде ничего сложного.
Или необходимо чтобы сервер постоянно знал текущий баланс?