Перейти к содержимому

Ожидание подтверждения от мерчанта что это

  • автор:

Когда дойдет мой платеж? Прочтите ВНИМАТЕЛЬНО ПРЕЖДЕ ЧЕМ ПИСАТЬ В ПОДДЕРЖКУ!

Обмен по всем онлайн направлениям производится в АВТОМАТИЧЕСКОМ режиме.

Вы можете наблюдать статусы вышей заявки, которые меняются. Статус заявки указан в верхней части самой заявки. Ссылка на заявку приходит к вам в письме при ее создании. Мы просим вас прежде чем писать в поддержку с вопросами “что с моей заявкой” — прочитать нижеследующее:

В первую очередь обновите страницу с заявкой и посмотрите в каком статусе она находится. Статусы заявок и объяснение:

Новая заявка или Принята, ожидает оплаты клиентом — заявка создана, мы еще не получили по ней оплату или получили ее совсем недавно. Необходимо от 5 до 15 минут — чтобы заявка с Новой изменила свой статус. Не нужно писать в техподдержку через 3 минуты — почему еще нет денег.

Ожидание подтверждения от мерчанта — это значит МЫ ПОЛУЧИЛИ ВАШИ ДЕНЬГИ, все в порядке, процесс пошел. Адрес ЗАКРЕПЛЕН и уже не уберется из заявки. Теперь осталось подождать подтверждения сети. Просмотреть количество подтверждений можно по ссылке в заявке. Мы НЕ МОЖЕМ ускорить процесс подтверждений, никак. Это НЕ ЗАВИСИТ от обменного пункта. Это зависит только от скорости работы бтк сети и от комиссии, которую вы выставили за перевод. Нужно просто ждать, вся информация в публичном доступе. Не НУЖНО писать в поддержку и спрашивать “где мои деньги и почему так долго?” это никак не повлияет на скорость их зачисления. Как правило долго деньги идут только когда вы ставите низкую комиссию на перевод. а сеть сильно загружена. В любом случае, рано или поздно транзакция подтвердится. Как только будет необходимое количество подтверждений сети — в течение 10 минут деньги зайдут на карту. До тех пор — просто ждать.

Ожидание подтверждение от модуля автовыплат — это значит, что ваш платеж был успешно зачислен и вам были отправлены деньги на карту. Это промежуточный статус, при котором деньги отправляются на ваши карты. Если вы видите данный статус — это значит что платеж на вашу карту был инициализирован и что вы должны получить его в ближайшее время.
Далее возможны несколько сценариев:
1. В подавляющем большинстве случаев 90% — платеж успешно проходит в течение 3х часов
2. В оставшемся 1% случаев платеж застрянет и либо НЕ проходит, либо проходит с задержкой более 3х часов. Иногда это случается в моменты сбоев на платежном шлюзе или при проведении работ у банков. В этом случае после финализации платежа, при условии, что платеж НЕ ПРОШЕЛ на карту заявка выпадет в статус Ошибка автовыплаты. Данная проблема также случается из-за того, что на любой карте установлены лимиты на прием (о которых вы можете даже не знать) и иногда вы можете упереться в эти лимиты, либо вы просто указываете заблокированную , недействительную или не гривневую, не украинскую карту. После ошибки вам на электронную почту придет письмо, с предложением зайти в заявку и заменить номер карты. Вы заходите по ссылку в заявку, жмете кнопку «проверить заявку», система опишет вам проблему, и вы можете заменить карту. Если вы уверены, что с вашей картой все в порядке, вы можете указать ту же карту и система попробует отправить на нее еще раз. У вас будет три попытки смены карты. Все происходит в полностью автоматическом режиме без участия оператора.
Если вы видите статус «Ошибка автовыплаты» БОЛЕЕ 3х часов, то ТОЛЬКО в этом случае стоит писать в поддержку, но и это не обязательно, так как вероятно заявка в скором времени выпадет в финальный статус, и после этого система предложит вам варианты действий.

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

Если же вы все-таки написали в поддержку, то пожалуйста, в запрос постарайтесь сразу указать номер заяки (емаил, номер карты) и описать проблему. Так мы сможем решить ее максимально быстро. Большое спасибо за содействие.

Статусы заказов в DS-системе

В «1С-Битрикс» существует порядка 20 статусов заказа, но в DS-системе «Огня» задействованы только некоторые из них.

Текущий статус заказа (status, целое число) может принимать следующие значения:

  • 1 — Принят
  • 2 — Обработка на складе
  • 3 — Ожидает подтверждения
  • 4 — Товар забронирован
  • 5 — Готов к отгрузке
  • 6 — Выслан на почту
  • 7 — Оплачен и доставлен
  • 8 — Отказ
  • 9 — Комплектация товара на складе
  • 10 — Злонамеренный отказ
  • 11 — Отправлен с курьером
  • 12 — Отгружен. Ожидаем оплату
  • 13 — Удален

Сразу стоит отметить, что статусы с числовым значением 10 (Злонамеренный отказ) и 12 (Отгружен. Ожидаем оплату) используются только на сайте поставщика и не применяются для DS-заказов «Огней». Статус 1 (Принят) присваивается заказу сразу же после его размещения в системе поставщика, при этом ни мерчанту, ни покупателю не отправляется никаких почтовых уведомлений.

Оставшиеся 10 статусов можно разделить на 3 группы:

  • статусы обработки заказа;
  • статусы заказов в пути;
  • статусы итоговых состояний.

Статусы обработки заказа

2 — Обработка на складе

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

На этом этапе ни мерчанту, ни покупателю не отправляется никаких почтовых уведомлений.

3 — Ожидает подтверждения

Этот статус присваивается заказу в том случае, если для дальнейшей его обработки необходимы какие-то уточнения от покупателя или же действия от мерчанта. Покупатель не определился с размером-цветом товара, указал не полный адрес доставки, не берёт трубку, когда ему звонят менеджеры для подтверждения заказа, и пр. – всё это возможные причины перевода заказа в статус «Ожидает подтверждения». Если на депозите мерчанта недостаточно средств для бронирования и доставки товаров или же на складе нет достаточного количества заказанных покупателем позиций, заказ также переводится в «Ожидает подтверждения».

При присвоении заказу статуса «Ожидает подтверждения» покупатель и мерчант получают следующие сообщения:

Шаблон письма покупателя:

Шаблон письма мерчатна:

9 — Комплектация товара на складе

Этот статус присваивается заказу, как только начинается его комплектация на складе. В этом статусе заказ может находиться до 48 часов.

При присвоении заказу статуса «Комплектация товара на складе» покупатель и мерчант получают следующие сообщения:

Шаблон письма покупателя:

Шаблон письма мерчатна:

4 — Товар забронирован

Этот статус присваивается заказу, когда все товары из него уже зарезервированы, и он находится в шаге от отправки покупателю: остаётся только его упаковать. В этом статусе заказ может находиться до 16 часов.

При присвоении заказу статуса «Товар забронирован» покупатель и мерчант получают следующие сообщения:

Шаблон письма покупателя:

Шаблон письма мерчатна:

5 — Готов к отгрузке

Этот статус присваивается полностью скомплектованному и подготовленному к отгрузке заказу.

При присвоении заказу статуса «Готов к отгрузке» покупатель и мерчант получают следующие сообщения:

Шаблон письма покупателя:

Если покупатель выбрал самовывоз со склада поставщика, к телу письма добавляется:

Если покупатель выбрал курьерскую доставку, к телу письма добавляется:

В остальных случаях к телу письма добавляется фраза:

Шаблон письма мерчатна:

Статусы заказов в пути

6 — Выслан на почту

Этот статус присваивается заказу, переданному сотрудникам Почты РФ или служб доставки PickPoint и DPD для дальнейшей доставки.

На этом этапе ни мерчанту, ни покупателю не отправляется никаких почтовых уведомлений.

Однако, как только служба доставки (Почта, PickPoint, DPD) пришлёт поставщику информацию о присвоенном посылке идентификаторе, система отправит и мерчанту, и покупателю уведомление о том, что заказ находится в пути. Также в этом уведомлении будет указан трек-номер для отслеживания отправления и предоставлена информация о том, как это сделать. Письма для каждой службы доставки разные с учётом специфики этого отслеживания.

11 — Отправлен с курьером

Этот статус присваивается заказу, переданному курьеру для дальнейшей доставки.

При присвоении заказу статуса «Отправлен с курьером» покупатель и мерчант получают следующие сообщения:

Шаблон письма покупателя:

Шаблон письма мерчатна:

Статусы итоговых состояний

7 — Оплачен и доставлен

Этот статус присваивается заказу, переданному покупателю. При этом, если доставка заказа предполагала получение от покупателя оплаты, поставщик получил её и начислил денежные средства на счёт мерчанта.

При присвоении заказу статуса «Оплачен и доставлен» покупатель и мерчант получают следующие сообщения:

Шаблон письма покупателя:

Шаблон письма мерчатна:

8 – Отказ

Этот статус присваивается заказам: 1)от которых отказался сам покупатель; 2)которые так и не были подтверждены покупателем в течение 10 дней после оформления; 3)с заведомо ложными данными для связи/доставки.

При присвоении заказу статуса «Отказ» покупатель и мерчант получают следующие сообщения:

Шаблон письма покупателя:

Шаблон письма мерчатна:

13 – Удален

Этот статус присваивается тестовым, ошибочным и техническим заказам.

При этом ни мерчанту, ни покупателю не отправляется никаких почтовых уведомлений.

Примечание: во всех письмах блоки и формируются с учётом контактных данных покупателя и названия интернет-магазина, в котором сделан заказ. – название магазина, – номер заказа.

Ожидание подтверждения от мерчанта что это

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

Вопросы по заявкам

Делал перевод с Perfect Money, но заявка не меняет статус или удалилась

Возможно, PM заморозил Ваш платеж из-за использования VPN, согласно п.4.8. правил системы PM. https://perfectmoney.com/faq.html

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

Косвенные признаки почему транзакция может попасть на проверку:

  1. Сумма поступает и сразу же снимается.
  2. Переводится около 100% средств.
  3. Необычный вход (другой IP, VPN, браузер).
  4. Частая смена браузера, IP.
  5. Включены не все способы безопасности аккаунта.

Оплатил заявку, когда она будет выполнена?

Регламент проведения операций по автоматическим направлениям: 1-15 минут, по ручным, 15-30 минут в рабочее время сервиса, в некоторых направлениях обмена срок выполнения заявки может быть до 4 часов (смотрите в описании направления обмена).

Оплатил заявку, но она в статусе «Удаленная заявка», что делать?

Если средства с Вас сняты (с карты, кошелька), а заявка находится в статусе «Удаленная заявка», скорее всего, транзакция либо на тот момент не появилась в сети, либо не получила необходимое количество подтверждений, либо была заморожена вашей ПС.
Решение: свяжитесь с технической поддержкой в чате или отправьте письмо на нашу почту, указанную в шапке сайта, с указанием номера вашей заявки (операции) в теме письма и объяснением своей проблемы, прикрепляя хэш транзакции или другой ее идентификатор.
Результат: оператор проверит зачисление по вашей заявке и совершит пересчет с последующей выплатой.

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

Скорость подтверждения зависит от множества факторов, таких как: загруженность самой сети, размер комиссии указанной при переводе, скорость интернет соединения и т.д.
В среднем, подтверждение транзакции длится от 30 минут до нескольких часов. Но иногда подтверждение можно ждать и от 2-х до 14 дней, если сеть перегружена.

Прошло 30 минут, а заявка не выполнена

Если заявка имеет статус «Оплаченная заявка» на протяжении 30 минут и более, убедитесь, что сейчас рабочее время сервиса. Если задержка происходит в рабочее время, напишите нам в чат технической поддержки и мы обязательно проверим в чём проблема.

Заявка в статусе «Ожидание подтверждения от мерчанта»

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

Создал заявку по одному курсу, а пришла сумма по другому

Некоторые направление, например, связанные с приемом/отправкой криптовалют, имеют отличные от других условия обмена: курс обмена криптовалюты фиксируется на момент зачисления средств на наш счет (после подтверждений от сети).

Регистрация и вход

Как произвести обмен?

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

Не приходит ссылка для подтверждения регистрации

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

Криптовалюты

Правила фиксации курса для криптовалют прочитать полностью
Правила зачисления депозитов прочитать полностью

Ожидание подтверждения от мерчанта что это

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

  • «Новая» — заявка создана, но Вы не перешли на страницу оплаты в платежной системе;
  • «Ожидание подтверждения от мерчанта» — заявка создана, но оплата по ней нами еще не получена;
  • «На проверке» — заявка будет выполнена после проверки оператором (такое бывает, если сумма либо счет в заявке не совпадает с реальной суммой либо счетом оплаты);
  • «Оплаченная» — заявка оплачена, оплата к нам поступила и в ближайшее время будет совершена выплата;
  • «Выполненная» — заявка выполнена, средства отправлены на указанные вами реквизиты к получению средств;
  • «Удаленная» — заявка отменена, не оплаченные заявки отменяются автоматически через 15 минут после создания;
  • «Ожидание подтверждение от модуля автовыплат» — ожидание подтверждения выплаты по заявке;
  • «Ошибка автовыплаты» — нам не удалось выплатить деньги по заявке. После данного статуса следует обратиться в поддержку для выяснения причины ошибки;
  • «Ошибочная» — ошибка оплаты по заявке.

wm.money — simple way to change money

Помощь исключительно по E-Mail: [email protected]

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

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

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

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

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

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

Что такое мерчант

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

Что такое «мерчант» и для чего он используется в РФ?

Мерчант – это специальная программа, которая дает возможность через интернет получать платежи с банковских карт и банковских счетов. Она эффективна, надежна и полностью безопасна.

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

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

Мерчант-счет нужен, прежде всего, компаниям, которые осуществляют торговлю товарами и услугами через интернет. К ним относятся:

биржи контента и пр.

Виды мерчант-аккаунтов

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

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

Какие преимущества имеет открытие мерчант-счета:

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

Конфиденциальность и безопасность сделок.

Минимальный риск мошенничества.

Операции обрабатываются за считанные секунды.

Система работает круглосуточно.

Платежный шлюз мерчанта

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

проверяется активность банковской карты;

кодируются данные о совершенной покупке;

данные перенаправляются в процессинговый центр;

если запрос прошел успешно – данные вновь возвращаются на сайт;

пользователь получает подтверждение в проведении транзакции (или отказ).

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

Как открыть Merchant Account

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

Для открытия Merchant Account необходимо выполнить следующие условия:

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

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

на сайте должен быть специальный раздел для регистрации и авторизации пользователей;

необходимо, чтобы сайт был размещен на платном хостинге;

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

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

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

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

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

подробное описание товаров и услуг, предоставляемых организацией;

персональные данные руководителей организации;

комплект регистрационных документов (устав, свидетельство о регистрации, лицензию, учредительный договор);

кредитную историю юридического лица;

сведения об объемах продаж и территории, на которую распространяется деятельность компании;

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

адрес сайта, через который будут проходить платежи.

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

Сервис Google Merchant Center

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

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

Мерчант Центр предлагает очевидные преимущества для интернет-магазинов. Товарное объявление увидят миллионы потенциальных клиентов, а если предложенный товар заинтересует их – уровень продаж интернет-магазина существенно вырастет. Для запуска товарных объявлений необходимо зарегистрироваться в сервисе Google Merchant Center.

Три решения для мгновенного подтверждения биткоин-транзакций

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

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

Централизованное решение

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

Доверенные адреса с мультиподписью

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

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

Открытые транзакции и доверенные серверы

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

Основные преимущества модели с открытыми транзакциями перед Coinbase в том, что серверы, хранящие средства, не могут фальсифицировать получение средств, и этих серверов несколько.

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

Хотите больше новостей? Facebook. Быстрее всех? Telegram и Twitter. Подписывайтесь!

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

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