криптограмма платежных данных не корректна что значит

Близкие контакты. Разбираемся, как работают системы безопасности кредитных карт

Содержание статьи

Номер карты

Оп­лата по номеру кар­ты исто­ричес­ки — самая стар­шая. Рань­ше на кар­тах не было ничего, кро­ме это­го номера. Номер был «эмбосси­рован» — выдав­лен на кар­те. При опла­те кар­та «про­каты­валась» на спе­циаль­ном устрой­стве, что поз­воляло про­дав­цу быс­тро внес­ти номер в древ­нюю замену базы дан­ных, то есть отпе­чатать на лис­те бумаги.

В кон­це рабоче­го дня или недели эти дан­ные собира­лись и переда­вались в банк‑эквай­ер. Далее банк отправ­лял зап­росы на спи­сание этих денег у вла­дель­цев карт через бан­ки‑эми­тен­ты. Это было так дав­но, что нем­ного людей зна­ют, отку­да появил­ся трех­знач­ный код верифи­кации пла­тежей, записан­ный на обратной сто­роне кар­ты, так называ­емый CVV2/CVC2. До нас дош­ла информа­ция, что этот код исполь­зовал­ся ско­рее как кон­троль­ная сум­ма, нуж­ная, что­бы вла­делец кар­ты не ошиб­ся и кор­рек­тно ввел всю информа­цию при опла­те. Похоже на прав­ду, если учесть, нас­коль­ко корот­кий этот код.

Сей­час физичес­кая кар­та может и вов­се не учас­тво­вать в опла­те. Это называ­ется card not present и чаще все­го исполь­зует­ся при опла­те в интерне­те. Если номер кар­ты вво­дит­ся при опла­те в пла­теж­ном тер­минале, а это харак­терно для оте­лей, биз­несов, ведущих дела по телефо­ну, а так­же для боль­шинс­тва тер­миналов в США, такой под­тип пла­тежей называ­ется PAN Key Entry.

Мно­гие до сих пор счи­тают, что поле Cardholder name с лицевой сто­роны кар­ты нуж­но вво­дить кор­рек­тно и что оно про­веря­ется. Это не так — ни один банк не про­веря­ет это поле.

Магнитная полоса

Опе­рации с маг­нитной полосой — один из самых прос­тых методов. Он ассо­циирует­ся у людей с опре­делен­ными типами мошен­ничес­тва. Ским­минг в бан­коматах, двой­ные сня­тия в рес­торанах — все это воз­можно бла­года­ря недос­таткам маг­нитной полосы. Маг­нитную полосу лег­ко ско­пиро­вать — для это­го необ­ходим толь­ко спе­циаль­ный ридер/энко­дер маг­нитной полосы. Даль­ше кло­ниро­ван­ной маг­нитной полосы дос­таточ­но для того, что­бы рас­пла­чивать­ся в боль­шинс­тве супер­марке­тов мира. Для верифи­кации вла­дель­ца кар­ты пред­полага­лось исполь­зовать под­пись на чеке, которую кас­сир дол­жен све­рить с под­писью на обратной сто­роне кар­ты.

На кар­тинке выше ты видишь при­мер записан­ной на кар­ту информа­ции. Чер­ные полос­ки — это еди­ницы, белые — нули. Сущес­тву­ют open source решения для декоди­рова­ния этих дан­ных — к при­меру, magstripe.

На самом деле по изоб­ражению вид­но, что на кар­те не одна, а целых две маг­нитные полосы раз­ной плот­ности (Track1 и Track2). Какие дан­ные содер­жатся на маг­нитной полосе?

Чип/EMV

На сме­ну маг­нитной полосе в девянос­тых приш­ли смарт‑кар­ты, для популя­риза­ции которых соз­дали кон­сорци­ум EMV (Europay, MasterCard, Visa). Прод­вига­емая кон­сорци­умом идея была прос­та: исполь­зуя осо­бен­ности смарт‑карт, сим­метрич­ную крип­тогра­фию и крип­тогра­фию с откры­тым клю­чом, решить все проб­лемы, свя­зан­ные с маг­нитной полосой. Опе­рации со смарт‑кар­той обес­печива­ют три сте­пени защиты:

Да­вай прой­дем­ся по исполь­зуемым методам.

Аутентификация карты

Для аутен­тифика­ции кар­ты исполь­зует­ся крип­тогра­фия с откры­тым клю­чом по про­токо­лу RSA. Текущие минималь­ные тре­бова­ния по дли­не клю­ча — 1024 бита. Огра­ничен­ное чис­ло цен­тров сер­тифика­ции выпус­кают клю­чи для бан­ков, а бан­ки их уже при­вязы­вают к самим кар­там. При­ват­ный ключ хра­нит­ся на самой смарт‑кар­те в области, недос­тупной для чте­ния. Кор­невые сер­тифика­ты уста­нав­лива­ются на тер­минал при его нас­трой­ке. Во вре­мя тран­закции кар­та пре­дос­тавля­ет пуб­личные клю­чи пла­теж­ному тер­миналу вмес­те с информа­цией, зашиф­рован­ной при­ват­ным клю­чом в режиме циф­ровой под­писи. Если пуб­личный ключ доверен­ный и информа­ция, передан­ная кар­той, успешно рас­шифро­выва­ется этим клю­чом, то тер­минал счи­тает кар­ту аутен­тичной, выпущен­ной имен­но тем бан­ком, который под­писал при­ват­ный ключ, выдан­ный цен­тром сер­тифика­ции.

Все­го сущес­тву­ет три режима аутен­тифика­ции кар­ты:

В пер­вом методе исполь­зовалось толь­ко одно ста­тичес­кое поле, хра­няще­еся на кар­те. Оно под­писыва­лось при­ват­ным клю­чом и про­веря­лось тер­миналом. Это было EMV-поле AIP (application interchange profile). Но кон­сорци­ум EMV быс­тро понял, что для популяр­ных в то вре­мя офлай­новых тер­миналов (они не выходи­ли в онлайн для свер­ки крип­тограм­мы) это­го было явно недос­таточ­но — любой мог кло­ниро­вать пуб­личный ключ и под­писан­ную ста­тичес­кую стро­ку, что­бы соз­дать под­делку.

Од­нако в 2009 году иссле­дова­тели из Кем­бридж­ско­го уни­вер­ситета пред­ста­вили работу, опи­сыва­ющую так называ­емую ата­ку PIN OK (PDF). Спе­циаль­ное устрой­ство, рас­полага­ющееся меж­ду кар­той и тер­миналом, совер­шало ата­ку «человек посере­дине» и под­меняло одно из полей, которые отправ­ляла кар­та. Эту под­мену нель­зя было обна­ружить на тер­минале с помощью опи­сан­ных выше методов. Для защиты от таких атак кон­сорци­ум EMV еще до наход­ки иссле­дова­телей пре­дус­мотрел новый механизм защиты — схе­му CDA. Во вре­мя нее тер­минал может про­верить целос­тность боль­шинс­тва полей, которые переда­ет кар­та и которые учас­тву­ют в фазе под наз­вани­ем «риск‑менед­жмент».

Оф­лай­новая аутен­тифика­ция соз­давалась в пер­вую оче­редь для защиты офлай­новых пла­тежей, ког­да тер­минал не под­клю­чен к интерне­ту пос­тоян­но. Имен­но поэто­му, если резуль­тат работы режимов DDA или CDA не закан­чива­ется успе­хом, в сов­ремен­ных тер­миналах, под­клю­чен­ных к интерне­ту, это не при­ведет к отка­зу тран­закции в 99% слу­чаев, так как банк‑эми­тент авто­ризу­ет ее с помощью крип­тограм­мы, как опи­сано ниже. Одна­ко некото­рые пла­теж­ные сис­темы рекомен­дуют обра­щать вни­мание на пос­тоян­ные неус­пешные аутен­тифика­ции, осо­бен­но если они про­исхо­дят в раз­ных тер­миналах.

Верификация плательщика

Есть два основных спо­соба верифи­кация пла­тель­щика: ПИН‑код и под­пись. На самом деле их нем­ного боль­ше — ПИН‑код может про­верять­ся в офлай­не (на самой кар­те) и онлайн. Он может быть зашиф­рован (с помощью сим­метрич­ного клю­ча 3DES) или переда­вать­ся в откры­том виде.

Еще воз­можен спо­соб верифи­кации NoCVM — то есть отсутс­твие верифи­кации. Хороший при­мер таких опе­раций — те, которые не пре­выша­ют лимиты 3000 руб­лей и не тре­буют вво­да ПИН‑кода. Их иног­да называ­ют Tap & Go.

Дру­гой спо­соб, который в зависи­мос­ти от пла­теж­ной сис­темы называ­ется CDCVM или On-Device CVM, дела­ет воз­можной верифи­кацию на мобиль­ном телефо­не вла­дель­ца кар­ты. Как ты уже догадал­ся, он исполь­зует­ся в Google Pay и Apple Pay.

Авторизация транзакции

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

По­лучен­ная стро­ка шиф­рует­ся с помощью записан­ного на кар­те сек­ретно­го клю­ча 3DES в режиме циф­ровой под­писи и переда­ется бан­ку вмес­те со всей под­писан­ной информа­цией. Банк‑эми­тент исполь­зует аппа­рат­ный модуль безопас­ности (hardware security module, HSM), на котором в защищен­ной от чте­ния области памяти содер­жится копия сим­метрич­ного клю­ча кар­ты.

HSM так­же соз­дает циф­ровую под­пись по дан­ным от пла­теж­ного тер­минала. Если он получит такую же крип­тограм­му, то тран­закция будет счи­тать­ся авто­ризо­ван­ной. Это зна­чит, что ник­то не под­менил дан­ные опе­рации во вре­мя их переда­чи от кар­ты до бан­ка эми­тен­та. На этом же эта­пе рас­шифро­выва­ется и све­ряет­ся ПИН‑код кар­ты, в слу­чае если исполь­зует­ся онлайн‑свер­ка ПИН.

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

Бесконтактные платежи

Бес­контак­тные пла­тежи ста­ли набирать популяр­ность с середи­ны 2010-х годов. Бан­ки и пла­теж­ные сис­темы прод­вига­ют их как быс­трый и удоб­ный спо­соб опла­ты. Оно и понят­но — чем боль­ше народ пла­тит кар­тами, тем боль­ше мож­но зарабо­тать на комис­сиях! С раз­вити­ем тех­нологий нуж­но раз­вивать и безопас­ность, но это далеко не всег­да так. И бес­контак­тные пла­тежи как раз при­мер из неудач­ных.

Ког­да соз­давались бес­контак­тные пла­тежи, кар­ты с чипом в США еще не были осо­бен­но рас­простра­нены, поэто­му Visa и MasterCard пре­дус­мотре­ли про­межу­точ­ный шаг, ког­да новыми бес­контак­тны­ми кар­тами мож­но пла­тить на ста­рых несов­ремен­ных пла­теж­ных тер­миналах, которые не под­держи­вают сов­ремен­ную крип­тогра­фию. Этот шаг называ­ется Legacy modes — режимы, сте­пень безопас­ности которых зна­читель­но ниже, чем у пла­тежей EMV и сов­ремен­ных форм бес­контак­тных пла­тежей.

Legacy modes по сте­пени защиты боль­ше напоми­нают опе­рации с маг­нитной полосой, толь­ко про­водят­ся через NFC. Нес­мотря на то что эти режимы пред­полага­лось исполь­зовать лишь в нес­коль­ких стра­нах, а через какое‑то вре­мя и вов­се отме­нить, мы в 2020 году встре­чаем их пов­семес­тно — в том чис­ле в Рос­сии, где даже маг­нитная полоса зап­рещена.

От­дель­ная проб­лема — это то, как пла­теж­ные сис­темы подош­ли к реали­зации бес­контак­тных пла­тежей. Вмес­то того что­бы при­думать что‑то новое, в ком­пани­ях Visa и MasterCard решили и здесь исполь­зовать EMV, но каж­дая сде­лала это по‑сво­ему, так что де‑юре они перес­тали быть частью стан­дарта EMV.

Что из это­го сле­дует:

В ком­пании Visa были недоволь­ны слиш­ком дол­гим вре­менем про­веде­ния пла­тежа. Ког­да для это­го исполь­зовал­ся чип, проб­лем не было — кар­та встав­лялась в тер­минал. Одна­ко в Visa пос­читали, что дер­жать кар­ту у тер­минала, ожи­дая, пока прой­дут все шаги EMV, — это не очень‑то удоб­но. Этап, который вызывал основную задер­жку, — это офлай­новая аутен­тифика­ция кар­ты.

Од­новре­мен­но с этим в MasterCard при­няли диамет­раль­но про­тиво­полож­ное решение — приз­нали, что офлай­новая аутен­тифика­ция важ­на и для тех карт, которые под­держи­вают наибо­лее безопас­ную схе­му аутен­тифика­ции CDA, и сде­лали ее обя­затель­ной. В спе­цифи­кации EMV, если вза­имо­дей­ствие по схе­ме CDA не закан­чива­ется успешно, тер­минал все еще может отпра­вить крип­тограм­му для онлай­новой авто­риза­ции. Тог­да как для бес­контак­тных пла­тежей MasterCard неудач­ная аутен­тифика­ция CDA всег­да ведет к отме­не пла­тежа. Раз­ница во вре­мени опе­раций нез­начитель­ная, одна­ко это оста­ется реша­ющим фак­тором для Visa.

Выводы

Те­перь, ког­да ты зна­ешь, как работа­ют элек­трон­ные и в том чис­ле бес­контак­тные пла­тежи, ты готов к раз­говору об уяз­вимос­тях в этих схе­мах. Это мы обсу­дим в сле­дующих стать­ях, а заод­но раз­берем самые гром­кие кей­сы мошен­ничес­тва.

Источник

Криптография платежных данных для продавцов

Прочитав это руководство, вы узнаете, как создать открытый ключ для запроса токена способа оплаты, подписанного и зашифрованного Google, а также как подтвердить и расшифровать этот токен.

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

В библиотеке Tink можно найти образец кода, исполняющего пункты 1–6.

Примечание. Мы настоятельно рекомендуем использовать код из библиотеки Tink для выполнения пунктов 1–6. Описание последовательности действий приведено для справки. Если вам нужен код для расшифровки токена, ознакомьтесь с разделом Как использовать библиотеку Tink для управления зашифрованными ответами.

Структура токена способа оплаты

Пример

Ниже показан пример токена способа оплаты в формате JSON.

Промежуточный ключ подписи

intermediateSigningKey представляет собой закодированный по стандарту UTF-8 сериализованный объект JSON с указанными ниже значениями.

Подписанный ключ

signedKey представляет собой закодированный по стандарту UTF-8 сериализованный объект JSON с указанными ниже значениями.

Подписанное сообщение

signedMessage представляет собой закодированный по стандарту UTF-8 сериализованный объект JSON с указанными ниже значениями.

Зашифрованное сообщение

Расшифрованное значение строки encryptedMessage представляет собой закодированный по стандарту UTF-8 сериализованный объект JSON. Объект JSON состоит из двух уровней. Внешний уровень содержит метаданные и поля, обеспечивающие безопасность. Внутренний уровень – это ещё один объект JSON, включающий фактические платежные данные.

Более подробную информацию о сообщении encryptedMessage можно найти в приведенных ниже таблицах и примерах объектов JSON.

Уникальный идентификатор продавца, позволяющий обработчику данных проверить, что сообщение предназначено запросившему его продавцу. Создается обработчиком; продавец передает этот идентификатор Google в объекте PaymentMethodTokenizationSpecification для приложения Android или сайта.

Карта

Платежные данные способа оплаты CARD имеют указанные ниже свойства.

PAN_ONLY

CRYPTOGRAM_3DS

В случае аутентификации способа оплаты CARD с помощью криптограммы 3-D Secure ( CRYPTOGRAM_3DS authMethod ) используются дополнительные поля:

Подтверждение подписи

Для подтверждения подписей с промежуточным ключом и подписями сообщений нужно следующее:

Алгоритм подписи

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). В схеме шифрования используются указанные ниже параметры.

ECIES-KEM в соответствии со стандартом ISO 18033-2.

Алгоритм HMAC и SHA-256 ( HKDFwithSHA256 ).

DEM2 в соответствии со стандартом ISO 18033-2.

Алгоритмы шифрования: AES-256-CTR с нулевым IV и без заполнения.

Формат открытого ключа шифрования

Этот формат подробно описан в документе «Криптография с открытым ключом для индустрии финансовых услуг: алгоритм цифровой подписи на эллиптических кривых (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.

Источник

Что делать, если не удается оплатить банковской картой в Интернет-магазине

Почему важно знать причины неоплаты?

Оплата банковской картой через интернет — эту услугу сейчас предлагает практически любой интернет магазин. Вы можете например купить билет на поезд, оплатив банковской картой, сделать покупку на 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 дней. Помните — никто деньги вам сразу не вернет. Будьте готовы ждать.

Источник