«Мир» введет отложенную оплату за такси и заказы на маркетплейсах
Платежная система «Мир» расширит применение функционала по отложенному списанию денежных средств со своих карт при оплате товаров, работ или услуг, говорится в технологическом бюллетене, который платежная система опубликовала на портале для банков. РБК ознакомился с документом, его подлинность подтвердили два источника на платежном рынке. Публикацию документа подтвердили представители НСПК и банка «Русский стандарт».
Весной 2024 года банки смогут проводить отложенные операции по картам, реквизиты которых сохранены у продавца. Например, это может быть оплата покупок в пунктах выдачи заказов маркетплейсов или оплата услуг такси, каршеринга и проката средств индивидуальной мобильности. Сейчас отложенные платежи по картам «Мир» действуют только при оплате проезда в общественном транспорте.
«Наблюдается растущее количество операций оплаты, инициированных держателями карт по сохраненным реквизитам, которые из соображений удобства обслуживания клиентов некоторым ТСП (торгово-сервисным предприятиям. — РБК) хотелось бы проводить в режиме отложенной авторизации», — говорится в бюллетене «Мира». К весне 2024 года, когда начнут действовать новые правила, «Мир» разработает список товаров и услуг, при оплате которых нельзя будет использовать отложенное списание средств, даже если держатель карты сохранил ее реквизиты.
Как объяснил РБК представитель НСПК, применение отложенной авторизации позволит улучшить скорость и качество обслуживания держателей карт «Мир» в тех случаях, когда выполнение операции в режиме реального времени невозможно по причине отсутствия связи либо занимает слишком много времени. Он добавил, что применение отложенных авторизаций не является обязательным для ТСП.
У международных платежных систем Visa и Mastercard, которые ушли из России весной 2022 года, был реализован похожий функционал: обычно при оплате их картами в общественном транспорте или такси блокировался рубль, а спустя время проходила полная сумма списания средств, напоминает руководитель лаборатории блокчейн и финтех Школы управления «Сколково» Егор Кривошея.
Как процесс оплаты происходит сейчас
В настоящее время подавляющее большинство операций по картам выполняется в режиме реального времени, то есть денежные средства списываются с них сразу, объясняется в документе платежной системы. Применение отложенных авторизаций по правилам «Мира» сейчас работает только для операций оплаты на транспорте с использованием контактных, бесконтактных карт, а также по сохраненным реквизитам с биометрической идентификацией клиентов.
Режим отложенной авторизации может применяться для того, чтобы списать деньги, если у продавца нет физической возможности сделать это сразу, либо если «выполнение авторизации в режиме реального времени приводит к неудобствам для клиентов и, как следствие, к снижению количества выполняемых операций», уточняется в документе. Он позволяет устранить эти проблемы, однако несет в себе дополнительные риски для продавцов, связанные с возможной неоплатой покупок. «Именно поэтому применение отложенных авторизаций в платежной системе нормативно ограничено», — подчеркивается там.
Риски неправомерного списания денег с карты клиента, а также за невозможность списания средств в полном объеме ложатся на банки-эквайеры, которые обслуживают продавца, следует из бюллетеня.
Риски и преимущества отложенного списания средств
Это хорошее решение для магазинов, так как в перечисленных сценариях платежей (покупки в марткеплейсах, такси, каршеринг) риск неоплаты невелик, а нехватка средств является одной из основных причин отказа авторизации и, как следствие, снижает конверсии, говорит один из источников РБК.
«Нововведение позволит решить целый ряд бизнес-задач, когда клиента необходимо обслужить без задержек», — согласен представитель банка «Русский стандарт». Он добавляет, что новые правила позволят также несколько раз направлять запросы на списание средств в случае неуспешной авторизации.
Отложенная авторизация при оплате картой особенно актуальна для тех территорий и торгово-сервисных предприятий, где могут возникать сложности с устойчивой связью, говорит представитель Почта Банка. «Безусловно, это удобно для держателей карт и будет способствовать повышению их лояльности торговым точкам и сервисам, где будет применяться эта схема. Однако для ТСП и банков-эквайеров отложенная авторизация потенциально несет риски увеличения числа случаев, когда оплата покупки не будет по факту совершена в силу ряда причин — отсутствия денег на карте, изменения статуса карты, различных мошеннических схем», — рассуждает он.
По мнению Кривошеи, вряд ли отложенное списание средств повысит риски неуплаты за товары или услуги. В случае неудачного списания продавец может перестать обслуживать клиента. Как правило, такие сервисы предоставляют крупные компании, поэтому для клиентов риски быть отключенными от них могут превышать возможность не заплатить за что-то, рассуждает Кривошея.
React Apollo, Gqlgen – авторизация. Часть 1
Это базовое руководство описывающее схему работы «отложенной» авторизации. При которой права пользователю выдаются с задержкой по времени. Здесь мы разберем только базовый принцип и авторизацию.
Задача
Разработать сервис позволяющий авторизовываться «нестандартным» образом: код в СМС либо код в URL. Пароль у user отсутствует.
Пользователь в форме входа вводит свой Username, и в зависимости от настроек метода авторизации получает:
Письмо с кнопкой на емайл, при ее активации – происходит авторизация. Почтовый клиент может находится на другом устройстве
Открывается форма ввода кода из СМС, при успехе пользователь авторизовывается
Проблема
Мы не знаем когда пользователь нажмет на кнопку. Но в случае ее активации фронтенд должен понять что авторизация произошла, выполнить HTTP запрос и получить токен.
Пользователь получает токен сессии по предьявлению – идентификатора клиента ClientID .
Как решать?
При первом запросе браузер Клиент получает cookie c идентификатором ClientID
При отправке Пользователем формы авторизации, клиенту возвращается токен авторизации Auth_token – обменивается на токен Пользователя
Создается авторизационная сессия, хранит Auth_token , ClientID и UserID
Пользователь подтверждает авторизацию. Ищем клиента по ClientID в соединениях websocket – отправляем сигнал об авторизации
Клиент получил сигнал о наличии авторизации. Выполняется GET-запрос с токеном Auth_token в HTTP-заголовке Authorization. Ищем Auth_token в сессиях, в случае успеха авторизовываем Пользователя
Отложенная авторизация приема наличных¶
Регулярные и непрогнозируемые перебои со связью негативно отражаются на коэффициенте доступности УС при авторизации операций в режиме онлайн по протоколу NDC. В ПроАТМ реализован набор расширений стандартных стейтов и функций для протокола NDC (согласно его описанию), позволяющих осуществить прием наличных при разорванном соединении с их последующим (отложенным) зачислением после восстановления связи с хостом.
Набор расширений включается в реестре параметром CASHIN_OFFLINE_MODE .
принятые, но не авторизованные в силу отсутствия связи операции;
принятые операции, отклоненные NDC-хостом (подробнее, IgnoreHostFailedReplyForCashin );
операции, которые были прерваны до авторизации в силу сбоя сценария, оборудования, ПО и пр.
Рисунок 85. Схема авторизации отложенных операций ¶
Хранение файла транзакций и регистрация операции¶
Вся информация о транзакциях хранится в файле БД TransactAuth.db , расположенном в директории размещения главного исполняемого файла ogre.exe (например, C:\FS365\Application).
БД включает в себя информацию о денежных операциях, внесенных денежных средствах, транзакционных запросах, буферах NDC, операционных циклах и номере карты (в замаскированным виде).
Каждой транзакции присваивается свой ID. После отправки транзакционного запроса операции присваивается статус: ожидание авторизации, неавторизованно, авторизовано. Каждому статусу соответствует свой код. В случае, когда транзакционный запрос был отправлен, но ответа от ПЦ получено не было, транзакции присваивается статус «неавторизованно», и в базе данных транзакция отмечается как незавершенная.
Работа механизма отправки отложенных сообщений¶
Авторизация отложенных операций запускается по событию «Завершен сценарий обслуживания» и выполняется в фоновом режиме (см. особенности реализации стейтов I и J при включенном механизме отложенной авторизации ). Предусмотрена возможность ограничения выполнения авторизации операций, проведенных в offline-режиме по картам, номера которых не совпадают с текущей. УС на время проведения фоновой авторизации самостоятельно переходит в состояние OutOfService и держит карту клиента внутри ридера, пока не завершится операция в фоновом режиме. В ходе фоновой авторизации выполняются транзакционные запросы со значениями Opcode Buffer, Buffer B, Buffer C и счетчиками принятых банкнот неавторизованных операций, ранее сохраненными в БД, и PAN-, PIN- и EMV-данными текущей карты, которая находится в устройстве, и используются текущие параметры макирования.
Критерием успешности авторизации отдельно взятой отложенной операции служит наличие функции Deposit And Print в ответе хоста (такие операции помечаются в БД как успешно авторизованные). Если во время авторизации отложенной операции не удалось установить соединение с хостом, то процесс фоновой авторизации прекращается. Устройство переходит в режим обслуживания клиентов, и до восстановления связи все последующие операции будут производиться в режиме offline. Авторизация PIN-кода при offline операции идет по ветке таймаута сценария обслуживания. Рекомендуется по таймауту авторизации PIN-кода предоставлять клиенту возможность выбора продолжения с отложенным зачислением или прекращения выполнения операции.
В процессе фоновой авторизации отложенных операций приема наличных блокируется переход в РОП: команды на переход в РОП выполняются отложено (только после завершения процедуры авторизации). На дисплее показывается служебный экран «C03» (Supervisor mode) или, при его отсутсвии, «С02» (Out-of-Service mode).
Во избежание возникновения отложенных операций, которые были проведены по заведомо недействительным картам, рекомендуется использовать фильтрацию по FIT-таблице.
Защита целостности базы данных отложенных транзакций¶
Хранение записей об отложенных операциях осуществляется в БД транзакций. Предусмотрен механизм подписывания БД: каждая запись подписывается, что позволяет исключить возможность редактирования отдельных полей, а также исключается возможность удалить или вставить отдельно подписанные записи в таблице незавершенных операций за счет использования механизма сбора подписи по конкатенации подписей отдельных записей. Подпись хранится в отдельных полях таблицы БД.
Предусмотрена защита от восстановления среза локальной БД путем копирования файлов или восстановления разделов жесткого диска (защита от многократного зачисления пакета отложенных операций).
Подпись транзакций выполняется после добавления каждой новой неавторизованной транзакции, но перед тем как сделать эту подпись, выполняется проверка, что уже существующие транзакции не искажены (проверяется текущая подпись) и, если искажений нет, переподписываются уже все транзакции, включая новую.
Отложенные операции с нарушенной подписью дальнейшей авторизации не подлежат и позже числятся в реестре незавершенных операций с соответствующей пометкой («ошибка проверки целостности») в чеке операционного цикла. Предполагается дальнейший разбор инцидента вручную.
В случае нарушения целостности функционирования механизма подписывания БД, отложенная авторизации приема наличных деактивируется до устранения проблемы. В журнал и перечень проблемных ситуаций помещается соответствующее сообщение.
Особенности закрытия операционного цикла¶
В момент закрытия операционного цикла БД транзакций может содержать ненулевое число незавершенных операций приема наличных, которые по ряду причин авторизованы не были (операция отложена либо нарушена целостность записи в БД). Данная ситуация не является препятствием для закрытия операционного цикла. В чеке закрытия операционного цикла отражается:
итоговая сумма принятых наличных;
сумма успешно авторизованных операций;
реестр незавершенных операций, сумма которых подлежит ручному зачислению по итогам пересчета банкнот в расчетном центре банка;
Авторизация банковской карты
Авторизация – разрешение на проведение операции с использованием банковской карты, предоставляемое банком-эмитентом. Авторизация проводится в том случае, если сумма списания по карте превышает неавторизованный лимит — сумму покупки, установленную банком для торгово-сервисного предприятия, не требующую авторизации. Независимо от состояния счета держателя карты банк гарантирует возврат средств торгово-сервисному предприятию в пределах этой суммы.
При списании средств с магнитной банковской карты также обязательна авторизация, так как на ней не хранится информация о состоянии счета держателя.
Выделяют два способа авторизации: голосовая или автоматическая.
Для голосовой продавец использует импринтер, связь с процессинговым центром происходит по телефону (в настоящее время практически не используется). При автоматической авторизации продавец формирует свой запрос в процессинговый центр с помощью POS-терминала.
В том и другом случае продавец при положительном ответе получает от процессингового центра код авторизации (буквенно-цифровой код). Он служит подтверждением проведенной авторизации и обязательно должен быть распечатан на чеке.
Существуют два вида режима авторизации: Онлайн-авторизация (непосредственная, например, в момент оплате по карте) и Оффлайн-авторизация (отложенная).