Утверждено правлением ООО нко



страница1/6
Дата09.07.2019
Размер0.64 Mb.
ТипПротокол
  1   2   3   4   5   6

УТВЕРЖДЕНО





Правлением ООО НКО «Рапида»

Протокол № 09-07/2012

от «09» июля 2012 г.

ИО Председателя Правления



ООО НКО «Рапида»
________________________/Р.В. Козлов






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



























ООО НКО «РАПИДА»
г. Москва
  1. Общие сведения

    1. Определения и сокращения


      определение/Сокращение

      Описание

      Документ

      Письменное уведомление или документ, которым обмениваются Стороны.

      ИС

      Информационная система.

      ПК

      Программный комплекс.

      Плательщик

      Физическое лицо, пользующееся услугами Участника для оплаты оказанных Получателям услуг.

      ППП

      Пункт приема платежей, место ввода первичной информации о платеже на стороне Участника. Обычно является структурным подразделением Участника.

      Правила

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

      НКО

      Общество с ограниченной ответственностью Небанковская кредитная организация «Рапида».

      Сторона

      Одна из сторон Договора, т.е. либо Участник, либо НКО.

      Счет Участника

      Банковский счет, который Участник, являющийся кредитной организацией, открывает в НКО.

      ТСП

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

      Платеж

      Операция по внесению денежных средств Плательщиками для последующего перевода

      Участник

      Организация, заключившая с НКО Договор.
    2. Назначение документа


Документ предназначен для описания общей концепции информационного взаимодействия НКО и Участника. В документе содержатся ссылки на протоколы и инструкции, уточняющие представленные общие описания.
  1. Концепция взаимодействия сторон


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

Заинтересованные лица процесса:



  • Плательщик – заинтересован в оплате услуг ТСП. Наиболее удобный способ оплаты дня него – воспользоваться услугами Участника.

  • Участник – заинтересован в оказании Плательщику услуги оплаты за вознаграждение. Не готов подстраиваться под каждого ТСП, в пользу которого может быть совершен платеж, заинтересован переложить взаимодействие с ТСП на сторону Рапиды.

  • НКО – заинтересована в предоставлении ТСП и Участникам услуги стандартного интерфейса проведения оплат за вознаграждение. Таким образом, для Участника выступает в роли единого получателя всех видов оплат, для ТСП – в роли единой однородной сети сбора оплат.

  • Получатель (ТСП) – заинтересован в сборе оплат с Плательщиков. Не готов самостоятельно организовывать сеть сбора оплат, заинтересован переложить организацию на сторону НКО.

Статическая схема взаимодействия заинтересованных лиц представлена на рисунке 1.

Рис. 1. Статическая схема взаимодействия заинтересованных лиц.

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

    1. Передача информации о платеже


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

  1. Плательщик производит оплату в пользу Получателя у Участника.

  2. Участник учитывает оплату в своей ИС.

  3. Участник передает информацию о платеже НКО.

  4. НКО учитывает оплату в своем ПК.

  5. НКО передает информацию о платеже Получателю.

  6. Получатель производит зачисление платежа в своей ИС.

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

Рис. 2. Схема последовательности взаимодействия заинтересованных лиц при передаче информации о платеже на обобщенном уровне.



Для передачи информации о платежах от Участника в НКО существует несколько схем взаимодействия:

  1. Одношаговая схема – включает в себя только передачу информации о платеже от Участника НКО после приема денежных средств от Плательщика. Данная схема является наиболее простой и характеризуется:

  • повышенной скоростью по причине простоты структуры взаимодействия;

  • пониженным риском отказов программно-технических средств сторон взаимодействия по той же причине;

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

  • пониженным удобством использования для Плательщика и Участника:

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

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

  • Участнику затруднительно принимать платежи, когда есть сложности с возвратом денежных средств в случае неуспешной оплаты (например, в платежных терминалах).

  1. Двухшаговая схема – дополняет передачу информации о платеже предварительной проверкой, в процессе которой НКО на своей стороне и, возможно, на стороне ТСП проверяет параметры потенциально оплаты и разрешает или запрещает Участнику прием оплаты. Благодаря этой мере, двухшаговая схема характеризуется:

  • пониженным риском передачи ошибочной информации о платежах по причине наличия дополнительной проверки;

  • повышенным риском отказа программно-технических средств сторон взаимодействия по причине усложнения схемы;

  • возможным понижением скорости взаимодействия по той же причине;

  • несколько большим удобством использования для Плательщика и Участника:

  • Участник получает возможность резко снизить риск неуспешных оплат, а значит резко снижается необходимость в возврате денежных средств Плательщику и связанная претензионная работа уменьшается до приемлемого уровня;

  • все еще нет поддержки повторного использования параметров платежа на уровне самого сценария;

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

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

  • наименьшим риском передачи ошибочной информации, поскольку в общем случае большая часть параметров платежа уже проверена ранее успешными оплатами или определена самим ТСП.

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

  • скоростью, сравнимой с двухшаговой схемой – непосредственно при оплате схема аналогична двухшаговой и даже может превосходить ее в скорости благодаря меньшим объемам передаваемой информации.

  • наибольшим удобством использования для Плательщика:

  • есть возможность повторно использовать повторяющиеся параметры платежа.

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

Наглядное представление о различиях схем может дать рисунок 3.

Рис. 3. Отличия схем оплаты.

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

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

Оплата по Коду требования рекомендуется при наличии достаточно большого объема параметров платежа, допускающих повторное использование (например, для осуществления переводов в банки). Так же оплата по Коду требования рекомендуется при наличии возможности переложить работу по определению параметров платежа на Получателя (например, при оплате заказов интернет-магазинов).

Взаимодействие Участника и НКО по одношаговой и двухшаговой схеме описано в документе «Протокол приема платежей «Платежи».

Взаимодействие Участника и НКО по Коду требования описано в документе Протокол приема платежей «Переводы по коду требования

Документы расположены по адресу: http://soft.rapida.ru


      1. Проверка параметров оплаты


Этап проверки оплаты используется в двухшаговой схеме и оплате по Коду требования для того, чтобы НКО могла гарантировать Участнику успешное проведение оплаты.

Главный сценарий проверки параметров оплаты:



  1. Участник получает от Плательщика параметры платежа или Код требования.

  2. Участник отправляет параметры или Код требования на проверку в НКО.

  3. НКО удостоверяется в корректности параметров платежа по внутренним правилам.

  4. НКО удостоверяется в корректности параметров платежа при помощи проверки на стороне ТСП.

  5. НКО оповещает Участника об успешной проверке.

  6. Участник приступает к проведению оплаты.

Возможные расширения:

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

4а Для платежей в сторону данного Получателя не нужны внешние проверки – процесс продолжается с шага 5 главного сценария.

4б Для платежей в сторону данного Получателя нужна внешняя проверка, но в данный момент ИС Получателя недоступна:

4б1 НКО оповещает Участника о технических проблемах на своей стороне или не отвечает в рамках отведенного промежутка времени.

4б2 Участник считает такой результат неуспешным и действует по аналогии с расширением 3а.

4б2а Участник считает такой результат успешным, процесс продолжается с шага 6 главного сценария.

Схема проверки параметров оплаты представлена на рисунке 4.



Рис. 4. Схема проверки параметров оплаты.


      1. Проведение оплаты


Этап проведения оплаты является наиболее важным при взаимодействии Участника и НКО, именно в рамках него достигается основная цель взаимодействия – передача информации о платежах от Участника НКО.

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

Главный сценарий проведения оплаты:


  1. Участник принимает платеж у Плательщика. В состав платежа входят денежные средства и параметры платежа (для двухшаговой схемы параметры платежа уже предоставлены ранее в рамках проверки параметров).

  2. Участник регистрирует оплату в своей ИС для последующей сверки с НКО.

  3. Участник отправляет параметры платежа в НКО с запросом проведения оплаты.

  4. НКО удостоверяется в корректности параметров платежа по внутренним правилам.

  5. НКО выполняет проведение платежа. Проведение платежа обычно включает проведение его на стороне Получателя с проверками по правилам Получателя, но не обязательно.

  6. НКО сообщает Участнику об успешном проведении платежа.

  7. Участник фиксирует оплату как успешную для последующей сверки с НКО.

  8. Участник выдает Плательщику чек.

Возможные расширения:

3а Участник может выдавать чек Плательщику не на шаге 8, а до отправки параметров платежа в НКО. Например в рамках двухшагового сценария была успешная проверка и Участник считает это гарантией успешного проведения платежа. В остальном сценарий остается неизменным.

4а НКО выявляет ошибку в параметрах платежа:

4а1 НКО оповещает Участника об ошибке.

4а2 Участник фиксирует оплату как неуспешную для последующей сверки с НКО.

4а3 Участник возвращает денежные средства Плательщику.

5а Проведение платежа прошло неуспешно – обработка происходит по аналогии с расширением 4а.

6а У НКО возникают временные сложности с проведением платежа ( Получатель временно недоступен, ошибка в ПК НКО и т.д.), в результате чего платеж становится в очередь для проведения:

6а1 НКО сообщает Участнику о задержке или не отвечает в отведенные для этого сроки.

6а2 Участник повторно отправляет те же параметры оплаты, т.е. процесс продолжается с шага 3 главного сценария.

6а2а Участник считает такой ответ успешным, процесс продолжается с шага 7 главного сценария.

6а2б Участник считает такой ответ неуспешным, процесс продолжается с шага 4а2.

Схема проведения оплаты представлена на рисунке 5.

Рис. 5. Схема проведения оплаты.


      1. Регистрация шаблона


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

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

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

Главный сценарий регистрации шаблона платежа:



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

  2. Участник успешно регистрирует Плательщика в НКО по предоставленным параметрам.

  3. Участник получает у Плательщика параметры оплаты.

  4. Участник производит успешную регистрацию шаблона платежа.

Возможные расширения:

1а Плательщик производит оплату по шаблонам не первый раз

1а1 Участник получает у Плательщика Код требования

1а1а Плательщик не знает Код требования и в пользу текущего Получателя еще не платил – процесс продолжается с шага 3 главного сценария.

1а1б Плательщик не знает Код требования, но уверен, что шаблон платежа у него есть – Участник запрашивает у НКО список шаблонов по данному Плательщику и, если среди них есть нужный, продолжает процесс с шага 1а2, если нет, то с шага 3 главного сценария.

1а2 Процесс регистрации заканчивается за ненадобностью, далее Участник может произвести проверку параметров оплаты используя параметры шаблона, идентифицированные полученным Кодом требования и, в случае успеха, произвести оплату.

3а. Плательщик, Участник не знают, какие именно параметры у платежа для данного Получателя:

3а1 Участник получает у НКО параметры шаблона платежа для данного Получателя.

3а2 Процесс продолжается с шага 3 главного сценария.

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

Схема регистрации шаблона представлена на рисунке 6.




Рис. 6. Схема регистрации шаблона.

    1. Каталог: media -> documents
      documents -> Техническое задание предмет запроса котировок, начальная (максимальная) цена договора
      documents -> Как смотреть видео онлайн Что нужно
      documents -> Техническое задание предмет запроса котировок, начальная (максимальная) цена договора
      documents -> Техническое задание предмет запроса котировок, начальная (максимальная) цена договора
      documents -> Техническое задание предмет запроса котировок, начальная (максимальная) цена договора
      documents -> Техническое задание предмет запроса котировок, начальная (максимальная) цена договора
      documents -> Громкоговоритель воспроизводит звук с искажениями (хрип, дребезг) Передние двери


      Поделитесь с Вашими друзьями:
  1   2   3   4   5   6


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница