RU2718973C2

RU2718973C2 - Способ и устройство для предоставления шлюза электронной транзакции

Info

Publication number: RU2718973C2
Application number: RU2016119160A
Authority: RU
Inventors: Алексзандер Энтони КАПУРРО
Original assignee: Изи Пэймент Гейтуэй Лтд
Priority date: 2015-06-04
Filing date: 2016-05-18
Publication date: 2020-04-15
Also published as: RU2016119160A3; US10664810B2; US20160358130A1; EP3101603A1; IL245195A0; RU2016119160A; CN106251131A

Abstract

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

Description

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

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

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

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

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

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

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

- отображения выбираемых данных, представляющих упомянутые модули и наборы правил в упомянутом рабочем пространстве;

- предоставления пользователю возможности конфигурирования визуального представления рабочего потока посредством:

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

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

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

и

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

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

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

Устройство может содержать машину обработки и модуль бэк-офиса (back office), при этом упомянутый модуль бэк-офиса выполнен с возможностью предоставления упомянутого интерфейса пользователя, а упомянутая машина обработки выполнена с возможностью выполнения упомянутого преобразования сконфигурированного пользователем рабочего потока в исполняемый код маршрута данных транзакции. Машина обработки и упомянутый модуль бэк-офиса могут быть коммуникативно связаны для двусторонней связи через услугу REST. В примерном варианте осуществления, предварительно определенные упомянутые наборы правил и упомянутые модули могут быть сохранены в базе данных доступной посредством упомянутой машины обработки и/или упомянутого модуля бэк-офиса.

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

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

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

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

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

- отображают выбираемые данные, представляющие упомянутые модули и наборы правил в упомянутом рабочем пространстве;

- предоставляют пользователю возможность конфигурирования визуального представления рабочего потока посредством:

и

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

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

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

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

- Решения могут быть сконфигурированы, чтобы быть показанными покупателям на основании их страны и валюты.

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

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

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

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

Фигура 1A является принципиальной структурной схемой, иллюстрирующей общее представление платформы управления транзакциями, включающей в себя устройство в соответствии с примерным вариантом осуществления настоящего изобретения;

Фигура 2 является принципиальной структурной схемой примерного модуля Web-Кассира для использования в системе на Фигуре 1;

Фигура 3 является принципиальной схемой, иллюстрирующей поток данных транзакции в системе на Фигуре 1;

Фигура 4 является снимком с экрана, иллюстрирующим работу редактора рабочего потока для использования в устройстве в соответствии с примерным вариантом осуществления настоящего изобретения;

Фигура 5 является принципиальной блок-схемой, иллюстрирующей типичный поток транзакции в системе на Фигуре 1;

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

Фигура 7 является снимком с экрана редактора правил Бэк-офиса для использования в устройстве в соответствии с примерным вариантом осуществления настоящего изобретения;

Фигура 8A является схематичным высокоуровневым представлением устройства в соответствии с примерным вариантом осуществления настоящего изобретения; и

Фигура 8B является принципиальной схемой, иллюстрирующей способ, посредством которого работает машина шлюза примерного варианта осуществления настоящего изобретения.

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

Обращаясь к Фигуре 1 чертежей, приложение транзакции, включающее в себя электронную систему шлюза в соответствии с примерным вариантом осуществления настоящего изобретения, может быть рассмотрено, как содержащее четыре основных компонента, а именно Web-кассира 10, Платежную Машину 12, Бэк-офис 14 и Базу 16 Данных.

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

В целом (и как будет описано более подробно в данном документе), Web-кассир 10 является автономным фрагментом программного обеспечения, который принимает запрос участников/покупателей (например, внесение) с web-сайта Торговца, проверяет пересылаемые данные, осуществляет связь с соответствующей услугой или платежным способом через его конкретный API, в свою очередь принимает одобренную или отказанную связь и записывает данные полного процесса и исход (бэк-офис).

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

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

Вновь обращаясь к Фигуре 1 чертежей, как показано, модули Web-кассира 10 и Бэк-офиса коммуникативно связаны с Платежной Машиной 12 посредством соответствующей услуги REST. REST означает Передачу Состояния Представления и основано на не запоминающем состояние, клиент-серверном, кэшируемом протоколе связи, при этом в данном случае (и виртуально во всех других случаях) используется протокол HTTP. REST будет знаком специалисту в соответствующей области техники в качестве архитектурного стиля для разработки сетевых приложений, причем идея состоит в том, что вместо использования сложных механизмов для соединения между машинами, простой HTTP используется для осуществления вызова между машинами. Соответствующие услуги REST, предоставленные в вышеупомянутых модулях, используют запросы HTTP, чтобы сообщать данные (создавать и/или обновлять), считывать данные (например, делать запросы), и (где уместно) удалять данные.

Платежная Машина 12 и Бэк-офис 14 соединены с базой 16 данных через интерфейс прикладной программы DAO (Объекты Доступа к Данным), который будет известен специалисту в соответствующей области техники.

Web-кассир 10 предоставлен в системах, где требуется предоставлять автоматизированную услугу (например, онлайновую) без присутствия пользователя, тогда как функция 18 Прямого Вызова, или интерфейс прикладной программы Прямого Соединения (DC-API), может быть использован в случае ‘нормального’ кассира или терминала точки продажи. Система может включать в себя одну или обе из этих опций, в соответствии с приложением и предпочтениями пользователя, и не обязательно подразумевается, что настоящее изобретение ограничено в этом отношении.

Web-кассир 10 может быть рассмотрен в качестве элемента верхнего уровня всей системы, и предоставляет интерфейс для торговца, чтобы позволить конечному пользователю (т.е., покупателю) осуществлять платежи и разнообразные другие операции (например, просмотр прошлых транзакций). Web-кассир является, сам по себе, законченным приложением MVC (Модель-Вид-Контроллер), которое использует Машину 12 в качестве ‘моста’ чтобы осуществлять доступ к базе 16 данных и извлекать данные, требуемые для представления требуемой информации, например, платежных способов доступных для конкретной конфигурации. Обращаясь к Фигуре 2 чертежей, структура Web-кассира 10, и способа, посредством которого он осуществляет связь с другими модулями системы, приведены в качестве примера.

Как схематично иллюстрируется, web-услуги 20 используются внутри Web-кассира 10, чтобы предоставлять требуемую гибкость для создания сложных потоков по запросу (как будет описано более подробнее позже). Web-кассир 10 осуществляет связь со слоем 22 REST, чтобы выполнять требуемые операции через машину 12, используя средний слой. Машина 12 будет освещена более подробно позже.

Web-кассир 10 имеет четыре принципиальных режима использования в своей стандартной конфигурации, а именно Внесение, Отзыв, Управление Платежом и Ожидающие Снятия. Тем не менее, следует иметь в виду, что в дополнение к этим четырем режимам по умолчанию, другие процессы также могут быть обработаны Web-кассиром, включая, например, извлечение списка способов Платежа, обработка истечения сеанса, идентификация браузера, в котором отображается приложение, и локализация. Тем не менее, сами по себе процессы транзакции делегируются Машине 12, так что Web-кассир является относительно простым слоем представления.

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

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

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

- Список торговцев;

- Страница ошибки по умолчанию для показа покупателю, когда они соединяются с конкретным торговцем;

- Общая страница ошибки по умолчанию, чтобы указать покупателю, что не может быть найдена информация о сеансе; и

- Для каждого из торговцев, имя оболочки, ассоциированное с этим торговцем.

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

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

- Идентификатор для Торговца.

- Имя покупателя.

- Фамилия покупателя.

- Дата регистрации покупателя.

- Язык на котором покупатель должен совершать сделки.

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

- Валюта.

- Страна покупателя.

- Контрольная сумма вызова.

- Уникальный идентификатор для сеанса клиента. Рекомендуется, чтобы это ссылалось не на id сеанса, который автоматически обеспечивается посредством java или любого другого языка, а наоборот это может быть уникальной произвольной строкой, которая не является последовательной, которая прикрепляется к сеансу клиентов.

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

- Любые комментарии к счету, прикрепленные к счету клиента – опционально

- Платежное Решение – Платежное решение к которому переслать покупателя. Если операция не является «ВНЕСЕНИЕМ» или «СНЯТИЕМ» должно быть выдано предупреждение – опционально

- Сумма – Числовое значение в валюте счета, в которой вошли. Если сумма заполнена а операция не установлено как «ВНЕСЕНИЕ» или «СНЯТИЕ» в ответ должна возвращаться ошибка. Если данное значение заполнено и операция указана корректно, тогда покупатель будет делать быстрое внесение или снятие. Ожидается, что это будет использовано в первую очередь в случае розничных транзакций. Это главным образом означает, что поле суммы будет предварительно заполнено и будет показан соответствующий шаблон страницы внесения/снятия.

- Id счета покупателя

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

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

- Версия – т.е. версия вызываемого вызова API (чтобы гарантировать то, что принятый формат результата совместим с используемой версией).

Таким образом, когда пользователь желает открыть кассира, Торговец будет выполнять вызов ко Внутреннему API, который в Платежной Машине с помощью информации пользователя (Id Пользователя, IP Пользователя, Страны, Валюты, Языка…), внутренний API будет создавать запись реестра с данной информацией и также генерировать уникальный одноразовый маркер, который будет предоставлен Торговцу. Торговец будет иметь возможность перенаправить пользователя к кассиру, используя данный маркер (который будет зашифрованным маркером сеанса, связанным с IP пользователя). Когда вызывается Web-кассир, то первым, что должно быть сделано, будет извлечение маркера, проверка того, что пользователь прибывает из правильного IP, и затем извлечение уязвимых данных, которые хранятся в системе. Также может быть сделан резерв, чтобы убедиться в том, что запрос исходит не от машины пользователя, вот почему торговец ранее выполнил операцию маркера запроса.

Эти маркеры хранятся в базе данных и связаны с конфигурацией пользователя (Id Пользователя, IP, Страна, Валюта, Язык …). Кассир использует данную информацию, чтобы представлять соответствующие страницы и операции доступные покупателю на основании возвращаемой конфигурации.

Фигура 3 показывает циклограмму того, каким образом торговец запрашивает экземпляр кассира. После начального вызова Машина должна перенаправить покупателя к URL внутри кассира; пересылая идентификатор вызова предварительного входа в систему, ассоциированный с данным покупателем

Пример: http://merchanturl.cashier.com/cashier?token=2342ksdfls

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

Данный способ двойных секретов обеспечивает безопасный вход в систему без вмешательства с третьей стороны. Это также предотвращает использование перенаправления URL любым другим покупателем, поскольку присутствует зависимость от сеанса. Кассир EPG может быть загружен внутрь объекта iframe или может быть полностью автономным. Инфраструктура кассира является 100% настраиваемой посредством торговца и также является дружелюбной и восприимчивой к мобильным устройствам.

Извлечение Конфигурации

Если подходящая конфигурация для торговца уже кэширована и кэш находится в пределах срока действия, тогда не будет выполнен вызов к Машине для конфигурации торговца. Если детали не кэшированы в памяти, или истек срок действия, тогда будет выполнен вызов к Машине в отношении соответствующих деталей торговца, пересылая merchantId, волюту и страну. Данный вызов вероятно будет выполнен через REST. Как только принимается ответ, он будет кэширован в памяти на отведенное время. Отметим, что вызов лишь извлекает конфигурацию для Торговца в текущей Стране и Языке торговца; это так, потому что нам не требуется загружать ненужные данные в систему.

Ответ Конфигурации

Успешный результат может иметь следующие детали.

- merchantId, на который ссылается данная конфигурация.

- Валюта, на которую ссылается данная конфигурация.

- Страна, на которую ссылается данная конфигурация.

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

Допускается ли оно (отметим, что если валюта не допускается для либо внесений, либо снятий, оно должно быть опущено в данном списке полностью)

Максимальная транзакция, которая может быть выполнена.

Минимальная транзакция, которая может быть выполнена.

Допускается ли конвертация валюты для данного способа?

Требуется ли конвертация валюты для данного способа?

В какую волюты она может быть конвертирована? – требуется, когда конвертация валюты является опцией

Какова комиссия за конвертацию валюты? – требуется только, когда конвертация валюты является опцией

Любые ожидающие снятия.

Конфигурация вида и ощущения кассира.

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

Как объяснено выше, основная техническая задача, которую стремятся решить разнообразные аспекты настоящего изобретения, состоит в том, каким образом выполнять онлайновую конфигурацию (и/или повторную конфигурацию) маршрутизации данных транзакции, по существу, в режиме реального времени, без необходимости выходить офлайн в целях компиляции. В частности, система в соответствии с примерным вариантом осуществления настоящего изобретения предоставляет, единый, конфигурируемый электронный шлюз для нескольких способ транзакций и/или платежных решений из единой платформы, при этом параметры и условия в отношении каждого маршрута транзакции могут быть выборочно и независимо сконфигурированы и/или повторно сконфигурированы, без необходимости в переброске какого-либо кода программного обеспечения. Это достигается в данном примерном варианте осуществления настоящего изобретения посредством использования так называемых рабочих потоков, которые, по существу, содержат ‘дорожную карту’, которая говорит Машине, что делать и какому пути данных следовать для каждого заданного запроса транзакции. Пользователи имеют возможность конфигурировать и повторно конфигурировать такие рабочие потоки и могут, по характеру методологии, предлагаемой в данном документе, быть настолько простыми или настолько сложными как того требует приложение. Интерфейс пользователя, предоставляемый посредством разнообразных аспектов настоящего изобретения, относительно прост в использовании, и в одном примерном варианте осуществления, пользователь может просто ‘перетаскивать’ модули на экран и связывать их с другими модулями, чтобы создавать визуальное представление требуемого рабочего потока. В дополнение, пользователь может связывать модули и потоки с наборами правил, так что поток может быть создан с несколькими внутренними маршрутами, основанными на решениях и исходах определенных наборов правил.

Фигура 4 иллюстрирует снимок с экрана рабочего потока, создаваемого, используя примерный вариант осуществления настоящего изобретения. Может быть видно, что процесс создания рабочего потока начинается с модуля 100 начала набора правил, который соответствует конкретному запросу транзакции (в данном случае, Внесение кредитной Карты). Два блока 102 набора правил предоставлены в определенном наборе правил и ‘связаны’ с модулем начала набора правил посредством соответствующих стрелок 104a, 104b. Может быть видно, что в данном конкретном рабочем потоке, существует два правила валюты, исход которых определяет внешнюю платежную услугу, которая должна быть использована для транзакции. Таким образом, если транзакция осуществляется в GBP, рабочий поток следует потоку левой руки и связан с модулями 106b, 108b авторизации и захвата первого поставщика услуги. Если транзакция осуществляется в Евро, рабочий поток следует потоку правой руки и связан с модулями 106a, 108a авторизации и захвата второго поставщика услуги.

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

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

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

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

Машина Рабочего Потока, включенная в Бэк-офис, включает в себя редактор рабочего потока, который предоставляет интерфейс пользователя, который позволяет пользователю просто и быстро конфигурировать и повторно конфигурировать рабочие потоки, используя визуальные элементы отображения, включающие в себя модули и наборы правил, и связывать их вместе интуитивно понятным образом. Фигура 6 показывает маршрут транзакции созданный посредством вышеупомянутого редактора рабочего потока для торговца. Торговцы могут очень просто создавать такие рабочие потоки посредством перетаскивания подходящего окна действий на основной ‘холст’. Правила создаются используя простой интерфейс (смотри Фигуру 7), где условия могут быть созданы, используя любой параметр хранящийся в базе данных или пересылаемый посредством торговца через интерфейс прикладной программы (API). Линии нарисованы чтобы соединить каждое окно действия с подходящим набором правил.

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

- Маршрутизация по Наименьшей Стоимости

Маршрутизация транзакций может быть осуществлена к нескольким эквайерам на основании стоимости обработки

- Маршрутизация Основанная на Объеме

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

- Круговая система

o Маршрутизация транзакция может быть осуществлена к разным эквайерам на основании счетчика

- Проверки Идентичности

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

- Отказы

o Маршрутизация транзакция может быть осуществлена к разным эквайерам или альтернативным решениям на основании отказов. Другими словами, если эквайер осуществляет отказ, может быть предпринята попытка с тем же самым запросом в режиме реального времени с другим/несколькими эквайерами

- Сторонние Платформы

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

- Базы Данных Отчетности

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

- Завершения при Сбое

o Разные эквайеры или платежные решения могут быть связаны с одним потоком в случае завершения при сбое.

- Альтернативные Решения

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

Высокоуровневое представление архитектуры Машины иллюстрируется на Фигуре 8A чертежей. Важно отметить здесь, что Web-кассир может находиться в другой машине, полностью отдельно от остальной части системы, при этом данный вид решения зависит от стратегии развертывания торговца. Мы рекомендуем наличие кассира на отдельной машине так как в случае возникновения атаки на услугу, экземпляр кассира, испытывающий нападение (мы можем иметь несколько экземпляров без каких-либо проблем), может быть отсоединен и поток может продолжаться не оказывая влияния на базовую систему. Таким образом, когда Модуль Услуг REST принимает вызов, он анализирует информацию, подтверждает, что все требуемые поля для стандартной транзакции на месте, и если все идет хорошо, он вызовет машину, которая будет отвечать за выполнение операций.

Машина Рабочего Потока

Существует четыре принципиальные концепции основанные на том, каким образом машина системы шлюза в соответствии с примерным вариантом осуществления настоящего изобретения работает:

- Этапы: Исполнение операции адаптера, подобной Авторизации Кредитной Карты, где Кредитная Карта является адаптером, а Авторизация является Операцией.

- Правила: Каждое из правил, которое может быть определено через запрос или результат каждого этапа (например, валюта является GBP, сумма больше 100, выбранный платежный способ является Кредитная Карта или даже результат параметра Код из верификации зачисления протокола 3D Secure соответствующий Да, являются примерами правил)

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

(В случае, когда мы имеет два с одинаковым приоритетом, то так как в базе данных они упорядочены, мы будем брать первое, которое встречается в списке).

- Связи: Связь между двумя этапами, определяет путь по которому следовать, если применяется набор правил

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

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

- Используя RequestBean (т.е. входные данные системы), который поступает от RestService, выполняется итерация по наборам правил, чтобы проверить, имеется ли какой-либо из них, который может быть сопоставлен с введенным запросом. В данном случае, может наступить один из двух сценариев:

o Если запрос не может быть сопоставлен, возникает ошибка, поскольку ожидается, что система способна обрабатывать все запросы; или

o Присутствует сопоставление, и тогда будет выполнен этап. Для этого, осуществляется доступ к адаптеру и выполняется операция (обе сущности заявлены в Этапе)

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

Графически, в Бэк-офисе (т.е. части системы, которая отвечает за создание потоков, этапов, правил, набора правил и связей), описанный выше процесс будет выглядеть подобно снимку с экрана, показанному на Фигуре 8B.

Интеграция Бэк-офиса

Бэк-офис сам по себе имеет свою собственную Услугу REST и Машину Бэк-офиса и отвечает за создание и управление всеми компонентами, как продиктовано бэк-офисом, осуществляя диалог непосредственно с DAO. Иногда бэк-офису может потребоваться выполнение некоторых операций через систему в режиме реального времени, подобно скидке например, вот почему присутствует связь между Машиной Бэк-офиса и Услугами REST для машины. Это обеспечивает возможность исполнения операций в режиме реального времени через бэк-офис. Бэк-офис и основная машина таким образом могут быть разъединены, поскольку не требуется чтобы бэк-офис был развернут там, где Машина. Наиболее важная мысль касательно данной примерной инфраструктуры состоит в том, что способ, посредством которого она разрабатывается, является независимым от сервера, на котором она будет работать. Отсутствует зависимость от каких-либо библиотек, предоставляемых Сервером Приложений (или Контейнером Сервлетов в случает Tomcat), библиотеки могут быть предоставлены на заказа.

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

Исполнение Базы данных

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

Доступ к этим данным может быть доступен только для платформы EPG через зашифрованные пароли и безопасные соединения. Торговцы будут иметь возможность осуществления доступа к этим данным через бэк-офис, тем не менее, некоторые данные будут ограничены для конкретных типов учетной записи. Таким образом, торговцы будут иметь возможность создания учетных записей бэк-офиса для их внутренних пользователей на основании разных уровней безопасности. В некоторых примерных вариантах осуществления, лишь некоторые процессы будут иметь возможность чтения и записи в базу данных, тем самым в значительной степени ограничивая то, что именно имеет доступ к этим данным. Даже эти процессы будут иметь возможность осуществлять доступ к базе данных только, если они предоставляют требуемые мандаты и вызов выполняется с безопасного и допустимого IP-адреса. Это будет гарантировать то, что связь между разными компонентами внутри платформы является безопасной и также будет содействовать предотвращению любых внешних атак или нарушений. Использование схемы «звезды» предоставляет возможность использования одной главной таблицы транзакций (таблицы фактов), которая содержит каноническую модель данных платежей и услуг и обеспечивает возможность быстрой отчетности. Данная таблица будет связана с многими другими таблицами (измерениями), которые будут дополнительно расширять модель данных транзакции. Однако более важно, что из-за характера исполнения схемы и того факта, что может быть предложено много таблиц измерения, как например таблица даты, торговцы будут иметь возможность запуска обширных отчетов, используя любые или все данные, предоставленные в нашей базе данных, без необходимости в сложных операторах sql. Каноническая модель используется во всей платформе и делает ее более легкой и более простой для обхода платформы, так как только конкретные детали платежа или счета запрашиваются, когда и если они требуются.

Специалисту в соответствующей области техники следует иметь в виду, что функциональность предложенной системы может быть реализована в некотором количестве разных способов, и не обязательно подразумевается, что настоящее изобретение ограничено в этом отношении. Тем не менее, для законченности, предусматривается, что Spring Security, инфраструктура Java EE, которая предоставляет аутентификацию, авторизацию и другие признаки обеспечения безопасности, может быть использована, чтобы управлять аспектами безопасности системы шлюза в соответствии с примерным вариантом осуществления настоящего изобретения. Предполагается, что система шлюза выполняет высокоуровневое управление и шифрование операций и это может быть подвергнуто ревизии. Пароли шифруются в рамках примерных вариантов осуществления системы, используя например односторонние алгоритмы шифрования (SHA1) и может быть предоставлено широкое управление доступом к потоку. HTTPS, блокирование IP-адреса, сертификаты SSL и проверки целостности также могут быть использованы для осуществления доступа к интерфейсу прикладной программы шлюза.

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

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

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

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

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

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

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

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

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

В некоторых примерных вариантах осуществления, система может предлагать отчетность в режиме реального времени как впрочем и планируемую отчетность применительно к предварительно определенным отчетам, которые могут быть загружены в, например, формате HTML, PDF, CSV или Excel.

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

Система может быть выполнена с возможностью предлагать полный поиск транзакций и полный просмотр деталей транзакции.

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

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

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

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

Система может предлагать замещение уязвимого элемента данных неуязвимом элементом данных (токенизация) для кредитных карт, ограничивая уровень PCI, требуемый торговцем; она также может предлагать Виртуальный Терминал, который позволяет торговцам выполнять MOTO (Заказ по Почте и Заказ по Телефону)-транзакции от лица их покупателей.

Платформа может быть выполнена с возможностью осуществления доступа через непосредственный API или через API перенаправления.

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

Claims

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

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

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

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

упомянутый модуль Web-Кассира сконфигурирован для предоставления пользователю возможности выбирать рабочий поток платежей и передавать данные запроса, представляющие его, в упомянутую машину обработки рабочего потока платежей;

упомянутая машина обработки рабочего потока платежей дополнительно сконфигурирована для:

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

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

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

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

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

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

5. Система по п. 1, в которой упомянутый модуль бэк-офиса выполнен с возможностью предоставления пользователю возможности определения одного или более наборов правил.

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

7. Система по п. 1, в которой упомянутая машина обработки рабочего потока и упомянутый модуль бэк-офиса коммуникативно связаны для двусторонней связи через услугу REST.

8. Система по п. 1, в которой предварительно определенные упомянутые наборы правил и упомянутые графические элементы хранятся в базе данных, доступной посредством упомянутой машины обработки и/или упомянутого модуля бэк-офиса.

9. Способ генерирования маршрута данных транзакции для направления и осуществления запроса транзакции в системе по п. 1, причем способ содержит этапы, на которых:

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

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

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

конфигурируют упомянутый модуль Web-Кассира для предоставления пользователю возможности выбирать рабочий поток и передавать данные запроса, представляющие его, в упомянутую машину обработки рабочего потока;

дополнительно конфигурируют упомянутую машину обработки рабочего потока для:

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

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

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

10. Система по п. 1, в которой упомянутая машина обработки рабочего потока сконфигурирована с возможностью выполнения операции аутентификации пользователя в ответ на данные аутентификации, полученные через упомянутый модуль Web-Кассира.