ШЛЮЗОВОЙ УРОВЕНЬ АБСТРАКЦИИ Российский патент 2020 года по МПК G06Q20/00 

Перекрестные ссылки на родственные заявки

[0001] Настоящая заявка является непредварительной заявкой и испрашивает приоритет предварительной патентной заявки США № 61/362872, поданной 9 июля 2010 года (дело поверенного № 79900-787564), все содержимое которой настоящим включено в данный документ посредством ссылки.

Уровень техники

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

[0003] Тем не менее, вследствие затрат на подписки и/или транзакции, ассоциированных с приемом каждого бренда и типа платежной услуги, предлагаемой посредством различных платежных сетей, некоторые продавцы выбирают прием и обработку только некоторой небольшой части доступных услуг из ограниченного числа или платежных сетей. Например, независимый онлайновый продавец может полагать, что затраты на прием всех платежных услуг, предлагаемых посредством Visa™, MasterCard™, American Express™, Discover™ и возможно других брендов платежных услуг, чрезмерно завышены. В дополнение к прямым затратам и комиссиям, ассоциированным с подпиской или использованием различных платежных сетей, существуют дополнительные приростные накладные расходы, ассоциированные с каждой дополнительной платежной сетью, приспосабливаемой продавцом.

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

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

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

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

[0008] Кроме того, когда продавец ограничивает число платежных сетей, которые он использует, он, по сути, ограничивает число и типы вспомогательных финансовых услуг, к которым он имеет доступ. Например, продавец может выбирать прием кредитных карт Visa™ и MasterCard™ для того, чтобы захватывать наибольшую долю потенциальных продаж держателей карт, но может знать, что он будет извлекать выгоду из мошеннических и рискованных услуг, предлагаемых посредством другой платежной сети или стороннего поставщика услуг, к которому он не имеет доступа. В настоящее время, у продавца, будь он небольшой или нет, нет способов быстро и экономически эффективно настраивать вспомогательные финансовые услуги, которые он принимает, когда подписывается на конкретную платежную сеть. Продавцы, по сути, "заперты" предложениями платежных сетей, которые они выбирают использовать для приема платежей.

[0009] Варианты осуществления настоящего изобретения разрешают эти и другие недостатки.

Сущность изобретения

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

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

[0012] Другие варианты осуществления настоящего изобретения направлены на способы для предоставления транзакционных услуг для множества запросчиков услуг с использованием шлюзового сервера. Способ включает в себя прием запроса на предоставление услуг от одного из множества запросчиков услуг по первому интерфейсу платформы приложений (API), синтаксический анализ данных запросов на предоставление услуг из запроса на предоставление услуг с использованием шлюзового сервера, затем осуществление доступа к базе данных уровня абстракции, чтобы определять одну или более транзакционных услуг с использованием шлюзового сервера. На основе информации, содержащейся в базе данных уровня абстракции, отправляется вызов по предоставлению услуг на основе данных запросов на предоставление услуг одному или более поставщиков услуг по второму API с использованием сервера. В ответ на вызов по предоставлению услуг, принимаются результаты от поставщиков услуг, и результаты отправляются запросчику услуг, эквайеру, процессору обслуживания платежей или коммерческой транзакционной сети.

Краткое описание чертежей

[0013] Фиг. 1 является блок-схемой шлюзового сервера шлюзового уровня абстракции (GAL) согласно различным вариантам осуществления настоящего изобретения.

[0014] Фиг. 2 является блок-схемой современной системы обработки платежей, которая может быть усовершенствована посредством различных вариантов осуществления настоящего изобретения.

[0015] Фиг. 3 является блок-схемой системы обработки платежей, включающей в себя GAL-шлюз согласно различным вариантам осуществления настоящего изобретения.

[0016] Фиг. 4 является блок-схемой системы обработки платежей, которая может быть усовершенствована посредством различных вариантов осуществления настоящего изобретения.

[0017] Фиг. 5 является блок-схемой системы обработки платежей, включающей в себя GAL-шлюз согласно различным вариантам осуществления настоящего изобретения.

[0018] Фиг. 6 является блок-схемой системы обработки платежей, включающей в себя GAL-шлюз согласно различным вариантам осуществления настоящего изобретения.

[0019] Фиг. 7 является блок-схемой системы обработки платежей, включающей в себя GAL-шлюз и сторонних поставщиков транзакционных услуг согласно различным вариантам осуществления настоящего изобретения.

[0020] Фиг. 8 является блок-схемой последовательности операций способа для осуществления запросов на предоставление транзакционных услуг и запросов на авторизацию по транзакциям с GAL-шлюзом согласно различным вариантам осуществления настоящего изобретения.

[0021] Фиг. 9 является блок-схемой последовательности операций способа для использования GAL-шлюза обработки запросов на предоставление транзакционных услуг и запросов на авторизацию по транзакциям согласно различным вариантам осуществления настоящего изобретения.

[0022] Фиг. 10 является схематичным видом системы с GAL-шлюзом согласно различным вариантам осуществления настоящего изобретения.

[0023] Фиг. 11 является схематичным видом системы для преобразования запросов из одного формата сообщений интерфейса платформы приложений (API) в другой формат API-сообщений согласно различным вариантам осуществления настоящего изобретения.

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

Подробное описание изобретения

[0025] Варианты осуществления настоящего изобретения направлены на системы, способы, шлюзы и серверы для предоставления обмена сообщениями, коммутации, трансляции и маршрутизации сообщений по транзакциям и запросов на проведение транзакций между запросчиками транзакций, сетями обработки платежей и сторонними поставщиками услуг. При использовании в данном документе, термин "запросчик транзакции" или "запросчик услуг" может означать любой объект, систему или системный компонент, который может запрашивать авторизацию по транзакции или другие услуги. Такие объекты и системы могут включать в себя, но не только, продавцов, эмитентов, эквайеров и процессоры обслуживания платежей. В различных вариантах осуществления, трансляция запросов на проведение транзакций или транзакционных услуг предоставляется посредством шлюза транзакции, имеющего уровень абстракции и другую внутреннюю логику. Шлюзовой уровень абстракции может размещаться в шлюзовом компьютере или на шлюзовом сервере и тем самым упоминается в данном документе как шлюзовой уровень абстракции.

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

[0027] В различных других вариантах осуществления, шлюз обработки платежей, имеющий шлюзовой уровень абстракции (GAL), может предлагать открытые или стандартизированные или канонические форматы, протоколы и процедуры связи и запросов на проведение транзакций для запросчиков транзакций, к примеру, продавцов и сторонних поставщиков услуг. Использование таких стандартизированных или канонических форматов сообщений и файлов и стандартов связи служит для того, чтобы упрощать фактическую связь между запросчиками транзакций, сторонними поставщиками услуг и платежными сетями. Каждое соответствующее подключение или интерфейс между продавцами, сторонними поставщиками услуг и платежными сетями к серверному GAL-компьютеру может включать в себя общий стандарт связи или конкретный для шлюза интерфейс платформы приложений (API). В некоторых вариантах осуществления, "уровень" может быть ассоциирован с функцией или протоколом, работающим на конкретном уровне в сетевой архитектуре или архитектуре системы. Уровень может быть реализован посредством любой подходящей комбинации аппаратных средств и программного обеспечения.

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

[0029] Фиг. 1 является блок-схемой GAL-шлюза 100 согласно различным вариантам осуществления. Как показано, GAL-шлюз 100 может включать в себя различные модули или уровни, которые могут предоставлять и/или хостить различные услуги для различных объектов, систем и системных компонентов, подключенных к GAL-шлюзу 100. GAL-шлюз 100 может включать в себя уровень 105 хранилища услуг и уровень 110 аналитических услуг, уровень 120 услуг хостинга приложений и данных, уровень 130 адаптации и интеграции, уровень 140 услуг управления членством и уровень 150 собственных дополнительных услуг обмена сообщениями (или уровень абстракции). Различные компоненты и уровни GAL-шлюза 100 могут включать в себя различные вычислительные компоненты, включающие в себя, но не только, аппаратные средства, микропрограммное обеспечение, программное обеспечение, а также сети из соединенных компьютеров и серверных компьютеров, выполненных с возможностью исполнять инструкции, чтобы осуществлять функции различных уровней. В вариантах осуществления, которые включают в себя подключенные к сети компьютеры или серверные компьютеры, каждый компьютер может подключаться друг к другу через сетевые соединения, такие как Ethernet, IEEE 802.11x, ISDN и другие открытые стандартные и коммерческие сетевые протоколы и соединения.

[0030] В некоторых вариантах осуществления, уровень 105 хранилища услуг может предоставлять интерфейс продавцам и сторонним поставщикам услуг, таким как разработчики программного обеспечения и поставщики программного обеспечения как услуги (SaaS). Электронная витрина уровня 105 хранилища услуг может представлять собой веб-узел или другой портал онлайновых ресурсов, который дает возможность сторонним поставщикам услуг выгружать/регистрировать свои продукты или услуги, а продавцам и другим пользователям - выбирать различное программное обеспечение/услуги, на которое они хотят подписаться или иным образом использовать. Уровень 105 хранилища услуг может включать в себя интерфейсы платформы приложений (API) для связывания внешних объектов, компьютеров и компонентов с различными услугами, предлагаемыми на уровне 105 хранилища услуг. В таких вариантах осуществления, API, хостируемые или предлагаемые посредством уровня 105 хранилища услуг либо другого уровня или компонента GAL-шлюза 100, могут включать в себя несколько API, которые являются конкретными или предназначены для простой интеграции выбранных услуг в унаследованные, существующие или модифицированные операции объекта, системы или компьютера объекта-подписчика. Хотя такая функциональность описывается выше в отношении уровня 105 хранилища услуг, другие варианты осуществления предоставляют трансляцию между API через уровень 150 собственных дополнительных услуг обмена сообщениями или хостинг приложений и данных.

[0031] Например, объект-подписчик, к примеру, розничный продавец может иметь или управлять онлайновой электронной витриной, хостируемой на удаленном сервере, которая включает в себя различные вызовы функции или SaaS-вызовы либо другой обмен сообщениями с внешней услугой обработки платежей, такой как PayPal™, к которой осуществляется доступ с использованием API, конкретного для этой услуги обработки платежей, через конкретный URL-адрес или IP-адрес. Уровень 105 хранилища услуг может предоставлять доступ к одной или более альтернативных или аналогичных услуг, предоставляемых посредством внешней услуги обработки платежей, посредством предоставления объекту-подписчику другого URL-адреса или IP-адреса, чтобы отправлять вызовы функций или SaaS-вызовы либо другие сообщения с использованием идентичного конкретного для внешней услуги обработки платежей API. Уровень 105 хранилища услуг либо некоторый другой компонент или уровень GAL-шлюза 100 затем может транслироваться из конкретного для внешней услуги обработки платежей API в другой формат или протокол для использования внутренне для GAL-шлюза либо в другой формат или протокол для использования посредством другого объекта, такого как другой продавец, эмитент, эквайер, сеть обработки платежей или сторонний поставщик услуг, и т.д. Такие признаки GAL-шлюза 100 позволяют объектам-подписчикам выполнять быстрые и экономически эффективные переключения с услуг внешнего поставщика услуг на услуги, предоставляемые или хостируемые на GAL-шлюзе, с незначительным (либо вообще без него) прерыванием бизнес-ориентированных или внутренних практических методик и процедур объектов-подписчиков. Все, что может потребоваться сделать объекту-подписчику, - это заменить целевой URL-адрес или IP-адрес, на который он отправляет сообщение с запросом либо вызовы функций или SaaS-вызовы.

[0032] Продавец или другой объект-подписчик также может использовать уровень 105 хранилища услуг для того, чтобы выбирать конкретные платежные сети, через которые можно принимать платежи. Аналогично, продавец может использовать уровень 105 хранилища услуг, чтобы выбирать конкретные сторонние транзакционные услуги, которые могут обрабатывать платежи через одну или более платежных сетей. В некоторых вариантах осуществления, электронная витрина 106 уровня 105 хранилища услуг может быть выполнена с возможностью разрешать продавцам выбирать использование или прием стандартных или предварительно определенных пакетов транзакционных услуг, предоставляемых посредством стороннего поставщика услуг или любой из платежных сетей, подписку на которые они выбирают. Продавцы также могут выбирать настройку транзакционных услуг посредством выбора услуг на заказ, зарегистрированных в GAL-шлюзе 100 и предоставляемых посредством отдельных разработчиков, сторонних поставщиков услуг и каждой из платежных сетей через уровень 105 хранилища услуг. Транзакционные услуги, которые сторонние поставщики услуг и платежные сети могут предоставлять через уровень 105 хранилища услуг GAL-шлюза 100, могут включать в себя, но не только, обработку платежей, обнаружение мошенничества, управление рисками, начисление баллов за покупки, программы лояльности, программы спецпредложений, программы партнерства/сотрудничества и другие финансовые, страховые, банковские и коммерческие услуги.

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

[0034] Способ, которым продавец может использовать различные транзакционные услуги, предоставляемые через уровень 105 хранилища услуг, может варьироваться согласно предложениям GAL-шлюза 100 и соглашениям, которые имеет оператор со сторонними поставщиками услуг и платежными сетями. Тем не менее, согласно различным вариантам осуществления настоящего изобретения, эти услуги не должны быть ограничены за исключением того, что они, возможно, должны соответствовать указанному протоколу либо API связи или обработки.

[0035] В некоторых вариантах осуществления, транзакционная услуга может предлагаться в качестве встраиваемой услуги, в которой конкретный вызов осуществляется с SaaS или с другим поставщиком услуг каждый раз, когда продавец отправляет запрос на авторизацию по транзакции в платежную сеть через GAL-шлюз 100. Таким образом, транзакционная услуга может выполняться параллельно, до, во время или после того, как запрос на авторизацию по транзакции отправляется в конкретную платежную сеть. Одно преимущество этого варианта осуществления состоит в том, что он дает возможность продавцу отклонять транзакцию и тем самым исключать затраты на выполнение запроса на авторизацию на основе результатов, возвращаемых от SaaS-поставщика, до того как запрос на авторизацию отправляется в платежную сеть.

[0036] Обратившись снова к примеру продавца ювелирных изделий, продавец ювелирных изделий может использовать электронную витрину 106, чтобы указывать то, что GAL-шлюз 100 должен отправлять требуемые данные запросов на предоставление транзакционных услуг, синтаксически проанализированные из запроса на авторизацию по транзакции, конкретному SaaS-поставщику, которого он выбирает. SaaS-поставщик может обеспечивать доступность услуг через уровень 107 центра разработчика и онлайновых ресурсов. В некоторых вариантах осуществления, GAL-шлюз 100 может отправлять данные запросов на предоставление транзакционных услуг SaaS-поставщику и ждать положительного результата до того, как запрос на авторизацию по транзакции отправляется в конкретную платежную сеть. Таким образом, продавец ювелирных изделий может исключать затраты на выполнение запроса на авторизацию по транзакции и просто отклонять транзакцию. Соответственно, продавцы могут извлекать выгоду из сторонних услуг, которые помогают им исключать потенциальные затраты и риски, ассоциированные с конкретной транзакцией и необязательным запросом на авторизацию по транзакции. Сторонние поставщики услуг, которые могут разрабатывать узкоспециализированные и/или эффективные транзакционные услуги, получают преимущество посредством осуществления доступа к продавцам с использованием уровня 105 хранилища услуг.

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

[0038] Например, онлайновый продавец может принимать фрагмент кода, т.е. сегмент Java-кода, чтобы включать его на свой веб-узел. Этот код может запускаться каждый раз, когда потребитель инициирует запрос на осуществление платежа с использованием веб-узла. В некоторых вариантах осуществления, Java-код может быть простым вызовом с SaaS-поставщиком, тогда как в других вариантах осуществления, приложение может работать в автономном режиме, чтобы предоставлять различные услуги продавцу каждый раз, когда инициируется запрос на проведение транзакции с использованием веб-узла или торгового терминала. Различные примеры автономных приложений предоставления транзакционных услуг могут включать в себя приложения для опроса клиентов, приложения для оценки веб-узлов, приложения для обработки специальных предложений и приложения для крупномасштабного межбрендового корпоративного партнерства.

[0039] Модуль 107 центра разработчика и онлайновых ресурсов на уровне 105 хранилища услуг может предоставлять интерфейс и поддержку для сторонних поставщиков транзакционных услуг. Как упомянуто выше, сторонние поставщики транзакционных услуг могут предлагать свои продукты и услуги как встраиваемые или встроенные решения продавцам, процессорам обслуживания платежей и платежным сетям. В некоторых вариантах осуществления, может требоваться сертификация сторонних поставщиков транзакционных услуг могут посредством GAL-шлюза 100. В других вариантах осуществления, все без исключения сторонние поставщики услуг могут предлагать свои продукты и услуги в качестве несертифицированных сторонних поставщиков услуг при условии, что они соответствуют требованиям API для сторонних поставщиков услуг или другого интерфейса.

[0040] Уровень 110 аналитических услуг может предлагать стандартные 111 или произвольно организующиеся (ad hoc) 112 типы аналитических услуг. Аналитические услуги, предлагаемые посредством уровня 110 аналитических услуг, могут включать в себя стандартную аналитику транзакций и платежей, предлагаемую посредством любой из брендовых платежных сетей. В других вариантах осуществления, уровень 110 аналитических услуг может предлагать произвольно организующиеся 112 аналитические услуги продавцам. В некоторых вариантах осуществления произвольно организующиеся 112 услуги могут включать в себя настраиваемые или тонко подстраиваемые системы, спроектированные посредством или для конкретного продавца. Аналитические услуги 110 могут подключаться и вызываться посредством любого из уровней на уровне 105 хранилища услуг.

[0041] GAL-шлюз 100 также может включать в себя уровень 120 услуг хостинга приложений и данных. В вариантах осуществления, включающих в себя уровень 120 услуг хостинга приложений и данных, GAL-шлюз 100 может предоставлять различные услуги продавцам, сторонним поставщикам услуг и платежным сетям, включающие в себя, но не только, хостинг 121 приложений, SaaS-интеграцию 122, интеграцию 123 шлюзовых услуг, защиту 124 данных транзакций, интеграцию 125 услуг на основе процессора и интеграцию 126 услуг эмитентов.

[0042] Дополнительным уровнем GAL-шлюза 100 может быть уровень 130 адаптации и интеграции. Уровень 130 адаптации и интеграции может включать в себя интерфейсы, порталы и поддержку для разработчиков 133, внешних шлюзов 135, процессоров 137 и эмитентов 139 для подключения, активации или маршрутизации запросов на авторизацию по транзакциям или запросов на предоставление транзакционных услуг через GAL-шлюз 100. С использованием уровня 130 адаптации и интеграции продавцы, разработчики, внешние шлюзы, процессоры обслуживания платежей и эмитенты могут видеть и использовать согласованный интерфейс, чтобы взаимодействовать друг c другом. Другими словами, каждый из продавца, разработчика, шлюза, процессора обслуживания платежей или эмитента должен соответствовать только требованиям GAL-шлюза 100, чтобы взаимодействовать с любыми другими объектами, услугами, серверами или сетями, подключенными к GAL-шлюзу 100. Это позволяет значительно снижать сложность ведения бизнеса, в частности, в отношении приема нескольких вариантов платежей и использования нескольких транзакционных услуг от различных объектов.

[0043] GAL-шлюз 100 также может включать в себя уровень 140 услуг управления членством. Уровень 140 услуг управления членством может включать в себя информационный портал для разработчиков 143 и продавцов 145. С использованием уровня 140 услуг управления членством разработчики 143 и продавцы 145 могут регистрировать свою конкретную информацию, обновлять информацию по серверам и хостингу, разрешать проблемы с GAL-шлюзом 100 и потенциально любыми другими объектами, подключенными к шлюзу 100. Уровень услуг продавца 140 также может включать в себя информацию и услуги в отношении биллинга, споров, расчетов, сверки и составления отчетов для разработчиков 143 и продавцов 145.

[0044] В завершение, GAL-шлюз 100 может включать в себя уровень 150 собственных дополнительных услуг обмена сообщениями (или уровень абстракции). Уровень 150 собственных дополнительных услуг обмена сообщениями (или уровень абстракции) иллюстрирует характеристики связи и взаимосвязанность между уровнем 105 хранилища услуг, уровнем 110 аналитических услуг, уровнем 120 услуг хостинга приложений и данных, уровнем 130 адаптации и интеграции, уровнем 140 услуг управления членством и внешними продавцами, сторонними поставщиками услуг и платежными сетями.

[0045] Например, услуги 150 интеграции на уровне хранилищ решений могут обмениваться данными с услугами 153 шлюзовой интеграции, услугами 155 интеграции на уровне процессоров и услугами 157 интеграции на уровне эмитентов. В свою очередь, каждая из услуг 151, 153, 155 в 157 на уровне 150 собственных дополнительных услуг обмена сообщениями может обмениваться данными, прямо или косвенно, со всеми остальными уровнями GAL-шлюза 100 или с любыми другими подключенными объектами, внешними для GAL-шлюза 100, такими как продавцы, процессоры обслуживания платежей, эмитенты, эквайеры и платежные сети. Уровень абстракции/уровень 150 собственных дополнительных услуг обмена сообщениями может включать в себя услуги по трансляции между различными форматами, протоколами и моделями обеспечения возможностей подключения для обмена сообщениями, маршрутизации и коммутации запросов на авторизацию по транзакциям и сторонних вызовов по предоставлению услуг между различными объектами.

[0046] В некоторых вариантах осуществления, услуги по трансляции включают в себя преобразование между форматами входящего запроса на авторизацию по транзакции от торгового или процессора обслуживания платежей и требованиями целевой платежной сети. Например, запрос на авторизацию по транзакции может быть принят в GAL-шлюзе 100 от продавца. Запрос на авторизацию по транзакции может быть в первом формате и включать в себя первый набор информации. Уровень 150 собственных дополнительных услуг обмена сообщениями может синтаксически анализировать первый набор информации из первого формата запроса на авторизацию по транзакции и затем транслировать его во второй формат, включающий в себя второй набор информации, которая может включать в себя или не включать в себя всю информацию из первого набора информации, надлежащую или требуемую посредством платежной сети. В других вариантах осуществления, уровень 150 собственных дополнительных услуг обмена сообщениями также может синтаксически анализировать информацию из первого набора информации и составлять третье сообщение формата или файл данных, которое должно отправляться или использоваться при активации сторонней услуги от одного или более сторонних поставщиков услуг.

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

[0048] Фиг. 2-7 являются блок-схемами различных систем для обработки финансовых транзакций, т.е. платежных транзакций, согласно различным современным системам и вариантам осуществления настоящего изобретения. Для понятности и простоты ссылок, элементы, проиллюстрированные на фиг. 2-7, имеющие идентичные или аналогичные функции, характеристики или возможности, обозначаются с использованием согласованных ссылок с номерами на каждом из чертежей.

[0049] Фиг. 2 является блок-схемой системы для обработки платежей с использованием нескольких платежных сетей, в которых продавцы подключаются напрямую к платежным сетям. Торговая система с прямым подключением имеет несколько уровней, включающих в себя, но не только, уровень 210 держателей карт, уровень 220 продавцов и уровень 260 брендовых сетей. В таких системах потребителям могут выдаваться различные формы платежных счетов. Платежные счета могут включать в себя кредитные, дебетовые, банкоматные, онлайновые и предназначенные для персональных вычислительных устройств платежные счета. Потребитель может выбирать использование одного из этих платежных счетов, чтобы инициировать платеж или другую финансовую транзакцию с продавцом на уровне 220 продавцов. Как показано, уровень 220 продавцов может включать в себя как небольших продавцов 223, таких как независимый музыкальный магазин, так и крупных продавцов 227, таких Wal-Mart™, и может подключаться напрямую к платежным сетям на уровне 260 брендовых сетей.

[0050] Довольно часто крупные продавцы 227 подключены напрямую к платежным сетям на уровне 260 брендовых сетей для обработки финансовых транзакций. Когда продавец на уровне 220 продавцов достигает определенного статуса и осуществляет определенное пороговое число финансовых транзакций с использованием каждой из платежных сетей, число транзакций, глубина ресурсов и экономия за счет роста масштаба компании, доступная для крупных продавцов 227, зачастую может оправдывать издержки и накладные расходы поддержания прямых подключений с каждой из платежных сетей. Гораздо менее вероятно, что небольшие продавцы 223 имеют ресурсы или требуемое число продаж, чтобы оправдывать поддержание прямых подключений с платежными сетями и уровнем 260 брендовых сетей.

[0051] Для небольших продавцов 223, более целесообразно с точки зрения бизнеса проводить свои финансовые транзакции через шлюз эквайера или шлюз шлюзового уровня абстракции, как показано на фиг. 4-5, поясненных ниже. Различные варианты осуществления настоящего изобретения решают проблему затрат и сложности, связанной с тем, что как небольшие продавцы 223, так и крупные продавцы 227 на уровне 220 продавцов участвуют в прямом подключении к платежным сетям на уровне 260 брендовых сетей.

[0052] Фиг. 3 является блок-схемой системы, которая использует шлюзовой уровень 240 абстракции, включающий в себя шлюз шлюзового уровня абстракции (GAL-шлюз), чтобы упрощать, ускорять и уменьшать затраты, ассоциированные с прямым подключением продавца на уровне 220 продавцов к платежным сетям на уровне 260 брендовых сетей. Как показано на фиг. 3, эта конкретная система включает в себя уровень 210 держателей карт, уровень 220 продавцов и уровень 260 брендовых сетей, как показано на фиг. 2, с добавлением шлюзового уровня 240 абстракции, который может включать в себя шлюз 100 шлюзового уровня абстракции (GAL). Уровень 250 обслуживающих шлюзов показан с целью показать, что прямое подключение между GAL-шлюзом 100 на шлюзовом уровне 240 абстракции и платежными сетями на уровне 260 брендовых сетей может полностью обходить эквайеров на уровне 250 обслуживающих шлюзов.

[0053] В таких вариантах осуществления, продавцы на уровне 220 продавцов могут принимать запрос на проведение транзакции от одного или более владельцев счетов на уровне 210 держателей карт. Как упомянуто выше, владельцы счетов могут использовать множество потребительских платежных счетов, таких как кредитные карты, дебетовые карты, банкоматные карты, онлайновые платежные веб-узлы и предназначенные для персональных вычислительных устройств платежные системы, чтобы инициировать покупку или другую финансовую транзакцию с продавцами на уровне 220 продавцов, такими как небольшие продавцы 223 или крупные продавцы 227.

[0054] GAL-шлюз 100 может предлагать продавцам на уровне 220 продавцов через различные уровни и модули GAL-шлюза 100 единый интерфейс, через который можно обрабатывать запросы на авторизацию по транзакциям и указывать различные транзакционные услуги. С точки зрения продавцов они должны только форматировать запрос на авторизацию по транзакции, который может включать в себя запросы для других транзакционных услуг, согласно одному формату, протоколу или модели обеспечения возможностей подключения для запроса на авторизацию по транзакции согласно требованиям GAL-шлюза 100 или шлюзового уровня абстракции. Нет необходимости отслеживать и/или управлять требованиями по отправке запросов на авторизацию по транзакциям для каждой из платежных сетей. GAL-шлюз 100 может управлять требованиями каждой из платежных сетей и осуществлять надлежащие трансляции из запросов на авторизацию по транзакциям, принимаемых от продавцов, в требуемые форматы, протоколы и модели обеспечения возможностей подключения для намеченной платежной сети.

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

[0056] После того, как GAL-шлюз 100 принимает запрос на авторизацию по транзакции от продавца на уровне 220 продавцов, он может транслировать этот запрос на авторизацию по транзакции в формат, протокол или модель обеспечения возможностей подключения, требуемую посредством намеченной платежной сети на уровне 260 брендовых сетей. Эта трансляция может быть основана на базе данных или таблице поиска, преобразованной в идентификатор платежной сети, включенный в запрос на авторизацию по транзакции, принимаемый от продавца. GAL-шлюз 100 может синтаксически анализировать идентификатор платежной сети и другие данные запросов на авторизацию по транзакциям из запроса на авторизацию по транзакции и извлекать данные касательно требований для отправки запросов на авторизацию по транзакциям в намеченную платежную сеть. Извлеченные данные касательно требований для предоставления запроса на авторизацию по транзакциям в конкретную платежную сеть могут включать в себя спецификации для форматов файлов, протоколов передачи, информации маршрутизации, сетевых шлюзов, ограничений, накладываемых сетью, и других стандартов связи. GAL-шлюз 100 затем может формировать надлежащие файлы и сигналы на основе спецификаций для конкретной платежной операции.

[0057] В некоторых вариантах осуществления, GAL-шлюз 100 может принимать данные коммерческой версии, включающие в себя изменения спецификаций для предоставления запросов на авторизацию по транзакциям, из платежных сетей на уровне 260 брендовых сетей. GAL-шлюз 100 затем может обновлять собственные базы данных и таблицы поиска, чтобы обеспечивать то, что последующая связь с платежными сетями не будет прерываться со стороны продавцов. Все, что требуется сделать продавцам - это продолжать форматирование запросов на авторизацию по транзакциям в форму, требуемую посредством GAL-шлюза 100 или любого одного или более API, которые они поддерживают. Эта функциональность GAL-шлюза 100 является преимущественной для продавцов, поскольку она может способствовать снятию с продавцов нагрузки по необходимости обновлять, поддерживать и управлять изменениями стандартов связи, которые периодически проводят платежные сети.

[0058] Фиг. 4 является блок-схемой современной системы для обеспечения возможностей подключения между продавцами на уровне 220 продавцов к платежным сетям на уровне 260 брендовых сетей через некоторое число обслуживающих шлюзов на уровне 250 обслуживающих шлюзов. Как пояснено выше, для многих менее крупных продавцов, таких как небольшие продавцы 223, может быть нецелесообразно с экономической или коммерческой точки зрения поддерживать прямые подключения с платежными сетями на уровне 260 брендовых сетей. Эта задача просто является слишком дорогой или трудоемкой, чтобы считать ее реализуемой.

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

[0060] Как показано, эта система по-прежнему имеет значительные недостатки в том, что существует определенное число эквайеров на уровне 250 обслуживающих шлюзов. Некоторые эквайеры на уровне 250 обслуживающих шлюзов могут подключаться к некоторым платежным сетям на уровне 260 брендовых сетей. Тем не менее, продавец по-прежнему может быть ограничен в выборе доступных платежных сетей на основе своего выбора эквайера. Например, фиг. 4 показывает небольшого продавца 223, принимающего запросы на авторизацию по транзакциям, инициированные посредством потребителя с использованием кредитной карты Visa. Небольшой продавец 223 затем должен отправлять запрос на авторизацию по транзакции выбранному эквайеру, в этом случае Cyber Source. Cyber Source затем маршрутизирует запрос на авторизацию по транзакции в намеченную платежную сеть, выбранную из числа платежных сетей, с которыми он аффилирован.

[0061] Хотя Cyber Source подключен к Visa™, MasterCard™, Shazam™, и American Express™ в этом примере, он не ассоциирован или подключен к сетям NYCE™ или Pulse™. Чтобы отправлять запросы на авторизацию по транзакциям в любую из платежных сетей, с которыми Cyber Source не соединен или ассоциирован, небольшой продавец 223 затем должен ассоциировать себя или подписаться на услуги другого эквайера, к примеру, эквайера 251, эквайера 252, эквайера 253, эквайера 254 или некоторого другого эквайера на уровне 250 обслуживающих шлюзов. В лучшем случае продавцам, вероятно, потребуется быть ассоциированными всего с двумя эквайерами; тем не менее, чтобы иметь возможность принимать платежи с использованием всех платежных сетей, которые они хотят использовать, продавцы, возможно, должны ассоциироваться с тремя или более эквайерами. Такие компоновки фактически не приводят к снижению затрат и сложности отправки запросов на авторизацию по транзакциям в больший поднабор выбранных платежных сетей.

[0062] Каждый эквайер на уровне 250 обслуживающих шлюзов обычно имеет различные стандарты связи для отправки запросов на авторизацию по транзакциям. Следовательно, небольшой продавец 223 должен включать в свои протоколы обработки запросов на авторизацию по транзакции конечную систему или процедуру для определения того, какой обслуживающий шлюз следует использовать для того, чтобы отправлять запрос на авторизацию по транзакциям в конкретную платежную сеть. Продавец затем должен формировать надлежащее сообщение запроса на авторизацию по транзакции и отправлять его согласно стандартам связи, требуемым посредством конкретного эквайера. Такие системы предлагают очень несущественную экономию затрат и ресурсов продавцам, которые должны содержать в себе услуги нескольких эквайеров. Хотя услуги, предоставляемые эквайерами на уровне 250 обслуживающих шлюзов, удовлетворяют некоторые из потребностей небольших продавцов, они по-прежнему не позволяют небольшим продавцам пользоваться различными преимуществами и экономией затрат, обеспечиваемыми для более крупных продавцов с более существенными ресурсами и возможностями по заключению договоров.

[0063] Фиг. 5 является блок-схемой системы, в которой шлюзовой уровень 240 абстракции, включающий в себя GAL-шлюз 100, может добавляться в систему, показанную на фиг. 4, чтобы дорабатывать доступ продавца к большему числу платежных сетей, чем те, к которым он может иметь доступ с использованием своего текущего эквайера или процессора обслуживания платежей. Как показано, шлюзовой уровень 240 абстракции может быть вставлен между уровнем 220 продавцов и уровнем 250 обслуживающих шлюзов. GAL-шлюз 100 на шлюзовом уровне 240 абстракции затем может обмениваться данными напрямую эквайером, ассоциированным с небольшим продавцом 223 (здесь Cyber Source), через которого продавец косвенно осуществляет доступ к некоторому числу платежных сетей. GAL-шлюз 100 также может подключаться напрямую к другим платежным сетям, ранее недоступным для небольшого продавца 223 через предыдущего эквайера. Преимущества таких вариантов осуществления включают в себя способность GAL-шлюза 100 предлагать один стандарт связи небольшому продавцу 223 для отправки запросов на авторизацию по транзакциям своему эквайеру и в платежные сети, к которым он подключен, при одновременном предоставлении доступа к большему числу платежных сетей на уровне 260 брендовых сетей. В некоторых вариантах осуществления, GAL-шлюз 100 может поддерживать и управлять обновлениями стандартов связи, требуемых для всех без исключения эквайеров на уровне 250 обслуживающих шлюзов, а также стандартов связи, требуемых посредством платежных сетей на уровне 260 брендовых сетей.

[0064] Фиг. 6 показывает блок-схему системы для использования шлюзового уровня 240 абстракции, имеющей GAL-шлюз 100 для помощи и упрощения запросов на авторизацию по транзакциям между процессорами обслуживания платежей и эквайерами на уровне 250 обслуживающих шлюзов и платежными сетями на уровне 260 брендовых сетей. Поскольку GAL-шлюз 100 может предлагать продавцам согласованные и единые стандарты для форматов файлов, протоколов, моделей обеспечения возможностей подключения и других стандартов связи, он также может предлагать эти преимущества эквайерам и процессорам обслуживания платежей на уровне 250 обслуживающих шлюзов. Каждый эквайер должен соответствовать только стандартам связи GAL-шлюза 100, тем самым уменьшая издержки и накладные расходы, ассоциированные с поддержанием, управлением и обработкой стандартов связи для нескольких платежных сетей.

[0065] По сути, система, показанная на фиг. 6, предоставляет каждому из эквайеров и/или процессоров обслуживания платежей на уровне 250 обслуживающих шлюзов доступ ко всем без исключения платежным сетям на уровне 260 брендовых сетей. Обновления стандартов связи, требуемых посредством платежных сетей, могут управляться посредством GAL-шлюза 100 для эквайеров и/или процессоров обслуживания платежей. Каждый из продавцов на уровне 220 продавцов затем может иметь доступ к выбранном варианту платежной сети с использованием выбранного эквайера или процессора обслуживания платежей.

[0066] Фиг. 7 является блок-схемой системы согласно одному варианту осуществления настоящего изобретения для использования шлюзового уровня 240 абстракции, имеющей GAL-шлюз 100. Фиг. 7 показывает возможности подключения между новыми продавцами 221 и новыми приложениями 225 на уровне 220 продавцов, сторонними поставщиками услуг на уровне 230 собственных дополнительных сторонних услуг и платежными сетями на уровне 260 брендовых сетей, которые обеспечивают возможность системе обходить потребность в эквайерах в обслуживающем шлюзе 250. Как показано, GAL-шлюз 100 может включать в себя интерфейсы 101 для обмена данными и подключения к продавцам 221 и другим новым приложениям 225 на уровне 220 продавцов. GAL-шлюз 100 также может подключаться к определенному числу сторонних поставщиков 231, 233 и 235 услуг на уровне 230 сторонних поставщиков собственных дополнительных услуг с использованием интерфейсов 103. В завершение, GAL-шлюз 100 также может включать в себя интерфейсы 107 для трансляции и передачи запросов на авторизацию и предоставление услуг от продавцов и сторонних поставщиков услуг согласно требованиям по связи намеченной платежной сети.

[0067] Интерфейс 101 между продавцами 221 и GAL-шлюзом 100 может включать в себя опубликованные и/или открытые стандарты связи для отправки и приема данных. В некоторых вариантах осуществления, интерфейс 101 может быть открытым стандартным интерфейсом платформы приложений (API), который может предлагаться продавцам 221 и новым приложениям 225 бесплатно или за комиссию. С использованием стандартов связи, предоставляемых посредством GAL-шлюза 100, продавцы 221 и новые приложения 225 могут содержать в себе один стандарт связи, на который они могут "повесить" свои алгоритмы и процедуры бизнес-транзакций, платежных транзакций и других финансовых транзакций, с входом или выходом, которые обмениваются данными со сторонними поставщиками услуг и/или платежными сетями через GAL-шлюз 100. Поскольку GAL-шлюз 100 может управлять изменениями в стандартах связи, публикуемыми посредством сторонних поставщиков услуг или посредством платежных сетей, GAL-шлюз 100 может выступать в качестве буфера изменений для продавцов и новых приложений, которые могут не иметь достаточных ресурсов в организационном или финансовом отношении, при необходимости самостоятельно адаптироваться к частым изменениям.

[0068] Интерфейс 103 между GAL-шлюзом 100 и сторонними поставщиками 231, 233 и 235 услуг на уровне 230 сторонних поставщиков услуг также может включать в себя опубликованный и/или открытый стандарт связи для отправки и приема данных. Аналогично интерфейсу 101, интерфейс 103 также может быть открытым стандартным интерфейсом платформы приложений (API), который может быть опубликован для сторонних поставщиков услуг бесплатно или за комиссию. Сторонние поставщики 231, 233 и 235 услуг затем могут проектировать и выполнять различные функции и услуги, подключенные к API GAL-шлюза 100.

[0069] В некоторых вариантах осуществления, сторонние поставщики услуг могут предоставлять загружаемый код, распространяемый посредством уровня 108 распространения встроенных приложений уровня 105 хранилища услуг GAL-шлюза 100. В таких вариантах осуществления, GAL-шлюз 100 может управлять функциями распространения встроенных приложений программного обеспечения и других приложений, предоставляемых посредством сторонних поставщиков услуг и разработчиков, продавцам 221 и другим новым приложениям 225. В конечном счете, для новых приложений 225, в дополнение к приему запросов на авторизацию по финансовым транзакциям от владельцев счетов на уровне 210 держателей карт, существует потенциал для перехода новых приложений 225, по меньшей мере, частично, на уровень 230 поставщиков услуг в качестве агрегатора дополнительных сторонних поставщиков услуг или сторонних поставщиков услуг.

[0070] Посредством предоставления единого стандарта связи для сторонних поставщиков 231, 233 и 235 услуг, GAL-шлюз 100 дает возможность сторонним поставщикам услуг представлять свои услуги на рынке для продавцов 221 и новых приложений 225 параллельно или в дополнение к услугам, предоставляемым посредством платежных сетей на уровне 260 брендовых сетей. Таким образом, сторонние поставщики услуг на уровне 230 сторонних поставщиков услуг могут, в частности, представлять на рынке свои приложения, программное обеспечение и программное обеспечение как услугу (SaaS) конкретным продавцам и типам продавцов. Например, продавец, который принимает транзакции по кредитной карте под брендом Visa, может, в дополнение к доступным услугам по обнаружению мошенничества под брендом Visa, также выбирать услуги начисления баллов за покупки или спецпредложений от одного или более сторонних поставщиков услуг, чтобы тонко подстраивать открытость продавца и возможности проведения покупок своими клиентами. Сторонние поставщики услуг также могут вводить новый поток доходов в форме рекламы, участия в прибылях, зарабатывания денег по щелчкам рекламных объявлений, когда они поддерживают партнерские отношения с одним или более продавцов.

[0071] Интерфейсы 107 могут отличаться от интерфейсов 101 и 103 тем, что интерфейсы 107 специально предназначены и поддерживаются с возможностью предоставлять требуемые стандарты связи, требуемые посредством каждой из платежных сетей. Другими словами, интерфейсы 107, в частности, выполнены с возможностью разрешать каждой из платежных сетей на уровне 260 брендовых сетей обмениваться данными с GAL-шлюзом 100 согласно собственным стандартам связи.

[0072] В некоторых вариантах осуществления, GAL-шлюз 100 может предоставлять платежные сети на уровне 260 брендовых сетей с единым и согласованным протоколом, с помощью которого можно сообщать обо всех изменениях соответствующих стандартов связи, требуемых посредством каждой платежной сети. Тем не менее, GAL-шлюз 100 также может быть выполнен с возможностью принимать, синтаксически анализировать и интегрировать коммерческие версии, опубликованные посредством платежных сетей, анонсирующие изменения требований по форматированию файлов, стандартов доступности сети и других стандартов связи, а также изменения процедур составления отчетов, биллинга и сверки. В таких вариантах осуществления, эта возможность GAL-шлюза 100 исключает необходимость для каждого продавца и новых приложений 225 на уровне 220 продавцов поддерживать собственную базу данных и реализацию указываемых стандартов для платежных сетей.

[0073] Сторонние поставщики услуг на уровне 230 сторонних поставщиков услуг могут включать в себя определенное число поставщиков услуг, разработчиков программного обеспечения и SaaS-услуг. Сторонние поставщики 231, 233 и 235 услуг могут подстраивать или конкретно нацеливать свои продукты на потребности нового продавца 221, новых приложений 225 и любого из продавцов на уровне 220 продавцов. Посредством открытия торговой площадки на уровне 230 сторонних поставщиков услуг GAL-шлюз 100 дает возможность продавцам, крупным и небольшим, конкретно запрашивать различные услуги, включенные в запросы на авторизацию по транзакциям, отправленные в GAL-шлюз 100.

[0074] Как пояснено выше, запросы на авторизацию по транзакциям могут представлять собой запросы на авторизацию по платежам, которые являются частью протоколов и процедур приема платежей продавцов. В различных вариантах осуществления, такие объекты, как новый продавец 221, новые приложения 225 и небольшие и крупные продавцы 223 и 227 на уровне 220 продавцов могут контактировать с GAL-шлюзом 100 по определенному числу сетевых протоколов. Например, продавцы на уровне 220 продавцов могут подключаться к GAL-шлюзу 100 посредством открытых и коммерческих проводных и беспроводных сетей, таких как Интернет, WLAN, LAN и любые из сотовых сетей передачи данных, которые работают на радио- или микроволновых частотных каналах.

[0075] Фиг. 8 является блок-схемой последовательности операций способа 800 для использования GAL-шлюза для проведения финансовой транзакции согласно различным вариантам осуществления настоящего изобретения. На этапе 810 продавец, приложение или некоторый другой тип пользователя может устанавливать связь с GAL-шлюзом. Установление связи с GAL-шлюзом может включать в себя подключение к веб-узлу, подключение к порталу по зашифрованной коммерческой сети или подключение по любой другой форме подходящей электронной связи. Соединение может быть прямым либо может быть упрощено посредством составных сетей, таких как Интернет.

[0076] На этапе 820 продавец может указывать множество сертифицированных и несертифицированных услуг, предлагаемых посредством сторонних поставщиков услуг через GAL-шлюз. В некоторых вариантах осуществления, плата с продавца посредством GAL-шлюза 100 может взиматься для каждой транзакции или транзакционной услуги, предоставляемой посредством сторонних поставщиков услуг. В некоторых вариантах осуществления, предоставление сторонних услуг может включать в себя загрузку загружаемого приложения на клиентское вычислительное устройство продавца, тогда как в других вариантах осуществления, сторонние поставщики услуг могут предлагать код, который может запускаться или хостироваться на GAL-шлюзе от имени каждого из продавцов, запрашивающих услугу. В завершение, GAL-шлюз также может осуществлять вызовы по предоставлению услуг с каждым из поставщиков услуг таким же образом, как и SaaS-протокол.

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

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

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

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

[0081] На этапе 840 продавец может форматировать запрос на авторизацию по транзакции в API-формат для GAL-шлюза или другой формат с открытым исходным кодом, требуемый посредством GAL-шлюза. В других вариантах осуществления формат запроса на авторизацию по транзакции может быть полностью интегрирован в протоколы обработки транзакций продавца посредством простого соответствия требованиям требований API-формата для GAL-шлюза. На этапе 850 продавец затем может отправлять запрос на авторизацию по транзакции в API-формате для GAL-шлюза в GAL-шлюз. В ответ на запрос на авторизацию по транзакции продавцы могут принимать информацию о платежах/транзакциях от сторонних поставщиков услуг, которых они выбирают, и платежных сетей через GAL-шлюз на этапе 860.

[0082] Фиг. 9 является блок-схемой последовательности операций способа 900 для трансляции и маршрутизации запроса на авторизацию по транзакции сторонним поставщикам транзакционных услуг и в платежные сети с использованием GAL-шлюза согласно различным вариантам осуществления настоящего изобретения. Процесс начинается на этапе 910, на котором GAL-шлюз принимает запрос на авторизацию по транзакции от одного из множества продавцов/пользователей. Запрос на авторизацию по транзакции может форматироваться в стандартном или открытом интерфейсе платформы приложений (API). В некоторых вариантах осуществления, GAL-шлюз может быть сконфигурирован как шлюзовой GAL-сервер, имеющий несколько сетевых соединений с несколькими продавцами/пользователями. Эти соединения могут устанавливаться по коммерческим или открытым сетям, таким как VisaNet или Интернет. Соответственно, любая электронная среда связи для установления надежных и защищенных сетевых соединений может быть использована для того, чтобы устанавливать соединения между GAL-шлюзом и продавцами/пользователями.

[0083] После того, как GAL-шлюз имеет запрос на авторизацию по транзакции от продавца в предварительно заданном API-формате, GAL-шлюз может синтаксически анализировать запрос на авторизацию по транзакции, чтобы извлекать или иным образом синтаксически анализировать данные запросов на предоставление транзакционных услуг, на этапе 920. Синтаксически проанализированные данные запросов на предоставление транзакционных услуг могут включать в себя идентификаторы и/или вызовы по предоставлению услуг, т.е. сегменты кода, для установления соединений со сторонними поставщиками услуг или для запуска приложения, предоставляемого посредством стороннего поставщика услуг. Сторонние поставщики услуг могут предлагать множество транзакционных услуг, включающих в себя, но не только, обнаружение мошенничества, управление рисками, начисление баллов за покупки, спецпредложения, партнерство, разрешение споров, отмены начислений, возвраты, аналитика и другие транзакционные услуги касательно конкретного запроса на авторизацию по транзакции.

[0084] В некоторых вариантах осуществления, GAL-шлюз может включать в себя базу данных уровня абстракции с преобразованиями между различными объектами, к которыми подключен шлюзовой GAL-сервер. На этапе 930 GAL-шлюз может осуществлять доступ к базе данных уровня абстракции, чтобы определять одного или более поставщиков транзакционных услуг на основе идентификаторов сторонних поставщиков услуг, синтаксически проанализированных из запроса на авторизацию по транзакции. GAL-шлюз затем может маршрутизировать надлежащую информацию согласно опубликованному API-формату сторонним поставщикам услуг или выполнять программное обеспечение/приложения, предоставляемые посредством сторонних поставщиков услуг, с использованием других данных транзакции, синтаксически проанализированных из запроса на авторизацию по транзакции, на этапе 940.

[0085] На этапе 950 в ответ на отправку вызова по предоставлению услуг одному или более поставщиков транзакционных услуг или активации приложения предоставления транзакционных услуг на основе данных запросов на предоставление транзакционных услуг, GAL-шлюз может принимать результаты от поставщиков транзакционных услуг или приложения для поставщиков транзакционных услуг. GAL-шлюз затем может транслировать результаты от стороннего поставщика услуг из API-формата для сторонних поставщиков услуг в API-формат, используемый для того, чтобы обмениваться данными с продавцами/пользователями. В некоторых вариантах осуществления API для поставщиков услуг является идентичным API для продавцов/пользователей. Транслированные результаты затем могут отправляться обратно продавцу/пользователю либо в некоторых вариантах осуществления также могут отправляться эквайеру или в коммерческую транзакционную сеть, если продавец/пользователь указывает, чтобы эта информация была совместно использована с другими объектами.

[0086] На этапе 960, если результаты услуг сторонних поставщиков услуг являются предпочтительными или не помечены иным образом для дополнительного внимания продавцом/пользователем, то GAL-шлюз может отправлять транслированный запрос на авторизацию по транзакции в намеченную платежную сеть. В некоторых вариантах осуществления намеченная платежная сеть может указываться посредством информации, содержащейся в сообщении с запросом на авторизацию, принимаемом от продавца/пользователя и синтаксически проанализированном посредством GAL-шлюза. Намеченная платежная сеть может указываться посредством идентификатора, содержащегося в запросе на авторизацию по транзакции, который GAL-шлюз затем может использовать для того, чтобы определять надлежащую трансляцию из первого API-формата в формат данных платежных сетей, требуемый посредством платежной сети для приема запросов на авторизацию по транзакциям.

[0087] На этапе 970 GAL-шлюз может принимать ответ по авторизации по транзакции из платежной сети в собственный для платежных сетей формат ответа по авторизации по транзакции. GAL-шлюз затем может транслировать ответ по авторизации по транзакции из формата платежной сети в первый API-формат, используемый продавцом/пользователем на этапе 980. На этапе 985 GAL-шлюз затем может отправлять транслированный ответ по авторизации продавцу/пользователю с использованием первого API, так что продавец/пользователь может выполнять или отклонять релевантную транзакцию. В завершение, на этапе 990, GAL-шлюз может сохранять результаты от сторонних поставщиков услуг или из платежной сети, запрошенные продавцом/пользователем.

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

[0089] Дополнительные выгоды и преимущества включают в себя возможность предоставлять эквайерам, процессорам обслуживания платежей и продавцам выбор вариантов услуг по обеспечению многоуровневых возможностей подключения. Например, GAL-шлюз может предлагать два уровня услуг. Уровень 1 может быть "моделью на основе развертывания". Модель на основе развертывания может включать в себя традиционную резервную частную сеть с высокой готовностью, развернутую в конечной точке, такой как физический магазин или веб-сервер продавца. Уровень 2 может быть "моделью на основе подписки". Модель на основе подписки может включать в себя немного менее доступный, но более дешевый вариант для возможностей подключения, в котором представители защищенно соединяются по открытой сети, такой как Интернет.

[0090] Дополнительно, варианты осуществления настоящего изобретения включают в себя преимущества для сторонних поставщиков услуг. Например, различные варианты осуществления предоставляют сторонним поставщикам услуг инфраструктуру, в которой можно разрабатывать и представлять на рынке программное обеспечение и SaaS для транзакционных услуг. Инфраструктура может включать в себя подключаемые модули или примеры кода, чтобы давать возможность разработчикам быстро интегрировать свои транзакционные услуги и платформы в шлюзовой уровень абстракции и/или GAL-шлюз. Кроме того, посредством принудительного пропускания всей обработки платежей продавцов через один шлюз, собственные дополнительные услуги могут согласованно применяться ко всем брендам карт вместо конкретного для платежной сети применения собственных дополнительных транзакционных услуг.

[0091] Стандартные или канонические модели, форматы и протоколы сообщений

[0092] Модуль 1010 организации транзакций на шлюзовом уровне абстракции может использовать и включать в себя одну стандартную или каноническую систему моделей, форматов и протоколов сообщений. При использовании в данном документе для понятности, термин "стандартный формат" означает совокупность стандартных или канонических моделей, форматов и протоколов сообщений. Например, логическая модель в основе стандартного формата может быть спроектирована в UML и переведена в XML-схему. XML может быть использован в качестве одного формата на уровне соединения для всего обмена сообщениями, но XML может заменяться или пополняться для поднабора сообщений посредством другого формата на уровне соединения, к примеру, двоичного или текстового, т.е. CSV, фиксированного формата и т.д. Такие альтернативные форматы на уровне соединения могут быть использованы для того, чтобы справляться с проблемами пропускной способности или задержки.

[0093] В некоторых вариантах осуществления могут быть написаны или сгенерированы комплекты разработчика программного обеспечения (SDK), чтобы предоставлять возможность сторонним поставщикам услуг и внешним брендовым платежным сетям передавать сообщение по GAL-шлюзу. SDK может быть написан на различных языках, таких как Java, Ruby, C/C+/C++, Perl и т.д. Форматы на уровне соединения, используемые в GAL, следовательно, могут быть независимыми от языка, так что они работают и поддерживают связь со всеми SDK. Соответственно, серийные Java-объекты не являются подходящими в качестве формата на уровне соединения.

[0094] Стандартные или канонические форматы могут быть разделены на определенное число групп бизнес-ориентированных процессов. Каждая группа бизнес-ориентированных процессов может быть ассоциирована с уникальным идентификатором, который может быть использован для того, чтобы обращаться к процессу. Например, группы бизнес-процессов могут представлять собой "транзакции по кредитной карте, "счета", и "биллинг", которые могут быть ассоциированы с такими сокращениями, как "cctx", "acct", и "bill", соответственно. Группа бизнес-ориентированных процессов может включать в себя сообщения для сбора при аутентификации или только для авторизации.

[0095] Стандартный или канонический формат может быть сохранен в качестве XMI, который является форматом сериализации OMG для UML, и, следовательно, может быть отредактирован с использованием любого типового UML-инструментария, такого как MagicDraw™. Например, MagicDraw™ может быть использован для того, чтобы формировать XML-схемы посредством использования своего мастера формирования отчетов, который использует настраиваемые шаблоны производительности. Шаблоны производительности также могут являться частью системы сборки, которая может быть отделена от UML-моделей. В таких вариантах осуществления, простые пользовательские настройки могут быть использованы для того, чтобы формировать идентичные схемы из других инструментальных UML-средств с использованием любых механизмов формирования схемы, которые предлагают эти инструментальные средства.

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

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

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

[0098] Примерная архитектура системы

[0099] Фиг. 10 является принципиальной схемой системы согласно и допускающей реализацию различных вариантов осуществления настоящего изобретения. Как показано, модуль 1010 организации транзакций на шлюзовом уровне абстракции (GAL/TC) может быть центром обеспечения возможностей подключения между обширным диапазоном систем, компонентов и объектов. GAL/TC 1010 может быть выполнен с возможностью транслировать или преобразовывать сообщения, файлы и передаваемые данные между определенным числом различных форматов и/или протоколов. Например, GAL/TC 1010 может быть выполнен с возможностью подключаться к сетям обработки платежей, процессорам обслуживания платежей, пользователям и продавцам с использованием различных SDK 1060 через соответствующие новые и существующие конечные точки 1030 и 1050 предоставления услуг (SE), разработанные посредством сторонних поставщиков услуг с использованием одного или более стандартных или канонических форматов сообщений.

[0100] В различных вариантах осуществления все компоненты и функциональность, показанные в группе 1070, могут быть выполнены посредством компонентов, модулей, компьютеров и логики, выполняемой или работающей на стороне сервера процесса. Аналогично, функциональность существующих внутренних интерфейсных реализаций и новых SDK, используемых для того, чтобы взаимодействовать с GAL/TC 1010, может выполняться на удаленных (либо находящихся на стороне клиента) компьютерах в местоположении пользователя или продавца. В другом варианте осуществления, такая функциональность выполняется на другом серверном компьютере, ассоциированном с пользователем или продавцом. В каждом из таких вариантов осуществления, каждый ввод и вывод между GAL/TC 1010 может доставляться через интерфейс, упрощенный посредством еще одного GAL SDK 1080 или 1090. GAL SDK могут включать в себя, но не только, SDK и API, сконструированные на Java, Perl, Ruby, C+и т.д.

[0101] API-архитектуры

[0102] Варианты осуществления настоящего изобретения основываются на различных уровнях интерфейсов платформы приложений или API. Каждый API может единичным либо совокупностью API для предоставления услуг, которые представляют собой поднабор большей совокупности шлюзового уровня абстракции API для предоставления финансовых и других транзакционных и информационных услуг. Например, совокупность API может включать в себя розничный API (RAPI), который может быть реализован посредством совокупности компонентов, включенных в модуле 1010 организации транзакций на шлюзовом уровне абстракции. Модуль 1010 организации транзакций на шлюзовом уровне абстракции может принимать запросы на предоставление услуг и выполнять в них последовательность преобразований до передачи в оптовый интерфейс платформы приложений (WAPI). Преобразования могут включать в себя изменения протокола, расширение, агрегирование, проверку достоверности, аутентификацию и авторизацию. Фиг. 11 является высокоуровневой схемой модуля 1110 организации транзакций на шлюзовом уровне абстракции RAPI.

[0103] Фиг. 11 показывает, что модуль 1110 организации транзакций на шлюзовом уровне абстракции может включать в себя различную функциональность, модули или компоненты для того, чтобы управлять услугами хранения, обмена сообщениями и преобразования для диапазона коммерческих услуг согласно различным вариантам осуществления настоящего изобретения. RAPI-архитектура может включать услуги в модуль 1110 организации транзакций на шлюзовом уровне абстракции, который связывается с конечной HTTP-точкой, и таким образом, язык реализации, выбранный для каждой услуги, является независимым от языка других услуг. Например, каждая услуга может быть реализована на любом языке, таком как Java™ или XML. Услуги могут быть нестрого или строго связаны посредством модуля 1110 организации транзакций на шлюзовом уровне абстракции с другими языками. В частности, языковые средства модуля 1110 организации транзакций на шлюзовом уровне абстракции могут включать в себя Vmware vFabric, SpringRoo и Spring Integration. VFabric может включать в себя определенное число технологий, которые могут предоставлять инфраструктуру для RAPI, которые могут включать в себя PaaS Provision, Tc Server, Gemfire, Hyperic, RAbbitMQ и ERS.

[0104] Модуль 1110 организации транзакций на шлюзовом уровне абстракции, показанный на фиг. 11, может включать в себя функциональность, компоненты или подсистемы, сконструированные на любом надлежащем языке, к примеру, преобразователь 1111 запросов на проверку достоверности счетов (AVS) в стандартные/канонические запросы, AVS-услуга 1112 модуля организации транзакций на шлюзовом уровне абстракции (GAL/TC) и преобразователь 1113 стандартных запросов в WAPI AVS-запросы. Вышеуказанная поддержка в модуле 1110 организации транзакций на шлюзовом уровне абстракции дает возможность вариантам осуществления принимать сообщения и запросы на стандартном формате, такие как SOAP AVS-веб-запрос 1120, в AVS WAPI-веб-запрос 1130 на предоставление услуг, который должен отправляться в один или более объектов для обработки. Эти средства обмена сообщениями и преобразования могут формировать абстрактные типы сообщений, которые могут включать в себя нормализованный расширенный набор полей и данных, в типах сообщений и протоколах связи, предоставляемых посредством других объектов. После того, как канонический или стандартный тип сообщений реализуется, услуги модуля 1110 организации транзакций на шлюзовом уровне абстракции могут быть разработаны таким образом, что они требуют только информацию канонических или стандартных типов сообщений вместо структур или языков, на которых они написаны (таких как XML, SOAP, JSON и NVP) каких-либо других объектов, производителей или сторонних поставщиков услуг. Добавление поддержки новых форматов требует просто нахождения, установки и интеграции API-поставщика Java-привязок.

[0105] Поддержка различных типов сообщений внешних объектов, производителей и сторонних поставщиков услуг требует только формирования модуля, который преобразует контент из типа или формата сообщений объектов, производителей и сторонних поставщиков услуг в стандартный либо канонический тип или формат. Предоставление стандартной или канонической формы для каждой услуги обеспечивает возможность хостинга RAPI в инфраструктуре модуля 1110 организации транзакций на шлюзовом уровне абстракции, чтобы использовать множество преимуществ и услуг, которые он предоставляет, таких как аналитическая обработка и другие собственные дополнительные услуги, упомянутые в данном документе. Как показано на фиг. 11, для любого конкретного вызова по предоставлению услуг модуля 1110 организации транзакций на шлюзовом уровне абстракции, данные входящих сообщений могут быть преобразованы в надлежащий стандартный или канонический формат либо представление и затем внутренне обработаны до тех пор, пока вызов не достигает WAPI-услуги, в которой стандартное или каноническое сообщение преобразуется в соответствующий формат исходящих или WAPI-сообщений.

[0106] Каждая стандартная или каноническая Java-модель может формироваться из документа XML-схемы (XSD), который описывает различные структуры и ограничения. XSD-документ может формироваться из XMI-описания на унифицированном языке моделирования (UML) для упрощения сопровождения. Модули преобразователя, показанные на фиг. 11, могут быть основаны на Java-технологии и сформированы вручную, посредством заполнения стандартной или канонической формы из исходного типа сообщений или сформированы автоматически из такого компонента, как ADS, который может выводить Java-код, чтобы выполнять заполнение полей, как сконфигурировано посредством графического пользовательского интерфейса.

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

[0108] Система 1200 представляет компьютерную систему, допускающую осуществление настоящего изобретения. Компьютерная система может присутствовать в любом из элементов на фиг. 1-7, включающих в себя GAL-шлюз 100, описанный выше. Специалистам в данной области техники должно быть очевидным, что множество других аппаратных и программных конфигураций подходит для использования с настоящим изобретением. Например, компьютер может быть настольным, портативным, смонтированным в стойке или планшетным. Дополнительно, компьютер может быть последовательностью объединенных в сеть компьютеров. Дополнительно, подразумевается использование любых микропроцессоров, таких как микропроцессоры Xeon™, Pentium™ или Core™; микропроцессоры Turion™ 64, Opteron™ или Athlon™ компании Advanced Micro Devices, Inc; и т.п. Дополнительно, подразумеваются различные типы операционных систем, такие как Windows®, Windows XP®, Windows NT® и т.п. компании Microsoft Corporation, Solaris компании Sun Microsystems, LINUX, UNIX и т.п. В еще одних других вариантах осуществления, технологии, описанные выше, могут быть реализованы на кристалле или вспомогательной плате обработки. Различные варианты осуществления могут быть основаны на системах, предоставляемых посредством daVinci, Pandora, Silicon Color или других производителей.

[0109] В одном варианте осуществления компьютерная система 1200 типично включает в себя дисплей 1210, компьютер 1220, клавиатуру 1230, устройство 1240 пользовательского ввода, компьютерные интерфейсы 1250 и т.п. В различных вариантах осуществления, дисплей (монитор) 1210 может быть осуществлен в качестве CRT-дисплея, ЖК-дисплея, плазменного дисплея, DLP с прямой проекцией или задней проекцией, микродисплея и т.п. В различных вариантах осуществления, дисплей 1210 может быть использован для того, чтобы отображать пользовательские интерфейсы и подготовленные посредством рендеринга изображения.

[0110] В различных вариантах осуществления устройство 1240 пользовательского ввода типично осуществляется в качестве компьютерной мыши, шарового манипулятора, сенсорной панели, джойстика, беспроводного пульта дистанционного управления, чертежного планшета, системы на основе речевых команд и т.п. Устройство 1240 пользовательского ввода типично позволяет пользователю выбирать объекты, значки, текст и т.п., которые отображаются на мониторе 1210, посредством такой команды, как щелчок кнопки и т.п. Дополнительное специализированное устройство 1245 пользовательского ввода, такое как устройство считывания магнитных полос, приемо-передающее RFID-устройство или устройство считывания смарт-карт, также может предоставляться в различных вариантах осуществления. В других вариантах осуществления, устройство 1245 пользовательского ввода включает в себя дополнительные дисплеи компьютерной системы (например, несколько мониторов). Дополнительное устройство 1245 пользовательского ввода может быть реализовано как один или более графических пользовательских интерфейсов на таком дисплее.

[0111] Варианты осуществления компьютерных интерфейсов 1250 типично включают в себя Ethernet-карту, модем (телефонный, спутниковый, кабельный, ISDN), модуль (асинхронной) цифровой абонентской линии (DSL), FireWire-интерфейс, USB-интерфейс и т.п. Например, компьютерные интерфейсы 1250 могут быть подключены к компьютерной сети, к FireWire-шине и т.п. В других вариантах осуществления, компьютерные интерфейсы 1250 могут быть физически интегрированы на материнской плате компьютера 1220, могут быть программой, к примеру, программной DSL и т.п.

[0112] RAM 1270 и накопитель 1280 на дисках являются примерами машиночитаемых материальных носителей, выполненных с возможностью сохранять данные, такие как пользовательские данные, данные счетов, данные продавцов, данные сторонних поставщиков услуг, данные платежных сетей, базы данных и таблицы поиска уровня абстракции, и другой выполняемый машинный код, воспринимаемый человеком код и т.п. Другие типы материальных носителей включают в себя магнитные носители данных, такие как гибкие диски, сетевые жесткие диски, съемные жесткие диски; оптические носители хранения данных, такие как CD-ROM, DVD, голографические запоминающие устройства и штрих-коды; полупроводниковые носители, такие как флэш-память, постоянное запоминающее устройство (ROM); энергозависимые запоминающее устройства с аварийным аккумуляторным питанием; сетевые устройства хранения данных и т.п.

[0113] В настоящем варианте осуществления компьютерная система 1200 также может включать в себя программное обеспечение, которое обеспечивает связь по сети, например, по HTTP-, TCP/IP-, RTP/RTSP-протоколам и т.п. В альтернативных вариантах осуществления настоящего изобретения также могут быть использованы другое программное обеспечение для связи и протоколы передачи, например, IPX, UDP и т.п.

[0114] В различных вариантах осуществления компьютер 1220 типично включает в себя общеизвестные компьютерные компоненты, такие как процессор 1260 и запоминающие устройства, такие как оперативное запоминающее устройство (RAM) 1270, накопители 1280 на дисках, и системную шину 1290, соединяющую между собой вышеуказанные компоненты.

[0115] В некоторых вариантах осуществления компьютер 1220 включает в себя один или более микропроцессоров Xeon компании Intel. Дополнительно, в настоящем варианте осуществления, компьютер 1220 типично включает в себя операционную систему на основе UNIX.

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

[0117] Любые из программных компонентов или функций, описанных в данной заявке, могут быть реализованы как программный код, который должен выполняться посредством процессора с использованием любого надлежащего машинного языка, такого как, к примеру, Java, C++ или Perl, с применением, к примеру, традиционных или объектно-ориентированных технологий. Программный код может быть сохранен как последовательность инструкций или команд на машиночитаемом носителе, таком как оперативное запоминающее устройство (RAM), постоянное запоминающее устройство (ROM), магнитный носитель, такой как жесткий диск или гибкий диск, или оптический носитель, такой как CD-ROM. Любой такой машиночитаемый носитель может размещаться в рамках одной вычислительной аппаратной системы либо может присутствовать или находиться внутри различных вычислительных аппаратных систем в рамках системы или сети.

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

[0119] Один или более признаков из любого варианта осуществления могут комбинироваться с одним или более признаков любого другого варианта осуществления без отступления от объема изобретения.

[0120] Указание в единственном числе имеет намерение означать "один или более", если не указано прямо иное.

Изобретение относится к способам и компьютерному устройству для обработки данных транзакции. Технический результат заключается в автоматизации обработки данных транзакции. В способе передают c компьютера продавца или эквайера на шлюзовой сервер сообщение запроса на предоставление услуг в соответствии с первым форматом данных через первый интерфейс платформы приложений (АРI) независимо от требований стандарта связи поставщика услуг или платежной сети, шлюзовой сервер анализирует данные запроса, содержащие идентификатор поставщика услуг, для доступа к базе данных уровня абстракции, преобразует данные запроса во второй формат данных для обмена данными с поставщиком услуг, отличный от первого формата данных, отправляет сообщение вызова услуги поставщику услуг через второй АРI, содержащее преобразованные данные запроса, анализирует данные запроса на авторизацию по транзакции из сообщения запроса, содержащие идентификатор платежной сети, преобразует данные запроса на авторизацию в третий формат данных для обмена данными с платежной сетью, отличающийся от второго формата данных, передает сообщение запроса на авторизацию в платежную сеть, содержащее преобразованные данные запроса, и управляет изменениями требований стандарта связи поставщика услуг и платежной сети. 3 н. и 22 з.п. ф-лы, 12 ил.

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

устанавливают c компьютера продавца или эквайера связь с шлюзовым сервером;

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

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

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

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

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

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

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

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

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

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

3. Способ по п. 2, в котором база данных уровня абстракции содержит таблицу поиска стандартов связи или АРI.

4. Способ по п. 3, в котором таблица поиска содержит соответствие преобразований между первым АРI и вторым АРI.

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

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

7. Способ по п. 1, в котором шлюзовой сервер принимает сообщение ответа на авторизацию по транзакции от платежной сети и преобразует сообщение ответа на авторизацию по транзакции в формат данных, совместимый с первым АРI, при этом в способе дополнительно:

принимают от шлюзового сервера на компьютер продавца или компьютер эквайера преобразованное сообщение ответа на авторизацию по транзакции по первой АРI.

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

9. Способ по п. 1, в котором шлюзовой сервер использует канонический формат сообщения.

10. Способ по п. 9, в котором канонический формат сообщения представляет собой XML формат.

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

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

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

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

процессор, и

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

устанавливают связь с шлюзовым сервером;

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

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

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

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

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

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

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

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

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

15. Компьютерное устройство по п. 14, в котором шлюзовой сервер получает результат от поставщика услуг и передает результат компьютеру продавца, компьютеру эквайера или платежной сети.

16. Компьютерное устройство по п. 15, в котором база данных уровня абстракции содержит таблицу поиска стандартов связи или интерфейсы платформы приложений АРI.

17. Компьютерное устройство по п. 16, в котором таблица поиска содержит соответствие преобразований между первым АРI и вторым АРI.

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

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

20. Компьютерное устройство по п. 14, в котором шлюзовой сервер принимает сообщение ответа на авторизацию по транзакции от платежной сети и преобразует сообщение ответа на авторизацию по транзакции в формат данных, совместимый с первым АРI, при этом в способе дополнительно:

принимают от шлюзового сервера на компьютерное устройство преобразованное сообщение ответа на авторизацию по транзакции по первой АРI.

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

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

принимают на компьютер поставщика услуг от шлюзового сервера запрос на предоставление услуг, при этом шлюзовой сервер сконфигурирован для:

установления связи с одним из множества компьютеров продавца или компьютеров эквайера,

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

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

осуществления доступа к базе данных уровня абстракции, чтобы определить

поставщика услуг, используя идентификатор поставщика услуги;

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

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

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

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

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

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

23. Способ по п. 22, в котором дополнительно

обрабатывают вызов услуги посредством компьютера поставщика услуг;

формируют результаты посредством компьютера поставщика услуг на основе обработки вызова услуги;

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

24. Способ по п. 23, в котором база данных уровня абстракции содержит таблицу поиска стандартов связи или АРI.

25. Способ по п. 24, в котором таблица поиска содержит соответствие преобразований между первым АРI и вторым АРI.