.. meta::
   :description: Модель биллинга SBC: иерархическое распределение дохода между банком, менеджером, реселлером, дилером и торговцем для транзакций Sale и Transfer.

Принципы построения модели выставления счетов
################################################################################

.. role:: ex

.. role:: code

.. |exclamation| image:: ../_static/images/exclamation.png

Введение
=============================

| Начиная с версии 3.23.01 доход распределяется между всеми участниками иерархически. Это повышает точность расчётов, позволяет управлять параметрами выплаты удержаний и настраивать модель тарифов в зависимости от платёжного потока.

| Эта модель позволяет переопределять тарифы, а также сумму удержания и дату его выплаты.

| Порядок распределения дохода для транзакций sale

.. image:: ../_static/images/billing_model_sale-flow.png
    :align: center

| При обработке транзакции SMS или DMS все участники удерживают свою комиссию из суммы Sale согласно заданным ставкам. Ставки применяются от Bank к Merchant. Каждый участник потока видит только определённые для него ставки, не зная ставок предшествующих участников платёжного потока. Для транзакций Sale последним участником является Reseller, и его ставка будет окончательной.

| Порядок распределения дохода для транзакций Transfer

.. image:: ../_static/images/billing_model_transfer-flow.png
    :align: center

| При обработке транзакции Transfer расчёт тарифа выполняется так же, за исключением дополнительного участника — получателя средств. Последний участник этого потока — торговец, а получатель видит свой тариф как окончательный.

Описание: Rates definition
=====================================

.. image:: ../_static/images/billing_model_rate-structure.png
    :align: center

| Ставки применяются по возрастанию: каждый последующий тарифный план наследует предыдущую ставку. Поэтому чем выше уровень пользователя, тем выше его ставка. Ставки Bank и Dealer определяются на уровне Gate, а для Manager, Reseller и Merchant — на уровне Project. Эти ставки могут быть переопределены на уровне Endpoint. В этом потоке могут отсутствовать некоторые участники.

Учёт комиссий
==========================================

.. image:: ../_static/images/billing_model_rate-order.png
    :align: center

| Первый элемент на диаграмме — общая комиссия, учтённая для транзакции. Для простоты рассмотрим транзакцию Sale в Проекте без Реселлера. Таким образом, с Торговца удерживается комиссия, определённая в тарифном плане Менеджера. В этом случае расчёт комиссии идёт по приоритетной цепочке Банк → Дилер → Менеджер. Это означает, что Банк первым получает свою долю согласно тарифу Банка, затем удерживается комиссия Дилера, а Менеджер получает остаток.

Существует вероятность, что комиссия не будет соответствовать ожидаемой.

| *Example 1:*
| Посмотрим, как изменится расчёт комиссии в зависимости от применённых диапазонов.

  * Тарифный план дилера определяется следующим образом: если сумма транзакции находится между 0 и 1000 USD, ставка дилера составляет 5 USD; если больше 1000 USD — 8 USD.
  * Ставка менеджера фиксирована: 10 USD;

| Предположим, что Менеджер не заметил диапазоны, заданные Dealer, и ожидает комиссию в 5 USD

.. image:: ../_static/images/billing_model_rate-correct.png
    :align: center

| Как видно на рисунке, комиссия Dealer рассчитывается раньше комиссии Manager, и фактическая комиссия Manager будет ниже ожидаемой – 2 USD.

| *Example 2:*
| Со ставками, заданными для BIN, страны или банка, следует быть гораздо внимательнее. Предположим, что диапазоны Dealer и Manager одинаковы.

  * Ставка дилера: для всех транзакций 5 USD, за исключением BIN 233445, для которого ставка составляет 12 USD;
  * Ставка Менеджера: предположим, что Менеджер не учёл ставку Dealer для BIN и задал фиксированную ставку 10 USD.

| Рассмотрим транзакцию с BIN 456778. Общая комиссия будет распределена следующим образом: 5 USD для Dealer и 5 USD для Manager. Транзакция с BIN 233445 приносит 12 USD для Dealer, а комиссия Manager будет отрицательной: -2 USD, поскольку общая комиссия в тарифном плане Manager составляет 10 USD.

.. image:: ../_static/images/billing_model_rate-incorrect.png
    :align: center

Удержание и его перенос
===============================================

| Чтобы застраховать риски Торговца, можно определить удержание для конкретных Торговцев. Система управления выплатами обеспечивает учёт замороженных удержаний и сумм удержаний, подлежащих возврату Торговцу. Удержание покрывает риски, связанные с Chargeback, инициированными недовольными клиентами при расторжении договора с Торговцем. Операция переноса выполняется не более чем за 182 календарных дня. Период выплаты и процент удержания определяются в тарифах.

| Алгоритм расчёта и переноса удержания
| Каждый участник платёжного потока, кроме торговца, может определить собственные процент удержания и период удержания. Процент и период удержания не зависят друг от друга.

.. image:: ../_static/images/billing_model_hold-one.png
    :align: center

| Согласно рисунку, для транзакции t1 Банк удерживает из общей комиссии значение HB за период ΔtB, определённый в тарифе Банка. Таким образом, Банк удерживает сумму HB за период [t1, t2] на своём счёте для покрытия рисков Chargeback и мошеннических операций. После истечения периода ΔtB, если не было отрицательных транзакций, Банк выплачивает удержанные средства Дилеру. Этот процесс CB называется переносом. Такая же схема применяется к любому участнику платёжного потока.

.. image:: ../_static/images/billing_model_hold-many.png
    :align: center

Общий доход любого участника составляет: комиссия + холд участника – холд предыдущего участника.

  * Для банка: в момент t1 за период ΔtB доход будет пополнен на сумму удержания HB, а в момент t2 эта же сумма будет вычтена.
  * Для дилера: в момент t1 за период ΔtD доход будет пополнен на сумму удержания HD, в момент t3 та же сумма будет списана, а в момент t2 доход дилера пополняется на сумму переноса CB, возвращённую банком.
  * Для Менеджера: в момент t1 за период ΔtM доход будет пополнен на сумму удержания HM, в момент t4 та же сумма будет списана, а в момент t3 доход Менеджера пополняется на сумму переноса CD, возвращённую Дилером.
  * Для Реселлера: в момент t1 за период ΔtR доход будет пополнен на сумму удержания HR, в момент t5 та же сумма будет списана, а в момент t4 доход Реселлера пополняется на сумму переноса CM, возвращённую Менеджером.
  * Для торговца: торговец не может определять значения удержания; в момент t1 за период ΔtR из дохода будет удержана сумма HR, а в момент t5 будет зачислена та же сумма.

| При правильном задании параметров удержания процент удержания участника платёжного потока будет не меньше процента удержания предыдущего участника. В противном случае возникают финансовые риски. То же относится к параметру периода удержания.

Описание: Rates validation
=====================================

| Начиная с версии 3.23.0 можно определять отрицательные ставки. Проверить тарифные планы в момент создания невозможно: проверка выполняется при обработке транзакции. Если отрицательные ставки определены намеренно, отключите проверку в настройках Project. Это отключит проверку всех ставок, определённых для Project.

Описание: Event model
================================

| SBC использует событийную модель для применения ставок. Процессоры генерируют различные события. Ставки применяются к этим событиям в соответствии с тарифными планами. SBC связывает событие с транзакцией в системе, будь то транзакция Sale или вызов внешней системы борьбы с мошенничеством. Транзакция является минимальной единицей тарификации. У транзакции есть тип и статус.

Стандартные типы транзакций
----------------------------------------------------

.. list-table::
   :widths: 20, 80
   :header-rows: 1
   :class: longtable

   * - Транзакция
     - Описание
   * - :code:`sale`
     - списывает сумму со счёта клиента
   * - :code:`preauth`
     - удерживает сумму на счёте клиента, но не списывает её
   * - :code:`capture`
     - списывает сумму со счёта клиента; может быть выполнена только после соответствующей предавторизации
   * - :code:`cancel`
     - отменяет транзакцию preauth, если она не была списана операцией capture
   * - :code:`reversal`
     - возвращает сумму на счёт клиента
   * - :code:`chargeback`
     - запрос на возврат суммы, инициированный держателями карт через банк-эмитент
   * - :code:`dispute`
     - для оспаривания операции Chargeback подтверждает двойное списание
   * - :code:`fraud`
     - операция помечает транзакцию как мошенническую
   * - :code:`refund`
     - операция прямого списания со счёта клиента
   * - :code:`transfer`
     - операция перевода денег, перевод денег между картами или со счёта Торговца

Стандартные статусы транзакций
-------------------------------------------------------

.. list-table::
   :widths: 20, 80
   :header-rows: 1
   :class: longtable

   * - Транзакция
     - Описание
   * - :code:`approved`
     - транзакция одобрена банком или PSP
   * - :code:`decline`
     - транзакция отклонена банком или PSP
   * - :code:`filtered`
     - Транзакция отфильтровывается системой до достижения банка или PSP

| Текущая модель допускает следующие комбинации типов и статусов:

   * :ex:`APPROVED`: все типы транзакций;
   * Статус :ex:`DECLINED`: sale, preauth, transfer;
   * Статус :ex:`FILTERED`: sale, preauth, transfer, reversal;

| Чтобы применить тарифы к событию, необходимо определить следующие параметры:

   * Параметр :ex:`Minimum (min)`
   * Параметр :ex:`Percentage (rate)`
   * :ex:`Фиксированная (абсолютная) ставка (abs)`
   * :ex:`Процент удержания (hold)`
   * Параметр :ex:`Hold period`
   * :ex:`Пользовательская функция`

| Ставка рассчитывается следующим образом:

   * сначала вычисляется максимум из заданных :ex:`minimum` и :ex:`percentage`, умноженного на сумму транзакции: :ex:`greatest(min, amount*rate)`
   * к рассчитанному значению добавляется :ex:`фиксированная` ставка: :ex:`наибольшее(min, amount*rate) + abs`
   * :ex:`удержание` списывается: :ex:`наибольшее(min, amount*rate) + abs + hold`
   * применяется :ex:`пользовательская функция`. Функция может переопределить расчёт
   * сумма транзакции уменьшается на рассчитанную сумму

| При определении тарифов для BIN, банка или страны необходимо задать следующие параметры:

   * Параметр :ex:`Minimum (min)`
   * Параметр :ex:`Percentage (rate)`
   * :ex:`Фиксированная (абсолютная) ставка (abs)`
   * :ex:`Пользовательская функция`

| Вы не можете переопределять параметры холда. Для переопределённых событий применяется следующий приоритет поиска: сначала ищется ставка, переопределённая для BIN; если она не найдена, система ищет ставку, переопределённую для банка; если и она не найдена, ищется ставка, переопределённая для страны. Если ни одна ставка не переопределена, применяется ставка по умолчанию.

Конфигурация таблицы тарифов
==================================================

| Для большей гибкости при определении ставок вы можете использовать интерфейс определения таблицы ставок.
| Для типов транзакций, инициирующих заказы, кроме перевода, поддерживается таблица ставок диапазона одного уровня. Диапазон можно определить по сумме транзакции, общей сумме и общему числу транзакций, обработанных шлюзом в текущем месяце.
| Для транзакций, не инициирующих заказы, можно определить следующие диапазоны: отношение текущего числа транзакций этого типа к общему числу транзакций за текущий или прошлый месяц.
| Для транзакций Transfer можно определить два уровня диапазонов в таблице тарифов. Диапазоны первого уровня такие же, как для транзакции, инициирующей заказы. Второй уровень — направление перевода. Направления перевода определяются на уровне экземпляра SBC. Стандартные направления: с карты Visa на любую другую карту, с карты MasterCard на любую другую карту, перевод внутри банка и многие другие. Чтобы выбрать необходимые направления, создайте запрос на улучшение.

|exclamation| Расчёт агрегированных величин (общей суммы, общего количества и соотношения) по умолчанию выполняется на уровне шлюза. Для прозрачности ставок следует выбрать расчёт агрегированных величин на уровне конечной точки или проекта.

| Рассмотрим конфигурацию таблицы тарифов для транзакций Transfer

| Предположим, что Шлюз поддерживает переводы для различных типов карт. Тариф перевода зависит от общей суммы транзакций, обработанных Шлюзом. Лимит установлен в размере 10 000 000. Можно определить разные тарифы в зависимости от направления перевода. Если общая сумма меньше 10 000 000, применяются тарифы для следующих направлений: Visa2Any, MasterCard2Any, Any2Any; в противном случае устанавливается общий тариф. В этом случае действует следующая иерархия:

.. image:: ../_static/images/billing_model_transfer-one.png
    :align: center

| Рассмотрим поток транзакции по карте 4444 5555 6666 1111. Поскольку сначала диапазоны первого уровня определяются для общей суммы транзакций, в момент обработки сначала проверяется общая сумма транзакций, обработанных Шлюзом. Предположим, что общая сумма равна 5 000 000 — это означает, что поток идёт по верхней ветви. Затем определяется диапазон для типа карты; обрабатываемая карта — Visa. Для карт Visa существует направление перевода Visa2Any. Это означает, что система выберет в таблице тариф: < 10 000 000, Visa2Any.

|exclamation| Карта может одновременно попасть в несколько направлений. В этом случае направление выбирается в следующем порядке приоритета: перевод внутри банка, затем направление, где определены и отправитель, и получатель (например, Visa2Visa), затем только отправитель (например, Visa2Any), только получатель (например, Any2Visa), направление по умолчанию.

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

Описание: Complex rates
=======================================

| Чтобы правильно определить тарифный план, необходимо понимать, как это сделать для разных участников платёжного потока. Рассмотрим простой случай. Пусть комиссия участников A и B определяется только минимальным значением и не зависит от суммы транзакции. Участник A ожидает доход ya, участник B — yb. В таком случае определите тарифный план с минимальной ставкой ya+yb.

.. image:: ../_static/images/billing_model_min.png
    :align: center

| Та же логика применяется к тарифам, для которых определена только процентная ставка. Предположим, комиссия участников A и B задана только как процент от суммы транзакции. Участник A ожидает комиссию Ra, участник B — Rb. В таком случае необходимо определить тарифный план с комиссией Ra+Rb.

.. image:: ../_static/images/billing_model_rate.png
    :align: center

| Рассмотрим более сложный случай. Предположим, что оба участника ожидают комиссию как минимальное значение для транзакций ниже определённой суммы, а в противном случае — процент от транзакции. Порог перехода от минимального тарифа к процентному для участника A равен x1, для участника B — x2. Если этот порог одинаков для обоих участников (x1 = x2), применяемый тариф будет равен сумме минимальных тарифов ниже порога и сумме процентных значений выше него.

.. image:: ../_static/images/billing_model_min-and-rate.png
    :align: center

| Если параметры различаются, ставка рассчитывается более сложным образом. Давайте рассмотрим возможные случаи.

.. only:: html

  .. image:: ../_static/images/billing_model_output.gif
      :align: center

.. only:: not html

  .. image:: ../_static/images/billing_model_output-0.png
  .. image:: ../_static/images/billing_model_output-5.png
  .. image:: ../_static/images/billing_model_output-7.png

| На рисунке минимально возможный тариф отмечен зелёным. В диапазоне (x1, x2) тариф определяется иной формулой, чем просто суммой двух минимальных тарифов и суммой процентных тарифов. Точно определить такой тариф невозможно. Необходимо добавить два диапазона: x1, x2. В диапазоне (0, x2] тариф определяется как сумма минимальных комиссий. В [x1, x2] тариф определяется как процентный тариф участника A (или участника B, если его порог срабатывает первым) и абсолютное значение комиссии участника B, равное минимальной комиссии участника B (или A соответственно). В [x2, +∞) тариф определяется как сумма процентных тарифов обоих участников.
| Чтобы избежать слишком сложных таблиц ставок, необходимо корректировать минимальное значение ставки и процент. Если увеличить минимальную ставку в диапазоне Δmin, необходимо также увеличить процентную ставку ΔR. Если минимальное значение ставки корректируется более чем на Δmin, процентные ставки корректировать не следует. Границы корректировки обозначены пунктирной линией.
| Если игнорировать эти корректировки для сумм транзакций, попадающих в (x1, x2), комиссия участника B будет снижена (предполагается, что B находится ниже в иерархии платёжного потока).