Что делать, если не удается оплатить банковской картой в Интернет-магазине
Почему важно знать причины неоплаты?
Оплата банковской картой через интернет — эту услугу сейчас предлагает практически любой интернет магазин. Вы можете например купить билет на поезд, оплатив банковской картой, сделать покупку на ozon.ru, купить ЖД билет онлайн.
Я всегда заказывал и оплачивал билеты банковской картой через интернет(я использую только дебетовые карты, у меня нет кредитной карты). Самое интересное, что и эта услуга иногда дает сбой — зависают деньги на карте, не проходит оплата.
Но у меня был случай, когда оплата просто не проходила. Робокасса писала сообщение — оплата отменена. Я не знал, в чем причина. В личном кабинете найти ошибку мне не удалось.
Существует множество разных причин ошибок — они бывают по причине банка или владельца карты. Важно хотя бы предполагать причину ошибки, чтоб понимать как действовать дальше? К примеру, если не удается оплатить горячий билет, то нужно понимать в чем причина и попытаться исправить проблему. Иначе билет может быть куплен другим человеком.
Основные причины ошибок при оплате банковской картой
Первая причина, которая является самой распространенной — отсутствие нужной суммы на карте. Рекомендуется проверить ваш баланс — для этого нужно позвонить в банк или войти в интернет банк. Иногда по карте устанавливают ежемесячный или ежедневный лимит трат. Чтоб это проверить — нужно позвонить в банк.
Эта причина может быть не ясна сразу — при отказе в оплате может не отображаться ваш баланс. Ошибка аутентификации 3D secure может быть также связана с неверным вводом реквизитов карты на предыдущем шаге. В таком случае просто повторите платеж и укажите правильные данные.
Вторая причина — на строне платежной системы. Например, терминал оплаты РЖД не позволяет платить картами MasterCard. Можно использовать только карты Visa.
Заданный магазин может не поддерживать данный способ оплаты. К примеру, робокасса, которую подключают к множеству магазинов предлагает различные тарифы для оплаты. 
Я сначала хотел оплатить вебмани, однако я позвонил в магазин. Оказалось, оплатить вебмани нельзя. У них не подключена эта опция. Хотя способ оплаты через вебмани предлагается на странице оплаты.
Третья причина — возможно ваша карта заблокирована. Опять же можно позвонить в банк и проверить это. Блокировка может быть осуществлена банком автоматически в случае наличия подозрительных операций у клиента.
Четвертая причина — у вас не подключена опция 3d Secure(MasterCard SecureCode в случае MasterCard).
Технология 3D Secure заключается в следующем: при оплате вам приходит СМС от банка, которую вы должны ввести в специальном окне. Эту СМС знаете только вы и банк. Мошенничество в данном случае достаточно трудно, для него потребуется и ваш телефон.
Эта опция нужна вам для оплаты на сумму больше 3 тыс. рублей. Это как раз мой случай. Я купил в интернет магазине газовую плиту Bosh. При оплате товара на сумму 22 тыс. рублей мне выдалось вот такое сообщение: 
Я был в замешательстве, не знал что делать. Сначала я думал, что это проблема магазина. Но сначала я все таки позвонил в банк. В моем случае это был Промсвязьбанк и карта Доходная.
Позвонив в поддержку Промсвязьбанка, мне предложили сначала пройти процедуру аутентификации
Далее для подключения услуги 3d Secure от меня потребовали 2 номера из таблицы разовых ключей. Вроде как услугу подключили, но через полчаса оплата снова не прошла. Позвонил в банк — сказали ожидайте когда подключится — услуга подключается не сразу. Нужно подождать.
Я решил проверить, подключена ли услуга. Я залогинился в Интернет-банк — увидел, что такая услуга есть(в ПСБ ритейл это можно посмотреть на странице карты, щелкнув по номеру карты) 
Еще раз попытка оплаты — мне высветилось окно, где я должен был ввести код подтверждения. После заполнения данных карты мне пришло СМС с кодом для оплаты 
Далее вуаля — заказ наконец то оплачен. Я получил следующее окно и статус заказа в магазине изменился на «Оплачен»
Мой заказ доставили в пункт назначения, где я его заберу в течение месяца. Главное оплата прошла. 
Самая частая ошибка 11070: ошибка аутентификации 3d-secure — причины
Самая частая ошибка, которая происходит при оплате картой — 11070: ошибка аутентификации 3dsecure. Есть 2 возможных причины этой ошибки
В любом случае, советуем повторить процесс оплаты и удостовериться, что вы ввели одноразовый пароль 3D Secure сразу после получения и пароль введен верно.
Ошибка процессинга карты — что это такое?
Процессинг банка — это сложная программа, которая отвечает за обработку транзакций по картам. Когда вы снимаете деньги в банкомате, делаете покупку, то идет запрос по интернет в данную систему. Проверяется есть ли на вашей карте деньги. Эта программа находится на серверах в Интернет.
Вы не можете повлиять на данную ошибку никак. Вам стоит обратиться на горячую линию банка или интернет-магазина, где вы осуществляете транзакцию. Исправление ошибки — дело специалистов, поддерживающих данную систему. Остается только ждать.
Вы можете попробывать осуществить оплату повторно примерно через пол-часа. По идее такие ошибки должны исправляться очень быстро. Аналогичная ошибка бывает с сообщением «Сервис временно недоступен». Это значит, что сломалась серверная сторона и сделать ничего нельзя. Только ждать починки
Что значит хост недоступен при оплате картой
Хост — это определенный сетевой адрес. Это может быть ip адрес или же просто доменное имя(к примеру, server1.sberbak.online). При оплате картой через терминал происходит подключение к определенному сетевому адресу(хосту). На данном хосте находится программное обеспечение, которое производит оплату — снимает с карты деньги, проверяет баланс и т.д.
Если хост недоступен, значит деньги снять нельзя. Есть 2 основных причины недоступности:
Что такое ошибка в CVC карты?
CVC-код — это трехзначный код, который находится на обратной стороне вашей банковской карты. Если появляется ошибка в CVC карты, то рекомендуем проверить, правильно ли вы ввели этот код? Если все правильно, пожалуйста проверьте, введены ли правильно другие данные вашей карты Сбербанка, ВТБ или другого банка.
CVC код нужен для того, чтоб проверить, есть ли у вас на руках данная карта в руках. Данная ошибка значит, что CVC код введен неверно. Просто осуществите оплату повторно и введите все данные верно
Проблема при регистрации токена — как решить?
Проблема при регистрации токена — частая ошибка, которая проявляется на сайте РЖД при оплате билетов.
Токен — это уникальный идентификатор(стока типа 23hjsdfjsdhfjhj2323dfgg), которая формируется когда вы заказываете билет. Это как бы ваша сессия оплаты. Ошибка возникает на стороне сервера оплаты.
Решений может быть два
Если ошибка в течение часа сохраняется, рекомендуем обратиться на горячую линию РЖД.
Ошибка банковской карты — карта не поддерживается
Ошибка «карта не поддерживается» может возникать, если вы оплачиваете какую-либо услугу картой другой платежной системы, предоплаченной картой либо же Виртуальной картой. Это не значит, что карта у вас «неправильная», на ней нет денег или еще что-либо. Просто в данном конкретном случае нельзя использовать карту вашего типа. К примеру, виртуальные карты нельзя использовать при оплате в Google Play Market.
Решение простое: попробуйте использовать другую карту. Если ошибка повторится, то обратитесь в службу поддержки интернет-магазина или платежного сервиса, где осуществляете оплату.
Таблица с кодами ошибок при оплате.
Немногие знают, что при оплате картой система обычно выдает код ошибки. Например, E00 при оплате. Иногда по ошибке можно понять, в чем проблема
Что делать, если с картой все ОК, но оплата не проходит?
Самая типичная проблема, когда оплата не проходит — сбой в банковской системе. В работе банка могут наблюдаться перебои. Это может быть не обязательно ваш банк, а банк который принимает платеж на стороне клиента(которому принадлежит терминал). В этом случае можно дать 2 совета
3 полезных совета при оплате картой через Интернет
Во первых — заведите себе специальную карту. Не используйте для оплаты зарплатную карту, на которой у вас все деньги. Оптимально — кредитная карта. Она позволяет в отдельных случаях вернуть часть суммы покупки(CashBack). Обычно это сумма до 5 процентов от покупки. Будьте внимательны, некоторые сервисы при оплате катой берут комиссии. И конечно же адрес страницы оплаты всегда должен начинаться с https и рядом с адресом должен стоять значок в виде замка(Соединение https).
Во вторых — не держите много денег на карте. На карте должно быть немногим больше суммы, необходимой вам для покупки. Примерно плюс 10% от общей стоимости покупки. Логика проста — с нулевой карты ничего не могут снять.
Делаете покупку — просто пополняете карту в интернет банке и получаете нужную сумму.
В третьих — Делайте оплату картой в известных магазинах. Почитайте отзывы о магазинах на Яндекс.Маркет. Если вы платите картой, будьте готовы к тому, что при отмене заказа могут вернуться на вашу карту не сразу.
В последний раз, когда я делал оплату заказа и потом возвращал заказ и деньги, возврат на карту шел в течение 7 дней. Помните — никто деньги вам сразу не вернет. Будьте готовы ждать.
Криптография платежных данных для продавцов
Прочитав это руководство, вы узнаете, как создать открытый ключ для запроса токена способа оплаты, подписанного и зашифрованного Google, а также как подтвердить и расшифровать этот токен.
Поскольку ваше приложение будет получать информацию о платежных картах напрямую, убедитесь, что оно соответствует требованиям стандарта PCI DSS, а серверы имеют необходимую инфраструктуру для безопасного использования платежных данных пользователей.
В библиотеке Tink можно найти образец кода, исполняющего пункты 1–6.
Примечание. Мы настоятельно рекомендуем использовать код из библиотеки Tink для выполнения пунктов 1–6. Описание последовательности действий приведено для справки. Если вам нужен код для расшифровки токена, ознакомьтесь с разделом Как использовать библиотеку Tink для управления зашифрованными ответами.
Структура токена способа оплаты
Пример
Ниже показан пример токена способа оплаты в формате JSON.
Промежуточный ключ подписи
intermediateSigningKey представляет собой закодированный по стандарту UTF-8 сериализованный объект JSON с указанными ниже значениями.
| Имя | Тип | Описание |
|---|---|---|
| signedKey | Строка | Сообщение в кодировке Base64, содержащее платежное описание ключа. |
| signatures | Строка | Проверяет, является ли Google отправителем промежуточного ключа. Создается с использованием кодировки Base64 и алгоритма ECDSA. |
Подписанный ключ
signedKey представляет собой закодированный по стандарту UTF-8 сериализованный объект JSON с указанными ниже значениями.
| Имя | Тип | Описание |
|---|---|---|
| keyValue | Строка | Версия ключа в формате ASN.1, закодированная с использованием Base64. Информация в строке SubjectPublicKeyInfo определяется в соответствии со стандартом X.509. |
| keyExpiration | Строка | Дата и время окончания действия промежуточного ключа (UTC, в миллисекундах UNIX-времени). Интеграторы отклоняют все ключи с истекшим сроком действия. |
Подписанное сообщение
signedMessage представляет собой закодированный по стандарту UTF-8 сериализованный объект JSON с указанными ниже значениями.
Зашифрованное сообщение
Расшифрованное значение строки encryptedMessage представляет собой закодированный по стандарту UTF-8 сериализованный объект JSON. Объект JSON состоит из двух уровней. Внешний уровень содержит метаданные и поля, обеспечивающие безопасность. Внутренний уровень – это ещё один объект JSON, включающий фактические платежные данные.
Более подробную информацию о сообщении encryptedMessage можно найти в приведенных ниже таблицах и примерах объектов JSON.
| Имя | Тип | Описание | |||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| gatewayMerchantId | Строка |
| Имя | Тип | Описание |
|---|---|---|
| pan | Строка | Номер банковского счета, с которого осуществляется оплата. Эта строка может содержать только цифры. |
| expirationMonth | Число | Месяц истечения срока действия карты (где 1 – январь, 2 – февраль и т. д.). |
| expirationYear | Число | Состоящий из четырех цифр год истечения срока действия карты (например, 2020). |
| authMethod | Строка | Метод аутентификации транзакции по карте. |
| assuranceDetails | AssuranceDetailsSpecifications | В этом объекте содержится информация о верификации данных способа оплаты. |
PAN_ONLY
CRYPTOGRAM_3DS
В случае аутентификации способа оплаты CARD с помощью криптограммы 3-D Secure ( CRYPTOGRAM_3DS authMethod ) используются дополнительные поля:
| Имя | Тип | Описание |
|---|---|---|
| cryptogram | Строка | Криптограмма 3-D Secure. |
| eciIndicator | Строка | Присутствует не всегда. Используется, только если карта относится к платежной системе Visa. Это значение должно быть передано в запросе авторизации платежа. |
Подтверждение подписи
Для подтверждения подписей с промежуточным ключом и подписями сообщений нужно следующее:
Алгоритм подписи
Google использует для подписывания сообщений алгоритм на эллиптических кривых (ECDSA) со следующими параметрами: алгоритм ECDSA на кривой NIST P-256 с хеш-функцией SHA-256 в соответствии с FIPS 186-4.
Подпись
Подпись включена во внешний уровень сообщения. Она кодируется с использованием Base64 в байтовом формате ASN.1. Чтобы получить дополнительную информацию о формате ASN.1, изучите приложение А к документу «Инструменты IETF». Подпись состоит из целых чисел r и s, рассчитанных по алгоритму ECDSA. Подробности можно найти в описании алгоритма создания подписи.
Ниже приведен пример использования байтового формата ASN.1 – стандартного формата, созданного с помощью расширения Java Cryptography Extension (JCE) в соответствии с алгоритмом ECDSA.
Как построить строку байтов для проверки подписи промежуточного ключа
Чтобы проверить подпись промежуточного ключа подписи в пробном токене способа оплаты постройте строку signedStringForIntermediateSigningKeySignature по следующей формуле:
Пример
В этом примере используется следующий токен способа оплаты:
Как подтвердить подпись для строки signedStringForIntermediateSigningKeySignature
Как построить строку байтов для подписи сообщения
Чтобы проверить подпись в токене способа оплаты, приведенного в качестве примера, постройте строку signedStringForMessageSignature по следующей формуле:
Пример
В этом примере используется следующий токен способа оплаты:
Как подтвердить подпись для строки signedStringForMessageSignature
Спецификация схемы шифрования
Для защиты токена способа оплаты в ответе Google Pay API применяется интегрированная схема шифрования на эллиптических кривых (ECIES). В схеме шифрования используются указанные ниже параметры.
| Параметр | Описание |
|---|---|
| Метод инкапсуляции ключа | |
| Алгоритм MAC | HMAC_SHA256 с использованием 256-битного ключа, полученного с помощью функции формирования ключа. |
Формат открытого ключа шифрования
Этот формат подробно описан в документе «Криптография с открытым ключом для индустрии финансовых услуг: алгоритм цифровой подписи на эллиптических кривых (ECDSA)», ANSI X9.62, 1998.
Как создать открытый ключ с помощью OpenSSL
Шаг 1. Создайте закрытый ключ
Просмотр закрытых и открытых ключей (необязательно)
Чтобы посмотреть закрытые и открытые ключи, введите следующую команду:
После ввода команды вы увидите строку примерно следующего содержания:
Шаг 2. Создайте открытый ключ с кодировкой Base64
Закрытый и открытый ключи, сгенерированные в предыдущем необязательном шаге, показаны в шестнадцатеричном формате. Чтобы увидеть открытый ключ с кодировкой Base64 в несжатом формате, введите команду:
После ввода команды вы увидите файл publicKey.txt примерно следующего содержания (это версия ключа с кодировкой Base64 в несжатом формате):
В этом файле не должно быть лишних пробелов и символов возврата каретки. Чтобы убедиться в этом, запустите следующую команду в Linux или MacOS:
Шаг 3. Создайте закрытый ключ с кодировкой Base64 в формате PKCS #8
Для библиотеки Tink нужен закрытый ключ с кодировкой Base64 в формате PKCS #8. Чтобы создать закрытый ключ в нужном формате на основе ключа, созданного на первом шаге, введите следующую команду:
После ввода команды вы увидите строку примерно следующего содержания:
Как расшифровать токен способа оплаты
Выполните следующие действия:
Управление ключами
Ключи шифрования продавца
Продавцы должны генерировать открытые ключи согласно требованиям, описанным в разделе Спецификация схемы шифрования.
Примечание. Продавцам следует ежегодно отправлять обновленную документацию PCI и менять ключи шифрования в Google Pay Business Console. Разрешается трехмесячная отсрочка обновления ключей. Если продавец не обновит ключи в течение этого периода, Google вправе прекратить исполнение запросов этого продавца, отправляемых на Google Pay API.
Корневые ключи подписи Google
Google публикует набор действующих в настоящий момент открытых корневых ключей, которые могут быть получены по общедоступному URL. Ключи действительны, если это подтверждается заголовками кеша HTTP, возвращаемыми URL. Срок действия ключей определяется значением поля keyExpiration. Если срок действия ключей истек, запросите новые по общедоступному URL.
Ключи, предоставленные через общедоступный URL, отображаются в следующем формате:
Предоставляются URL-адреса для тестовой и рабочей среды.
Обновление ключей
Если вы расшифровываете токены способов оплаты прямо на своих серверах с прямой интеграцией, обновлять ключи нужно раз в год.
Выполните следующие действия:
Чтобы не возникло проблем, не выключайте поддержку расшифровки со старыми ключами, пока не будет завершен переход к новым.
Если для расшифровки токенов вы пользуетесь библиотекой Tink, включите поддержку нескольких закрытых ключей. Сделать это можно с помощью следующего Java-кода:
Убедитесь, что код для расшифровки развернут в рабочей среде, и следите за тем, насколько успешно проходит расшифровка.
Измените открытый ключ, который используете в коде.
Укажите в свойстве PaymentMethodTokenizationSpecification parameters новое значение атрибута publicKey :
Убедитесь, что старые открытые ключи действительно не применяются для шифрования каких-либо транзакций.
Как использовать библиотеку Tink для управления зашифрованным ответом
Используйте криптографическую библиотеку Tink для подтверждения подписей и расшифровки сообщений. Чтобы интегрировать свое приложение с библиотекой Tink, выполните указанные ниже действия.
В файле pom.xml добавьте paymentmethodtoken Tink в качестве зависимости.
При запуске сервера получите ключи подписи Google, чтобы они были доступны в памяти. Благодаря этому при расшифровке данных ключ будет загружаться быстрее.
Если вы не можете каждый раз при расшифровке ключей обращаться к серверу Google, используйте код, приведенный ниже. Вместо элементов, выделенных полужирным шрифтом, подставьте собственные значения.
В обычных условиях текущий ключ будет действовать в рабочей среде до 14 апреля 2038 года. В случае взлома ключей Google отправляет продавцам уведомления о том, что необходимо обновить файл keys.json раньше срока. При отправке уведомлений используется контактная информация, указанная на портале.
Поскольку перечисленные ниже операции проверки безопасности уже реализованы в приведенном фрагменте кода, вы можете сконцентрироваться на работе с платежной информацией.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Токенизация карт в E-commerce: что это такое и как работает?
Всем привет! Недавно мы в Яндекс.Кассе совместно с платежными системами Visa и Mastercard запустили новую технологию токенизации платежей для E-commerce, или, по-другому, онлайн-коммерции. Кто-то может подумать: что тут такого — с токенизацией карт разобрались уже с выходом Apple Pay, Google Pay и других *Pay. Но нет, тут что-то новенькое, а мы еще и первыми эту технологию запустили в России этой весной для магазинов-партнеров, так что почему бы не поделиться.
В США и Европе эта технология появилась несколько раньше, и пользователи таких сервисов, как Netflix и Amazon, уже платят E-commerce токенами, хотя, возможно, даже не знают об этом. А я сейчас расскажу, как это устроено не только снаружи (для партнеров и держателей карт), но и изнутри, с точки зрения разработчика и тимлида этого проекта. Если интересно — велкам под кат.
Что общего с Apple Pay и Google Pay
Те читатели, которые представляют, как работают Apple Pay и Google Pay (а кто не знает — вот наша статья про запуск *Pay), увидят тут знакомые слова.
Если коротко, то одна из особенностей технологий *Pay заключается в том, что плательщику не нужно передавать магазину данные своей банковской карты. Он один раз обменивает их на специальный цифровой токен и дальше, не подвергаясь риску перехвата данных карты, при платеже использует только этот токен. А преимущество в том, что токен работает только вместе с одноразовой криптограммой, которая генерируется на телефоне плательщика, а вне телефона эту криптограмму создать не получится. К тому же этими токенами легко управлять — удалять или создавать новые — дело одной минуты в онлайне, никаких походов в банк и прочей бюрократии.
Пока запомним эти особенности токенизации карт на устройствах пользователей:
Запомнили? А теперь перейдем к токенизации карт для E-commerce, иначе говоря, для онлайн-платежей в интернет-магазинах.
Итак, что такое токенизация в E-commerce
Вообще, токенизация карты — это обмен конфиденциальных данных банковской карты на специальный токен, который позволяет оплачивать покупки с помощью этой карты.
Конфиденциальные данные карты — это ее номер (PAN — Primary Account Number) и срок действия.
Если для подключения карты в *Pay инициатором является сам держатель карты, то токенизацию для E-commerce инициирует интернет-магазин. Но зачем (и с какой стати)?
Наверняка многие из вас пользуются сервисами с подписками: будь то ежемесячная оплата музыки, фильмов или, например, коммунальных услуг. Как оформляется эта подписка? Вы заходите на сайт интернет-магазина, вводите данные своей карты и ставите галочку, подтверждающую ваше согласие на то, что магазин сохранит данные вашей карты (PAN и срок действия) и сможет самостоятельно инициировать оплату за конкретную услугу.
Нужно понимать, что такое действие подразумевает, что магазин должен где-то сохранить данные карты. Тут обычно два варианта:
Давайте обо всем по порядку. При токенизации мы обмениваем данные банковской карты на некий токен, но что это такое? Токен предоставляется платежной системой карты — Mastercard или Visa. Он представляет собой уникальный идентификатор, аналогичный номеру учетной записи устройства в Apple Pay или номеру виртуального счета в Google Pay, которые можно найти в приложении на смартфоне (Wallet на устройствах Apple и Google Pay — на Android).
В отличие от *Pay, в E-commerce токенизации создание токена инициирует интернет-магазин или его платежное решение, а сами токены хранятся на серверах платежных систем.
Разумеется, кто угодно не может прийти к платежной системе и получить токен чьей-либо карты для оплаты покупок. Во-первых, токенизировать карты могут только те платежные решения, которые пройдут сертификацию и получат одобрение платежных систем. Такое платежное решение называется On-Behalf Token Requestor или Token Service Provider, но для простоты будем впредь оперировать термином Token Requestor. И только Token Requestor может инициировать платежи токеном. Во-вторых, токен всегда выпускается для конкретного магазина, и с помощью токена можно платить только в этом магазине. Очень похоже на то, как токен *Pay связан с устройством, на котором он был создан.
За счет чего это достигается? Просто перед проведением каждого платежа по токену Token Requestor должен получить одобрение у платежной системы на этот платеж. Факт такого одобрения надо будет предъявить во время фактического проведения платежа, поэтому одобрение это имеет форму одноразовой криптограммы, которую формирует платежная система карты. При проведении платежа эта криптограмма добавляется к параметрам запроса в банк-эквайер и затем передается платежной системе, которая проверяет подлинность этой криптограммы, которую сама ранее выдавала.
А что там про управление токеном независимо от управления картой? Тут вообще все просто — токен живет своей жизнью, имеет свои статусы жизненного цикла, и о каждом изменении статуса Token Requestor сразу же узнает от платежной системы карты.
Подведем некоторый итог. Что токенизация дает держателю карты?
*Мы сравнивали платежи за этот апрель в крупном онлайн-кинотеатре (MCC 4899) — привязанными картами без 3DS, без учета неуспешных платежей из-за нехватки денег на карте.
Технические аспекты
Для любителей копнуть чуть глубже, расскажу о технологии токенизации карт и ее запуске в Яндекс.Кассе — как все это выглядит изнутри нашего платежного решения.
Интеграция с платежными системами
Чтобы получить техническую возможность токенизировать карты и проводить платежи токенами, необходимо интегрироваться с Visa и Mastercard, пройти тесты, сертификацию и получить их одобрение на запуск в production. Поначалу это звучало устрашающе. Да и не только поначалу, если честно, по крайней мере, для меня. Но устрашала скорее сертификация, а по технике все было предельно ясно.
Интеграция подразумевает реализацию следующего API (условно) между платежной системой и нами в качестве Token Requestor:
Токенизация в Яндекс.Кассе
Яндекс.Касса представляет из себя большую систему по приему платежей для интернет-магазинов. Она состоит из многих десятков различных сервисов: backend-, frontend-приложения, BI-сервисы. Они обеспечивают прием платежа пользователя различными способами, перевод денежных средств магазину, управление платежами через личный кабинет магазина, аналитические сервисы и тому подобное. И как именно сюда встроилась токенизация карт?
Главный вопрос: в какой момент создавать токен для банковской карты?
В API Яндекс.Кассы есть возможность сохранять выбранный способ оплаты для последующих платежей в будущем, мы это называем автоплатежи.
Это может происходить как при привязке карты к аккаунту пользователя в личном кабинете магазина, так и при подписке на периодической основе, когда платежи с карты будут проводиться автоматически. В обоих сценариях при создании платежа магазин по API передает параметр save_payment_method: true, и после успешного платежа мы выдаем магазину payment_method_id — идентификатор сохраненного способа оплаты, с помощью которого он сможет проводить новые платежи.
Вот он, этот момент. Токены созданы как раз для платежей, инициированных магазином. Поэтому сразу после проведения платежа с сохранением способа оплаты мы асинхронно ставим нашему сервису токенизации задачу создать токен для пары «карта и магазин».
Что же сами платежные системы делают в момент токенизации карты?
Они обращаются в банк-эмитент, с запросом на создание токена (как это происходит и при создании токенов *Pay), и банк выпускает токен для данного магазина. Банк также может уведомить об этом держателя карты и отобразить созданный токен в его личном кабинете.
Как происходит платеж токеном?
Пожалуй, тут понадобится некоторая иллюстрация, как вообще проходит платеж ранее сохраненной картой, который инициирует интернет-магазин:
Итак, при платеже ранее сохраненным способом магазин передает только его идентификатор — payment_method_id. По этому идентификатору сервис платежей картами находит данные (PAN и срок действия) карты и передает их одному из банков-эквайеров, который далее общается с платежной системой карты.
С токенами в этом сценарии добавляется еще один шаг:
Если видим, что для карты и магазина ранее был выпущен токен, то мы можем провести платеж без использования данных карты. Для этого мы через сервис токенизации предварительно отправляем запрос в международную платежную систему с данными токена и в ответ получаем одноразовую криптограмму, которая подтверждает, что токен действующий и мы имеем право провести платеж. И уже после этого мы передаем банку-эквайеру данные токена вместе с этой криптограммой.
А что происходит в сценарии, когда пользователь перевыпускает карту в своем банке?
Если к карте ранее были выпущены токены, то банк-эмитент сообщает в платежную систему Mastercard/Visa, что карта перевыпущена. В свою очередь, каждый Token Requestor, который выпускал токены к этой карте, получит уведомление от платежной системы. Оно содержит обновленную информацию о карте: последние 4 цифры номера и новый срок действия. Токен при этом остается прежним.
Когда магазин инициирует очередной платеж с уже просроченной карты, которая на самом деле была перевыпущена, а у нас есть токен к ней для этого магазина — платеж пройдет успешно. К тому же мы сообщим магазину уже новые последние 4 цифры банковской карты — они будут присутствовать в ответах нашего API. Это нужно для того, чтобы и магазин, и пользователь всегда видели, с какой именно карты списываются средства.
Вместо заключения
Токенизация в E-commerce — это новый этап развития приема платежей, повышающий удобство для всех участников процесса оплаты. Мы ожидаем, что в ближайшее время технологию поддержат многие российские банки и провайдеры — и она станет новым стандартом платежного рынка.
Конечно, рассказ получился скорее обзорным, но я надеюсь, что каждый читатель найдет в нем что-то полезное для себя — повысит свой уровень финансовой грамотности, узнает о новинках в финтехе или, может, найдет идею для развития своего бизнеса.
