В Части 1 мы разобрали основы проведения платежа. Выяснили, что процесс очень прост и состоит из нескольких участников: Клиента, Витрины, Банка и Мерчанта, а так же двух базовых методов: check и pay.  Теперь поговорим о способе, который позволит Банку избежать расхождений при сверках с Мерчантом. Сверками называют процесс квитовки реестра принятых платежей с витрин, где размещены услуги Мерчанта, с реестром фактически проведенных платежей Мерчантом.   Проще говоря, успешность этой сверки показывает Банку, нет ли услуг, где деньги были приняты у Клиента, но не зачислены Мерчантом.  Если все системы отработали синхронно, то успешные платежи автоматически выгрузятся в ближайший реестр переводов для дальнейшей квитовки.  Но что делать, если мы не получили ответ на запрос pay или ответ получили, но операция у Мерчанта в промежуточном статусе? Для этого существует запрос финального статуса операции getStatus. Тип взаимодействия – асинхронный.   Мы его инициируем в случае:  Время ожидания ответа на pay превысило допустимый порог. В Банке ставим операцию в проведение и инициируем запрос getStatus; В ответ на запрос pay мы получили промежуточный статус операции - InProgress.  Первое событие наступает по любым техническим причинам.  А второе событие наступает, когда Мерчант не является Поставщиком оказываемых услуг, а заказывает их у третьих лиц и продает Банку за определенный процент. Мерчанту необходимо время, чтобы сходить на удаленные системы Поставщика и дать задание на зачисление. Поэтому он в ответе на pay статусом InProgress сообщает Банку: деньги приняты, но о статусе зачисления не знаю. Попробуй узнать позже.  Вот как это выглядит в схеме общего процесса проведения платежа Банк анализирует операции, где не был получен ответ на запрос pay или где был получен ответ, но статус операции промежуточный: InProgress; Далее опрашивает систему Мерчанта с некой периодичностью: обычно раз в 15 минут в течение суток. Далее операция переводится в ошибку на всем контуре инфообмена; Витрина в свою очередь делает то же самое, но по отношению в Банку. Клиент к этому времени уже ушел, у него есть чек с печатью Банка: платеж принят. Если будут какие-то сложности и денежные средства Мерчант не зачислит, с ним свяжутся сотрудники Банка или витрина обновит статус в личном кабинете клиента в автоматическом режиме, как раз по результатам обработки этих статусов и дальнейшей квитовки. Пример запроса getStatus/XML  Систем-инициатор: Банк  Система-получатель: Мерчант В запросе мы указываем id транзакции, полученный в ответ на pay. Если мы его не получили, система Банка должна попытаться допровести платеж путем отправки pay раз в несколько минут, обычно, не более трех. Далее операцию ставят в InProgress, инициируют getStatus.  Пример ответа getStatus/XML  Систем-инициатор: Мерчант  Система-получатель: Банк   В ответ на запрос getStatus, Мерчант так же может сообщить не финальный статус операции (успех или ошибка), а промежуточный InProgress. Для этих случаев действуют такие же правила, как и для случая неполучения ответа на pay: продолжаем опрос системы Мерчанта до получения финального статуса операции, обычно, не более 24 часов. Структура запроса и ответа от Витрины к Банку тождественна, за исключением наименования полей и значений Id транзакции. Система Банка анализирует значение поля status_id. Успешные операции сразу выгружает в ближайший реестр переводов, для квитовки и дальнейшего возмещения денежных средств Мерчанту.  По ошибочным операциям возмещение не выполняется. Если в ответ на запрос getStatus был получен status_id в значении error, выполняется автоматический возврат денежных средств на карту клиента.  Подробнее о возмещениях и сверках мы поговорим в следующих статьях.