Платежная система способы платежа

Какие бывают способы оплаты? Классификация

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

Какие бывают способы оплаты?

Статья 140 ГК РФ гласит, что платежи на территории РФ могут осуществляться наличными или безналичными расчетами. Это основная классификация, которая разделяет абсолютно все способы платежей.

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

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

Способы оплаты наличными

• Наличными в кассе, курьеру, путем передачи денежных средств от непосредственного заказчика исполнителю или третьему лицу.
• Через терминалы самообслуживания Qiwi, Элекснет, Киберплат и другие. Пользователь выбирает необходимую услугу на экране терминала и оплачивает ее, путем внесения денежных средств в купюромприемник. В таких терминалах можно оплатить практически все, в том числе кредиты, онлайн-займы и т.д.
• В банковских ПВН и банкоматах с функцией приема наличных. Опять же нужно выбрать необходимый параметр (например, оплата госпошлины), ввести назначение платежа и вставить купюры, оплатив операцию.
• Платеж в банке или на Почте России. Большинство пенсионеров до сих пор платят за электроэнергию и квартиру в отделениях Почты, так уж завелось. Для совершения платежа необходимо предъявить платежное поручение или просто указать реквизиты получателя, после чего передать наличные денежные средства операционисту.
• Достаточно популярным в России остается способ оплаты через системы переводов (Contact, Золотая Корона и т.д.) Для расчета достаточно подойди в отделение выбранной системы переводов, указать реквизиты платежа или хотя бы назвать организацию и внести наличные.

Безналичные способы

Безналичные платежи в свою очередь делятся на контактные и бесконтактные.

• Расчет с помощью банковской карты с магнитной полосой и/или чипом — самый популярный способ безналичного платежа. В последнее время карты с магнитной полосой стали вытесняться более защищенным чипованным пластиком. Чтобы оплатить товар с помощью карточки, нужно вставить ее в чип-ридер POS-терминала (для карт с чипом) или провести пластиком через ридер (для карт с магнитной полосой). После этого останется ввести ПИН-код и деньги спишутся со счета, а товар будет успешно оплачен.
• Расчет с помощью карты с технологией PayPass (Мастеркард) или Pay Wave (Visa) — самый распространенный способ бесконтактной оплаты товаров. Для расчета по такой карте достаточно поднести ее к POS-терминалу и товар автоматически будет оплачен без ввода ПИН-кода и прочих манипуляций. У этого способа есть один существенный недостаток, платеж по 1 операции не может превышать 1000 рублей. То есть, если сумма вашей покупки составит 1035 рублей, оплатить ее картой бесконтактным способом не получится, придется вставлять пластик в терминал и вводить ПИН-код. Также далеко не в каждом магазине есть терминалы с возможностью бесконтактной платы.
• Расчет с помощью реквизитов карты — еще один популярный способ бесконтактных расчетов, чаще всего применяется при оплате покупок в интернет-магазинах или услуг через интернет. Для совершения операции достаточно ввести в нужные поля номер карточки, срок ее действия, имя и фамилию латинскими буквами, а также защитный CVC/CVV2 код, который расположен на обратной стороне пластика. После ввода необходимых реквизитов нужно вписать специальный 3D-Secure код для подтверждения операции. После чего деньги спишутся со счета.
• Платеж электронными деньгами через интернет-кошелек QIWI, Webmoney, Яндекс.Деньги(сейчас Юмани) и т.д. Для оплаты товаров/услуги достаточно зайти в личный кошелек одной из платежных систем и оплатить выставленный счет или просто перевести деньги по реквизитам организации и т.д.
• Оплата мобильным телефоном с технологией NFС — далеко не самый распространенный в России способ бесконтактной платы за товары/услуги. Технология NfС позволяет оплачивать различные услуги с помощью поднесения к считывающему устройству мобильного телефона. Чтобы воспользоваться этим способом, нужно приобрести сим-карту с поддержкой технологии NfС и установить в телефон дополнительную антенну. После чего можно оплачивать услуги в одно касание, просто приложив смартфон к терминалу и деньги спишутся со счета мобильника (с баланса). Конечно, в России не так много мест, где можно расплатиться по такой технологии. Например, этим методом можно воспользоваться при оплате проезда в Московском Метрополитене.
• Банковский перевод через интернет-банкинг. Еще одни способ безналичной платы за услуги. Для расчета достаточно зайти в интернет-банк, выбрать нужную категорию, ввести назначение платежа и выбрать карту/счет для списания средств в счет платы. Останется подтвердить операцию специальным кодом и деньги спишутся со счета.
• Оплата с помощью криптовалюты. Производится прямым переводом с одного криптокошелька на другой.

Таким образом все платежи можно поделить на контактные/бесконтактные и наличные/безналичные.

Источник

Платежные технологии – просто о сложном. Часть 1

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

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

Устраивайтесь поудобнее, будет интересно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Верхняя, или горячая – это комиссия с клиента сверх тела платежа (суммы зачисления);

Нижняя или холодная, это комиссия, которую платит Банку Мерчант;

Смешанная – в этой рубрике мы не будем о них говорить;

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

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

Time – дата платежа;

type – тип источника списания;

type_number – маскированный PAN карты (примечание: PAN — номер карты) по PCI DSS;

code – код валюты перевода, в примере рубли;

amount – сумма зачисления или, по-другому, тело платежа

commission_amount – сумма с учетом верхней комиссии;

service – цифровой идентификатор услуги, который проверяет есть ли вообще такая услуга в Банке и на витрине;

account – контейнер с идентификатором пополнения, в нашем случае – номер телефона;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник