Современные платежные технологии доклад
Обновлено: 25.06.2024
Всё давно уже сказано, но так как никто не слушает, приходится постоянно возвращаться назад и повторять всё сначала.
Что такое POS-терминал? Это компактное и защищенное аппаратное решение, специально созданное для того, чтобы принимать платежи в торговле по картам международных платежных систем. Он решает множество задач включая упрощение и стандартизацию процесса покупки, позволяет избавится от наличности и дает возможность мгновенной проверки платежеспособности клиента. Звучит солидно, есть только одно но — эта технология появилась в 1983-м году, почти 40 лет назад!
Вокруг POS терминала построена сложная экономика, в которой участвуют производители устройств и вендоры программного обеспечения, а также банки, платежные системы и лаборатории, которые занимаются проверкой и сертификацией терминалов EMVCo L1, L2 и L3, PCI DSS. Терминал нужно спроектировать и произвести в Китае, сертифицировать в лабораториях, ввести в страну и растаможить, продать, поддерживать и управлять жизненным циклом. И все это стоит денег, что в конечном итоге отражается в тарифной линейке для торговых предприятий со стороны банков и платежных систем, которые играют по принципу — мы свои проценты взяли, а вы крутитесь как хотите.
Процесс вымывания POS терминалов с вершины технологического прогресса происходил волнами и сейчас мы наблюдаем, вероятно, терминальную стадию. Пройден этап, когда китайскими и корейскими производителями была разрушена монополия Ingenico и Verifone на производство POS устройств и эксклюзивную поставку программного обеспечения. Затем на несколько лет небольшие mPOS машинки показали, что стоимость устройства может быть в десятки раз меньше. Правда споткнулись о PIN. Ну и наконец, в связи с директивами платежных систем, к 2021-му году прекращается эмиссия карт без NFC чипа. Концепция SoftPOS — способ принимать платежи без участия POS терминала вообще, является просто финальным аккордом. Сегодня есть техническая возможность принимать платежи при помощи пользовательских мобильных устройств — через NFC и QR.
Что же должно случиться дальше? После того как PCI SSC (Security Standards Council) выпустит новый стандарт CPoC (Contactless Payments on commercial off-the-shelf), регламентирующий использование PIN-кода на экране мобильного телефона — все больше торговых предприятий устремится в сторону программного решения, которое будет представлять собой симбиоз классического экваеринга бесконтактных карт и смартфонов и национального и корпоративного QR. Давление центральных банков и война ставок продолжится — вопрос доходности экваеринга и снижения издержек будет актуален как никогда.
Безусловно, в конечной точке видится, что непосредственно прием платежей будут осуществлять несколько крупных игроков на местном рынке. Это будут местные крупные системообразующие коммерческие банки, государства и несколько транснациональных игроков (Google, Apple, Amazon). Они будут предоставлять свои приложения как сервис, которые будут включать в себя NFC платежи, различный QR, биометрию и все то, что придумают к этому моменту.
POS терминалы и классический экваеринг не исчезнет завтра. Платежная индустрия крайне консервативна и новые методы оплаты, при всем их удобстве и разнообразии, будут внедряться десятилетиями. Множество стран еще только запускает бесконтактные проекты, QR активно используется только в Азии, где как раз и наблюдается активный рост продаж POS машин. Но направление движения не подлежит сомнению и продажа Ineginco Worldline по цене Plaid — яркий тому пример.
Пластиковая карта слишком задержалась. Например, компании VISA уже 62 года, а первая карта была выпущена Long Island Bank еще в 1951-м году, когда еще был жив Сталин! Карта, безусловно, за эти годы прошла через серьезную технологическую эволюцию. Вслед за магнитной полосой появился Chip&PIN, который, к слову, внедрялся не то чтобы уж очень быстро в мире. А затем пришла пора бесконтактных карт.
Бесконтактную карту можно просто приложить к терминалу, для совершения оплаты. Цифры на ней теперь нужна разве что для e-commerce, а магнитную полосу продолжают делать из уважения к истории (ради поддержки fallbacks?).
Однако, бесконтактная карта достигла пика развития уже поздне-айфонную эпоху. Внезапно выяснилось, что навороченный смартфон есть в кармане у каждого, а вот банковский счет — далеко не у всех. Инклюзивность. Новое слово. Быстрее всех это поняли в Китае, который сильно запаздывал в развитии финтех сектора от западных государств, но, соответственно, и не имел на балансе баланса legacy-технологий прошлого. AliPay и WeChat.Pay полностью захватили платежный рынок, сделав традиционную платежную систему UnionPay — лишь дополнением. Зачем нужна карта если можно удобно платить и без нее?
Чуть менее очевидно, что также нет никакого смысла показывать ее фотографию на экране телефона — это просто реверанс в сторону ушедший эпохи, символ преемственности и не более того. Нет карты, нет чипа на карте и, соответственно, нет больше необходимости вводить ПИН-код — производители смартфонов Samsung и Apple смогут аутентифицировать вас по отпечатку пальца или форме головы.
Карта исчезла, ужавшись до квадратика QR или цифрового токена внутри брелоков и часов. И это имеет очень серьезные последствия. Например, e-commerce традиционно был выстроен вокруг ввода реквизитов карты в форму оплаты. Но если больше нет никакой карты, то что же вводить и куда? Наиболее простой ответ — ничего вводить не нужно, кроме одноразового пароля в лучших традициях SCA (strong customer authentication). Ваши платежные данные уже и так хранятся в системах Apple.Pay, Google.Pay или Sber.Pay и практически все сделано для того, чтобы покупка происходила в одно касание. Это удобно.
Что будет дальше? Сейчас чтобы заплатить Apple.Pay необходимо просто предъявить свое лицо камере своего смартфона. Развитие этой идеи аутентификация со стороны мерчанта. Это именно то, что уже несколько лет делают в Китае. Национальные базы биометрических данных, роуминг между регионами и биометрическая аутентификация на стороне мерчанта — логично, удобно и при этом дешево для всех участников процесса.
Коммодитизация обработки платежей, вмешательство центральных банков в платежные сервисы непосредственно, идентичные продуктовые линейки и как следствие острая конкуренция, бурный рост финтех компаний и конечно же open banking под флагами PSD2-подобных директив. Казалось бы, что хуже быть не может, но тут раздается стук снизу — подоспели технологические компании. Samsung, Google, Huawei, Amazon, Apple, Uber и бесчисленное количество не таких крупных организаций стали активно входить на рынок финансовых услуг, не желая допускать другие компании к своим пользователям и, тем более, платить существенный процент за обслуживание.
Сегодня решительно непонятно, чем сервис банков будет лучше, чем тот же сервис, который предоставит крупная сеть супермаркетов, получившая банковскую лицензию? Почему их мобильное приложение будет хуже? Если выяснится, что единственное отличие только лишь в исторически серьезных барьерах входа на рынок — то нас ждут серьезные перемены. Никто не любит промежуточные звенья, которые берут денег больше, чем добавляют ценности в ценностную цепочку.
Можно также наблюдать происходящее слияние платежного мира и обычной повседневной инфраструктуры. Уже сложно встретить вендинг, куда POS терминал если не встроен, то хотя бы не прилеплен снаружи. В системах городского транспорта чуть ли ни каждый день стартует новый проект, который позволяет использовать токенизированные карты (мобильный телефон) для оплаты, прикладывая к обычным смонтированным терминалам. Городской транспорт вроде велосипедов или электро-самокатов выпускается с возможностью бесконтактной оплаты картой, хотя бы через QR.
В мире пост-PSD2 существует относительно небольшое количество банков, которые занимаются только сервисными функциями по управлению счетами пользователей, в то время как все остальные операции выполняет либо государство, либо рой финтех организаций, которые сталкиваются на маркетплейсах и конкурируют по стандартизированным условиям. Люди же будут выбирать между экосистемами продуктов или интерфейсами мобильных банков. Возможно, что крупные компании сделают банковское обслуживание просто частью более широкой подписки — 10% скидка на такси и вот вам еще и льготные условия для управления финансами. Упор будет сделать на функциональность и удобство для конечного пользователя. Инициативы вроде управления личными финансами из Excel станут нормой.
Давайте поговорим о платежных технологиях и что происходит, когда клиент хочет оплатить услугу на сайте или в интернет-Банке, сделать перевод или нам просто необходимо настроить интеграцию с агрегатором, магазином или платежной системой в целях вывода их услуг в своих дистанционных каналах обслуживания.
Устраивайтесь поудобнее, будет интересно.
Часть 1: Проведение и подтверждение платежа
Клиент для оплаты услуг как правило авторизуется в интернет-Банке, выпустившим его карту: Банку-Эмитенту его карты.
Далее в интернет-Банке, выбирает услугу для оплаты: пополнение мобильного телефона, оплаты интернета или услуг ЖКУ.
В базе поставщика услуги, например оператора сотовой связи, у клиента есть свой уникальный идентификатор – номер телефона.
Это для клиента так. А давайте посмотрим, как это выглядит внутри систем.
Витрина – в данном случае, интернет-Банк клиента;
Банк клиента – он же оператор по переводу денежных средств, он же Банк-Эмитент, выпустивший карту клиента, и он же расчетный Банк по переводам средств клиента Сервис-Провайдеру;
Наш оператор сотовой связи – Поставщик услуг;
И у Сервис-Провайдера и у Поставщика услуг есть свои расчетные Банки. В итоге, Банк Сервис-Провайдера в офлайне перечислит денежные средства на счет Поставщика услуг в целях зачисления на счет клиента. Но об этом в следующих статьях.
Я буду использовать сущности: Банк, Мерчант и Витрина для описания онлайн взаимодействия внутри систем.
Центральной фигурой в нашем взаимодействии является Банк клиента.
У Банка задача не только проверить наличие денежных средств у клиента, но и доставить их Сервис-Провайдеру. Для выполнения этого условия Банк, как правило, пишет два шлюза либо использует текущие:
Исходящий: от Банка к Мерчанту;
Оба эти шлюза могут работать как по тождественному протоколу, так и по разным.
Мы рассмотрим самый простой вариант: витрина Банка, Банк и Мерчант работают по одному сквозному протоколу, представленному всего двумя методами: check и pay.
Описание процесса проведения и подтверждения платежа в этом случае выглядит следующим образом:
Сиквенс проведения и подтверждения платежа
Описание процесса проведения и подтверждения платежа
Клиент выбирает услугу;
Витрина Банка проверяет наличие услуги у себя в Базе данных;
2.1 Если услуга найдена, формирует запрос в Банк на холдирование денежных средств в Процессинге. Далее формирует запрос на возможность совершение платежа check:
2.2 Если услуга не найдена, завершает процесс ошибкой, клиент уходит;
Витрина инициирует check;
В Банк поступает запрос check. Далее Банк маршрутизирует запрос Мерчанту;
Мерчант принимает запрос, выполняет проверку совершения платежа;
5.1 Если зачисление возможно, отправляет успех, клиенту отображается пречек. Система Банка ожидает подтверждение платежа;
5.2 Если зачисление невозможно, Банк отправляет код ошибки, витрина завершает процесс, проведение невозможно, клиент уходит;
Банк присваивает идентификатор транзакции и сразу отправляет ответ на витрину;
Зачисление денежных средств у Мерчанта уже выполняется в офлайне. Банк инициирует pay и, если зачисление возможно, Мерчант присваивает свой идентификатор транзакции и отправляет в Банк успешный ответ. А если зачисление невозможно – спросите Вы? Тогда Мерчант отправляет ответ в Банк с кодом ошибки, и Банк выполняет возврат денежных средств клиенту в автоматическом режиме в тот же день.
Теперь рассмотрит рассмотрим формат запроса и ответа для каждого из методов, за что они отвечают и для чего они нужны
CHECK – проведение платежа
Метод отвечает за возможность совершения платежа. На этом шаге выполняется проверка доступности услуги на витрине, в Банке и у Мерчанта. Мерчант в свою очередь, в онлайне, может сходить к Поставщику и проверить валидность идентификатора пополнения у Поставщика, и, если, он не найден или ошибка, отклонить платеж.
Очень часто на этом шаге закладывают минимальные требования к времени отклика ответа на запрос от Мерчанта, т.к. клиент не будет ждать, пока Витрина Банка, сам Банк и Мерчант проверят доступность услуги.
Отличительной особенностью этого шага является так же расчет комиссии. Комиссии бывают:
Верхняя, или горячая – это комиссия с клиента сверх тела платежа (суммы зачисления);
Нижняя или холодная, это комиссия, которую платит Банку Мерчант;
Смешанная – в этой рубрике мы не будем о них говорить;
В нашем примере на check рассчитывается только комиссия с клиента, нижняя и смешанная комиссии рассчитываются в отдельно. Об этом с следующих статьях.
Структура запроса check/XML, шлюз контура Витрина – Банк:
Time – дата платежа;
type – тип источника списания;
type_number – маскированный PAN карты (примечание: PAN - номер карты) по PCI DSS;
code – код валюты перевода, в примере рубли;
amount – сумма зачисления или, по-другому, тело платежа
commission_amount – сумма с учетом верхней комиссии;
service – цифровой идентификатор услуги, который проверяет есть ли вообще такая услуга в Банке и на витрине;
account – контейнер с идентификатором пополнения, в нашем случае – номер телефона;
Когда клиент на витрине нажимает иконку с оплачиваемой услугой, первое, что выполняет система, это проверяет доступность услуги и если она доступна, то дальше обращается в процессинг для проверки источника списания (поля Type и type_number)
Далее если денежные средства есть, проверяет возможность зачисления денежных средств на номер телефона (phone_number в значении 86248541234)
Подождите, секундочку – спросите вы. Что-то здесь не сходится. Как по маскированному PAN в поле type_number можно проверить наличие денежных средств на карте клиента?
Авторизация в процессинге выполняется перед check и это отдельный метод и отдельный процесс, посмотрите выше на диаграмму процесса. На проведении платежа мы уже работаем с маскированным PAN, т.к. на этом шаге мы проверяем возможность проведения платежа, а не наличие денежных средств на карте клиента.
Далее мы формируем запрос Мерчанту.
Мы не указываем ни PAN, ни тип источника списания, нас интересует только возможность совершения платежа для конкретного сервиса.
Структура запроса check/XML, шлюз контура Банк – Мерчант:
В ответе Мерчант возвращает все те же самые поля, но появляется дополнительный контейнер со статусом обработки операции, а также идентификатор транзакции в поле id
Структура ответа check/XML, шлюз контура Мерчант – Банк:
Такой ответ будет означать, что Мерчант готов к подтверждению платежа клиентом.
В ответе мы у нас будет временный id транзакции у Мерчанта, а так же статус обработки платежа: status_id == Success (успех) и код ошибки равный 0 (успех) в поле errorCode
Не всегда к нам приходят успешные статусы транзакций и не всегда у нас отсутствуют коды ошибок, но об этом мы поговорим в следующих статьях.
Мы сохраняем ответ и обогащаем его необходимыми для витрины полями, присваиваем идентификатору транзакции мерчанта – идентификатор в Банке и отправляем ответ на витрину.
Структура ответа check/XML, шлюз контура Банк – Витрина
Клиент видит экранную форму пречека, с который каждый из нас знаком: там будет сумма платежа, дата, а так же идентификатор пополняемой услуги.
В запросе витрина может передать как все поля из предыдущего ответа check, так и просто сумму платежа и идентификатор транзакции, полученной на предыдущем шаге.
Мы будем использовать первый вариант.
PAY – подтверждение платежа
Структура запроса pay/XML, шлюз контура Витрина – Банк :
Структура ответа pay/XML, шлюз контура Банк – витрина:
Клиенту печатается чек о приеме к исполнению платежа, с печатью Банка и он уходит.
Но вы еще к Мерчанту не сходили, не подтвердили у него оплату, не зарегистрировали у него платеж, а уже отпускаете клиента – снова спросите вы?
Для регистрации оплаты у мерчанта, для переданного id транзакции витрины, находим транзакцию мерчанта из предыдущего шага и с ней уже регистрируем платеж.
Структура запроса pay/XML, шлюз контура Банк – мерчант:
Структура ответа pay/XML, шлюз контура мерчант - Банк:
В ответ мерчант сообщает статус обработки транзакции, который может принимать статус успех, в проведении или, если оплата была отклонена, ошибка.
Два статуса финальные, а один промежуточный.
Можно сказать, что на этих статусах обязательства и Банка и Мерчанта перед клиентом завершены.
Подождите, подождите - резюмируете Вы. Как же обязательства завершены? Ведь клиент ушел с чеком, где написано, что Банк всего лишь принял операцию к исполнению, да и Мерчант может отклонить операцию, а клиент уже ушел, что делать?
Да, такое бывает достаточно часто, и для решения этой задачи существует отдельный процесс по запросу финального статуса операции как на стороне витрины, так и на стороне Банка, но об этом в следующих статьях.
Читайте также: