В Части 1 мы разобрали основы проведения платежа. Выяснили, что процесс очень прост и состоит из нескольких участников: Клиента, Витрины, Банка и Мерчанта, а так же двух базовых методов: check и pay.

Теперь поговорим о способе, который позволит Банку избежать расхождений при сверках с Мерчантом.

Сверками называют процесс квитовки реестра принятых платежей с витрин, где размещены услуги Мерчанта, с реестром фактически проведенных платежей Мерчантом.

Проще говоря, успешность этой сверки показывает Банку, нет ли услуг, где деньги были приняты у Клиента, но не зачислены Мерчантом.

Если все системы отработали синхронно, то успешные платежи автоматически выгрузятся в ближайший реестр переводов для дальнейшей квитовки.

Но что делать, если мы не получили ответ на запрос pay или ответ получили, но операция у Мерчанта в промежуточном статусе?

Для этого существует запрос финального статуса операции getStatus.

Тип взаимодействия – асинхронный.

Мы его инициируем в случае:

• Время ожидания ответа на pay превысило допустимый порог. В Банке ставим операцию в проведение и инициируем запрос getStatus;

• В ответ на запрос pay мы получили промежуточный статус операции - InProgress.

Первое событие наступает по любым техническим причинам.

А второе событие наступает, когда Мерчант не является Поставщиком оказываемых услуг, а заказывает их у третьих лиц и продает Банку за определенный процент. Мерчанту необходимо время, чтобы сходить на удаленные системы Поставщика и дать задание на зачисление. Поэтому он в ответе на pay статусом InProgress сообщает Банку: деньги приняты, но о статусе зачисления не знаю. Попробуй узнать позже.

Вот как это выглядит в схеме общего процесса проведения платежа

1. Банк анализирует операции, где не был получен ответ на запрос pay или где был получен ответ, но статус операции промежуточный: InProgress;

2. Далее опрашивает систему Мерчанта с некой периодичностью: обычно раз в 15 минут в течение суток. Далее операция переводится в ошибку на всем контуре инфообмена;

3. Витрина в свою очередь делает то же самое, но по отношению в Банку.

Клиент к этому времени уже ушел, у него есть чек с печатью Банка: платеж принят. Если будут какие-то сложности и денежные средства Мерчант не зачислит, с ним свяжутся сотрудники Банка или витрина обновит статус в личном кабинете клиента в автоматическом режиме, как раз по результатам обработки этих статусов и дальнейшей квитовки.

Пример запроса 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, выполняется автоматический возврат денежных средств на карту клиента.

Подробнее о возмещениях и сверках мы поговорим в следующих статьях.