payment code что это

Что такое Payment to в Сбербанке?

Очень часто мы сталкиваемся с вопросом от наших читателей, которые интересуются: что такое «Payment to» и почему от его имени приходят переводы на карты Сбербанка? Поясним данную ситуацию.

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

Предложения от Сбербанка:

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

Обратите внимание — таким образом осуществляется перевод именно на банковский счет, а не на карточку, поэтому отследить контакты отправителя через систему «Сбербанк Онлайн» нельзя.

Чаще всего так отображается перевод от какой нибудь организации, к пример:

Таким же образом могут приходить различные пособия, которые вам положены по возрасту или состоянию здоровья. Такое наименование еще встречается при выводе электронных денег на карточку (например, Webmoney или Яндекс.Деньги).

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

Иногда приходят сообщения с похожим обозначением: “Payment From”, которые наоборот обозначают произведенные расходные операции. В некоторых случаях, таким образом помечают выполнение автоплатежа или какого-либо списания. Если вы не уверены, что эти операции проводились с вашего разрешения, уточнить ситуацию можно по телефону 8-800-555-55-50.

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

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

Если вы уже получили логин и пароль, то вам нужно зайти в свой Личный кабинет, найти нужную карточку, на которую поступило зачисление, нажать на её название и в описании выбрать операцию “Заказать выписку”, все способы подробно перечислены этой статье.

Получить выписку можно и по смс на номер 900 с текстом: “ВЫПИСКА XXXX”, где XXXX – последние 4 цифры номера банковской карточки. В ответ придет отчет с 10 последними операциями.

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

Кроме того, есть возможность воспользоваться банкоматом. В главном меню выберите “Выписка о движении средств” (или “История карты” в меню “Информация и сервис”. Эта услуга, как и описанная выше, платная, цена на уровне 10-15 рублей.

Источник

Payment code что это

Откройте возможности нейронного машинного перевода PROMT

PROMT.One (www.translate.ru) – бесплатный онлайн-переводчик на основе нейронных сетей (NMT) для азербайджанского, английского, арабского, греческого, иврита, испанского, итальянского, казахского, китайского, корейского, немецкого, португальского, русского, татарского, турецкого, туркменского, узбекского, украинского, финского, французского, эстонского и японского языков.

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

Изучайте времена и формы глаголов в английском, немецком, испанском, французском и русском языках в разделе Спряжение и склонение. Учите употребление слов и выражений в разных Контекстах. Мы собрали для вас миллионы примеров перевода на разные языки, которые помогут вам в изучении иностранных языков и подготовке домашних заданий.

Источник

payment purpose code

Смотреть что такое «payment purpose code» в других словарях:

Code: Breaker — Code:Breaker Cover of the first volume コード: ブレイカー (Kōdo:Bureikā) Genre Action, School Life, Supernatural, Comedy … Wikipedia

Code of Ur-Nammu — Ur Nammu (seated) bestows governorship on Ḫašḫamer, ensi of Iškun Sin (cylinder seal impression, ca. 2100 BC) … Wikipedia

Payment Card Industry Data Security Standard — The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle cardholder information for the major debit, credit, prepaid, e purse, ATM, and POS cards. Defined by the Payment Card… … Wikipedia

payment — The fulfilment of a promise, or the performance of an agreement. A discharge of an obligation or debt, and part payment, if accepted, is a discharge pro tanto. In a more restricted legal sense payment is the performance of a duty, promise, or… … Black’s law dictionary

Facilitating payment — A facilitating payment is a certain type of payment to foreign officials which is not considered to be bribery according to legislations of some states as well as in the international anti bribery conventions, e.g., coming from the OECD.… … Wikipedia

Card security code — The Card security code is located on the back of MasterCard, Visa and Discover credit or debit cards and is typically a separate group of 3 digits to the right of the signature strip … Wikipedia

Internal Revenue Code section 61 — Section 61 of the Internal Revenue Code (IRC 61, usc|26|61) defines gross income, the starting point for determining which items of income are taxable for federal income tax purposes in the United States. Section 61 states that except as… … Wikipedia

National Electrical Code — The National Electrical Code, 2008 edition The National Electrical Code (NEC), or NFPA 70, is a regionally adoptable standard for the safe installation of electrical wiring and equipment. The NEC, while having no legally binding regulation as… … Wikipedia

Penal Code (Singapore) — The Penal Code of Singapore [Singapore Statute | c ed = 1985] sets out general principles of the criminal law of Singapore, as well as the elements and penalties of common criminal offences such as homicide, theft and cheating. The Penal Code… … Wikipedia

International Financial Services Centre (code) — articleissues orphan = June 2008 unreferenced = June 2008In the Structured Financial Messaging System (SFMS), the Indian Financial System Code (IFSC) is being used as the addressing code in user to user message transmission. The Payment System… … Wikipedia

List of Code Lyoko episodes — This is a list of episodes for the French animated television series, Code Lyoko. The first season has no set viewing order save for the last two episodes, so it is listed by the order in which it aired. The following seasons have their episodes… … Wikipedia

Источник

Платежные технологии – просто о сложном. Часть 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, шлюз контура Банк – мерчант:

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

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

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

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

Источник

Payment Code уже запущена

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

Несмотря на необходимость установки дополнительного оборудования и софта как у покупателя, так и у продавца, PayPalпозиционирует новую систему платежей как более удобную (в сравнении с банковскими картами и наличными деньгами).Расширение доли платежей посредством Payment Code планируется и за счет реализации программ лояльности клиентов –предоставление различных бонусов, скидок и купонов.

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

Апробация услуги Payment Code проводилась на территории Австралии. Итоги тестирования подтвердили работоспособности востребованность новой системы платежей. Полномасштабное развертывание системы запланировано на первый квартал 2014 года. Будет ли доступна услуга на территории России в настоящее время неизвестно. Стратегия PayPal предполагает увеличение своей доли на рынке off-line платежей. Поэтому в качестве перспективного направления развития рассматривается переход от QR-кодов на технологию RFID.

Источник