В Части 1 мы разобрали основы проведения платежа. Выяснили, что процесс очень прост и состоит из нескольких участников: Клиента, Витрины, Банка и Мерчанта, а так же двух базовых методов: check и pay.
Теперь поговорим о способе, который позволит Банку избежать расхождений при сверках с Мерчантом.
Сверками называют процесс квитовки реестра принятых платежей с витрин, где размещены услуги Мерчанта, с реестром фактически проведенных платежей Мерчантом.
Проще говоря, успешность этой сверки показывает Банку, нет ли услуг, где деньги были приняты у Клиента, но не зачислены Мерчантом.
Если все системы отработали синхронно, то успешные платежи автоматически выгрузятся в ближайший реестр переводов для дальнейшей квитовки.
Но что делать, если мы не получили ответ на запрос pay или ответ получили, но операция у Мерчанта в промежуточном статусе?
Для этого существует запрос финального статуса операции getStatus.
Тип взаимодействия – асинхронный.
Мы его инициируем в случае:
Время ожидания ответа на pay превысило допустимый порог. В Банке ставим операцию в проведение и инициируем запрос getStatus;
В ответ на запрос pay мы получили промежуточный статус операции - InProgress.
Первое событие наступает по любым техническим причинам.
А второе событие наступает, когда Мерчант не является Поставщиком оказываемых услуг, а заказывает их у третьих лиц и продает Банку за определенный процент. Мерчанту необходимо время, чтобы сходить на удаленные системы Поставщика и дать задание на зачисление. Поэтому он в ответе на pay статусом InProgress сообщает Банку: деньги приняты, но о статусе зачисления не знаю. Попробуй узнать позже.
Вот как это выглядит в схеме общего процесса проведения платежа
Банк анализирует операции, где не был получен ответ на запрос pay или где был получен ответ, но статус операции промежуточный: InProgress;
Далее опрашивает систему Мерчанта с некой периодичностью: обычно раз в 15 минут в течение суток. Далее операция переводится в ошибку на всем контуре инфообмена;
Витрина в свою очередь делает то же самое, но по отношению в Банку.
Клиент к этому времени уже ушел, у него есть чек с печатью Банка: платеж принят. Если будут какие-то сложности и денежные средства Мерчант не зачислит, с ним свяжутся сотрудники Банка или витрина обновит статус в личном кабинете клиента в автоматическом режиме, как раз по результатам обработки этих статусов и дальнейшей квитовки.
Пример запроса getStatus/XML
Систем-инициатор: Банк
Система-получатель: Мерчант
<pay>
<payment>
<time>2021-02-08T00:16:25</time>
<id>123456789</id>
</payment>
</pay>В запросе мы указываем id транзакции, полученный в ответ на pay. Если мы его не получили, система Банка должна попытаться допровести платеж путем отправки pay раз в несколько минут, обычно, не более трех. Далее операцию ставят в InProgress, инициируют getStatus.
Пример ответа getStatus/XML
Систем-инициатор: Мерчант
Система-получатель: Банк
<pay>
<payment>
<Time>2021-02-08T:16:25</Time>
<id>123456789</id>
</payment>
<StatusInfo>
<status_id>Success</status_id>
<disсriptin>Успех</disсriptin>
<errorCode>0</errorCode>
</StatusInfo>
</pay>В ответ на запрос getStatus, Мерчант так же может сообщить не финальный статус операции (успех или ошибка), а промежуточный InProgress. Для этих случаев действуют такие же правила, как и для случая неполучения ответа на pay: продолжаем опрос системы Мерчанта до получения финального статуса операции, обычно, не более 24 часов.
Структура запроса и ответа от Витрины к Банку тождественна, за исключением наименования полей и значений Id транзакции.
Система Банка анализирует значение поля status_id. Успешные операции сразу выгружает в ближайший реестр переводов, для квитовки и дальнейшего возмещения денежных средств Мерчанту.
По ошибочным операциям возмещение не выполняется. Если в ответ на запрос getStatus был получен status_id в значении error, выполняется автоматический возврат денежных средств на карту клиента.
Подробнее о возмещениях и сверках мы поговорим в следующих статьях.
