发明内容
本发明的各方面的目的在于解决这些问题中的至少一些,并且根据本发明的一个方面,提供了用于实施交易请求的交易网关设备,所述设备被配置成接收交易请求数据、基于所述交易请求数据来选择多个工作流中的要被执行的一个工作流,所述多个工作流中的要被执行的一个工作流限定了所述设备和所述工作流中所指定的交易服务提供商之间的交易数据路线,其中所述设备被配置成:
-显示限定了工作空间的用户界面,在所述工作空间内,用户能够配置工作流;
-访问多个模块、多个规则集,每个模块限定了对应的服务提供商功能,所述多个规则集限定了对于交易数据路线遵循工作流的指定路径来说要履行的条件;
-在所述工作空间中显示表示所述模块和规则集的可选择数据;
-使用户能够通过下述内容来配置工作流的视觉表示:
o选择与工作流相关联的交易类型或参数;
o选择要被包含在所述工作流中的一个或更多个模块与规则集的组合,所述设备被配置成在所述工作空间中显示所选择的组合;
o选择性地限定所述模块和/或规则集之间的视觉链接,以限定对应的工作流路径;
以及
-在确定由所述设备接收的交易请求数据同与所述工作流相关联的交易类型或参数相匹配的情况中,基本上实时地将用户所配置的工作流转换成能执行的交易数据路线以用于执行。
用户界面可以被配置成将用户所配置的工作流显示为图形图像。所述规则集中的至少一些可以具有与之相关联的优先级值,并且其中,所述设备可以被配置成在工作流中识别两个或更多个冲突的规则集。在这种情况中,设备可以 被配置成基于所述冲突的规则集的优先级值,选择所述冲突的规则集中的一个,以用来在所述工作流中执行;和/或当在工作流中识别出两个或更多个冲突的规则集的情况中生成并显示错误消息。
根据本发明的一个示例性实施例,设备可以被配置成使用户能够限定一个或更多个规则集。在这种情况中,设备可以被配置成通过显示表示可选择条件语句的数据并且使用户能够选择一个或更多个条件语句并输入与一个或更多个条件语句相关的指定参数,来使用户能够限定一个或更多个规则集。
设备可以包括处理引擎和后台(back office)模块,其中,所述后台模块被配置成提供所述用户界面,并且所述处理引擎被配置成执行将用户所配置的工作流到能执行的交易数据路线编码的转换。所述处理引擎和所述后台模块经由表述性状态转移(REST)服务而被可通信地耦接以用于双向通信。在一个示例性实施例中,预限定的所述规则集和所述模块可以被储存在能由所述处理引擎和/或所述后台模块所访问的数据库中。
根据本发明的另一个方面,提供了一种交易管理系统,其包括用于接收交易请求数据的用户交易接口和基本上如前文所述的交易网关设备,所述交易网关设备被配置成根据由与所述交易请求数据的参数相关联的工作流所限定的交易数据路线,经由多个交易服务提供商中的所选择的一个来实施交易。
所述用户交易接口和所述交易网关设备经由REST服务而被可通信地耦接以用于双向通信。交易网关设备可以被配置成响应于从所述用户交易接口接收到的认证数据而执行用户认证操作。
根据本发明的又一方面,提供了一种在基本上如前文所述的设备中生成用于定向并实施交易请求的交易数据路线的方法,所述方法包括:
-显示限定了工作空间的用户界面,在所述工作空间内,用户能够配置工作流;
-访问多个模块、多个规则集,每个模块限定了对应的服务提供商功能,所述多个规则集限定了对于交易数据路线遵循工作流的指定路径来说要履行的条件;
-在所述工作空间中显示表示所述模块和规则集的可选择数据;
-使用户能够通过下述内容来配置工作流的视觉表示:
o选择与工作流相关联的交易类型或参数;
o选择要被包含在所述工作流中的一个或更多个模块与规则集的组合,所述设备被配置成在所述工作空间中显示所选择的组合;
o选择性地限定所述模块和/或规则集之间的视觉链接,以限定对应的工作流路径;
以及
-在确定由所述设备接收的交易请求数据同与所述工作流相关联的交易类型或参数相匹配的情况中,将用户所配置的工作流转换成能执行的交易数据路线以用于执行。
本发明的各方面延伸至包括用于使计算机执行基本上如前文所述的方法的计算机编码装置的计算机程序元件。
因此,本发明的各示例性方面解决了上述问题,并且实现了向单一网关功能的交易管理系统中的合并,其中,工作流可以被实时地(以及在线地)配置和重新配置,以取决于所请求的交易的类型或参数,对要被定向至一个或其他交易解决方案或服务的交易数据流进行定向。EPG(Electronic Program Guide(电子节目指南))平台仅需要一个简单的合并。一旦被并入平台中,所有其他第三方合并便由网关设备实施。通过使用能够供非技术操作者使用而设计的技术创新的后台,商户能够经由电子网关平台的示例性实施例而十分容易地管理各个和每个服务与支付解决方案。在本发明的各种示例性实施例中:
·解决方案可以被实时地开启或关闭,而无需对所提供的服务的任何中断。
·解决方案可以被配置成基于顾客的国家和货币来向顾客进行显示。
·可以对用于解款和支取的不同解决方案应用限制,所有都是基本上实时的。
·可以维护具有每个服务/支付解决方案的商户账户,所有都从一个位置进行。这意味着商户能够基于他们想要的任意规则组合来配置个人支付解决方案 和服务,特别地对于他们所具有的每个出纳机/付款台或甚至下延至顾客级别,所有均基本上实时地来自于上述“后台”。
具体实施方式
本文所描述的电子网关系统、设备和方法解决了在无需离线进行编译的情况下如何基本上实时地完成对交易数据路由的在线配置(和/或重新配置)的技术问题。特别地,根据本发明的一个示例性实施例的系统从单个平台向多个交 易方法和/或支付解决方案提供单个可配置的电子网关,其中,与每个交易路线相关的参数和条件可以被选择性地且独立地配置和/或重新配置,而无需重新部署任何软件编码。
参照附图中的图1,包括根据本发明的一个示例性实施例的电子网关系统的交易应用可以被认为包括四个主要部件,即网络出纳机10、支付引擎12、后台14以及数据库16。
参照附图中的图2,可以看出可以以自包含包的形式提供根据本发明的一个示例性实施例的平台,能够由商户经由其现有平台直接地访问该自包含包,如本领域网关系统目前所要求的,所有都通过单个API合并而非对所提供的每个支付解决方案或服务分别进行合并。
总之(以及如将在本文中更详细地进行描述的),网络出纳机10是独立的一个软件,该软件从商户的网站接受参与者/顾客的请求(例如存款(deposit))、验证所传递的数据、通过其专用API中的合适的服务或支付方法进行通信、转而接收被认可的或被拒绝的通信、以及记录整个过程的数据和结果(后台)。
然而,典型地,公司已经在一对一的基础上将其出纳机/网站合并至电子钱包,这在实际上很花费时间并且因此成本高昂。在另一个方面,根据本发明的一个示例性实施例的平台给予商户经由多种不同的领先支付方法以及访问作为包的诸如ID或地址验证服务的多个服务来在线以及经由销售点来接受付款的能力,关键是无需任何额外的开发。
此外,平台可以被配置成通过将记录每个单独交易和相关联的数据的全功能后台包括在内来满足商户的计划与报告需求。如果需要的话,能够以每次交易的精细详情水平来查看该被记录的数据,但是该被记录的数据也可以被表示为综合的报告、表格以及图表。如果有需要,该工具也可以允许商户根据基本数据来创建商户自己的报告和图表。
重新参照附图中的图1,如该图所示出的,网络出纳机10模块和后台模块通过对应的REST服务被可通信地耦接至支付引擎12。REST(Representational State Transfer)表示表述性状态转移,并且依赖于无状态、客户机-服务器、可 缓存的通信协议,其中,在本情况中(以及几乎所有其他情况)使用了HTTP协议。REST将被本领域的技术人员所熟知为用于设计联网应用程序的架构式样,其理念为通过仅使用HTTP在机器间进行调用,来替代使用复杂机制在机器之间进行连接。在上述模块中所提供的各个REST服务使用了HTTP请求来发布数据(创建和/或更新)、读取数据(例如,进行查询)以及(在恰当的情况中)删除数据。
支付引擎12和后台14经由将被本领域技术人员所已知的DAO(Data AccessObjects(数据访问对象))应用程序接口而被连接至数据库16。
在需要提供无用户在场的自动服务(例如,在线)的系统中提供网络出纳机10,然而直接调用功能18或直接连接应用程序接口(DC-API,Direct Connection ApplicationProgram Interface)可以被用于‘正常的’出纳机或销售点终端的情况中。根据应用和用户喜好,该系统可以包括这两个选项中的一个或两个,并且在这点上本发明并非旨在以任何方式被限制。
网络出纳机10可以被视为整个系统的顶层元件,并且为商户提供接口以允许最终用户(即,顾客)执行支付以及各种其他操作(例如,查看过去的交易)。网络出纳机在自身中是完整的MVC(Model-View-Controller(模型-视图-控制器))应用,该应用将引擎12用作访问数据库16和检索呈现所需信息所需要的数据(例如,可用于特定配置的支付方法)的‘桥梁’。参照附图中的图3,网络出纳机10的结构以及网络出纳机10与系统的其他模块通信的方式被示例性地示出。
如示意性地示出的,在网络出纳机10内使用了网络服务20,以按需提供创建复杂流程所需的灵活性(如将在下文更详细地描述的那样)。网络出纳机10与REST层22进行通信,以使用中间层来在引擎12上执行所需的操作。将在下文更详细地涉及到引擎12。
网络出纳机10在其标准配置中具有四个主要使用模式,即存款、取款、支付管理以及受理中的取款。然而,将要理解的是,处了这四个默认模式之外,网络出纳机也可以处理其他过程,例如包括支付方法列表检索、会话逾期处理、 对其中显示该应用的浏览器的识别、以及定位。然而,交易过程本身被委托给引擎12,使得网络出纳机是相对简单的表示层。
为了调用网络出纳机,商户需要通过使用安全连接和加密后的密码以及商户服务器IP地址的已知列表(如将在下文中更详细地进行描述的那样)认证电子网关平台,来执行一些内部调用以检索在网络出纳机寿命期间内所使用的安全令牌。执行上述内容是为了确保连接的安全性,并且避免该配置中的未被授权的用户修改。
在对系统的连续使用期间,当出纳服务被启动时(即,要求执行交易),网络出纳机请求来自于引擎12的所选信息。该信息包括系统的整个运行所必需的基本配置信息,尤其在错误的情况中。
以下信息可以被首先需要,以防在已加载更深入的信息之前有任何错误:
·商户列表;
·当顾客被连接至特定商户时显示给顾客的默认错误页面;
·向顾客表明未能找到会话信息的整个默认错误页面;以及
·对于商户中的每一个,与该商户相关联的显示名称。
当然,将要理解的是,至少对于一些系统而言,为了系统的充分运行,可以要求可替代的或附加的初始信息,并且在这点上本发明并不旨被限制。可以从引擎取得相同的信息(定期地或其他方式),以及时了解自初始启动以来所发生的任何改变。
商户可以出于初始认证的目的来执行预登录调用,并且预登录调用包括从引擎到商户所进行的第一调用。该调用可以包含下述信息中的任一项或全部:
·商户的标识符
·顾客的名
·顾客的姓
·顾客的注册日期
·顾客进行交易所用的语言类型
·将被显示给顾客的所托管的流程的区域,例如用来列出存款页面的存款(Deposit)
·货币
·顾客的国家
·调用的校验和
·顾客会话的唯一标识符,
建议该顾客会话的唯一标识符不引用由java或任何其他语言所自动维护的会话id,而是该标识符可以是被附加至顾客会话的非连续的唯一随机字符串。
·顾客的地址—可选的但可能是给定装置所需要的
·附加至顾客账户的任何账户评论—可选
·支付解决方案—允许顾客进行的支付解决方案
如果操作不是“存款”或“取款”,将发布警告—可选
·金额—被登录账户的货币上的数值。
如果金额已被填入并且操作没有被设置成“存款”或“取款”,则在响应中将返回错误。如果该数值之后被填入并且正确地指定了操作,那么顾客将可进行快速的存款或取款。希望这些内容主要地被用于零售交易的情况中。这基本上意味着将预先生成金额字段并且将显示相关的存款/取款页面模板。
·顾客的账户ID
·希望在顾客交易的同时被显示在实时报告部分中的任何额外的详情
·余额—可选,然而如果顾客的余额需要被显示在所托管的流程内,那么该内容将是必要的。
·版本—即被调用的API调用版本(以确保所接收的结果格式与所使用的版本相兼容)。
因此,当用户希望打开出纳机时,商户将利用用户信息(用户ID、用户IP、国家、货币、语言…)来执行对位于支付引擎中的内部API的调用,内部API将利用该信息来创建注册记录,并且还生成唯一的一次性使用令牌,该一次性使用令牌将会被提供给商户。商户将能够使用这个令牌(这个令牌将是与用户IP相链接的加密会话令牌)将用户重定向至出纳机。当网络出纳机被调用时, 要做的第一件事情将是提取令牌,检验用户是否来自于正确的IP,并且之后检索被储存在系统中的敏感数据。也可以做出规定来确保请求不是来自于用户机器,这便是商户为何在之前执行请求令牌的操作。
这些令牌被储存在数据库中,并且被链接至用户配置(用户ID、IP、国家、货币、语言…)。出纳机基于所返回的配置来使用该信息以向顾客呈现相关的页面和可用的操作。
图4示出了商户如何请求出纳机的实例的顺序图。在初始调用之后,引擎应该将顾客重新引导至出纳机内的URL;传递与该顾客相关联的预登录调用标识符。
示例:http://merchanturl.cashier.com/cashier?token=2342ksdfls
顾客最后一次被重定向回到EPG引擎,这一次传递在预登录调用之后初始返回的会话ID,该会话ID应当从顾客的会话中被读取,而不应当从对调用内容的查找中被读取。会话ID将被用作对如下的确认:顾客确实是其本人以及对没有第三方已干涉两个服务器(商户服务器和EPG服务器)之间的通信。
这种双重保密的方法允许没有经由第三方干涉的安全登录。由于存在对会话的依赖性,因此该方法也防止了重定向URL被任何其他顾客使用。EPG出纳机可以被装载在内嵌框架(iframe)中,或可以完全独立。出纳机的框架是可由商户100%自定制的,并且也可以友好地移动以及响应。
配置检索
如果商户的合适配置已经被缓存并且缓存没有过期,则不会针对商户配置来对引擎进行调用。如果详情没有被缓存在存储器中或已经过期,则将针对相关的商户详情来对引擎进行调用,并传递商户ID、货币以及国家。该调用将很可能通过REST来进行。一旦接收到响应,该响应将被缓存在存储器中维持指定的时长。注意到该调用仅在顾客的当前国家和语言中检索用于商户的配置;这使得我们不需要向系统中加载不必要的数据。
配置响应
一个成功的结果可具有下述详情:
·该配置所引用的商户ID
·该配置所引用的货币
·该配置所引用的国家
·对于该商户、国家以及货币的组合来说可用的支付解决方案的列表。对于这些支付解决方案中的每一个,我们需要下述信息来进行存款和取款二者:
o是否允许(注意到如果货币不允许被存款或取款,则其应当从该列表中完全地删除该货币)
o可以进行的最大交易金额
o可以进行的最小交易金额
o该方法是否允许货币兑换?
o该方法是否需要进行货币兑换?
o可以被兑换成哪种货币?-当选择货币兑换时才需要
o货币兑换的收费是多少?-仅当选择货币兑换时才需要
o任何受理中的取款
o出纳机的外观和感观配置
如果响应不成功,则顾客可以利用预定错误消息而被重定向至相应的错误页面。
如上所述,将通过本发明的各个方面寻求解决的主要技术问题是如何基本上实时地完成交易数据路由的在线配置(和/或重新配置)而无需为了编译而离线进行。特别地,根据本发明的一个示例性实施例的系统从单个平台向多个交易方法和/或支付解决方案提供单个可配置的电子网关,其中,与每个交易路径相关的参数和条件可以被选择性地且独立地配置和/或重新配置,而无需重新部署任何软件编码。通过使用所谓的工作流,上述内容在本发明的该示例性实施例中得以实现,工作流基本上包括‘路线图’,‘路线图’针对每个给定的交易请求来告诉引擎将要做什么以及要遵循的数据路径。用户能够配置以及重新配置这样的工作流,并且就本文所提出的方法学的本质而言,能够如应用所需要的一样简单或一样复杂。由本发明的各个方面所提供的用户界面相对易于使用, 并且在一个示例性实施例中,用户可以简单地将模块‘拖拽’到屏幕上并且将这些模块链接至其他模块以创建对所期望的工作流的视觉表示。此外,用户可以将模块和流程链接至规则集,使得可以基于所限定的规则集的决策和结果利用多个内部路线来创建工作流。
图5示出了使用本发明的一个示例性实施例所创建的工作流的屏幕截图。可以看出,工作流创建过程开始于规则集源模块100,该规则集源模块100对应于特定的交易请求(在本情况中,为信用卡存款)。在所限定的规则集中提供了两个规则集块102,并且这两个规则集块102分别通过箭头104a、104b被‘链接’至规则集源模块。可以看到,在这个特定的工作流中,存在两个货币规则,其结果限定了将被用于交易的外部支付服务。因此,如果以英镑(GBP)进行交易,则工作流按照左侧的流程进行并且被链接至第一服务提供商的授权模块106b和捕获模块108b。如果以欧元(Euros)进行交易,则工作流按照右侧的流程进行并且被链接至第二服务提供商的授权模块106a和捕获模块108a。
用户能够创建并储存他们的工作流,之后用户能够访问工作流修改历史以在对将来做出的任何修改进行复原,以及恢复被删除的流程。可以对工作流中的每一项指定工作流优先级,使得如果工作流或工作流中的规则与另一个发生了冲突,则引擎会知道这两个工作流中的哪一个处于优先,并且防止更低优先级工作流的内部错误和非故意执行。
如前所述,存在许多商户需要使用第三方供应商来托管支付或甚至储存顾客数据。有时这些商户不能够添加任何新的服务或支付解决方案,或这些商户完全地依赖于第三方服务。本发明的各方面允许商户将任何服务或解决方案相对容易地用作交易路线(或“工作流”)中的一部分,而无需涉及第三方技术支持并且无需任何的系统再开发。
图6示出了交易工作流的一个示例,该交易工作流被配置成将信用卡交易发送给预限定的信用卡收单方。取决于来自于收单方的结果,交易流程之后被终止,或在否定性结果的情况中,交易流程被发送至可替代的解决方案。
因此,工作流是根据本发明的一个示例性实施例的网关平台的关键要素, 并且基本上包括路线图或路径,路线图或路径针对每个给定的请求来告诉工作流引擎要做什么和去哪里,并且根据与本文所描述的工作流的创建相关联的本质和根本技术观念,工作流引擎可以被配置成在单个服务器上处理许多规则,例如每秒超过300个规则。
被结合到后台中的工作流引擎包括工作流编辑器,该工作流编辑器提供了用户界面,用户界面使用户能够使用包括模块和规则集的视觉显示要素以及以直观的方式对它们一起进行的链接来简单快速地配置和重新配置工作流。图7-图8示出了由上述工作流编辑器为商户创建的交易路线。商户可以通过将合适的操作框拖拽到主‘画布’上来十分容易地创建这样的工作流。使用简单界面来创建规则(参见图9),其中可以使用储存在数据库中或由商户经由应用程序接口(API)所传递的任何参数来创建条件。绘制线条以将每个操作框连接至合适的规则集。
存在许多类型的能够使用EPG平台来创建的流程。下面是能够使用根据本发明的一个示例性实施例的平台的最典型的流程中的一个小示例。
·最低成本路由
o基于处理成本,交易可以被路由至多个收单方。
·基于容量的路由
o交易可以被路由至不同的收单方以达到特定金额的容量,并且之后可以被容易地切换以路由至一不同的收单方。
·轮转法
o基于计数器,交易可以被路由至各不同的收单方
·身份检验
o顾客注册或支付可以被路由至身份检验服务以用于地址验证或年限检验。基于响应,商户能够决定终止请求还是继续。
·拒绝
o基于拒绝,交易可以被路由至各个收单方或可替代的解决方案。换言之,如果收单方拒绝,则可以实时地尝试对另一个/多个收单方进行同一 的请求。
·第三方平台
o有时商户需要将数据发送给第三方收单方。这可以作为用于任意类型请求(顾客注册、支付、转账等)的流程中的一部分来被做出。
·报告数据库
o可以进行调用来作为向内部或第三方报告/备份数据库实时地请求数据复制或备份的任何请求中的一部分。
·故障转移
o各不同的收单方或支付解决方案可以被链接至单个流程以防止故障转移
·替代的解决方案
o商户可以基于诸如金额、国家、货币、账户的年限等不同的条件,来路由至被合并至EPG平台中的支付解决方案中的任一种。
在附图的图10中示出了引擎架构的高层概览。重要的是在这里指出网络出纳机可以位于一不同的机器中,与系统的其余部分完全分离,这种决定取决于商户的部署策略。我们建议使出纳机位于单独的机器中,因为如果发生拒绝服务攻击,则出纳机在受到攻击的情况中(我们可能有多种不具有任何问题的情况)可以被断开连接,并且流程可以继续进行而不会影响核心系统。因此,当REST服务模块接收调用时,REST服务模块对信息进行解析,并验证用于标准交易的所有所需字段已经就位,并且如果一切运行良好,则REST服务模块将对负责执行操作的引擎进行调用。
工作流引擎
存在根据本发明的一个示例性实施例的网关系统的引擎的工作方式所基于的四个主要概念:
·步骤:适配器的操作执行,如信用卡授权,其中信用卡是适配器,授权是操作。
·规则:能够通过请求或每个步骤的结果来限定的规则中的每一个(例如, 规则的示例为:货币是英镑、金额大于100、所选择的支付方法是信用卡、或甚至来自于三维安全注册验证的编码参数的结果为是。)
·规则集:规则的集合,这些规则具有相关优先级,因此如果两个规则集应用于一个条目,则我们总可以决定我们将使用哪一个规则集。(在我们有两个具有相同优先级的规则集的情况中,因为在数据库中规则集是被排过序的,因此我们将得到列表中出现的第一个。)
·链接:如果应用了一个规则集,则两个步骤之间的链接限定了将要遵循的路径。
利用这四个要素,可以对流程以及系统将如何工作进行限定。典型的引擎过程情景由下述算法来限定(这是仅用于一般性理解的简化后的版本):
·获得限定了系统起始点的所有链接;这些链接提供了按照优先级排序的规则集。
·使用来自于REST服务(RestService)的请求Bean(Requestbean)(这是系统输入数据),通过规则集来执行迭代以检验规则集中的任一个是否与所输入的请求相匹配。在这种情况中,可以继续进行下述两种情景中的一种:
o如果请求不能被匹配,则产生错误,因为希望系统能够处理所有请求;或
o存在匹配,并且之后将执行步骤。为此,适配器被访问,并且操作运行(在该步骤中陈述这两个方面)。
·根据上一个步骤,来自于适配器的响应和初始响应,流程将尝试到达下一个步骤,并且该进程继续到达步骤和运行操作直到不再能够找到路径。
图示性地,在后台中(其为负责创建流程、步骤、规则、规则集和链接的系统的那部分),上述过程将看起来像图11中所示的屏幕截图。
后台合并
后台本身具有其自己的REST服务和后台引擎,并且后台通过直接与DAO对话来负责创建并管理如后台所指示的所有部件。偶尔,后台可能需要实时地通过系统来执行一些操作,例如返利,因此这便是后台引擎和引擎的REST服 务之间存在链接的原因。这使得能够经由后台来实时地执行操作。可以以这种方式对后台和主引擎进行解耦,因为在引擎所在之处不需要对后台进行部署。关于这个示例性基础结构的最重要的事情在于,开发该基础结构的方式不依赖于将运行该基础结构的服务器。不存在对应用服务器(或在Tomcat情况中的服务应用容器)所提供的任何函数库的依赖性,可以提供定制的函数库。
数据库遵循十分简单的表格结构,其不具有任何种类的存储程序或复杂类型,因此可以很快地整套搬到任何数据库,并且在将MyBatis用作服务器端的数据库框架的情况中,对数据库的修改与修改一些配置文件一样简单有效,因此能够以简明的方式适于任何需求。在可能使用Tomcat的情况中,情形是类似的:如果需要的话,则可以非常容易地转移至任何应用服务器(例如IBoss),因为不存在对随服务器函数库的依赖性。
数据库设计
根据本发明的一个示例性实施例的平台可以在其数据库中使用星型模式设计。因此,该平台将使用可以被配置成允许储存每个请求(例如支付请求或服务请求)可用的每个单个详情的各种各样的表格。除了请求详情之外,任何顾客支付详情也将被储存在该平台中。外部引用也将被储存在与其相关联的维度表中,该维度表可以被用于外部调用或仅用于报告的目的。与请求和或顾客有关的所有数据之间的关系将被维护在整个数据库中。
只有经由加密后的密码和安全连接对该数据进行的访问可用于EPG平台。商户将能够经由后台来访问该数据,但是特定的数据将被限于指定的账户类型。因此,商户将能够基于不同的安全级别来为其内部用户创建后台账户。在一些示例性实施例中,只有特定的进程将能够被读取以及被写入数据库中,因此很大程度上限制了能够访问该数据的确切对象。甚至这些进程将仅在它们提供了所需的证书并且调用是从安全且可接受的IP地址进行的情况下才能够访问数据库。这将确保平台内的不同部件之间的通信是安全的,并且也将有助于防止任何外部攻击或侵犯。使用星型模式允许使用包含了规范的支付和服务数据模式的一个主交易表格(事实表),并且允许快速的报告。该表格将被链接至将进 一步扩展交易数据模式的许多其他表格(维度)。然而更重要的是,由于该模式设计的本质以及可以提供许多维度表(诸如日期表)的事实,商户将能够使用在我们的数据库中所提供的数据中的任一项或全部来运行大量的报告,而无需复杂的SQL表述。规范模式被用在整个平台中,并且使得更轻便简单地在需要时且如果需要的话仅通过所请求的指定的支付或账户详情在平台中传递。
本领域的技术人员将理解的是,所提出的系统的功能可以以多种不同的方式来实现,并且在这点上本发明并不一定旨在于受限制。然而,为了完整性,设想SpringSecurity、提供认证的Java EE框架、授权以及其他安全特征可以被用于对根据本发明的一个示例性实施例的网关系统的安全方面进行控制。网关系统旨在执行高层控制和对操作的加密,并且这些内容可以被审查。在系统的示例性实施例内使用例如单向加密算法(SHA1)对密码进行加密,并且可以提供大量的访问流程控制。HTTPS、IP地址阻止、SSL证书以及完整性检验也可以被用于访问网关应用程序接口。
因此,尽管现有技术中存在许多不同的支付网关,但是由本发明的各方面所提供的平台不仅仅是网关,该平台是之前没有设想过的一种类型的全面合并的支付管理平台。该平台允许商户针对向任何数量的支付方案、内部软件过程或第三方解决方案的任何请求来确实地‘画出’路线,所有均是实时的并且不需要任何指定的IT技术。
下文是可以由根据本发明的各个方面的网关系统所提供的(实时)功能和服务的非穷举列表,虽然将要理解的是,可以在任一个实施例中以及在任何组合中提供下述功能和服务中的任一项或全部,并且关于下述潜在功能和服务的列表,不旨在于推断或暗示对本发明范围的限制:
·因此,根据本发明的一个示例性实施例的网关系统允许通过非常简单地使用图形工具来创建工作流,该图形工具允许用户将部件和规则集(条件)拖拽至流程中,因此允许无限的路线和组合。
·该网关系统可以在无需重新部署任何编码的情况下提供实时的出纳机配置。可以对每个出纳机单独地配置国家和货币。
·系统可以被配置成与使用其自己的出纳机或使用商户的出纳机来工作,这意味着需要更少的合并以及对商户的现有平台妨碍更小。
·系统可以被配置成使用其自己的被合并的数据库或使用商户的数据库来工作。对于数据库位于哪里是没有限制的。
·由根据本发明的一个示例性实施例的系统所提供的支付方法和其他服务可以均被视为独立的服务。这意味着系统能够快速且容易地插入商户所要求的任意数量的服务。这也意味着每个服务连同其相关参数和结果均可以被用于创建报告、过滤器、规则集。
·该系统可以是自包含的并且不需要任何外部函数库,这意味着系统可以十分轻便并且几乎可以在任何环境中作为现成的产品来执行。
·平台可以被本地性地托管在任意数量服务器上的商户自己数据中心上,或如果期望的话则它可以被托管在云服务器上。
·在一些示例性实施例中,系统可以提供实时的报告以及排定的报告,用于能够以例如HTML、PDF、CSV或Excel格式被下载的预限定报告。
·系统可以被配置成通过过滤来提供对交易的实时实况监控,过滤使用户能够基于商户所创建的任意数量的条件来对编码进行着色(高亮)或隐藏任何交易。
·系统可以被配置成提供完整的交易搜索和完整的交易详情观看。
·系统可以被配置成提供顾客的地理位置以及历史交易地理位置映射,以全球性地跟踪顾客的路径。
·系统可以被配置成提供完整的二进制范围映射和信用卡的地理位置;并且可以提供辅助管理工具,该辅助管理工具允许商户将任意数量的受理中的顾客支出聚集成组。该工具也允许商户通过使用其之前所创建的规则和条件,来人工地或自动地执行对受理中交易的延迟捕获。
·可以利用小插件来提供实时的控制面板,该小插件可由商户来配置以在任意时间段中显示任意预限定的量的数据。
·系统可以被完整地审查并且可以是完全基于角色和权限的,这意味着功 能中的每一部分和每一项均可以被限制为指定的角色和权限。
·系统可以提供信用卡令牌化,以限制商户所要求的PCI的级别;系统也可以提供虚拟终端,虚拟终端允许商户代表其顾客来执行MOTO交易。
·平台可以被配置成经由定向API或经由重定向API来进行访问。
根据前述描述,本领域的技术人员将理解的是,在不脱离如附加权利要求所限定的本发明范围的前提下,可以对所描述的实施例进行修改和变型。