Холд процентного модуля со снятием что это
Перейти к содержимому

Холд процентного модуля со снятием что это

  • автор:

Холдирование

Холдирование (англ. hold — «удерживать») или замораживание — это резервирование суммы платежа на определенный промежуток времени между моментом авторизации банковской карты и получением расчетов от эквайера.

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

В процессе холдирования возникает несколько важных нюансов:

  1. Если валюта платежа отличается от валюты счета, то конвертация будет произведена по курсу на дату списания, а не резервирования средств. Клиенту следует внимательно относиться к таким операциям, прогнозировать изменения курса и не допускать появления отрицательного баланса
  2. Часто банк списывает не зарезервированную, а новую сумму по реквизитом торгово-сервисного предприятия из клиринговых файлов. Резерв остается замороженным, и держателю кажется, что с карты происходит двойное списание. Холдированная сумма разблокируется спустя установленный период времени. Если ожидание вызывает неудобство у пользователя или деньги нужны срочно, то следует обратиться в банк с запросом на отмену авторизации и предоставить подтверждающие дату покупки документы
  3. В редких случаях подтверждающие документы от эквайера приходят, когда резерв уже снят. Банк в любом случае произведет списание, но если на карточном счету мало средств, то образуется неразрешенный овердрафт, что который грозит штрафом клиенту
  4. Технические сбои в работе оборудования либо ошибки кассира могут вызвать двойное холдирование средств на карте. При этом если магазин своевременно проведет отмену операции до момента получения информации банком, сумма сразу же разморозится. Подобное происходит при возврате товара в день совершения покупки: продавец отменят платеж и средства возвращаются покупателю без участия кредитной организации

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

Процедура холдирования средств состоит из следующих этапов:

  • Торговая точка формирует платеж, сумма которого равна цене товара или услуги
  • Покупатель оплачивает покупку картой в POS-терминале или платежной форме на сайте
  • Платежный сервис отправляет запрос в банк-эквайер, обслуживающий торгово-сервисное предприятие
  • Эквайер запрашивает у эмитента карты совершение оплаты
  • Эмитент, временно резервирует сумму на счету покупателя
  • Эквайер закрывает сделку, кассир выдает чек
  • При получении положительного ответа о транзакции эмитент списывает зарезервированную сумму и перечисляет эквайеру

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

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

  • Официальный сайт Тинькофф
  • interkassa.com: Холдирование денежных средств на карте

HOLD на 2 недели без возможности отмены

В очередной раз вынужден писать негативный отзыв этому банку, в котором я обслуживаюсь почти 5 лет. Сегодня при оплате сервисов Google с использованием биллинга Assist был совершен платеж, при котором произошла ошибка авторизации. Информация о платеже и заказе: Номер платежа (BillNumber: 312213434251090) Название магазина: ООО Гугл Номер заказа: 110147836859 Покупатель: 5944324602 Юрий Дата операции: 25 июня 2012 12:37 Сумма операции: 400.00 RUR Результат авторизации: ПОВТОРИТЕ АВТОРИЗАЦИЮ Расшифровка: ОТКАЗ В АВТОРИЗАЦИИ. Попытайтесь повторить операцию через некоторое время. Код авторизации: N/A Номер карты: ****3522 Идентификатор предприятия: 5204374001 При этом, с карты были списаны деньги в HOLD. Google денег не получил, Assist денег не видел. Тех. поддержка Ассиста посоветовала позвонить в Альфабанк и попросить снять холд и повторить платеж, что для этого достаточно звонка в банк. Пытаюсь позвонить на номер горячей линии, однако меню IVR не имеет быстрой клавиши связи с оператором. Я вынужден слушать информацию о типах услуг. Выйти на оператора мне удалось только после звонка в центральный офис (попал в отдел юр. лиц), где мне подсказали, что на номере горячей линии необходимо набрать комбинацию клавиш 5, 3, 0 чтобы попасть на оператора. При всем этом я готов выкинуть банковскую карту! Потому что нервы на пределе. Дозвонившись, оператор сообщила мне, что HOLD снять невозможно, что деньги заморожены на 2 недели, что необходимо, чтобы интернет магазин подтвердил списание. Звоню в Ассист, мне говорят, что это невозможно, так как была ошибка авторизации, предлагают повторить платеж. Я решил поехать положить наличку на карту другого банка и платить через него.

Альфа-Банк

2012-06-26T19:36:00+04:00

Уважаемый Клиент, позвольте объяснить Вам ситуацию в принципе. В соответствии с Договором при проведении авторизации платежный лимит карты уменьшается на сумму проведенной операции, т.е. сумма операции блокируется (резервируется) на счете карты. В случае непоступления в Банк в течение 14 дней документов (в электронном виде), подтверждающих совершение операции, сумма операции разблокируется автоматически. После получения подтверждения о совершении операции с использованием карты, Банк имеет право списать денежные средства. Теперь конкретно о Вашем случае. Указанная Вами сумма заблокирована как раз на основании авторизационного запроса. Оснований для досрочной разблокировки нет. Если данная операция не будет представлена к оплате, то сумма автоматически разблокируется через 14 дней с даты совершения операций. В случае если сумма будет списана, то Вам будет необходимо оформить претензию по оспариваемым суммам. Надеемся на понимание и дальнейшее сотрудничество. С уважением, Юлия Зиновьева, начальник отдела обработки электронных запросов Дирекции по обслуживанию Клиентов ОАО «Альфа-Банк»

Холдирование средств

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

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

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

При работе в двухэтапном режиме, после совершения оплаты клиентом, статус платежа изменится на «Получен/Совершён, авторизован»:

Авторизованный платёж в таблице платежей

Это означает, что средства на карте клиента заморожены (холдированы), в банк-эмитент (банк плательщика) был отправлен запрос на авторизацию средств.
Если до истечения срока авторизации, который задан в платежной платформе, не было выполнено списание средств или частичный возврат (через личный кабинет или API), то списание произойдёт автоматически. Точная дата списания указана в параметрах платежа, параметр «Платёж авторизован». Максимальный срок авторизации — 9 дней.​

Отмена авторизации

Диалог возврата платежа позволяет отменить авторизацию или произвести частичное списание

В течение срока авторизации (холдирования) возможно выполнить её отмену. При отмене авторизации комиссия по операции банком-эквайером не взимается.

Для отмены авторизации через личный кабинет:

  1. Нажмите на кнопку «Полный или частичный возврат платежа»
  2. В разделе «Сумма к возврату» выберите «Полный возврат суммы»
  3. Нажмите на кнопку «Вернуть платёж» и подтвердите выполнение возврата

Для отмены авторизации через JSON API личного кабинета PayKeeeper, используйте метод 2.8. Запрос на возврат платежа /change/payment/reverse/.

Списание средств с карты

Списание можно проводить в любое время после выполнения авторизации двумя способами:

  1. Через личный кабинет: нажав на кнопку «Списать средства» в информации о платеже на вкладке «Платежи»
  2. Через API личного кабинета: метод 2.12. Списание средств по ранее проведённой авторизации /change/payment/capture/

Если списание не было выполнено по запросу через личный кабинет или API, то в последний день авторизации, в 19:00 (значение по умолчанию, его можно изменить), запрос на списание средств будет отправлен автоматически.

В момент списания платежной платформы отправит запрос в кассу на печать чека.

Частичное списание

Выполнение частичного списания производится посредством частичного возврата авторизованного платежа.

Для выполнения частичного списания с помощью личного кабинета:

Указание суммы частичного возврата

Указание суммы частичного возврата

  1. На вкладке «Платежи» найдите платёж, который нужно вернуть и разверните его. Платёж должен быть в статусе «Получен, авторизован»
  2. Нажмите на кнопку «Полный или частичный возврат платежа»
  3. В открывшемся окне, в разделе «Сумма к возврату» выберите «Частичный возврат суммы»
  4. Укажите ту часть суммы, которую нужно вернуть. Сумму к возврату необходимо указывать в формате «1234.56» — используя только цифры, символ точки, без использования пробела
  5. Нажмите на кнопку «Вернуть платёж» и подтвердите выполнение возврата

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

Заполните заявку

и сразу получите доступ в личный кабинет

Путешествия банковской транзакции

image

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

Как выглядит упрощённая схема работы работы процессингового центра банка:

image

Процессинг

FrontEnd — отвечает за online сообщения: общение с банкоматами и POS-терминалами, передача авторизаций карт в VISA.
BackEnd — отвечает за offline: закрытие операционного дня, обмен финсообщениями с VISA.
HSM (Hardware Security Module) — модуль работы с ключами безопасности (подробнее описано ниже).

Все шифрование производится с помощью алгоритма 3DES.

Подключение к VISA
  • online
  • offline
Online-подключение

Транспортный уровень
Подключение к VISA осуществляется через вполне конкретного провайдера, в 2006 году это был Equant и его партнёр в России — Golden Telecom, как обстоят дела сейчас — я не в курсе.

Получается, что VISA доступна в локальной сети одного провайдера. Это обязательное требование VISA. Для подключения провайдер прокладывает в банк собственный оптоволоконный кабель для основного канала связи и для резервного. Устанавливает конечные маршрутизаторы и выделяет по одному порту на каждом (основной и резервный). Управление маршрутизаторами осуществляется только провайдером.

Итак, связь транспортного уровня с VISA установлена, далее прикладной уровень.

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

Кроме всего этого все сообщения должны передаваться зашифрованными. Для этого специальные люди — офицеры безопасности — генерируют ключевые последовательности заданной длины на HSM и результаты отправляются в VISA.

Оффлайн-подключение

Оффлайн-подключение — это не что иное, как обмен файлами с информацией обо всех транзакциях, совершённых за операционный день. То есть, если в банкоматах банка «А» были обслужены карты не банка «А». Подробнее об этом чуть ниже в сценарии «Чужой клиент в нашем АТМ».

Стоит немного рассказать про HSM.

HSM

HSM — это классический чёрный ящик. При инициализации он генерирует закрытую и открытую компоненту мастер-ключа банка. Закрытую компоненту никто никогда не видит, она всегда остаётся в памяти HSM.

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

Три части открытой компоненты мастер-ключа записываются на 3 магнитные карты и выдаются офицерам безопасности банка.

Итак, связь с VISA установлена, и всё работает. Теперь нам надо выпускать карты.
При вступлении в VISA банку выдаются так называемые БИНы (Bank Identification Number): то есть подмножества номеров карт доступных для выпуска. Для VISA они всегда начинаются на 4.

БИНы распределены по карточным продуктам, например:

  • VISA Classic: 400001
  • VISA Gold: 400002
  • VISA instant issue: 400003
  • и так далее

Формат номера выглядит так: допустим, у нас есть карта с номером: 4408 0412 3456 7890

Номер карты состоит из:

  • 4ХХХХХ — код VISA
  • 4408(04) — код банка (код карточного продукта)
  • 12 3456 7890 — номер лимита авторизации. Подробнее о лимите авторизации ниже.

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

Для каждого БИНа генерируется пара ключей: IWK (issuer working key) и AWK (acquirer working key). Процедура генерации и передачи результата в VISA аналогична описанной выше.

После этого всё это добро прописывается в FrontEnd и BackEnd процессинга. В BackEnd для выпуска карт и их эмбоссирования, вo FrontEnd для обслуживания авторизаций.

Теперь у нас есть связь с VISA и есть выпущенные карты; другими словами, мы осуществили эмиссию карт. Нам осталось сделать эквайеринг.

Банкоматы

Не буду повторяться и описывать, что находится внутри банкомата, это уже описали здесь. Скажу только, что протокол NDC+ (NCR Direct Connect) разработан чёрт знает сколько лет назад корпорацией NCR — одним из ведущих производителей банкоматов на сегодняшний день.

Широко известны три производителя:

  • NCR
  • Wincor Nixdorf GmBH (бывший Siemens Nixdorf)
  • Diebold (бывший IBM)

Да, и Siemens и IBM когда-то давно производили банкоматы, но впоследствии продали этот бизнес Wincor Nixdorf и Diebold соответственно.
Ваш покорный слуга является сертифицированным инженером как раз таки Wincor Nixdorf. Однако, у нас был один стародавний IBM, который был выпущен ещё до продажи бизнеса и который работал.
Не скажу, что работал он как часы, ибо его всё время приходилось подкручивать и подлаживать, чтобы он хоть как-то дышал, но для него можно было купить запчасти. Правда, стоили они в три раза дороже чем аналогичные для Wincor Nixdorf.
Итак, мы выяснили что есть два протокола по которому работают банкоматы. Мне довелось работать лишь с NDC+, про DDC я только слышал, но никогда не видел.
Поскольку я близко знаком только с Wincor Nixdorf, предположим, что наш банк купил именно их.

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

Готовим банкомат
Обучение

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

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

Ключи шифрования

В банкомат загружают 2 ключа шифрования:
мастер-ключ (MASTER KEY) — используется для шифрования ПИН-блока введённого клиентом.
коммуникационный ключ (COMM KEY) — для шифрования пакета к FrontEnd процессинга.

На HSM генерируются открытая и закрытая компонента каждого ключа, после чего открытая компонента прописывается во FrontEnd, а закрытая загружается в банкомат.
Оба ключа загружаются в ПИН-клавиатуру (EPP Encrypted Pin Pad) и хранятся только там. По сути EPP — это такой маленький HSM, который не умеет генерировать ключи, но умеет очень хорошо их хранить. Когда я плотно работал с банкоматами — EPP имели 7 ступеней защиты от физического проникновения.

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

Сценарий

Про сценарий уже было сказано в статье, на которую я ссылался, хочу лишь немного добавить.
Весь сценарий банкомата основан на так называемых ФИТах (Financial Institution Table).
FIT — не что иное, как БИН банка выданный VISA.
Например: для нашего родного банка мы позволим делать переводы с карты на карту, возможность просмотреть детали по вкладу и внести наличные на карточный счёт в дополнение к обычным возможностям (баланс, выдача наличных), а для всех остальных только баланс и выдача.

Таким образом, мы должны загрузить неколько ФИТов в банкомат:

  • 400001, 400002, 400003 — позволим всё и вся
  • 999999 — только выдача и баланс

Сценарий проверяет номер карты клиента и работает по первому совпадению в ФИТ-таблице.

Итак, мы полностью подготовили весь комплекс к работе, осталось самое главное: совершить транзакцию.

Транзакция

Самый простой сценарий: наш клиент в нашем АТМ:

  1. Клиент вставляет карту в АТМ;
  2. АТМ видит что клиент наш и выдаёт ему опции;
  3. Клиент выбирает: выдача, 100 рублей
  4. Банкомат шифрует ПИН-блок мастер-ключом;
  5. Шифрует всё сообщение коммуникационным ключом и отправляет в FrontEnd;
  6. FrontEnd получает сообщение;
  7. по ID определяет банкомат (каждый банкомат подключается на свой собственный порт, так что ID получить проблем никаких);
  8. Расшифровывает сообщение открытой компонентой коммуникационого ключа;
  9. по БИН понимает, что карта наша;
  10. Расшифровывает ПИН-блок открытой компонентой мастер-ключа;
  11. Обрабатывает запрос на списание (есть ли деньги, не исчерпаны ли лимиты и всё такое прочее);
  12. Зашифровывает сообщение открытой компонентой коммуникационого ключа;
  13. Отправляет банкомату;
  14. Банкомат расшифровывает сообщение;
  15. Сообщает результат клиенту;
  16. Уведомляет хост, что деньги выданы (так же с шифрованием и всем прочим).

Стоит отметить, что всё шифрование на стороне хоста осуществляется при помощи HSM.
То есть шаги 8 и 9 в деталях выглядят так:

  1. Хост отправляет зашифрованный ПИН-блок, мастер-ключ и контрольную сумму на HSM;
  2. HSM расшифровывает ПИН-блок;
  3. Сверяет контрольную сумму после расшифровки с присланной;
  4. Зашифровывает открытый ПИН-блок при помощи IWK и считает контрольную сумму;
  5. Если контрольные суммы открытого ПИН-блока и зашифрованного IWK равны — ПИН введён верно.

Клиент получает свои 100 рублей и уходит довольный, однако это только половина дела.

В этот момент FrontEnd установил клиенту hold — заморозил на его лимите авторизации (доступная к снятию сумма) 100 рублей, но его текущий счёт никак не изменился.

Здесь стоит немного пояснить: в процессинге нет счетов клиентов — движение денег происходит по так называемым «лимитам авторизации». Фактически, лимит авторизации — не что иное, как карточный счёт клиента, но он никак не фигурирует в плане счетов и бухгалтерском балансе.

Другими словами, лимит авторизации есть техническая сущность, которая отражает состояние реального текущего счёта клиента в процессинге. Отличие лимита авторизации в том, что:

  1. на лимит авторизации действуют лимиты процессинга: лимит на единоразовую выдачу, лимит на ежедневную выдачу и так далее;
  2. лимит авторизации может изменяться в течение операционного дня, текущий счёт только в момент закрытия операционного дня.

Вечером текущего дня или утром следующего дня (но, как правило, это делается ночью) закрывается операционный день. Все авторизации карт и суммы холдов выгружаются из FrontEnd и загружаются в BackEnd, где и происходит движение денег по текущим счетам клиентов. После этого финальные отчёты выгружаются в Автоматизированную Банковскую Систему, где хранятся текущие счета клиентов. На основании этих отчётов происходит реальное движение денег, а также во FrontEnd — новые лимиты авторизации (наш клиент из примера выше получает новый лимит авторизации, который меньше на 100 рублей).

Теперь сложнее: Чужой клиент в нашем АТМ:

  1. Клиент вставляет карту в АТМ;
  2. АТМ понимает что клиент чужой, показывает ему только баланс и выдачу;
  3. Клиент выбирает: выдача, 200 рублей
  4. АТМ шифрует ПИН-блок мастер-ключом;
  5. Шифрует сообщение коммуникационным ключом;
  6. Отправляет сообщение на FrontEnd;
  7. FrontEnd расшифровывает сообщение открытой компонентой коммуникационого ключа;
  8. Определяет что БИН не наш и надо его отправить в VISA;
  9. FrontEnd зашифровывает сообщение компонентой AWK (так как мы в данном случае эквайер) и отправляет в VISA;
  10. VISA получает от нас сообщение, расшифровывает его второй компонентой нашего AWK и по БИНу определяет какого банка это карта;
  11. Зашифровывает сообщение компонентой IWK (так как обращается к эмитенту) того банка, который выпустил эту карту и отправляет сообщение;
  12. Банк-эмитент получает сообщение:
  13. Расшифровывает сообщение при помощи закрытой компоненты IWK (тут сразу понятно что карта наша, БИН смотреть нет смысла);
  14. Расшифровывает ПИН-блок;
  15. Авторизует карту (даёт добро на выдачу 200 рублей);
  16. Зашифровывает сообщение закрытой компонентой IWK и отправляет в VISA;
  17. VISA расшифровывает открытой компонентой IWK банка-эмитента, зашифровывает открытой компонентой AWK нашего банка и отправляет нам;
  18. Мы расшифровываем сообщение закрытой компонентой AWK;
  19. Записываем результат транзакции;
  20. Зашифровываем открытой компонентой коммуникационого ключа нужного банкомата и отправляем ему сообщение;
  21. Банкомат получает сообщение, расшифровывает его и выдаёт клиенту деньги;
  22. Уведомляет хост, что деньги выданы (опять же, шифрую все сообщения);
  23. Мы уведомляем банк-эмитент, что деньги успешно выданы;

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

  1. Мы отправляем в VISA отчёт (оффлайном, медленно и печально) о том, что не наш клиент с номером карты таким-то получил 200 рублей в нашем банкомате;
  2. VISA отправляет требование банку-эмитенту перечислить нам 200 рублей и ещё 0,5% от суммы транзакции, но не менее $3 самой VISA за то, что она провела транзакцию через себя. Это есть так называемый interchange fee;
  3. Банк-эмитент получает файлы от VISA, закрывает свой операционный день в процессинге, потом закрывает день в Автоматизированной Банковской Системе и переводит через корр. банк VISA на наш счёт наших 200 рублей;
  4. Рассчитывается с VISA (покрывает interchange fee)

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

UPD: В комментариях, товарищ Spewow привёл ссылку на статью о HSM и криптографии

UPD2:И мною была обнаружена статья, где более подробно описана архитектура ПО для банкоматов (XFS): habrahabr.ru/post/93507

  • банковские карты
  • банки
  • visa
  • mastercard
  • процессинг кредитных карт

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *