fastpay платежная система что это такое простыми словами
Fastpay платежная система что это такое простыми словами
Знаете ли вы, что каждые семь секунд в Узбекистане подключается новый абонент сотовой связи? Знаете ли вы, что количество этих абонентов уже превысило 6 миллионов по всей стране, и только в компании МТС-Узбекистан обслуживается более 3 миллионов, или 11% от всего населения Республики Узбекистан? Прибавьте к этому два с лишним миллиона наших интернет-пользователей и несколько сотен тысяч пользователей услугами IP-телефонии.
Получается, что уже сегодня четверть населения страны постоянно нуждается в быстрых, а главное — надежных платежах. При этом только уровень проникновения сотовой связи растет более чем на 100% в год. Именно поэтому на рынке Узбекистана появилась новая платежная система FAST PAY, которая является торговой маркой компании DAKA OMAD.
Девизом FAST PAY являются три обычных слова: быстро, удобно, надежно. Платежи действительно осуществляются моментально. Пункты оплаты расположены в удобных местах. Надежность платежной системы FAST PAY не вызывает никаких сомнений. Что еще нужно для взыскательного пользователя? Расскажем о системе FAST PAY немного подробнее.
Общество с ограниченной ответственностью DAKA OMAD было создано в марте 2005 года. Учитывая повышенный спрос населения на оказание моментальных услуг по оплате за услуги сотовых операторов, интернет-провайдеров и международные переговоры, ООО DAKA OMAD начало работу по организации сети по приему оплаты от населения за вышеуказанные услуги в режиме реального времени (on-line). Так родилась система FAST PAY.
Для осуществления своей инновационной деятельности в августе 2007 года компания DAKA OMAD получила лицензию № 0002142 Узбекского агентства связи и информатизации на осуществление деятельности «Проектирование, строительство, эксплуатация и оказание услуг сетей передачи данных».
Уже в октябре 2007 года, успешно завершив апробацию системы, ООО DAKA OMAD запустило разработанную высококвалифицированными специалистами компании систему FAST PAY — «Единая платежная система», не уступающую по критериям надежности и качества мировым аналогам.
В настоящее время эта система успешно работает по всей республике под торговой маркой FAST PAY и стремительно развивается. За короткое время нашими агентами стали более чем 1000 физических и юридических лиц, точки обслуживания которых расположены в самых удобных для наших клиентов местах: в жилых кварталах, рынках, метро, аптеках, супер- и мини-маркетах, авто- и железнодорожных вокзалах, учебных заведениях и в других многолюдных местах. Так что FAST PAY — это всегда близко и удобно.
Компания DAKA OMAD обеспечивает агентов соответствующим оборудованием (термопринтер для выдачи чека абоненту о произведенной оплате) и рекламными материалами (рекламные бланки, банеры). Мы делаем все для быстрого расширения сети наших агентов. С FAST PAY всегда работать выгодно.
Система FAST PAY позволяет принимать оплату в «on-line»-режиме за услуги ведущих сотовых компаний Узбекистана: «Билайн», COSCOM и Perfectum Mobile, а также за пользование услугами Интернета более чем 20 провайдеров Узбекистана и оплату услуг по международной IP-телефонии. С этими компаниями заключены прямые договора на выполнение услуг. Кроме того, с компанией COSCOM заключен агентский договор на оказание населению услуг по подключению к сети COSCOM.
Ежедневно через систему FAST PAY проходят более 15000 платежей. Для оперативного управления системой наша компания связана быстрым соединением с обслуживающим филиалом Национального банка ВЭД Республики Узбекистан по системе «Банк-Клиент», которая позволяет производить моментальную оплату и получать сведения о поступлениях от клиентов в режиме реального времени.
Компания не стоит на месте. В настоящее время специалистами системы FAST PAY проводится масштабная работа по дальнейшему совершенствованию системы и увеличению спектра оказываемых платных услуг населению Узбекистана.
В частности, ведутся переговоры по приему платежей нашего крупнейшего оператора сотовой связи — компании МТС-Узбекистан («Уздунробита»). В этой связи уже в ближайшее время ожидается увеличение ежедневно оказываемых услуг населению до 50,0 тыс. транзакций, а к концу 2008 года — до 100,0 тыс. транзакций.
Кроме того, подключение к нашей системе МТС-Узбекистан позволяет обеспечивать население отдаленных сел Узбекистана к быстрому и надежному доступу по оплате в режиме реального времени за услуги различных компаний, а также существенно снизить количество использования карточек предоплаты.
Необходимо отметить, что платежная система FAST PAY позволяет интегрировать платежные шлюзы также к операторам спутникового и кабельного телевидения, организаций жилищно-коммунального комплекса, энергосбытовые и другие компании. В связи с этим решаются вопросы по сотрудничеству с энергосбытовыми, почтовыми организациями, а также с организациями жилищно-коммунального хозяйства.
Ведутся активные переговоры с АК «Узтрансгаз» и филиалом «Тошшахаргаз» о возможности приема оплаты от населения за использованный газ в режиме реального времени через систему FAST PAY. Это позволит создать еще большие удобства абонентам при оплате, экономить время и не заполнять соответствующие бланки, предъявив только ID-карту.
Кроме того, специалистами компании ведутся переговоры по сотрудничеству с предприятиями ОАО «Узбекистон почтаси». При этом предполагается установка соответствующего оборудования для приема платежей от населения в режиме реального времени через все почтовые отделения Узбекистана, что также позволит существенно увеличить оборачиваемость денежных средств и предоставлять населению максимальные удобства пользования системой FAST PAY.
Компанией ведутся еще более перспективные и инновационные разработки. Так, например, осуществляются работы по проекту внутренней электронной валюты «Pegas Money», предусматривающей проведение интернет-аукционов, открытие интернет-магазинов и т.п.
Таким образом, электронная система приема платежей FAST PAY будет предназначена не только для оплаты услуг сотовых операторов, интернет-провайдеров, IP-телефонии, но и для оплаты практически всего спектра услуг для потребителей.
Компания FAST PAY также совместно с мобильной платежной системой Mobliss разрабатывают новый проект, который предоставит возможность абонентам сотовой связи оплачивать услуги по мобильному телефону через компанию FAST PAY.
Одним из направлений дальнейшего совершенствования деятельности ООО DAKA OMAD является организация работы собственного интернет-провайдера, деятельность которого позволит нашим агентам подключиться к сети Интернет в любой точке республики по льготным тарифам. Это также будет содействовать дальнейшему увеличению агентских точек FAST PAY, повышению их оперативности и надежности.
До конца 2008 года планируется создать более чем 2500 дилерских точек FAST PAY по всему Узбекистану.
Уже сейчас компания DAKA OMAD ведет работу по строительству в многолюдных местах Ташкента более 200 собственных «эксклюзивных точек» с запоминающимся дизайном и новейшим оборудованием.
Мы ценим наших агентов и поощряем лучших. С начала этого года мы проводим акции среди своих агентов. Наиболее отличившиеся будут награждаться ценными призами, подарками и другими памятными сувенирами. Проведение подобных акций планируется вести постоянно.
Наша компания всегда будет стремиться совершенствовать платежную систему FAST PAY, внедрять различные «ноу-хау» и перспективные технологии. Мы привлекаем к работе у нас только высококвалифицированных специалистов и профессионалов из заинтересованных компаний.
В планах компании привлечение иностранных инвестиций. В этих целях ООО DAKA OMAD ведет переговоры и рассматривает взаимовыгодные предложения от иностранных фирм и компаний по созданию совместного предприятия.
Компания DAKA OMAD всегда открыта для диалога с нашими клиентами, агентами и партнерами в плане совершенствования деятельности системы FAST PAY.
Система быстрых платежей простыми словами
или денежные переводы вчера, позавчера и сегодня.
Если вы ученый, квантовый физик, и не можете в двух словах объяснить пятилетнему ребенку, чем вы занимаетесь, — вы шарлатан.» (С) Ричард Фейнман
Я уже 12 лет работаю в индустрии денежных переводов и успел застать смену нескольких эпох. Сейчас я работаю в Системе быстрых платежей, и приходится рассказывать про СБП школьным друзьям, бывшим коллегам и даже продавцам шаурмы, поэтому на тысячный раз я взял и записал свои рассказы и решил их опубликовать. Тут будет рассказ, как транзакции стали такими повседневными и незаметными, что про них никто не вспоминает.
Перевод, как это делалось раньше
Сегодня речь пойдет только о переводах от человека к человеку, Consumer-to-Consumer, C2C.
Кто и как этим пользовался?
Как это выглядело для клиента?
Говоришь код получателю (хорошо, если банк тебе его в СМС отправил, можно просто переслать).
Кассир распечатывает заявление на выдачу, и после получения подписи выдает наличные.
Дочитали? Еще недавно это было нормой.
По требованию законодательства нужно идентифицироваться, поэтому при отправке больших сумм личного визита в банк не избежать никак.
Card-to-cash, когда сумма вносится картой, а не наличными. Как правило это оформление перевода на сайте с оплатой картой как в интернет-магазине;
Cash-to-card, на карту. Переводы самому себе для пополнения дебетовой карты или погашения кредитной.
Первые два варианта ограничивается суммой 15.000 рублей, так как отправитель не идентифицирован.
Как сегодня? Mobile only
Основная предпосылка нового поведения – у каждого есть смартфон и смартфон используется как инструмент по умолчанию для любой бытовой операции.
Вроде всех все устраивало, но вот кейс: пообедали совместно пять человек и хотят заплатить.
— упс, а я наличку дома забыл. Дайте взаймы, я завтра сниму и отдам!
— давайте я заплачу за всех, а вы мне скинетесь?
— у меня только тысяча, есть сдача?
— Нет, “ББ”. А твой АА умеет в ББ переводить?
— Посмотрим. не вижу такого. Вроде нет. А твой банк может в мой запрос кинуть?
— Ну ок. А карточки в другом банке нет?
— Да это нормальный банк!
— Понял. Тогда по номеру карточки?
— Ага, перевожу. Ого, комиссия. Отправил. Жди, скоро переведется. Хотя тут про сроки ничего не сказано.
Какие кейсы переводов хотелось бы видеть в своем мобильном? Перевод микросуммы человеку, который рядом. С минимальными транзакционными расходами (комиссия, время, количество нажатий). И хорошо бы не афишировать номер карточки.
Скинуться другу, оплатившему общий счет.
Собрать деньги на подарок коллеге.
Вернуть долг, пока не забыл.
Пополнить общий семейный бюджет.
Срочно подкинуть ребенку денег на обед.
Перевести полученную зарплату в другой банк.
Как все это можно сделать в СБП. Это и даже чуть больше.
С 2019 года в России работает Система быстрых платежей. Это система межбанковских переводов, разрабатываемая и поддерживаемая Банком России и Национальной Системой Платежных Карт. В продолжении статьи я расскажу, как это устроено изнутри, а для пользователя нужно знать только две важные вещи:
Сейчас к СБП подключилось более 200 банков, включая крупнейшие, и ваш банк, скорее всего, тоже, даже если вы этого не знаете. И банк того парня, которому нужно перевести тоже подключен, можно его не спрашивать.
Идентификатором перевода служит номер телефона. И всё. Этого достаточно, не нужно знать номер карты и прочее.
(Больше того, карточки вообще не нужны. Перевод идет со счета на счет, так что можно перевести с «бескарточного» счета на «бескарточный»)
Это значит, что кейс с взаиморасчетом после обеда выглядит теперь так:
Скачал специальную программку
Спросил, в каком банке у получателя счет
Убедился, что мой банк может отправлять деньги в этот банк
Шучу, нет конечно же. Вот так:
1. В своем мобильном банке ввел мобильный номер получателя / выбрал его из контактов
3. Проверил глазами, кому отправляешь. Подтвердил отправку.
Вот и всё. Помните историю про изобретение шариковой ручки? Вот и здесь вроде ничего принципиально нового нет, а поведение изменилось. И весь рассказ уложился в один абзац.
Не нужно скачивать никаких новых приложений – перевод можно сделать внутри мобильного приложения вашего банка.
Не нужно платить комиссию, если переводишь между разными банками в СБП. Переводы до 100 тыс. рублей в месяц бесплатно.
Деньги на счете получателя появляются действительно мгновенно, и это реальные деньги, а не авансирование под ожидаемое пополнение; деньги по корсчетам банков тоже движутся мгновенно. Это очень актуально для бизнеса, т.е. для C2B – не нужно прикидывать, когда у банка следующий рейс в ЦБ; даже если на дворе Новогодние каникулы – платежи мгновенные.
Не нужно заполнять печатными буквами заявления, если уж сравнивать с 2010 годом 🙂
Сценарий C2C Pull, то есть опять перевод от человека к человеку, но уже по запросу получателя. Перевод зарплаты из зарплатного банка в любимый банк (ведь удобнее это сделать из приложения любимого банка). Краудфандинг, сбор на подарок или возврат долга.
Лежа на диване, увидел сообщение “Василий П. запросил у Вас 1000 руб”.
Нажал “Ок, перевести”.
Продолжаешь лежать на диване уже с чистой совестью.
Обзор платежной системы FasaPay
FasaPay – относительно новая платежная система, предлагает мгновенный перевод средств по всему земному шару. В начале работы целевой аудиторией компании были резиденты Индонезии, но со временем география работы вышла за пределы этого региона и сейчас FasaPay пользуются и в Европе, и в других регионах мира.
О компании
Компани FasaPay появилась в 2011 году в Индонезии, головной офис находится в Сингапуре. На главной странице есть статистика, согласно которой работа ведется в 197 странах, а клиентами ЭПС стали почти четверть миллиона человек.
Предлагаются стандартные для любой электронной платежной системы возможности:
Комиссии предлагаются умеренные, ограничения по переводам зависят от класса аккаунта, сравнимы с конкурирующими платежными системами. Большое внимание уделяется вопросу безопасности.
Для жителей стран СНГ неудобно то, что FasaPay на русском языке недоступна. Сайт доступен лишь на английском и индонезийском языках. Неудобно и то, что в системе доступно всего 2 валюты – американский доллар и индонезийская рупия.
Условия использования
Все клиенты делятся на 3 категории:
В зависимости от статуса аккаунта отличаются и возможности:
Главное преимущество платежной системы – малые комиссии:
Помимо обычных аккаунтов есть класс счетов «Merchant» – подойдет для тех, кто планирует использовать FasaPay в бизнесе.
Регистрация в системе и начало работы
Для регистрации в системе:
Перед использованием ЭПС вам предложат заполнить форму, в которой нужно будет добавить банк, в котором у вас открыт счет. В форме нет банков, работающих в СНГ, так что это не очень удобно, но можно внести банк, отсутствующий в списке.
В разделе «Profile» нас будет интересовать пункт «Upload ID» – для верификации необходимо загрузить скан паспорта. Причем сделать это можно только в будние дни, на выходные форма для загрузки просто отключается.
Очень серьезное ограничение по работе – принимаются только сканы загранпаспорта, внутренний документ не подойдет. Об этом написано в FAQ и здесь же приведен пример скана. Общие требования стандартные – нужна цветная версия, в фоторедакторах изображение не нужно обрабатывать, необходимо, чтобы были видны уголки документа.
Для повышения статуса аккаунта нужно загрузить скан квитанции об оплате коммунальных услуг или любого другого документа, подтверждающего указанный адрес проживания.
Что касается того, как пользоваться FasaPay, то здесь все стандартно – просто указываете номер кошелька получателя и переводите ему деньги. Либо выводите средства через банк, но пользоваться всем функционалом системы можно только после верификации.
Заключение
На стороне этой платежной системы одни из самых низких (если не самые низкие) тарифы в этом виде бизнеса. На этом преимущества заканчиваются. Можно было бы отметить безопасность, но у конкурентов этому вопросу уделяется не меньшее внимание.
Главные недостатки – поддержка только 2 типов валют и не самая простая верификация. Если у потенциального клиента нет загранпаспорта, то пройти процедуру верификации не получится. Пока что с этой точки зрения предпочтительнее смотрятся другие платежные системы.
Платежная сеть Facebook FastPay оказалась в 7 раз быстрее системы Visa
Команда разработчиков из Facebook Novi — подразделения Facebook, разрабатывающего криптовалютный кошелек — представила новую систему для расчетов транзакций FastPay. Технология подходит для двух направлений: обработки платежей в криптовалюте и поддержки розничных платежей в фиатных валютах. В ходе серии испытаний FastPay обрабатывала более 160 тыс. транзакций в секунду с 20 различными платежными инструментами и установила среднюю скорость подтверждения в 100 миллисекунд.
На реализацию FastPay ушло 2,5 месяца работы с сервером из 96 виртуальных процессоров на базе 48 физических ядер Intel Xeon Platinum и 384 Гб памяти. По словам инженеров, при общей нагрузке в 1,5 млн. транзакций по 48 ядрам, FastPay безошибочно поддерживал все операции, включая запросы на подтверждение и сами транзакции. Задержка составила менее 200 миллисекунд для клиентов на западном побережье США и около 50 миллисекунд для участников из Великобритании, сообщает VentureBeat.
«Система FastPay устраняет кредитные риски и устраняет необходимость в банках-посредниках и сложных финансовых контрактах между ними для поглощения этого риска. FastPay поглощает эти случайные возможности за счет эффективных архитектур сегментирования в каждом процессе», — заявили в Facebook Novi.
В то же время представители компании отметили, что FastPay — это экспериментальная система, которая требует доработки. В FB подчеркнули, что технология уже превосходит отраслевые стандарты с точки зрения производительности и надежности, но процесс проверки и утверждения новых протоколов для платежей занимает много времени. Чтобы доказать прозрачность проекта команда также выложила исходный код FastPay, данные измерений и сценарии поддержки в открытый доступ.
Судя по всему, первоначально FastPay был частью проекта Facebook Libra, который неоднократно менялся в течение последних лет — от единой криптовалюты для всего мира до цифрового мультикошелька с поддержкой стейблкойнов. Сама компания пока не стала рассказывать предысторию появления этого проекта и какие цели перед ним поставлены.
Платежные технологии – просто о сложном. Часть 1
Давайте поговорим о платежных технологиях и что происходит, когда клиент хочет оплатить услугу на сайте или в интернет-Банке, сделать перевод или нам просто необходимо настроить интеграцию с агрегатором, магазином или платежной системой в целях вывода их услуг в своих дистанционных каналах обслуживания.
Здесь будет представлена серия статей, которая поможет начинающим специалистам в ИТ, занимающихся платежными технологиями, ответить на вопрос: «как писать исходящий шлюз с платежной системой или агрегатором», «как решить вопрос с расхождениями при сверках», как реализовать интеграцию с международной платежной системой.
Устраивайтесь поудобнее, будет интересно.
Часть 1: Проведение и подтверждение платежа
Клиент для оплаты услуг как правило авторизуется в интернет-Банке, выпустившим его карту: Банку-Эмитенту его карты.
Далее в интернет-Банке, выбирает услугу для оплаты: пополнение мобильного телефона, оплаты интернета или услуг ЖКУ.
В базе поставщика услуги, например оператора сотовой связи, у клиента есть свой уникальный идентификатор – номер телефона.
Чтобы оплатить услугу клиент вводит свой идентификатор и сумму пополнения, нажимает кнопку «подтвердить платеж».
А дальше ему отображается пред чек с идентификатором пополнения и суммой пополнения. Он подтверждает оплату и далее интернет-Банк отображает ему чек. Клиент радостный уходит. Деньги «моментально» поступают на его номер телефона.
Это для клиента так. А давайте посмотрим, как это выглядит внутри систем.
Наш онлайн обмен сообщениями, будет состоять из нескольких участников:
Витрина – в данном случае, интернет-Банк клиента;
Банк клиента – он же оператор по переводу денежных средств, он же Банк-Эмитент, выпустивший карту клиента, и он же расчетный Банк по переводам средств клиента Сервис-Провайдеру;
Сервис-Провайдер – юридическое лицо, оказывающее услуги зачисления средств Поставщику, его часто называют «Мерчант». Сервис-Провайдер имеет прямые договора со многими поставщиками услуг, и чтобы Банку не настраивать интеграцию с каждым из них, на рынке есть компании-посредники: Сервис- Провайдеры, еще их называют агрегаторами, платежными системами. Они уже настроили интеграцию с Поставщиками услуг и предоставляют большое количество сервисов за определенный процент;
Наш оператор сотовой связи – Поставщик услуг;
И у Сервис-Провайдера и у Поставщика услуг есть свои расчетные Банки. В итоге, Банк Сервис-Провайдера в офлайне перечислит денежные средства на счет Поставщика услуг в целях зачисления на счет клиента. Но об этом в следующих статьях.
Я буду использовать сущности: Банк, Мерчант и Витрина для описания онлайн взаимодействия внутри систем.
Центральной фигурой в нашем взаимодействии является Банк клиента.
У Банка задача не только проверить наличие денежных средств у клиента, но и доставить их Сервис-Провайдеру. Для выполнения этого условия Банк, как правило, пишет два шлюза либо использует текущие:
Входящий: от Витрины к Банку;
Исходящий: от Банка к Мерчанту;
Оба эти шлюза могут работать как по тождественному протоколу, так и по разным.
Мы рассмотрим самый простой вариант: витрина Банка, Банк и Мерчант работают по одному сквозному протоколу, представленному всего двумя методами: check и pay.
Описание процесса проведения и подтверждения платежа в этом случае выглядит следующим образом:
Сиквенс проведения и подтверждения платежа
Описание процесса проведения и подтверждения платежа
Клиент выбирает услугу;
Витрина Банка проверяет наличие услуги у себя в Базе данных;
2.1 Если услуга найдена, формирует запрос в Банк на холдирование денежных средств в Процессинге. Далее формирует запрос на возможность совершение платежа check:
2.2 Если услуга не найдена, завершает процесс ошибкой, клиент уходит;
Витрина инициирует check;
В Банк поступает запрос check. Далее Банк маршрутизирует запрос Мерчанту;
Мерчант принимает запрос, выполняет проверку совершения платежа;
5.1 Если зачисление возможно, отправляет успех, клиенту отображается пречек. Система Банка ожидает подтверждение платежа;
5.2 Если зачисление невозможно, Банк отправляет код ошибки, витрина завершает процесс, проведение невозможно, клиент уходит;
Клиент знакомится с пречеком, нажимает кнопку «подтвердить платеж». Витрина инициирует pay;
Банк присваивает идентификатор транзакции и сразу отправляет ответ на витрину;
Зачисление денежных средств у Мерчанта уже выполняется в офлайне. Банк инициирует pay и, если зачисление возможно, Мерчант присваивает свой идентификатор транзакции и отправляет в Банк успешный ответ. А если зачисление невозможно – спросите Вы? Тогда Мерчант отправляет ответ в Банк с кодом ошибки, и Банк выполняет возврат денежных средств клиенту в автоматическом режиме в тот же день.
Теперь рассмотрит рассмотрим формат запроса и ответа для каждого из методов, за что они отвечают и для чего они нужны
CHECK – проведение платежа
Метод отвечает за возможность совершения платежа. На этом шаге выполняется проверка доступности услуги на витрине, в Банке и у Мерчанта. Мерчант в свою очередь, в онлайне, может сходить к Поставщику и проверить валидность идентификатора пополнения у Поставщика, и, если, он не найден или ошибка, отклонить платеж.
Очень часто на этом шаге закладывают минимальные требования к времени отклика ответа на запрос от Мерчанта, т.к. клиент не будет ждать, пока Витрина Банка, сам Банк и Мерчант проверят доступность услуги.
Отличительной особенностью этого шага является так же расчет комиссии. Комиссии бывают:
Верхняя, или горячая – это комиссия с клиента сверх тела платежа (суммы зачисления);
Нижняя или холодная, это комиссия, которую платит Банку Мерчант;
Смешанная – в этой рубрике мы не будем о них говорить;
В нашем примере на check рассчитывается только комиссия с клиента, нижняя и смешанная комиссии рассчитываются в отдельно. Об этом с следующих статьях.
Структура запроса check/XML, шлюз контура Витрина – Банк:
Time – дата платежа;
type – тип источника списания;
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, шлюз контура Банк – мерчант:
В ответ мерчант сообщает статус обработки транзакции, который может принимать статус успех, в проведении или, если оплата была отклонена, ошибка.
Два статуса финальные, а один промежуточный.
Можно сказать, что на этих статусах обязательства и Банка и Мерчанта перед клиентом завершены.
Да, такое бывает достаточно часто, и для решения этой задачи существует отдельный процесс по запросу финального статуса операции как на стороне витрины, так и на стороне Банка, но об этом в следующих статьях.