Create token account что это

Токены Solan’ы

Понимание токенов Solana может быть довольно сложным, если вы имеете опыт работы с Ethereum. В Ethereum обычные токены используют стандарт ERC20, а NFT токены используют стандарт ERC721. Каждый токен ERC20, ровно как и каждая NFT коллекция, имеет свой собственный смарт-контракт

Модель аккаунтов Соланы

Чтобы понять как работают токены на солане, вам сначала нужно понять модель учетных записей соланы. Я настоятельно рекомендую прочитать эту вики , особенно если вы имеете опыт работы с Ethereum. Вот краткая выжимка:

• Учетная запись либо содержит данные (например, сколько у вас токенов), либо представляет собой исполняемую программу (например, смарт-контракт). Первые называются «data accounts», а вторые — «program accounts». Важно отметить, что в отличие от Ethereum, учетные записи программы не хранят состояние. Все состояние хранится в учетных записях данных
• Каждый аккаунт содержит следующие поля:

• Каждая учетная запись имеет уникальный адрес (похожий на Ethereum). Большинство адресов являются открытым ключом keypair
• Каждая учетная запись принадлежит program. По умолчанию вновь созданная учетная запись принадлежит встроенной программе под названием «System Program». Только владелец учетной записи может изменить ее

Для получения более подробной информации вы можете обратиться к вики , о которой я упоминал выше, или прочитать краткий учебник по учетным записям

Учетная запись слева — это учетная запись программы, которая может увеличивать счетчик. Значение счетчика необходимо хранить в отдельной учетной записи с данными. Учетная запись с данными принадлежит учетной записи программы, что означает, что учетная запись программы может изменять состояние учетной записи с данными

Что такое Solana’s Token Program?

Solana Token Program позволяет следующее (для взаимозаменяемых и невзаимозаменяемых токенов):

• Минт токенов
• Трансфер токена
• Сжигание токенов

Вот hana рассказывал о том, как это работает:

Одним из преимуществ модели программы/учетной записи является то, что у вас может быть одна общая программа, которая работает с различными данными. Лучшим примером этого является программа токена spl. Чтобы создать новый токен, вам не нужно развертывать код, как это делается в эфириуме. Вы создаете учетную запись, которая может минтить токены, и другие учетные записи, которые могут их получать. Адрес минтера однозначно определяет тип токена, и все они передаются в качестве аргументов одному статическому экземпляру программы

По сути, вместо развертывания нового смарт-контракта ERC20 для каждого нового токена, все, что вам нужно сделать, это отправить инструкцию программе токена. В зависимости от того, какую инструкцию вы отправляете, программа токенов будет минтить/передавать/сжигать токены

Если вы еще не совсем поняли, не волнуйтесь! Рассмотрение примера должно прояснить ситуацию!

Примечание: иногда вы увидите токены Solana, называемые «SPL tokens». SPL означает Solana Program Library (библиотеку программ Solana), которая представляет собой набор программ Solana, которые команда Соланы развернула в сети. Токены SPL аналогичны токенам ERC20, поскольку каждый токен SPL имеет стандартный набор функций

Как работает Solana Token Program?

Самый простой способ понять это — рассмотреть несколько примеров. В наших примерах будут рассмотрены взаимозаменяемые токены, и мы будем использовать инструмент командной строки spl-token для взаимодействия с программой токена (вы можете установить его, запустив в командной строке cargo install spl-token-cli)

Повторюсь, все, что делает spl-token — это отправляет инструкции в token program. Вы можете имитировать следующее поведение, используя клиент JavaScript или взаимодействуя с программой токена через CPI в Rust

Подготовка

Во-первых, убедитесь, что вы установили Solana CLI и spl-token

Затем запустите solana-keygen new -o ~/my_solana_wallet1.json и создайте новую переменную окружения с именем $SOLADDR1, в которой будет храниться полученный открытый ключ. Повторите эти действия, но со второй переменной окружения с именем $SOLADDR2 (и назовите файл пары ключей my_solana_wallet2.json). Мы будем использовать эти адреса и файлы пар ключей позже, чтобы протестировать минт и трансфер токенов

Вот как это выглядит у меня:

$ echo $SOLADDR1 3sdsSwWWjjGA7HpPBQfGaXRE2HqmdKicMXHRapqLAu4L $ echo $SOLADDR2 ES2C1YPzNh5JjQu7DdxrveaPUHj9CnrRWSdrFo4ku5Zh

Примечание: многие команды в этом руководстве можно сократить, запустив solana config set — keypair ~/my_solana_wallet1.json, который устанавливает пару ключей клиента по умолчанию. Например, это позволяет не указывать флаг —owner для многих из следующих команд. Я использую более длинные версии команд, чтобы обьяснение было более понятным

Создание токена

Теперь, когда мы все настроили, мы можем использовать spl-token. Во-первых, давайте создадим новый тип токена

$ spl-token create-token --mint-authority ~/my_solana_wallet1.json Creating token 6ifRGEkJ6XmEjuqfTFNqAjjomUiDJTjRv4GHqBH6usWr

При создании токена нового типа создается новая учетная запись с данными, которую в дальнейшем мы будем называть «mint account». Каждый тип токена связан ровно с одним mint account. Адрес mint account — 6ifRGEkJ6XmEjuqfTFNqAjjomUiDJTjRv4GHqBH6usWr, но вместо этого мы будем использовать $TOKEN1, чтобы упростить чтение. Мы можем запросить информацию об учетной записи следующим образом (в конце много непонятных символов, но не переживайте, они нам пока не нужны):

$ solana account $TOKEN1 Public Key: Aqf1rBKNQYgX1mjE64STwV3miEwXEe2ioZzD7n4vkpXk Balance: 0.0014616 SOL Owner: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA Executable: false Rent Epoch: 207 Length: 82 (0x52) bytes 0000: 01 00 00 00 2a b0 1a 64 bb c5 f0 df bf 57 d5 61 . *..d. W.a 0010: 56 a8 b8 85 8f a8 0b 09 f1 f1 a2 dc 4d 51 b3 63 V. MQ.c 0020: 8f 72 bd e9 00 00 00 00 00 00 00 00 09 01 00 00 .r. 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . 0050: 00 00

Мы можем проверить владельца (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA) с помощью Solana Explorer . Владельцем является token program (учетная запись программы), которая отвечает за создание новых токенов, минт токенов и передачу токенов

Теперь давайте посмотрим на данные mint account, которые идут после «Length: 82 (0x52) bytes», как показано выше. Человеку трудно читать шестнадцатеричные данные, поэтому вместо этого мы можем использовать Solana Explorer :

Solana Explorer декодирует данные и отображает их в удобочитаемом формате. Вот что означает каждое из полей:

• Address — это адрес mint account
• Current Supply — количество сминченных токенов. Поскольку мы только что создали токен, он равен 0
• Mint Authority — открытый ключ из keypair, которому разрешено минтить токены (мы указали это с помощью флага —mint-authority. Если кто-то еще попытается минтить токены, то он этого не сможет)
• Decimals — определяет наименьший номинал токена. Для NFT он должен быть равен нулю. Девять по умолчанию

Прежде чем мы двинемся дальше, вот простая диаграмма, показывающая учетные записи, которые находятся в контакте, и то, как они связаны

• «Internal Solana relations» относятся к полю владельца, которое устанавливается для каждой учетной записи, например владелец, который отображается при запуске учетной записи solana $TOKEN1
• «User-space relations» — это когда отношение между двумя учетными записями закодировано в данных учетной записи, например поле «mint authority», которое мы видели выше

Владельцем Token Program является загрузчик BPF. Я не изображаю это здесь, потому что это не так важно и загромождает диаграмму

Создание Token Account

Прежде чем мы сможем создать токены, мы должны сначала создать учетную запись токена

$ spl-token create-account $TOKEN1 --owner $SOLADDR1 Creating account 9EYnoqiBQmJPR55db44cF4wkN1PD5D6vjxEz61r2Ujak

Отныне мы будем использовать $TOKENACCT1 вместо 9EYnoqiBQmJPR55db44cF4wkN1PD5D6vjxEz61r2Ujak, и мы будем называть эту учетную запись «token account». Вам может быть интересно, что такое токен-аккаунт? По сути, он просто хранит, сколько токенов есть у конкретного пользователя для определенного типа токена. Например, если у вас есть 10 токенов 1 и 5 токенов 2, то у вас будет две учетные записи токенов

Вот как выглядит токен-аккаунт:

$ solana account $TOKENACCT1 Public Key: 9EYnoqiBQmJPR55db44cF4wkN1PD5D6vjxEz61r2Ujak Balance: 0.00203928 SOL Owner: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA Executable: false Rent Epoch: 207

Учетная запись токена связана с тремя другими учетными записями. Его внутренним владельцем является token program, поскольку token program должна иметь возможность изменять учетную запись (например, добавлять к ней больше токенов). Затем в пользовательском пространстве его владельцем является $SOLADDR1, а его «mint» или связанный с ним mint account — $TOKEN1

Вот как теперь связаны все аккаунты:

Token Minting

Наконец-то мы можем сминтить токены! Эта часть проще — мы просто указываем mint account (которая определяет «type» токена для минта), количество токенов и учетную запись, которой их нужно передать

$ spl-token balance $TOKEN1 --owner $SOLADDR1 0 $ spl-token mint $TOKEN1 10 $TOKENACCT1 --mint-authority ~/my_solana_wallet1.json Minting 10 tokens Token: Aqf1rBKNQYgX1mjE64STwV3miEwXEe2ioZzD7n4vkpXk Recipient: 9EYnoqiBQmJPR55db44cF4wkN1PD5D6vjxEz61r2Ujak $ spl-token balance $TOKEN1 --owner $SOLADDR1 10

Помимо использования spl-token balance, вы также можете использовать spl-token accounts, чтобы просмотреть, сколько каждого токена принадлежит определенной учетной записи

$ spl-token accounts --owner $SOLADDR1 Token Balance ------------------------------------------------------------- Aqf1rBKNQYgX1mjE64STwV3miEwXEe2ioZzD7n4vkpXk 10

Что произойдет, если вы попытаетесь создать токены с другим значением параметра —mint-authority?

$ spl-token mint $TOKEN1 10 $TOKENACCT1 --mint-authority ~/my_solana_wallet2.json Minting 10 tokens Token: Aqf1rBKNQYgX1mjE64STwV3miEwXEe2ioZzD7n4vkpXk Recipient: 9EYnoqiBQmJPR55db44cF4wkN1PD5D6vjxEz61r2Ujak RPC response error -32002: Transaction simulation failed: Error processing Instruction 0: custom program error: 0x4 [5 log messages]

Ответ? Это не работает! Это связано с тем, что в поле «mint authority» token account’а указана другая учетная запись, и только этой учетной записи разрешено минтить новые токены

Token Transferring

Давайте попробуем перенести некоторые токены в $SOLADDR2 (которые должны были быть созданы в разделе « Подготовка »)

$ spl-token transfer $TOKEN1 1 $SOLADDR2 --owner ~/my_solana_wallet1.json Transfer 5 tokens Sender: 9EYnoqiBQmJPR55db44cF4wkN1PD5D6vjxEz61r2Ujak Recipient: ES2C1YPzNh5JjQu7DdxrveaPUHj9CnrRWSdrFo4ku5Zh Recipient associated token account: FFednTgQRKDbGYjXrXk8SWPfzSJW3Q8ApN5mGCpGdAtE Error: Recipient's associated token account does not exist. Add `--fund-recipient` to fund their account

Неудача! Сообщение об ошибке говорит, что нам не разрешено передавать токены, если у получателя нет token account

Есть два способа исправить это:

1. Создайтеtoken account для получателя, а затем перенесите токены.
2. Используйте флаг —fund-recipient. Это заставляет отправителя платить за создание token account получателя

Мы пойдем с подходом № 1

$ spl-token create-account $TOKEN1 --owner $SOLADDR2 Creating account FFednTgQRKDbGYjXrXk8SWPfzSJW3Q8ApN5mGCpGdAtE $ spl-token transfer $TOKEN1 1 $SOLADDR2 --owner ~/my_solana_wallet1.json Transfer 1 tokens Sender: 9EYnoqiBQmJPR55db44cF4wkN1PD5D6vjxEz61r2Ujak Recipient: ES2C1YPzNh5JjQu7DdxrveaPUHj9CnrRWSdrFo4ku5Zh Recipient associated token account: FFednTgQRKDbGYjXrXk8SWPfzSJW3Q8ApN5mGCpGdAtE $ spl-token balance $TOKEN1 --owner $SOLADDR2 1

Красиво, сработало! Давайте посмотрим на все учетные записи в этом действии

Wrapped SOL

Точно так же, как ETH можно обернуть токеном ERC20, чтобы сформировать wETH, так и SOL можно обернуть токеном SPL

$ spl-token wrap 1 ~/my_solana_wallet1.json Wrapping 1 SOL into DXWzvX3RtZbito65G8ZgqmEzJM6Z6Fqy7NHkbpEmCUZD

Конечно, вы можете обратно развернуть полученный токен SPL, чтобы вернуть свои SOL

$ spl-token unwrap DXWzvX3RtZbito65G8ZgqmEzJM6Z6Fqy7NHkbpEmCUZD ~/my_solana_wallet1.json Unwrapping DXWzvX3RtZbito65G8ZgqmEzJM6Z6Fqy7NHkbpEmCUZD Amount: 1 SOL Recipient: 3sdsSwWWjjGA7HpPBQfGaXRE2HqmdKicMXHRapqLAu4L

Такая упаковка SOL позволяет легко обменивать SOL на другие токены SPL

Подождите, а как там NFT?

Теперь, когда мы рассмотрели, как работают взаимозаменяемые токены, понять, что такое невзаимозаменяемые токены, должно быть легко. Я просто позволю вам прочитать доки , так как в любом случае я бы не стал много добавлять. Основными важными моментами являются:

• Используйте —decimals 0 при создании токена, так как он должен быть только один
• После минта одного токена отключите минты в будущем. Это гарантирует, что будет только один токен

На практике никто не создает NFT таким образом. Вместо этого большинство людей используют Candy Machine , инструмент для загрузки изображений и метаданных и создания NFT на их основе

Вот и все! К этому моменту вы должны понимать, как работают токены SPL и чем они отличаются от токенов ERC20

Заключение:

• Одна программа, называемая Token Program, может создавать новые токены, минтить новые токены и передавать токены между учетными записями
• В отличие от токенов ERC20, где каждый новый токен связан с новым смарт-контрактом ERC20, в солане существует только одна Token Program. Однако каждый новый тип токена связан с новым mint account
• Если пользователь хочет владеть некоторыми токенами определенного типа, ему необходимо иметь учетную запись токена. Другими словами, если кто-то владеет пятью разными типами токенов, у него будет пять разных учетных записей токенов
• Вы можете обернуть SOL в токен SPL, что позволяет легко обменять его на другие токены SPL
• Не взаимозаменяемый токен SPL — это токен с нулевым Decimals, который создают одну копию и отключил минт в будущем

Create token account что это

Изменить язык

Полная версия

© Valve Corporation. Все права защищены. Все торговые марки являются собственностью соответствующих владельцев в США и других странах. Политика конфиденциальности | Правовая информация | Соглашение подписчика Steam | Возврат средств

Установить Steam

Все обсуждения > Форумы Steam > Русскоязычный Форум > Подробности темы

Тема закрыта

7 сен. 2016 в 7:50

Создание токена для сервера

Собственно проблема ,перешел я по ссылке http://steamcommunity.com/dev/managegameservers , ввел id игры, примечание и нажал создать. После чего на всю страницу «Failed to create account: 24 (This account is banned from creating game server login tokens)». При этом, аккаунту чуть больше двух недель, 5$ на балансе есть, cs go куплена. До этого игровых серверов у меня не было, т.е. получить бан создания токенов я не мог. Что это вообще такое? Valve в край обнаглели, т.е. я заплатил за хостинг сервера, настроил его, чтобы люди играли, по факту никто не может зайти. Что делать, как быть? Или просто забить на это все? Честно сказать крик души.

Отредактировано unnamed; 7 сен. 2016 в 7:50

Create Token

Token20 это наш стандарт для реализации токена на блокчейне IOST. Он включает в себя несколько практических функций помимо перевода токенов, такие как замораживание токенов, уничтожение токенов и может быть тщательно настроен.

iost также реализован в соответствии со стандартом Token20 на основе встроенного системного контракта token.iost . Интерфейсы token.iost описываются следующим образом:

// create tokenSymbol create(tokenSymbol, issuer, totalSupply, configJson); // string, string, number, json issue(tokenSymbol, to, amountStr); // string, string, string transfer(tokenSymbol, from, to, amountStr, memo); // string, string, string, string, string transferFreeze(tokenSymbol, from, to, amountStr, unfreezeTime, memo); // string, string, string, string, number, string destroy(tokenSymbol, from, amountStr); // string, string, string // query interfaces balanceOf(tokenSymbol, from); // string, string supply(tokenSymbol); // string totalSupply(tokenSymbol); // string 

create(tokenSymbol, issuer, totalSupply, configJson)

Authority required: issuer

TokenSymbol это уникальный идентификатор конкретного токена, то есть вы не можете создать токен в контракте token.iost с ранее использованным tokenSymbol. Это строка длинной от 2 до 16, состоящая только из символов a-z , 0-9 и _ .

Issuer является эмитентом токена, только эмитент имеет разрешение на выдачу токенов на произвольный аккаунт. Обычно эмитент токена это аккаунт, но также может быть и контракт. Когда issuer(эмитентом) является ID контракта, это означает, что только у этого контракта есть разрешение на вызов метода issue для выдачи(выпуска) токенов другим. Допустим, эмитентом токена mytoken является контракт Contractabc , тогда Contractabc может вызвать issue для выпуска в обращение mytoken , Contractabc также может вызвать функцию в контракте Contractdef , и таким образом Contractdef будет иметь разрешение на выпуск в обращение mytoken . То есть, разрешение контракта может быть передано в вызываемый контракт, вам нужно использовать системную функцию blockchain.callWithAuthority вместо blockchain.call при вызове другого контракта для передачи разрешения.

TotalSupply это число типа int64, эмитент не может выпустить в обращение больше токенов, чем totalSupply.

ConfigJson это формат json, содержащий конфигурации для токена. Вот все поддерживаемые свойства конфигурации:

issue(tokenSymbol, acc, amountStr)

Authority required: issuer of tokenSymbol

Выдача tokenSymbol для аккаунта acc , amountStr это строка содержащая сумму выпуска, сумма должна быть положительным десятичным числом с фиксированной запятой, такой как «100», «100.999»

transfer(tokenSymbol, accFrom, accTo, amountStr, memo)

Authority required: accFrom

Перевод токенов tokenSymbol с аккаунта accFrom на аккаунт accTo с amountStr и memo, сумма должна быть положительным десятичным числом с фиксированной запятой, а memo — это дополнительное строковое сообщение этой операции перевода токенов длиной не более 512 байт.

transferFreeze(tokenSymbol, accFrom, accTo, amountStr, unfreezeTime, memo)

Authority required: accFrom

Перевод токенов tokenSymbol с аккаунта accFrom на аккаунт accTo с amountStr и memo, и заморозка этой части токенов до unfreezeTime (времени разморозки). unfreezeTime это наносекунды времени unix по истечению которых, токены будут разморожены.

destroy(tokenSymbol, accFrom, amountStr)

Authority required: accFrom

Уничтожение amountStr количества токенов в аккаунте accFrom . После уничтожения, запас токенов на этом аккаунте уменьшиться, что означает, вы можете выпустить больше токенов при наличии totalSupply путем уничтожения некоторого количества токенов.

Authority required: null

Запрос баланса аккаунта (количества определенного токена — tokenSymbol, которым владеет данный аккаунт — acc).

Authority required: null

Запрос запаса определенного токена.

Authority required: null

Запрос общего объема поставки определенного токена.

Создать Token20 в блокчейне iost можно необыкновенно просто, вам достаточно только вызвать контракт token.iost , без реализации интерфейсов Token20 и развертывания смарт-контракта самостоятельно.

Ниже приведен пошаговый пример того, как создать токен с помощью bank аккаунта и переводить токены между аккаунтами, вначале вам нужно создать аккаунты bank , user0 , user1 .

iwallet call token.iost create '["mytoken", "bank", 21000000000, ]' --account bank iwallet call token.iost issue '["mytoken", "bank", "1000"]' --account bank iwallet call token.iost issue '["mytoken", "user0", "100.00000001"]' --account bank iwallet call token.iost transfer '["mytoken", "user0", "user1", "10", "user0 pay coffee"]' --account user0 iwallet call token.iost transferFreeze '["mytoken", "user1", "user0", "0.1", 1544880864601648640, "voucher"]' --account user1 iwallet call token.iost destroy '["mytoken", "bank", "1000"]' --account bank 

Токенизация карт в 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 и срок действия) и сможет самостоятельно инициировать оплату за конкретную услугу.

Нужно понимать, что такое действие подразумевает, что магазин должен где-то сохранить данные карты. Тут обычно два варианта:

1. сохранить их на собственных серверах, если они сертифицированы на соответствие стандарту PCI DSS, что могут себе позволить далеко не все интернет-магазины,
2. доверить их хранение своему платежному решению, например Яндекс.Кассе, которая сертифицирована PCI DSS по высшему уровню безопасности.

Давайте обо всем по порядку. При токенизации мы обмениваем данные банковской карты на некий токен, но что это такое? Токен предоставляется платежной системой карты — 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 сразу же узнает от платежной системы карты.

Подведем некоторый итог. Что токенизация дает держателю карты?

1. Сохранность данных реальной банковской карты. При платеже используется токен, а сами данные карты не передаются, поэтому их никак не сможет перехватить потенциальный злоумышленник. А перехватывать данные токена нет никакого смысла, потому что токен превращается в тыкву при попытке заплатить в любом другом магазине.
2. При перевыпуске банковской карты токен, выпущенный для интернет-магазина, продолжает действовать, и владельцу карты нет необходимости привязывать новую карту к нужным ему сервисам.
3. Возможность управления токеном. Токенами можно будет управлять, не затрагивая саму банковскую карту. Банки-эмитенты смогут реализовать в своих интерфейсах специальные инструменты для гибкого управления привязками в интернет-магазинах (создание токена в новом магазине, просмотр имеющихся токенов, удаление неактуальных).

1. То, что хорошо для покупателя, хорошо и для магазина, поэтому использование токенизированных карт может повысить лояльность клиентов.
2. Возможность перевыпуска банковской карты с сохранением токена важна для магазинов, использующих сценарии платежей по подписке. Магазину больше не нужно будет отключать подписку, если пользователь забыл обновить данные карты, и не придется всячески напоминать ему об этом. Стоит отметить, что у держателя карты все равно остается полный контроль и в любой момент он сможет отключить саму подписку.
3. Повышение конверсии платежей. Мы исследовали, как использование токенов влияет на конверсию платежей в сравнении с использованием сохраненных данных карт. Выяснилось, что доля успешных платежей без использования токенов была 88,53%, а после включения токенизации выросла до 97,89%*. Получившаяся разница объясняется тем, что если банк-эмитент уже одобрил создание токена, то в дальнейшем платежи этим токеном будут вызывать большее доверие у антифрод-системы банка. На конверсию влияет также возможность оплаты перевыпущенными картами. Если человек не обновит данные карты, которую он привязал к интернет-магазину, то оплата не пройдет, а с токеном такой проблемы не возникнет.

*Мы сравнивали платежи за этот апрель в крупном онлайн-кинотеатре (MCC 4899) — привязанными картами без 3DS, без учета неуспешных платежей из-за нехватки денег на карте.

Технические аспекты

Для любителей копнуть чуть глубже, расскажу о технологии токенизации карт и ее запуске в Яндекс.Кассе — как все это выглядит изнутри нашего платежного решения.

Интеграция с платежными системами

Чтобы получить техническую возможность токенизировать карты и проводить платежи токенами, необходимо интегрироваться с Visa и Mastercard, пройти тесты, сертификацию и получить их одобрение на запуск в production. Поначалу это звучало устрашающе. Да и не только поначалу, если честно, по крайней мере, для меня. Но устрашала скорее сертификация, а по технике все было предельно ясно.

Интеграция подразумевает реализацию следующего API (условно) между платежной системой и нами в качестве Token Requestor:

1. Создание токена.
   Мы передаем платежной системе данные банковской карты и идентификатор интернет-магазина, для которого создается токен. Дополнительно мы проводим скоринг для оценки рисков (risk scoring) токенизации конкретной карты для конкретного магазина и также передаем результат скоринга в запросе. В ответ мы получаем решение, одобрена токенизация карты ее эмитентом или нет, и если одобрена, получаем уникальный идентификатор созданного токена. После этого токен активен, можно проводить платежи с его использованием.
2. Получение одноразовой криптограммы для платежа токеном.
   Мало обладать токеном, чтобы им платить: для каждого платежа нужно еще получить одобрение от платежной системы — криптограмма, помните? Так вот, чтобы получить эту криптограмму, мы передаем в запросе платежной системе идентификатор токена и некоторые детали платежа. Если токен активен, мы в ответе получаем эту одноразовую криптограмму, которую затем надо будет передать эквайеру при проведении платежа по карте.
3. Уведомление от платежной системы об изменении состояния токена.
   Это может быть приостановка/возобновление действия токена по инициативе держателя карты, удаление этого токена навсегда, а также обновление данных банковской карты, для которой был выпущен этот токен, в случае ее перевыпуска. Нам нужно уметь обрабатывать определенные запросы от платежных систем и обновлять у себя информацию о токене, проще простого.

Токенизация в Яндекс.Кассе

Яндекс.Касса представляет из себя большую систему по приему платежей для интернет-магазинов. Она состоит из многих десятков различных сервисов: 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 — это новый этап развития приема платежей, повышающий удобство для всех участников процесса оплаты. Мы ожидаем, что в ближайшее время технологию поддержат многие российские банки и провайдеры — и она станет новым стандартом платежного рынка.

Конечно, рассказ получился скорее обзорным, но я надеюсь, что каждый читатель найдет в нем что-то полезное для себя — повысит свой уровень финансовой грамотности, узнает о новинках в финтехе или, может, найдет идею для развития своего бизнеса.

Я всё, будьте здоровы и не болейте!

• токенизация
• e-commerce
• платёжные системы

• Блог компании ЮMoney
• Платежные системы
• Разработка под e-commerce
• Финансы в IT
• IT-компании