Подтверждение операций с помощью myDSS | КриптоПро DSS

Транзакция в магазине: что происходит на самом деле?

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

Банковская транзакция выполняется в несколько этапов:

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

Свидетельством удачного списания средств с карты и оплаты покупки становится чек, на котором содержится вся важная информация: сумма покупки, дата и время, номер транзакции.

Что такое транзакция (transaction)?

Транзакция — это некий набор связанных операций с базой данных.

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

Например, давайте представим такую ситуацию: у каждого человека есть карта, с помощью которой он может совершать определенные действия, будь то онлайн-покупка, перевод денежных средств с карты на карту, оплата счетов и т.д. Какие операции происходят в базе данных при совершении перевода денежных средств с одного лицевого счета на другой? В этой ситуации необходимо выполнить два запроса к базе данных:

1. С первого лицевого счета происходит списание N-ой суммы денежных средств.

2. На второй лицевой счет идет зачисление этой же суммы.

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

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

Описание процесса проведения и подтверждения платежа

1. Клиент выбирает услугу;

2. Витрина Банка проверяет наличие услуги у себя в Базе данных;

   2.1 Если услуга найдена, формирует запрос в Банк на холдирование денежных средств в Процессинге. Далее формирует запрос на возможность совершение платежа check:

   2.2 Если услуга не найдена, завершает процесс ошибкой, клиент уходит;

3. Витрина инициирует check;

4. В Банк поступает запрос check. Далее Банк маршрутизирует запрос Мерчанту;

5. Мерчант принимает запрос, выполняет проверку совершения платежа;

   5.1 Если зачисление возможно, отправляет успех, клиенту отображается пречек. Система Банка ожидает подтверждение платежа;

   5.2 Если зачисление невозможно, Банк отправляет код ошибки, витрина завершает процесс, проведение невозможно, клиент уходит;

6. Клиент знакомится с пречеком, нажимает кнопку «подтвердить платеж». Витрина инициирует pay;

7. Банк присваивает идентификатор транзакции и сразу отправляет ответ на витрину;

8. Зачисление денежных средств у Мерчанта уже выполняется в офлайне. Банк инициирует pay и, если зачисление возможно, Мерчант присваивает свой идентификатор транзакции и отправляет в Банк успешный ответ. А если зачисление невозможно – спросите Вы? Тогда Мерчант отправляет ответ в Банк с кодом ошибки, и Банк выполняет возврат денежных средств клиенту в автоматическом режиме в тот же день.

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

«транзакция отклонена» – что это означает?

Нередко при попытке оплатить транзакцией платежная система выдает одну из следующих форм отказа: платеж не совершен, транзакция отклонена, запрещена.

Причинами такого отказа могут быть следующие ситуации:

• Нахватает денег на балансе для денежного перевода в указанном объеме. Это самая распространенная причина, которая устраняется пополнением баланса любым доступным способом: перевод с другого счета, внесение наличных через терминал, кредит.
• Карта новая и еще не активированная. Для активации ее необходимо вставить в банкомат и ввести ПИН-код.
• Владельцы некоторых карт, например, «Мир» не могут осуществлять транзакции заграницу и оплачивать товары на зарубежных торговых онлайн-площадках.
• Ошибка при заполнении реквизитов отправителя (неверный номер счета, СVС, срок действия) или получателя (ошибка при вводе номера карты).
• Технические причины: неисправность терминала, потеря соединения с сервером, проблемы с банковским программным обеспечением.

Если на счету точно есть средства, карта не просрочена и проблем с вводом ПИН-кода не было, то за разъяснением причин приостановки транзакций следует позвонить в банк на горячую линию. Также можно лично обратиться в отделение банка.

При сложностях оплаты в интернет-магазинах, причины могут скрываться в работе самого ресурса. Это могут быть технические работы на сайте или сбои в работе платежного сервиса. Попробуйте оплатить заказ через пару часов или обратиться по этому вопросу к консультантам магазина.

В любом случае, если оплатить покупку или перевести деньги не удается, не стоит паниковать. Приостановка и отклонение транзакции – это действенный инструмент для защиты средств клиентов банка, и применяется он для обеспечения финансовой безопасности владельца счета.

Что такое транзакция по банковской карте

Транзакция – это любая операция со счетом в банке, которая приводит как к увеличению, так и к уменьшению баланса.

Оплата покупки при помощи карты – транзакция, что сопровождается уменьшением счета. Получение пенсии на карту – тоже транзакция, которая увеличила баланс. А вот проверка баланса – таковой не является, однако, если банк берет за эту услугу даже незначительную сумму, то оплата проверки является транзакцией.

Понятие произошло от английского transaction обозначающего «сделку». В деловой сфере правильным считается написание и «транзакция» и «трансакция». Слово «транзакция» вне профессиональной банковской сферы обозначает сделку, платеж, соглашение, договор. Также оно используется в программировании.

По банковскому счету выполняются два типа финансовых транзакций:

Что значит «транзакции по вашей карте приостановлены»?

Такое сообщение получает владелец карты, которая временно заблокирована. Причины блокировки могут быть разнообразны:

• Срок действия карты истек.
• Счет временно заблокирован из-за многократного неправильного ввода ПИН-кода.
• Карта заблокирована банком из-за угрозы мошенничества.
• Карта заблокирована по заявке налоговой инспекции.
• Счет заблокирован по решению суда.

Также могут блокироваться и отдельные транзакции. Например, для реализации крупного транзакционного перевода банку потребуется дополнительное согласие плательщика на проведение. Или же получатель подозревается в мошенничестве либо незаконной деятельности.

Льготникам начали оформлять электронные сертификаты

Что такое подтверждение транзакции?

Подтверждения транзакции Bitcoin — это количество блоков, добавленных в блокчейн, которые сеть Bitcoin приняла после выполнения определенной транзакции. Чем больше блоков добавлено — тем больше подтверждений, а значит тем более безопасна транзакция.

Atomicity или атомарность (a)

Вернемся к предыдущему примеру с переводом денежных средств между двумя лицевыми счетами. Мы установили, что эти 2 операции, которые взаимодействуют с базой данных, являются операциями транзакции. А какие проблемы могут возникнуть, если мы просто выполним эти операции последовательно, отправив два запроса к БД?

1. Первый запрос выполнится успешно. С первого лицевого счета будет списана N-ая сумма денежных средств.

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

В этой ситуации речь идет о проблеме потери данных. В целях снижения этого риска транзакции обладают таким свойством, как атомарность (atomicity), неделимость: либо будут выполнены все действия транзакции, либо никакие.

Check – проведение платежа

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

Очень часто на этом шаге закладывают минимальные требования к времени отклика ответа на запрос от Мерчанта, т.к. клиент не будет ждать, пока Витрина Банка, сам Банк и Мерчант проверят доступность услуги.

Отличительной особенностью этого шага является так же расчет комиссии. Комиссии бывают:

В нашем примере на check рассчитывается только комиссия с клиента, нижняя и смешанная комиссии рассчитываются в отдельно. Об этом с следующих статьях.

Структура запроса check/XML, шлюз контура Витрина – Банк:

где

Когда клиент на витрине нажимает иконку с оплачиваемой услугой, первое, что выполняет система, это проверяет доступность услуги и если она доступна, то дальше обращается в процессинг для проверки источника списания (поля Type и type_number)

Далее если денежные средства есть, проверяет возможность зачисления денежных средств на номер телефона (phone_number в значении 86248541234)

Подождите, секундочку – спросите вы. Что-то здесь не сходится. Как по маскированному PAN в поле type_number можно проверить наличие денежных средств на карте клиента?

Все верно, внимательные читатели обратили внимание, что по маскированному PAN это сделать нельзя.

Авторизация в процессинге выполняется перед check и это отдельный метод и отдельный процесс, посмотрите выше на диаграмму процесса. На проведении платежа мы уже работаем с маскированным PAN, т.к. на этом шаге мы проверяем возможность проведения платежа, а не наличие денежных средств на карте клиента.

Далее мы формируем запрос Мерчанту.

Мы не указываем ни PAN, ни тип источника списания, нас интересует только возможность совершения платежа для конкретного сервиса.

Структура запроса check/XML, шлюз контура Банк – Мерчант:

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

Структура ответа check/XML, шлюз контура Мерчант – Банк:

Такой ответ будет означать, что Мерчант готов к подтверждению платежа клиентом.

В ответе мы у нас будет временный id транзакции у Мерчанта, а так же статус обработки платежа: status_id == Success (успех) и код ошибки равный 0 (успех) в поле errorCode

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

Мы сохраняем ответ и обогащаем его необходимыми для витрины полями, присваиваем идентификатору транзакции мерчанта – идентификатор в Банке и отправляем ответ на витрину.

Структура ответа check/XML, шлюз контура Банк – Витрина

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

Если клиент со всем согласен, он нажимает кнопку «оплатить». Теперь отменить платеж можно только по письменному распоряжению плательщика, как правило – при личном обращении в Банк.

В запросе витрина может передать как все поля из предыдущего ответа check, так и просто сумму платежа и идентификатор транзакции, полученной на предыдущем шаге.

Мы будем использовать первый вариант.

Consistency или согласованность (c)

Согласованность означает, что если до выполнения транзакции данные в БД находятся в неком состоянии «good state»*, то они будут в этом же состоянии и после выполнения транзакции.

*Иными словами, выполняется некий набор условий. Примеры: в таблице countries не должно быть двух строк с названием страны «Российская Федерация»; возраст человека не может быть больше 150 лет.

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

Durability или долговечность (d)

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

Если вы пользуетесь облачными хранилищами, такими как Amazon S3, то могли заметить, что разные тарифы обещают вам разное количество девяток durability. В контексте облака  durability означает сохранность ваших данных и то, как они реплицируются. Чем больше копий ваших данных в разных точках мира, тем выше вероятность их не потерять из-за наводнения, землетрясения или нашествия инопланетян. В контексте «ACID» это обычно означает, что после фиксирования данные записываются в постоянное хранилище.

Isolation или изоляция (i)

Переходим к самому интересному свойству — изоляции. Представим ситуацию, когда в определенный момент времени с системой работают несколько пользователей. Естественно, операции транзакции в БД выполняются параллельно, чтобы ускорить работу системы. Но у параллельной работы транзакций есть свои подводные камни:

Выделяют несколько эффектов, связанных с этим явлением.

Представим, что у клиента банка есть счет, на котором находится 1000 денежных единиц. Транзакции А и В считывают данное значение из БД. Транзакция А должна увеличить данную сумму на 100 денежных единиц, а транзакция В — на 200. Транзакция А увеличивает сумму денежных единиц на счёте на 100 (итого 1100) и записывает значение в БД, транзакция В увеличивает сумму на 200 денежных единиц и записывает в БД (итого 1200). В результате на счете должно оказаться 1300, а по факту имеем 1200 денежных единиц.

Представим, что транзакция А переводит все деньги клиента на другой счет, но не фиксирует изменения. Транзакция В считывает изменения счёта А, получает 0 денежных единиц на счете и отказывает клиенту в выдаче наличных. Транзакция А прерывается и отменяет перевод между счетами.

Например, по правилу согласованности клиент банка не может иметь отрицательный баланс на счёте. Транзакция А хочет уменьшить баланс счета клиента на 200 денежных единиц. Она проверяет текущее значение суммы на счёте — 500 денежных единиц. В это время транзакция В уменьшает сумму на счёте до 0 и фиксирует изменения. Если бы транзакция А повторно проверила сумму, то получила бы 0 денежных единиц, но на основе первоначальных данных она уже приняла решение уменьшить значение, и счет уходит в минус.

Например, правило согласованности запрещает иметь клиенту более 3 лицевых счетов. Для открытия нового счета транзакция А проверяет все счета клиента банка и в результате получает 2 счета. В этот момент транзакция B открывает еще один счет клиенту и фиксирует изменения (3 счета). Если бы транзакция А повторно проверила количество лицевых счетов клиента, то их оказалось бы 3, и по правилу согласованности открытие нового счета было бы невозможно.

Offline подтверждение транзакции

Offline сценарий может использоваться как альтернативный способ подтверждения или отклонения транзакции.
Сценарий может использоваться когда мобильное приложение не имеет доступа в Интернет, либо по каким либо причинам не смогло загрузить с сервера
данные транзакции (сопровождающий текст, подписываемый документ)

Интегрируемая система должна отобразить пользователю QR-код (Image), полученный при первом обращении к Сервису Подтверждения Операций, и предоставить пользователю интерфейс
для ручного ввода кода подтверждения (отказа) транзакции.

Пример запроса

Pay – подтверждение платежа

Структура запроса pay/XML, шлюз контура Витрина – Банк :

Банк регистрирует платеж, и сразу отправляет ответ с промежуточным статусом обработки операции «в проведении» в ответ витрине

Структура ответа pay/XML, шлюз контура Банк – витрина:

Клиенту печатается чек о приеме к исполнению платежа, с печатью Банка и он уходит.

Подождите – спросите Вы. А что, Банк платежи в систему антифрод не отправляет? Отправляет, конечно, как раз, чтобы у клиентов не было проблем с переводами в адрес «службы безопасности из мест лишения свободы». Для этого каждый платеж отправляется на проверку системой и только после этого Мерчанту. Но этот процесс уникальный в каждой организации и общих правил нет.

Но вы еще к Мерчанту не сходили, не подтвердили у него оплату, не зарегистрировали у него платеж, а уже отпускаете клиента – снова спросите вы?

Все верно, клиент не будет ждать, пока мы сходим и зарегистрируем платеж у Мерчанта, а он свою очередь к своим поставщикам на удаленные системы. Мы уже проверили возможность совершения платежа в онлайне на предыдущем шаге check, а теперь можем отпустить клиента с печатью Банка «в проведении» и зарегистрировать оплату у мерчанта в офлайне.

Для регистрации оплаты у мерчанта, для переданного id транзакции витрины, находим транзакцию мерчанта из предыдущего шага и с ней уже регистрируем платеж.

Структура запроса pay/XML, шлюз контура Банк – мерчант:

Структура ответа pay/XML, шлюз контура мерчант – Банк:

В ответ мерчант сообщает статус обработки транзакции, который может принимать статус успех, в проведении или, если оплата была отклонена, ошибка.

Два статуса финальные, а один промежуточный.

Можно сказать, что на этих статусах обязательства и Банка и Мерчанта перед клиентом завершены.

Подождите, подождите – резюмируете Вы. Как же обязательства завершены? Ведь клиент ушел с чеком, где написано, что Банк всего лишь принял операцию к исполнению, да и Мерчант может отклонить операцию, а клиент уже ушел, что делать?

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

Асинхронное подтверждение транзакции

Если в первом запросе к Сервису Подтверждения Операций пользователь указал CallbackUri, то после подтверждения операции
на мобильном устройстве пользователя придёт оповещение о завершении транзакции.

Сообщение о завершении транзакции содержит:

• Result – результат подтверждения транзакции (success или failed)
• TransactionId – идентификатор транзакции на Сервисе Подтверждения операций (RefId)
• Error – код ошибки
• ErrorDescription – описание ошибки

Примеры ответа на CallbackUri

Оповещение о подтверждении операции:

{
    "Result":"success",
    "TransactionId":"aa1a4a5d-bb4d-456b-87da-31818604fcd8",
    "Error":"",
    "ErrorDescription":null}

Оповещение об отказе (пользователь в мобильном приложении Отказался от подтверждения операции):

{
    "Result":"failed",
    "TransactionId":"2fbd0a40-77be-4a40-a688-a0249bba16a6",
    "Error":null,
    "ErrorDescription":null}

Оповещение об истечении строка действия транзакции.

{
"Result":"failed",
"TransactionId":"bc0ffdee-7143-439f-bf6b-d1400725d8f1",
"Error":"transaction_expired",
"ErrorDescription":"Срок действия транзакции истёк"}

Если пользователь подтвердил операцию на мобильном устройстве, необходимо обратиться на Сервис Подтверждения Операций
для получения нового AccessToken. В запросе передаётся идентификатор RefId.

Пример запроса

Виды транзакций

Транзакции делят на два вида:

Неявные транзакции, которые предусмотрены на уровне базы данных. Например, БД задает отдельную инструкцию INSERT, UPDATE или DELETE как единицу транзакции.

Явные транзакции — их начало и конец явно обозначаются такими инструкциями, как BEGIN TRANSACTION, COMMIT или ROLLBACK.

В ORM Laravel при использовании фасада DB есть возможность явно указать транзакцию с помощью конструкции DB::transaction(). Если необходимо больше гибкости, можно обратиться к конструкциям DB::beginTransaction(), DB::rollBack(), DB::commit().

Например:

Внимание!

В Offline сценарии на мобильном устройстве пользователя не может быть отображён
подписываемый документ. Отобразить возможно только сопровождающий операцию текст.

Зачем нужны номера транзакций

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

Собственный номер присваивается транзакции на стадии первичного запроса. Если сумма не поступила адресату, транзакция отклонена или произошел сбой, сотрудники банка по номеру за несколько секунд смогут найти транзакцию в базе, проанализировать ситуацию и принять решение по устранению проблем.

Транзакционный номер доступен владельцу счета. Он указывается на мониторе банкомата, в выписках и на чеках. Чек с номером – гарантия удачной транзакции и страховка на случай, если перевод не дойдет адресату или возникнут другие внештатные ситуации.

Защита транзакции

Защита финансов клиента – приоритетное направление работы каждого банка. Поэтому безопасность транзакций обеспечивает электронный протокол SecureElectronicTransaction. Он был разработан в 1996 году группой американских ученых и вместил в себя набор алгоритмов, сертификатов безопасности и криптографических функций. Его предназначение – защита транзакций, проводимых в незащищенной сети Интернет.

Альтернативой SET является протокол 3-D Secure, разработанный и внедренный платежной системой VISA. Безопасность переводов осуществляется при помощи одноразовых смс-паролей.

Как работают подтверждения в сети?

При отправке монет другому пользователю, отправитель предоставляет в сеть адрес (открытый ключ), с которого произошла отправка BTC, и подписывает его своим закрытым ключом, формируя так называемую асимметричную пару ключей.

Затем майнеры проверяют открытый ключ, чтобы убедиться в подлинности подписи. Если все верно, они добавят его в добываемый блок, тем самым «подтверждая» транзакцию. В случае, если будет выявлено мошенничество, майнеры признают этот факт и полностью проигнорируют этот блокчейн. Дальнейшие блоки добавляться не будут.

Если эти «другие» майнеры считают предыдущий блок действительным, они впоследствии добавят свои блоки в цепочку, тем самым дополнительно подтвердив исходную транзакцию. В некотором смысле, придавая ей больший авторитет.

Как ускорить транзакцию биткоина?

Воспользуйтесь нашим ускорителем Bitcoin Транзакций. Это сервис для ускорения подтверждений в сети Bitсoin. Он «проталкивает» ваши неподтверждённые транзакции. Просто введите ID транзакции и ваш перевод добавится в следующий блок, добываемый разными крупными пулами. Даже если комиссия Вашей транзакции очень мала, у вас есть шанс быстрее получить подтверждение. Бесплатно!

Онлайн и оффлайн: в чем разница?

С зависимости от оперативности выполнения, транзакции объединяются в две группы:

Онлайн-транзакция проводится мгновенно. Ею мы чаще всего пользуемся, оплачивая товары и снимая зарплату в банкомате. В течение пары секунд банки-участники сделки обмениваются запросами и кодами, и осуществляют перевод средств. От покупателя требуется только подтверждение согласия перевода в виде предоставления карты в магазине, ПИН-кода для терминала или смс-кода при заказе товаров в сети.

Оффлайн-транзакция – означает отложенный платеж. Этим способом чаще всего пользуются компании и фонды для перевода финансов в определенные дни (зарплаты, пенсии). Для проведения сделки не требуется личное участие плательщика. Все необходимые условия задаются заранее, а переводы могут выполняться регулярно.

Оплата пластиковой картой

Что такое транзакция по банковской карте Сбербанка? Это оплата любых счетов без использования наличных. Пластиковая карта уже давно обогнала наличные деньги по частоте и объемам оплаты. И это закономерно, ведь при оплате карточкой никогда не возникнут проблемы отсутствия сдачи и обсчета недобросовестными продавцами.

Пластиковой картой удобно:

• Оплатить покупки и услуги.
• Оплатить коммунальные счета, налоги и даже штрафы с банкоматов и терминалов.

Отмена транзакции

Отменить транзакцию можно несколькими способами, в зависимости от вида и цели платежа.

1. Аннулирование операции

Если Вы ошиблись при введении номера карты получателя и отправили деньги неизвестному человеку, отмена займет много времени и сил. Первым делом обратитесь в ваш банк и получите дальнейшие инструкции. Скорее всего придется лично посетить отделение и составить заявление.

2. Возврат средств

Согласно закону о защите прав потребителей, Вы можете вернуть некоторые товары в магазин в течение 14 дней после оплаты. Сделка может быть отменена или же будет оформлен возврат.

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

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

Оффлайн-транзакция вне реального времени

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

Для отложенного перевода денег с карты выполняется ее электронный оттиск и оформляется специальная заявка. Эти данные пересылаются банку-эмитенту для оформления платежа.

Перевод средств между счетами

Денежный перевод – самый простой способ пополнить свой счет, или перевести любую сумму родным и близким. В рамках одного банка комиссия насчитывается от 0 до 3 %. При переводе между различными банками оплата услуг может быть и выше.

Переводом с одного счета на другой легко:

• оплачивать товары в интернет-магазине;
• перевести денежные средства любому получателю;
• оплатить услуги, например, косметолога, репетитора или врача.

Удобной услугой является «Регулярный платеж», который позволяет вовремя оплачивать некоторые счета и не заботиться о соблюдении сроков, например, пополнение баланса мобильного.

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

Предварительные условия

В подтверждении транзакции задействованы следующие сервисы DSS:

Подтверждение транзакции подписи на сервисе подтверждения операций

Для подтверждения транзакции, созданной на Сервисе Подписи, пользователь отправляет запрос содержащий:

• CallbackUri – адрес для оповещения о завершении транзакции (опционально).
• TransactionTokenId – идентификатор транзакции, созданной на сервисе подписи.
• Resource – идентификатор Сервиса Подписи.
• ClientId – идентификатор OAuth клиента.
• ClientSecret – пароль OAuth клиента (для неконфиденциальных клиентов данный параметр не указывается).

Получение подписанного документа на сервисе подписи

Для получения подписанного документа необходимо отправить запрос Сервису Подписи на конечную точку /documents.

Примеры запросов

Примечание

При обработке ответа Сервиса Подтверждения Операций вызывающее приложение должно смотреть на значение двух флагов:
IsFinal и IsError. Если получен ответ с IsError – true, то дальнейшее подтверждение транзакции не возможно. Если получен ответ с IsFinal – false, то подтверждение транзакции ещё не завершено.

Приходные, увеличивающие сумму на счету:

• Пополнение счета наличными.
• Перевод с другого личного счета.
• Онлайн-займ на карту.
• Перечисление зарплаты и пенсии.

Расходные банковские транзакции подразумевают уменьшение финансов на счету:

• Обналичивание.
• Перевод денег на другие счета и пополнение электронных кошельков.
• Оплата покупок и услуг.
• Автоматические платежи.
• Оплата взносов по кредитам и займам.
• Оплата штрафов.

Решение

Для устранения данных эффектов на уровне баз данных предусмотрены уровни изоляции, или transaction isolation levels, которые так или иначе реализованы во многих СУБД. Для примера рассмотрим движокInnoDB  в СУБД MySQL:

Все запросы SELECT считывают данные в неблокирующей манере.       

Блокирующее чтение (SELECT … FOR UPDATE, LOCK IN SHARE MODE), UPDATE и DELETE блокирует искомые индексные строки. Таким образом, возможна вставка данных в промежутки между индексами. Промежутки блокируются только при проверках на дублирующиеся и внешние ключи.

Согласованное чтение не накладывает блокировок, однако считывает данные из свежего снэпшота. В остальном ведёт себя так же, как и read uncommitted.

Согласованное чтение не накладывает блокировок и считывает данные из снэпшота, который создается при первом чтении в транзакции. Таким образом, одинаковые запросы вернут одинаковый результат.

Блокировка для блокирующего чтения будет зависеть от типа условия:

Кстати, в InnoDB именно уровень repeatable read используется по умолчанию.

Аналогично repeatable read, но есть интересный момент. Если выключен autocommit (а при явном старте транзакции START TRANSACTION он выключен по умолчанию), то все запросы SELECT превращаются в запросы SELECT … LOCK IN SHARE MODE.

SELECT … LOCK IN SHARE MODE – блокирует считываемые строки на запись.

SELECT … FOR UPDATE – блокирует считываемые строки на чтение.

Теперь, когда разобрались со всеми подводными камнями, сформулируем определение изоляции.

Изоляция — это свойство транзакции, которое позволяет скрывать изменения, внесенные одной операцией транзакции при возникновении явления race condition.

Свойства транзакции

Выделяют так называемые «магические» свойства транзакции, которые описываются аббревиатурой «ACID». Каждая буква аббревиатуры означает одно из свойств, о которых мы поговорим ниже.

Синхронное подтверждение транзакции

В синхронном режиме пользователь должен периодически опрашивать Сервис Подтверждения Операция, ожидая
завершение подтверждения транзакции (флаг IsFinal = true).

Пример запроса

Системы денежных переводов и электронные платежи

Денежные переводы WesternUnion и MoneyGram, а также электронные кошельки PayPal, QIWI и подобные – это возможность дистанционно переводить средства тем людям, у которых нет банковского счета.

Главными преимуществами этих способов являются широкое распространение и высокая скорость. К недостаткам можно отнести высокую комиссию, по сравнению с внутренними банковскими переводами.

Надеемся, наша статья оказалась полезной и помогла Вам разобраться, что такое транзакция.

Сколько bitcoin нужно подтверждений?

Шесть подтверждений считаются достаточно безопасными и надежными, чтобы считать транзакцию действительной и постоянной. Первоначальный блок транзакции определяется как первое подтверждение, поэтому рекомендуется подождать, пока не будут добавлены пять дополнительных блоков, в результате чего получится блокчейн из шести блоков. На этом этапе вероятность того, что ваша транзакция будет признана недействительной, составляет менее 0,1%.

Новые блоки добавляются в блокчейн в результате майнинга, который необходим для защиты сети и обработки транзакции BTC. Чем больше сумма транзакции — тем больше подтверждений вам следует дождаться. Например, при отправке сумм свыше $1 миллиона рекомендуется дождаться 60 подтверждений, в то время как всего трех подтверждений может быть достаточно для транзакции на сумму менее $1 тысячи (на том основании, что это просто не оправдает ни по времени ни с финансовой стороны действия злоумышленника для такой небольшой суммы).

Создание транзакции подписи на сервисе подписи

После прохождения аутентификации пользователь инициирует подписание документа.
Для подтверждения любых операций на Сервисе Подписи используется метод /transactions
В запросе необходимо указать:

Статусы транзакций

Каждой транзакции присущи два статуса:

• Транзакция завершена – оба банка одобрили транзакцию и оплата успешно совершена.
• Транзакция отклонена – возникли какие-либо проблемы с переводом средств, из-за которых операция не может быть выполнена.

Главное определение транзакции – ее неразрывность. Она может быть выполнена или нет. Никаких промежуточных статусов и значений быть не может.

Если транзакция отклонена одним из участников, то в зависимости от причин, владелец счета может получить сообщение о приостановке или отклонении.

Участники транзакции

Какой бы ни был тип транзакции, в каждом из финансовых переводов участвуют несколько сторон:

1. Банк, обслуживающий терминал и принимающий платеж транзакцией – эквайр.
2. Банк, выдавший карту и совершающий платеж – эмитент.
3. Платежная система, выступающая в роли посредника и обеспечивающая финансовый канал транзакции.
4. Владелец счета – инициатор процедуры, дающий соглашение на транзакцию.

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

Часть 1: проведение и подтверждение платежа

Клиент для оплаты услуг как правило авторизуется в интернет-Банке, выпустившим его карту: Банку-Эмитенту его карты.

Далее в интернет-Банке, выбирает услугу для оплаты: пополнение мобильного телефона, оплаты интернета или услуг ЖКУ.

В базе поставщика услуги, например оператора сотовой связи, у клиента есть свой уникальный идентификатор – номер телефона.

Чтобы оплатить услугу клиент вводит свой идентификатор и сумму пополнения, нажимает кнопку «подтвердить платеж».

А дальше ему отображается пред чек с идентификатором пополнения и суммой пополнения. Он подтверждает оплату и далее интернет-Банк отображает ему чек. Клиент радостный уходит. Деньги «моментально» поступают на его номер телефона.

Это для клиента так. А давайте посмотрим, как это выглядит внутри систем.

Наш онлайн обмен сообщениями, будет состоять из нескольких участников:

• Витрина – в данном случае, интернет-Банк клиента;

• Банк клиента – он же оператор по переводу денежных средств, он же Банк-Эмитент, выпустивший карту клиента, и он же расчетный Банк по переводам средств клиента Сервис-Провайдеру;

• Сервис-Провайдер – юридическое лицо, оказывающее услуги зачисления средств Поставщику, его часто называют «Мерчант». Сервис-Провайдер имеет прямые договора со многими поставщиками услуг, и чтобы Банку не настраивать интеграцию с каждым из них, на рынке есть компании-посредники: Сервис- Провайдеры, еще их называют агрегаторами, платежными системами. Они уже настроили интеграцию с Поставщиками услуг и предоставляют большое количество сервисов за определенный процент;

• Наш оператор сотовой связи – Поставщик услуг;

И у Сервис-Провайдера и у Поставщика услуг есть свои расчетные Банки. В итоге, Банк Сервис-Провайдера в офлайне перечислит денежные средства на счет Поставщика услуг в целях зачисления на счет клиента. Но об этом в следующих статьях.

Я буду использовать сущности: Банк, Мерчант и Витрина для описания онлайн взаимодействия внутри систем.

Центральной фигурой в нашем взаимодействии является Банк клиента.

У Банка задача не только проверить наличие денежных средств у клиента, но и доставить их Сервис-Провайдеру. Для выполнения этого условия Банк, как правило, пишет два шлюза либо использует текущие:

1. Входящий: от Витрины к Банку;

2. Исходящий: от Банка к Мерчанту;

Оба эти шлюза могут работать как по тождественному протоколу, так и по разным.

Мы рассмотрим самый простой вариант: витрина Банка, Банк и Мерчант работают по одному сквозному протоколу, представленному всего двумя методами: check и pay.

Описание процесса проведения и подтверждения платежа в этом случае выглядит следующим образом:

Вывод

Как мы рассмотрели выше, ошибки при проведении транзакций могут приводить к нежелательным последствиям в работе с системой. В статье мы осветили возможные риски при проведении транзакции и то, как ее “магические свойства” помогают справиться с каждой отдельной проблемой. Надеемся, что этот материал был вам полезен, и ждем ваших комментариев.