Как устроены интернет-платежи: вопрос—ответ
Привет! В одном из недавних постов ребята из Додо разбирали устройство интернет-платежей и в самом конце текста задались десятком вопросов по теме. Меня зовут Антон, я IT-менеджер в продукте Эквайринга, и мне удалось собрать знающих ребят в QIWI, чтобы довольно подробно ответить на эти вопросы.
Предложение пообщаться
Я думаю, что немного сомневаться в своих решениях и ресёрчить новые возможности просто необходимо на постоянной основе. У меня накопилась целая куча вопросов относительно интернет-платежей, ответы на которые я пока для себя не нашёл.
@aurokk
Что получилось — под катом.
Итак, давайте по порядку.
В соответствии с PCI DSS хранить CVC нельзя. Как работают платежи с помощью сохранённой карты?
Да, верно, CVC2\CVV2 хранить нельзя и банки-эквайеры его не сохраняют после проведения авторизации. Мы тоже так делаем при сохранении карт в эквайринге, QIWI Кошельке и в системе CONTACT.
С точки зрения технологии проведения платежа отличие лишь в нескольких значениях в соответствующих полях в теле транзакционного сообщения, позволяющих эмитенту, выпустившему платежную карту, определить, что транзакция совершена с использованием сохраненных реквизитов.
А с точки зрения пользователя платежи становятся только удобнее, ведь при оплате не требуется вводить реквизиты карты, такие как номер, срок действия и трёхзначный код проверки подлинности (CVC2\CVV2), что, несомненно, является преимуществом, например, при оплате такси или совершении регулярных платежей для продления доступа к любимому сервису.
1.1 Почему банкам не нужен CVC в этом случае?
• В целом зависит от реализации, но, как правило, сохранению реквизитов в любом приложении, либо на сайте предшествует первоначальная транзакция, инициированная держателем карты с предоставлением реквизитов карты и проведением полной аутентификацией держателя карты (3-D Secure\EMV 3DS).
• Именно на данном этапе совершаются все необходимые проверки карты и держателя карты и сохраняется и история и результат выполнения проверок.
• Таким образом, для последующих платежей по операциям с сохраненными реквизитами карты выполнение каждый раз проверки подлинности карты с использованием значения (CVC2\CVV2) попросту не требуется.
Сейчас мы интегрируемся с PSP, а PSP интегрируются с банками и платёжными системами. «АПИшки» PSP — зоопарк, у всех всё по-разному и редко сделано хорошо. А насколько API банков лучше? Есть ли какие-то банковские стандарты по разработке API и насколько банки их придерживаются?
Немного матчасти про международный стандарт ISO 8583
Международный стандарт (ISO 8583) определяет формат и правила передачи электронных транзакций между участниками платежными системами (Visa, MC, МИР). С его помощью устанавливают стандартные протоколы обмена данными в операциях платежей, включая кредитные и дебетовые карты. В теории он позволяет упростить интеграцию между участниками платежных систем и обеспечить безопасность транзакций.
А вот на практике у ISO 8583 относительно более простых API есть и недостатки, например:
Сложный для интеграции на стороне ТСП, требующий передачи полного набора данных для формирования авторизационных запросов, а также специфичных знаний по работе протокола и операционно-технологических правил каждой ПС у интеграционной команды ТСП.
Отсутствие шифрования по умолчанию: ISO 8583 не включает шифрование данных по умолчанию, что требует дополнительных усилий по поддержанию защищенного канала.
Даже не все банки-эквайеры готовы к разработке собственного процессингового решения для интеграции с ПС. Большинство банков работают в партнерстве с вендорами.
Решения вендоров уже имеют различные варианты взаимодействия (API) для интеграции мерчантов (ТСП, желающих подключить прием платежей с банковских карт). Причем у API каждого вендора есть отличия.
В общем, даже если провести не самую простую интеграцию на стандартный (ISO) протокол популярного вендора, то каждый переход с одного банка-эквайера на другой потребует доработок в интеграции и, возможно, изменения операционных процессов в связи со спецификой «диалекта», казалось бы, стандартного API каждого эквайера.
Ключевым тут является стремление каждого банка-эквайера к упрощению и ускорению технической интеграции конечных ТСП, что приводит к разработке более простых и «разношерстных» протоколов, создаваемых как вендорами процессинговых решений, так и самими банками и платежными фасилитаторами (PSP).
Более оптимальным решением для ТСП будет интеграция с платежным фасилитатором, работающим с большим количеством эквайеров — это и проще, гибче, быстрее, и не будет требовать доработок при переключении с эквайера на эквайер.
Не стоит забывать, что PSP дают и другие платежные сервисы, так, например, возможность отправлять фискальные данные в ОФД или в сервисы по аренде онлайн-касс в единой с платежами интеграции. А ещё единую для банков панель администрирования, автоматизированный бординг и реестры.
Если интегрироваться с банками напрямую, то можно ли получить выигрыш в скорости разработки относительно интеграции с PSP?
Если говорить про технику, то скорее нет, чем да. Первая интеграция по ISO 8583 займет больше времени, нужно будет организовать безопасное подключение, реализация бизнес-сценариев потребует передачи большего количество параметров. Почти у каждого банка-эквайера есть отличия в реализации даже стандартного протокола. Их еще называют «диалектами». В конечном счете все зависит от потребностей ТСП и конкретных API, предоставляемых банком или PSP.
В «среднем по больнице» первое подключение по ISO занимает в 3–5 раз больше времени, чем, к примеру, по REST JSON API.
Помимо интеграций с банками нужно ли будет ещё интегрироваться и с платёжными системами VISA/MC/НСПК?
Если говорить про обычные платежи в интернет-эквайринге с использованием номера банковской карты, то интеграция с Международными платежными системами не потребуется.
Но есть дополнительные сервисы, которые могут быть реализованы как на стороне банка, так и на стороне самого ТСП. Например, ТСП может захотеть самостоятельно реализовать сервис аутентификации для платежей по пластиковым картам (3DS Server), тогда потребуется интеграция и сертификация решения с ПС при участии эквайера.
Или размещение кнопки оплаты с помощью * Pay на собственной платежной странице (в приложении) ТСП — это тоже требует интеграции с сервисом *Pay. Но большинство банков и PSP, включая КИВИ, предоставляют эти сервисы «из коробки» или позволяют в разы упростить интеграцию.
Можно ли интегрироваться с банками и сохранить схему расчётов такую, как у нас сейчас, чтобы средства зачислялись напрямую на счета франчайзи, или нужно будет агрегировать средства на своих счетах и потом самим рассчитываться с франчайзи?
Все зависит от конкретного банка и его желания и возможностей. Сможет ли банк с достаточной оперативностью подключать (онбордить) каждого франчайзи?
Такое возможно. Мы поддерживаем и развиваем такую схему расчетов.
Можно ли получить выигрыш в комиссии эквайринга или всё наоборот? Кажется, что если в цепочке оплаты мерчант → PSP → банк-эквайер пропадает звено PSP, то комиссия должна быть ниже, но, с другой стороны, PSP — крупные клиенты банков и, возможно, банки дают им максимально низкую комиссию, настолько, что комиссии при интеграции напрямую могут оказаться выше. Как на самом деле?
Тарифы, установленные платежными системами, едины для всего рынка.
Если проще — «себестоимость» обработки операции для банка одинакова в обоих случаях (напрямую или с PSP). Доход банка или PSP сверх себестоимости обусловлен сервисами, которые этот банк или PSP предоставляют.
Примеры таких сервисов — предоставление платежной формы, техническая поддержка для ТСП и для покупателей в ТСП, Личный Кабинет для ТСП, организация обмена отчетной/сверочной информацией (Акты, реестры), антифрод-система, система аналитики и мониторинга за трафиком, разнообразие вариантов проведения платежа/выставления счета (прием платежей через социальные сети, выставление счетов на оплату через ЛК, готовые SDK, набор готовых модулей для интеграции в CMS). Другие методы оплаты (СБП, электронные кошельки, платежи с баланса мобильной оператора).
За предоставление этих сервисов банк или PSP и берут комиссию.
Конечно же, коммерческие условия обговариваются индивидуально. Но стоит понимать, что для PSP прием платежей это основной бизнес (а значит, высокая конкуренция за конечного клиента — ТСП), а для банков — один из видов банковской деятельности, чаще не основной.
Как искать и выбирать банки-эквайеры для интеграции напрямую?
Прежде всего — определитесь с потребностями. Решите для себя, как именно фичи вам необходимы, изучите API популярных PSP, посмотрите, как работает авторизация, подумайте, какие тестовые сценарии во время интеграции эквайер сможет упростить.
Одним из эффективных методов конкурентного отбора является тендер.
Можно составить анкету или опросник с теми вопросами, что критичны для вашего бизнеса, и разослать его потенциальным поставщикам платежных решений. Участие в тендерах для эквайеров и PSP — привычное дело.
С наиболее подходящими кандидатами рекомендуем проводить онлайн- или оффлайн-встречи для более глубокого обсуждения деталей и демонстраций их решений.
Что ещё нужно знать? Возможно, моё представление всего процесса слишком наивно и для интеграции напрямую надо делать ещё миллион всяких вещей, менеджить терминалы, например.
Тут, на самом деле, ответ получается настолько объёмным, что заслуживает отдельного поста. Если вам будет интересно прочитать конкретно про это — пишите в комментах.
Кстати, о терминалах (е-ком): что это такое и кто их менеджит, PSP или банк-эквайер? Это то же самое, что MID, т.е. виртуальная сущность, или есть какой-то физический девайс, в который это мапится?
В интернет-эквайринге менеджеры PSP под словом «терминал» чаще всего имеют в виду уникальную пару Merchant ID (MID) и Terminal ID (TID), которую банки-эквайеры создают для каждой конкретной торговой точки.
Это виртуальные сущности. Merchant ID — это уникальный ID ТСП в эквайере и платежной системе, Terminal ID — это уникальный ID терминала в эквайере и Платежной системе (корнями из торгового эквайринга, где для каждого физического POS-устройства должен использоваться отдельный TID).
В рамках одного MID может несколько TID (например, для разных видов деятельности).
Все PSP имеют собственные процессинги и чаще всего «маппят» пару MID и TID в свой идентификатор торговой точки, называя этот ID по-разному, например «shop» или «public» или «merchant», «site».
Насколько всё это отличается от страны к стране, от региона к региону, например, в странах Европы, в странах Азии?
Если речь в целом про подключение / интеграцию, управление терминалами, проведение взаиморасчетов, поддерживаемые технологии и прочее, то тарифы, условия, операционно-технологическое взаимодействие и подобное могут отличаться в целом даже от Банка к Банку или PSP, не говоря уже о различиях по странам или регионам.
Если же речь о правилах и стандартах платежных систем, то платежные системы стремятся к унификации для обеспечения возможности приема и обслуживания платежных карт в большинстве стран.
Иными словами протокол для всех единый, но есть и специфика работы внутри отдельной страны. Существуют исторические и культурные предпосылки и особенности развития платежных систем в каждой стране / регионе, которые оказали и продолжают оказывать влияние на сложившуюся конъюнктуру рынка платежной индустрии.
А ещё есть предпосылки регуляторные — законодательные, которые оказывают непосредственное влияние на степень технологического развития и поддержки современных платежных технологий, создания рыночных условий, конкурентной среды, обеспечения безопасности платежей и другое.
Как можно сделать несколько транзакций внутри одного платежа без участия пользователя, например, один для оплаты заказа, один в благотворительность, один в чаевые?
Для совершения платежа требуется распоряжение держателя карты, поэтому в каком-то виде участие пользователя все же потребуется. Было ли дано распоряжение / согласие на проведение платежа в момент совершения оплаты или заблаговременно — значения в контексте вопроса не имеет.
Если же говорить о технологии, то потребность в проведении нескольких транзакций внутри одного платежа сформировалась в процессе развития приема платежей в интернет-магазинах.
Например, для таких маркетплейсов, где встречаются продавец и покупатель, крайне важно обеспечить списание средств только в случае отгрузки товара со склада, особенно, когда участвует несколько продавцов.
С точки зрения пользовательского сценария и технологии совершения платежа покупатель на сайте маркетплейса формирует заказ, соглашается с условиями и предоставляет реквизиты карты на платежной форме. После нажатия «Оплатить» формируется запрос авторизации на полную сумму заказа.
Далее маркетплейс по мере поступления подтверждений от продавцов об отгрузке товаров инициирует формирование финансовых транзакций для списания средств с карты по каждому такому подтверждению на отдельную сумму, но суммарно в объеме, не превышающем полную сумму заказа или захолдированную сумму.
Предположим, что в заказе присутствует и товар, и благотворительность и от разных продавцов, то финансовые транзакции будут сформированы на каждое подтверждение по мере реализации заказа, а изначальный запрос авторизации один.
А если клиент еще хотел бы и отблагодарить курьера за доставку, то чаевые можно авторизовать отдельно по сохраненным реквизитам карты, либо заранее включить в сумму заказа, как отдельную услугу.
11.1 Сплитование платежей
Еще у некоторых банков (в том числе у нас) и PSP есть решения, позволяющие разделить сумму платежа от покупателя между несколькими получателями (физическими и юридическими лицами) на этапе расчетов (выплаты средств получателям). То есть со стороны покупателя это выглядит как один платеж, со стороны получателей — как отдельные суммы.
Чаще всего такой функционал называется «сплитованием платежа» и требует передачи данных о сумме и реквизитах каждого получателя прямо в самом запросе на списание, либо уже после самого списания с покупателя, в формате реестра.
В общем-то, это всё. Конечно, тонкости платежей и их механика у разных банков, вендоров и систем — это отдельная вселенная. Мы постарались объяснить всё подробно, при этом не слишком растекаясь по древу, так что если у вас остались вопросы или уточнения — пишите в комментариях.
