CN115965374A - 用于旅行管理系统的支付整合 - Google Patents
用于旅行管理系统的支付整合 Download PDFInfo
- Publication number
- CN115965374A CN115965374A CN202211232735.8A CN202211232735A CN115965374A CN 115965374 A CN115965374 A CN 115965374A CN 202211232735 A CN202211232735 A CN 202211232735A CN 115965374 A CN115965374 A CN 115965374A
- Authority
- CN
- China
- Prior art keywords
- payment
- sdk
- travel
- travel record
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/02—Reservations, e.g. for tickets, services or events
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
- G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/405—Establishing or using transaction specific rules
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Tourism & Hospitality (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Quality & Reliability (AREA)
- Operations Research (AREA)
- Marketing (AREA)
- Human Resources & Organizations (AREA)
- Entrepreneurship & Innovation (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本公开涉及用于旅行管理系统的支付整合。用于实现旅行管理系统的支付整合过程的方法、系统和计算机程序产品。在支付整合服务器处经由支付整合用户接口接收包括旅行记录标识的支付请求。支付标识与旅行记录标识相关联,并且支付整合用户接口通过单个接口提供对多个支付处理器服务器的访问。支付整合服务器从预订系统获得与旅行记录标识相关联的合格支付处理器信息。支付整合服务器基于合格支付处理器信息访问来自第一支付提供商的第一软件开发工具包(SDK)和来自第二支付提供商的第二SDK。支付整合服务器然后用与第一SDK相关联的第一接口元素和与第二SDK相关联的第二接口元素来更新支付整合用户接口。
Description
技术领域
本发明一般而言涉及计算机和计算机软件,更具体而言,涉及用于实现支付整合过程的方法、系统和计算机程序产品。
背景技术
为了使旅行提供商能够处置朝着更标准的零售行业方法的转变以集成来自不同软件系统(例如,软件开发工具包(SDK))和欺诈预防(例如,现代接触点、无摩擦流程、移除中介等),旅行提供商需要确保其前端系统和客户图形用户接口(GUI)接触点在新分销能力(NDC)上下文(例如,乘客姓名记录(PNR)系统)和支付上下文之间维持协同增效效应。例如,国际航空运输协会(IATA)引入了NDC标准,以使“航空零售”更加精简。
商家需要在其接触点上单独集成各种SDK以接受支付。例如,航空业可期望在所有航空公司商家数字接触点(例如,预订、签入(check-in)等)上提供支付范围(例如,信用卡、数字支付工具、加密货币、欺诈检查等)。提供各种支付选项、认证、欺诈检查等将要求实体在其网站上集成每个不同的SDK。这种与网站的整合导致实体成本增加、上市时间更长和复杂性增加。此外,与支付和PNR相关的支付操作需要经由后端服务器执行(例如,奖励支付(诸如在现金支付的情况下使用里程之类)、费用计算等)。而且,航空业还将需要在后端侧维护其PNR集成和支付编排逻辑,以匹配在其前端集成的支付SDK。
在一些常规的预订系统中,支付信息是以使得支付信息不能被认证的方式提供的。例如,旅行客户可以使用电话通信与旅行社通信,并且旅行客户可以口头提供旅行社支付信息。在这个示例中,旅行社在诸如计算机之类的预订设备上输入支付信息,并且支付信息未被核实/认证。再举一个示例,如果旅行客户亲自与旅行社预订旅行,那么除非旅行社配备电子支付捕获设备(即,信用卡读卡器等),否则支付信息(例如,信用卡号)仍然可以是欺诈性的。照此,对于这些用于旅行预订的传统支付渠道,通过此类渠道提交的支付可以被认为是不安全的。
一般而言,因为通过不安全的支付渠道进行欺诈性支付的责任通常由旅行商、旅行预订系统和/或第三方预订服务承担,所以不安全的支付增加旅行商家(例如,航空公司、铁路旅行供应商、宾馆等)、旅行预订系统(例如,全球分销系统)和/或第三方预订服务(例如,旅行社)。此外,因为旅行商家、预订系统和/或第三方预订服务处置用于此类不安全支付渠道的支付信息,所以可以要求旅行商家、预订系统和/或第三方预订服务遵守用于敏感支付信息的各种安全性标准。例如,可以要求旅行商家、预订系统和/或第三方预订服务遵守支付卡行业数据安全性标准(PCI DSS),这是用于为许多借记卡、信用卡、预付卡、电子钱包、ATM和销售点(POS)支付卡处置持卡人信息的组织的信息安全性标准。遵守此类标准通常增加与处理用于旅行预订的支付相关联的成本。
而且,许多旅行商家和预订系统利用旅行社销售模式,即,旅行社代表旅行商家分销旅行商家的产品。但是,即使在欺诈性支付的情况下,旅行商家一般也要对支付负责。因此,在利用旅行社销售模式的常规系统中,旅行商家一般依赖旅行社规程来确保支付。
每当旅行商家和预订系统接受支付时,他们需要确保数据一致并且他们能够提供最终对账目的可能要求的所有必要信息(例如,代码等)。例如,旅游商家需要确保数据可供其后台部门使用并有能力在其预订系统内维护支付数据的集成。因此,需要用于为旅行预订提供改进的支付整合系统的改进的方法、系统和计算机程序产品。
发明内容
在本发明的实施例中,一种用于实现支付整合过程的方法。该方法包括在支付整合服务器处经由客户端设备处的支付整合用户接口接收来自旅行提供商服务器的包括旅行记录标识的支付请求。支付标识与旅行记录标识相关联。支付整合用户接口是提供对多个支付处理器服务器的访问的第一级接口。在支付整合服务器处从预订系统获得与旅行记录标识相关联的合格支付处理器信息。预订系统对旅行记录标识进行了处理。基于合格支付处理器信息,访问来自第一支付提供商的第一软件开发工具包(SDK)和来自第二支付提供商的第二SDK。第一SDK包括与第二SDK不同的配置。用与第一SDK相关联的第一接口元素和与第二SDK相关联的第二接口元素更新支付整合用户接口。
这些和其它实施例可以各自可选地包括以下特征中的一个或多个。
在本发明的一些实施例中,该方法还包括在支付整合用户接口处经由第一SDK从客户端设备接收支付数据。
在本发明的一些实施例中,该方法还包括:响应于从客户端设备接收到支付数据,在支付整合服务器处,使用支付标识经由支付网关从支付处理器获得与旅行记录标识相关联的支付交易数据;由支付整合服务器通过将支付交易数据整合到旅行记录中来更新旅行记录;以及由支付整合服务器将更新后的旅行记录提供给预订系统。
在本发明的一些实施例中,支付整合用户接口包括与第三SDK相关联的第三接口元素,第三SDK与欺诈服务实体相关联,并且该方法还包括经由第三SDK接收与支付交易数据相关联的欺诈信息。
在本发明的一些实施例中,该方法还包括经由欺诈数据库基于第一支付提供商访问与旅行记录标识相关联的欺诈核实信息;以及核实支付交易数据不是欺诈性的。
在本发明的一些实施例中,该方法还包括确定与支付交易数据相关联的第一商家和与旅行记录数据相关联的第二商家匹配;确定与支付交易数据相关联的支付的授权成功;基于授权时间戳确定与支付交易数据相关联的授权是有效的;确定不存在与支付交易数据相关联的尝试的后续操作或未决的后续操作;确定与支付交易数据相关联的支付的金额和货币是可用的;和/或确定与支付交易数据相关联的支付工具和与旅行记录数据相关联的支付工具匹配。
在本发明的一些实施例中,在支付整合用户接口处经由第一SDK从设备接收支付数据还包括:基于旅行记录标识来执行客户端设备的认证。
在本发明的一些实施例中,该方法还包括通过将支付标识与其它接收到的支付标识进行比较来确定尚未接收到支付标识。
在本发明的实施例中,一种用于实现支付整合过程的计算装置。该计算装置包括一个或多个处理器、与该一个或多个处理器耦合的至少一个存储器设备、以及可操作地与该一个或多个处理器相关联的数据通信接口。至少一个存储器设备包含多个程序指令,所述多个程序指令在由一个或多个处理器执行时使得包括装置执行操作。操作包括在支付整合服务器处经由客户端设备处的支付整合用户接口接收来自旅行提供商服务器的包括旅行记录标识的支付请求。支付标识与旅行记录标识相关联。支付整合用户接口是提供对多个支付处理器服务器的访问的第一级接口。在支付整合服务器处从预订系统获得与旅行记录标识相关联的合格支付处理器信息。预订系统对旅行记录标识进行了处理。基于合格支付处理器信息,访问来自第一支付提供商的第一软件开发工具包(SDK)以及来自第二支付提供商的第二SDK。第一SDK包括与第二SDK不同的配置。用与第一SDK相关联的第一接口元素和与第二SDK相关联的第二接口元素更新支付整合用户接口。
在本发明的实施例中,一种用计算机程序编码的非暂态计算机存储介质,该计算机程序包括多个程序指令,所述多个程序指令在由一个或多个处理器执行时使所述一个或多个处理器执行操作。操作包括在支付整合服务器处经由客户端设备处的支付整合用户接口接收来自旅行提供商服务器的包括旅行记录标识的支付请求。支付标识与旅行记录标识相关联。支付整合用户接口是提供对多个支付处理器服务器的访问的第一级接口。在支付整合服务器处从预订系统获得与旅行记录标识相关联的合格支付处理器信息。预订系统对旅行记录标识进行了处理。基于合格支付处理器信息,访问来自第一支付提供商的第一软件开发工具包(SDK)以及来自第二支付提供商的第二SDK。第一SDK包括与第二SDK不同的配置。用与第一SDK相关联的第一接口元素和与第二SDK相关联的第二接口元素更新支付整合用户接口。
提供本发明内容以简化形式介绍概念的选择,这些概念将在下面的详细描述中进一步描述。本发明内容既不旨在识别所要求保护的主题的关键特征或必要特征,也不旨在单独用于帮助确定所要求保护的主题的范围。
附图说明
结合在本说明书中并构成本说明书的一部分的附图图示了本发明的各种实施例,并且与以上给出的本发明的一般描述以及以下给出的实施例的详细描述一起用于解释本发明的实施例。在附图中,在各个视图中,相同的附图标记是指示相同的特征。
图1图示了根据本发明实施例的用于实现支付整合过程的分布式数据库环境。
图2图示了根据本发明实施例的序列图形式的示例例程,该例程可以由图1中所示的分布式数据库环境执行,作为促进用于旅行预订的支付整合过程的规程。
图3图示了根据本发明实施例的基于支付请求的示例支付整合过程。
图4图示了根据本发明实施例的经由支付整合用户接口的示例支付整合过程。
图5是根据本发明实施例的用于基于支付请求更新支付整合用户接口的示例过程的流程图。
图6是示出根据本文描述的实施例的能够执行本文描述的软件组件的计算机的示例计算机架构的框图。
具体实施方式
为了使旅行提供商能够处置朝着更标准的零售行业方法的转变以集成来自不同软件系统(例如,软件开发工具包(SDK))和欺诈预防(例如,现代接触点、无摩擦流程、移除中介等),旅行提供商需要确保其前端系统和客户图形用户接口(GUI)接触点在新分销能力(NDC)上下文(例如,乘客姓名记录(PNR)系统)和支付上下文之间维持协同增效效应。软件开发工具包是一个可安装包中的软件开发工具的集合。它们通过具有编译器、调试器和可能的软件框架来促进应用的创建。它们通常特定于硬件平台和操作系统组合。本公开为支付和欺诈提供商提供了不同的能力,这些提供商已经从传统的后端API和web服务转到现代基于GUI的支付系统,从而提供GUI组件以通过使用支付整合用户接口来接受支付,该用户接口提供来自不同软件系统的多个支付交易(例如,经由SDK)。
商家需要在其接触点上单独集成各种SDK才能接受支付。例如,航空业可以期望在所有航空公司商家数字接触点(例如,预订、签入等)上提供支付范围(例如,信用卡、数字支付工具、加密货币、欺诈检查等)。航空公司将需要在其网站上集成每个不同的SDK。这导致航空公司成本增加、上市时间更长和复杂性增加。此外,与支付和PNR相关的支付操作需要经由后端服务器执行(例如,奖励支付(诸如在现金支付的情况下使用里程之类)、费用计算等)。而且,航空业还将需要在后端侧维护其PNR集成和支付编排逻辑,以匹配在其前端集成的支付SDK。
本专利申请中的技术涉及用于使用一个或多个支付整合服务器来实现支付整合过程的系统和方法,这些服务器经由支付平台网关与旅行提供商、旅行预订系统和支付处理器通信。支付整合过程将签出过程集成为单个接口来执行支付并用支付详细信息更新支付记录(例如,乘客姓名记录(PNR))。支付整合指令集在需要时动态加载第三方系统(例如,SDK),从商家的角度隐藏复杂性,并为每个商家的每个支付记录(例如,PNR)提供轻松的旅行集成。
在一个示例中,本发明的实施例可以包括可以帮助集中执行高数据消耗计算的整合过程。例如,特定航空公司实体可以在支付系统中定义数百条规则,以基于PNR的内容计算信用卡附加费。在没有任何交互或解决方案以便与预订系统计算器实际连接的情况下,这是无法完成的。因此,系统可以计算费用,应用费用,然后将信息返回到用户接口,以便随后可以使用它来执行认证。
本发明的实施例可以仅包括可以显示和/或发送到支付处理器以限制共享的信息量的相关信息。例如,关于信息是否相关的决定可以由基于与旅行预订相关的所有可用信息(例如,航空公司信息、乘客信息等)的支付整合指令集来确定。此外,相关信息然后可以经由开放接口消息协议(例如,JavaScript对象表示法(JSON)消息等)的接口被共享。虽然一些数字支付系统要求单独的接口,但与具有定义的JSON消息的统一支付整合用户接口的集成可以被用于归一化支付整合用户接口、后端支付过程和PNR本身之间的交互。因此,例如,当商家基于PNR上下文从支付实体加载第三方SDK时,支付整合服务器将知道例如是否实际显示支付实体的图标(例如,支付链接,诸如可选择的按钮/图标之类)。
本发明的实施例可以包括支付整合指令集,该指令集允许旅行者使用飞行常客里程或在与支付处理器实体进行处理之前应用于旅行者记录的其它形式的信用来支付预订的一部分。例如,支付整合服务器将在签出时确定是否从旅行提供商(例如,航空公司)检索这个信息,和/或是否提供使用里程支付部分旅行预订的选项并将该信息发送到单个用户接口。
虽然本文提供的示例参考旅游业,但所描述的整合过程可以应用于任何订单管理系统。
图1是根据本发明实施例的用于实现支付整合过程的分布式数据库环境的示例环境100。示例环境100包括一个或多个客户端设备110、一个或多个旅行预订服务器120、一个或多个旅行提供商服务器130、一个或多个支付网关服务器140、一个或多个支付处理器服务器150和一个或多个支付整合服务器160,它们通过数据通信网络102(例如,局域网(LAN)、广域网(WAN)、因特网、移动网络或其组合)通信。
一个或多个客户端设备110(例如,由请求者使用的设备)可以包括台式机、膝上型计算机、服务器或移动设备(诸如智能电话、平板计算机、可穿戴设备(例如,智能手表)、车载计算设备和/或其它类型的移动设备)。此外,一个或多个客户端设备110可以是诸如信息亭、用户终端等的公共使用设备。一个或多个客户端设备110包括用于管理去往/来自一个或多个旅行预订服务器120的旅行预订请求的应用,诸如应用112。一个或多个客户端设备110可以包括其它应用。一个或多个客户端设备110由请求者经由应用112发起旅行预订请求。在搜索(例如,航空公司预订搜索)过程中旅行预订请求可以包括请求实体(诸如客户端、应用、安装在用户终端上的浏览器等)进行的可用性搜索查询。客户可以使用一个或多个客户端设备110来审查预订的旅行预订并为预订的旅行预订提供和认证支付信息。此外,使用一个或多个客户端设备110的旅行预订的请求者可以包括航空公司代理、旅行社、其它专用全球分销系统(GDS),例如提供用于购物业务(如航班预订等)的航班搜索应用的航空公司预订系统。
一个或多个旅行预订服务器120管理从一个或多个客户端设备110从应用112接收的旅行预订请求。一个或多个旅行预订服务器120可以是个人计算设备、平板计算机、瘦客户端终端、智能电话和/或其它此类计算设备。一个或多个旅行预订服务器120从客户端设备接收预订数据以预订旅行预订并为与预订数据相关联的(一个或多个)特定旅行产品生成PNR。虽然描述了生成PNR,这与航空公司预订的示例有关,但本文描述的系统还可以包括用于能够生成与预订数据相关的记录的其它旅行提供商(诸如宾馆、租车等)的任何其它类型的订单管理系统。照此,一般而言,预订应用在预订设备(例如,客户端设备110上的应用112)上执行以生成前端,旅行社可以通过该前端与预订服务器120接口以预订用于旅行客户的旅行预订。例如,执行预订应用的预订设备可以作为连接到预订服务器120的远程终端操作,并且旅行社可以通过使用客户端设备110与预订服务器120接口来为旅行客户预订旅行预订。例如,执行预订应用的客户端设备110可以向由预订服务器120实施的GDS提供命令行接口。在这个示例中,由客户端设备110传送的预订数据可以是旅行社格式,诸如命令行。此外,在客户端设备110上的消费者确认用于与预订数据相关联的(一个或多个)特定旅行产品的发行(issuance)之后,预订服务器120通过向与来自客户的(一个或多个)请求的旅行产品相关联的一个或多个旅行提供商服务器发送订单请求来发起支付过程130。
一个或多个旅行提供商服务器130(例如,旅行商家)一般包括航空公司、铁路旅行提供商、宾馆和/或使用客户端设备110向客户提供旅行或旅行相关服务的其它此类商家。一个或多个旅行提供商服务器130一般促进与其进行远程通信以从特定旅行商家预订旅行或旅行相关服务。在客户端设备110上的消费者确认与预订数据相关联的(一个或多个)特定旅行产品的发行之后,旅行提供商服务器130从预订服务器120接收订单请求并通过从客户端设备110请求支付来发起支付过程。在接收到用于特定旅行预订的支付确认之后,旅行提供商服务器130可以从预订服务器120请求和接收旅行记录ID,并经由预订服务器120向客户端设备110发送预订确认。此外,一个或多个旅行提供商服务器130被配置为在经由一个或多个支付网关服务器140从一个或多个支付处理器服务器150接收到支付确认并通过向一个或多个支付整合服务器160发送支付请求发送预订确认数据之后发起支付整合过程。
一个或多个旅行提供商服务器130可以是(一个或多个)前端服务器,用于管理、收集、处理和传送存储在旅行记录数据库135中的旅行记录(例如,旅行预订请求、资源信息、收入管理数据、预订数据、航空公司/系统配置数据等)。另外,一个或多个旅行提供商服务器130可以是(一个或多个)前端服务器,用于管理、收集、处理支付请求和支付整合数据并将其从一个或多个支付整合服务器160传送到一个或多个预订服务器120。
一个或多个支付网关服务器140管理从一个或多个客户端设备110与(一个或多个)支付处理器服务器150之间的应用112接收的旅行预订请求的支付交易。一个或多个支付网关服务器140的管理协议可以通过管理多个客户端(例如,(一个或多个)客户端设备110)而基于冗余负载平衡系统,使得与旅行预订请求相关联的支付由一个或多个支付处理器服务器150之一处置。例如,可以存在能够为旅行预订支付提供服务的多个支付处理器服务器150,并且(一个或多个)支付网关服务器的冗余负载平衡系统140负责确保旅行预订请求由有能力的(一个或多个)支付处理器服务器150之一执行。支付处理器包括例如信用卡/借记卡发行商、银行、数字支付服务等,并且用于每个支付处理器的一个或多个服务器一般促进与其进行远程通信以经由支付网关服务器140认证和/或授权支付。支付交易数据可以存储在与每个支付处理器相关联的一个或多个支付数据库152中。
一个或多个支付整合服务器160接收并处理来自预订服务器120的(一个或多个)支付请求。一个或多个支付整合服务器160包括支付整合指令集170,该指令集执行根据本文描述的过程的支付整合协议。支付整合指令集170可以包括用于执行旅行记录标识和支付标识的欺诈检查的欺诈模块172。旅行记录标识和支付标识的欺诈检查可以包括经由欺诈数据库173基于第一支付提供商访问与旅行记录标识相关联的欺诈核实信息并核实支付交易数据不是欺诈性的。例如,欺诈核实信息可以包括用于识别用户的各种标识信息,诸如IP地址、浏览器、浏览器配置、设备、位置、可用硬件、预订细节(例如,旅行记录、订单信息等)、用户行为,支付方法等。各种信息的数据收集可以由第三方SDK收集。核实支付交易数据不是欺诈性的可以基于收集到的欺诈核实信息,并且可以被用于识别可疑简档,和/或用户是否已经提供了合法支付。
在一些实施方式中,支付请求不包括支付标识。支付标识可以在支付请求已经做出之后由一个或多个支付整合服务器160发回,并且在设备110和一个或多个支付整合服务器160之间的完整支付过程期间用作密钥。支付标识可以在整个支付过程中被使用并且与所有支付和旅行细节相关联,这些细节可以在任何时间从一个或多个支付整合服务器160恢复。在一些实施方式中,支付标识可以不包括在支付数据中,因为支付提供商不需要支付标识来处理支付。例如,一个或多个支付整合服务器160可以从支付标识中恢复必要的支付数据并将这个数据发送到支付提供商。因此,一个或多个支付整合服务器160可以将旅行记录与支付标识相关联并且在支付过程期间保持该关联。
在本发明的一些实施方式中,支付整合指令集170还包括认证模块174以核实用户经由来自预订服务器120的商家网页在客户端设备110上进行支付。在本发明的示例性实施例中,可以在支付整合用户接口处(例如,经由支付处理器SDK)从客户端设备110接收支付数据,并且可以通过核实来自安全性数据库175的真实性信息基于旅行记录标识来执行客户端设备的认证。此外,作为认证协议的一部分,认证模块174可以执行支付交易数据和旅行记录数据的健全性检查。如本文所述,欺诈性检查可以确定交易是否是欺诈性的,而健全性检查可以确定信息与(一个或多个)数据库中的信息一致。例如,支付交易数据和旅行记录数据的健全性检查可以包括记录定位符一致性检查,该检查包括支付标识和旅行记录标识之间的标识检查(例如,记录定位符(RLOC)一致性检查)。附加的健全性检查可以包括商家匹配、授权批准以及基于时间戳是否是最近的、检查后续或未决操作、确认支付的金额和货币以及支付工具匹配。
支付整合指令集170还包括支付模块176,用于在经由支付处理器服务器150的支付提供商和客户端设备110之间实现支付处理方案。
在本发明的一些实施方式中,支付整合指令集170还包括用户接口模块178,用于基于支付整合SDK集成(例如,将一个或多个支付处理器SDK集成到用于在设备110处显示的预订服务器120网页的单个接口)生成支付整合用户接口。本文参考图4的支付整合用户接口420进一步讨论示例支付整合用户接口。
本文参考图2的序列图200进一步讨论了实现如图1的环境中所示的支付整合协议的示例例程。
图2图示了根据本发明实施例的序列图200形式的示例例程,该例程可以由图1中所示的分布式数据库环境执行,作为促进用于旅行预订的支付整合过程的规程。图2提供了与本发明的一些实施例一致的可以由客户端设备110、(一个或多个)预订服务器120、(一个或多个)旅行提供商服务器130、(一个或多个)支付网关服务器140、(一个或多个)支付处理器服务器150和/或(一个或多个)支付整合服务器160执行的示例性例程以经由支付整合用户接口(例如,集成来自多个支付处理器实体的SDK的单个接口)处理用于预订的旅行预订的安全支付。序列图200在方框202处经由应用112在客户端设备110处发起(例如,在发起支付网站的消费者设备处录入旅行请求)。旅行预订请求由预订服务器120接收。作为响应,在方框204处,预订服务器120预订与预订请求相关联的旅行预订并生成相关联的PNR。预订确认从预订服务器120传送到客户端设备110(例如,进行临时旅行预订、挂起消费者确认和支付)。
在方框206处,在客户端设备110处录入对预订的消费者确认(例如,旅行者想要继续为票进行支付),并且预订支付请求被传送到预订服务器120。然后预订服务器120将订单请求传送到旅行提供商服务器130。在方框208处,旅行提供商服务器130响应于订单请求而将用于旅行预订的相关联的PNR存储在旅行记录数据库135中。根据本发明的一些实施方式,在接收到订单请求之后,旅行提供商服务器130从预订服务器120请求并接收旅行记录ID。旅行提供商服务器130然后向客户端设备110发送对支付交易的请求(例如,支付形式(FOP)和支付数据)。旅行提供商服务器130可以经由预订服务器120请求支付交易,或直接将请求传送到客户端设备110(例如,支付门户窗口/应用)。
在方框210处,在客户端设备110处向用户呈现并选择继续进行支付交易。然后将带有旅行记录标识的支付请求发送到支付整合服务器160。然后支付整合服务器160发起支付整合协议以从预订服务器120获得必要信息(例如,显示哪些支付处理器作为用于支付的选项)以便生成支付整合用户接口。因此,支付整合服务器160从预订服务器120请求合格的支付方法。预订服务器120然后将合格的支付方法提供给支付整合服务器160。
在方框212处,支付整合服务器160从预订服务器120获取合格的支付方法,并基于相关联的支付处理器SDK生成支付整合用户接口,其中支付处理器SDK被集成在客户端设备110上的单个视图(例如,小部件应用)中。支付整合服务器160然后经由支付整合用户接口将合格的支付处理器SDK发送到客户端设备110。支付数据(例如,支付形式和支付信息),包括任何认证信息、欺诈信息、安全性信息等,然后从客户端设备110被传输(例如,通过预订服务器120网站经由支付整合用户接口被录入)到支付整合服务器160。
然后,支付交易数据经由一个或多个支付网关服务器140传送到支付处理器服务器150之一。在方框216处,支付处理器服务器150(例如,由网关服务器140选择的处理器)与处理器(例如,银行、信用卡/借记卡发行商、数字支付服务等)进行支付交易。支付处理器服务器150经由支付网关服务器140将支付状态消息(例如,支付确认ID)传送到支付整合服务器160。支付整合服务器160然后将更新旅行记录ID(例如,PNR)的消息与支付状态一起发送到预订服务器120。
在方框218处,预订服务器120然后用支付状态(例如,客户对预订进行了支付)更新旅行记录ID。如图所示,然后可以经由支付整合服务器160将支付确认消息从预订服务器120发送到客户端设备110,以在支付整合用户接口上查看。
可替代地,支付处理器服务器150可以直接向客户端设备110发送支付确认消息,并且支付处理器服务器150可以将支付确认ID传送到旅行提供商服务器130。根据本发明的一些实施方式,在接收到支付确认消息和/或支付确认ID之后,旅行提供商服务器130从预订服务器120请求并接收旅行记录ID。此外,旅行提供商服务器130可以将预订确认数据发送到预订服务器120,并且作为响应,预订服务器120可以将发行确认消息传送到客户端设备。发行确认可以在支付交易完成期间(例如,同时,在方框218处发起),或者在支付交易完成之后立即生成。
(一个或多个)支付整合服务器160利用支付整合指令集170来处理支付整合协议的动作在本文参考图3中的图示进一步描述。
图3图示了根据本发明实施例的基于支付请求的示例支付整合过程。特别地,图3图示了用于基于接收到支付请求310来确定支付整合SDK 320(例如,生成整合的用户接口)的支付整合实施方式的示例环境300。SDK 320可以是基于web的接口、设备上的原生应用或任何其它类型的接口。支付整合指令集170的目标是向最终用户显示具有来自多个支付提供商的不同支付选项的整合的用户接口,使得商家不必在他们的接触点上各自单独集成各种SDK以接受支付。例如,航空业可以期望在所有航空公司商家的数字接触点(例如,预订、签入等)上提供支付范围(例如,信用卡、数字支付工具、加密货币、欺诈检查等)。例如,存储在一个或多个支付整合服务器160上的支付整合指令集170接收支付请求310(例如,来自客户端设备110)。支付请求310包括与旅行预订相关联的支付请求信息312(例如,旅行/预订ID、旅行记录数据、支付记录ID等)。在一些实施方式中,完整的支付数据集不在请求查询中(例如,支付请求信息312),但是,支付记录ID允许支付整合指令集170识别数据库中的支付交易以检索所有相关的支付数据。
支付整合指令集170发起支付整合协议314(例如,图2的方框212)以生成支付整合SDK 320(例如,整合的用户接口)。支付整合协议314包括例如欺诈检查过程、支付处理过程、认证/授权过程和支付SDK集成过程。例如,欺诈模块172通过确定支付交易数据不是欺诈性的来执行支付请求信息312(例如,旅行记录数据)的欺诈检查。此外,认证模块174通过执行真实性检查来核实支付请求信息312(例如,支付交易数据和旅行记录数据),该真实性检查包括支付标识和旅行记录标识之间的识别检查(例如,记录定位符(RLOC)一致性检查)。执行支付交易数据和旅行记录数据的认证可以包括确定旅行提供商服务器有权访问支付交易数据和旅行记录数据的特定数据集。附加的健全性检查可以包括商家匹配、授权批准以及基于时间戳是否是最近的、检查后续或未决操作、确认支付的金额和货币以及支付工具匹配。支付整合协议314还包括支付模块176,用于在经由支付处理器服务器150的支付提供商和设备110之间的支付处理方案。支付整合协议314还包括支付SDK集成过程,其将每个旅行商家的单独SDK集成到单个支付整合用户接口中。本文参考图4的支付整合用户接口420进一步讨论集成每个旅行商家的单独SDK的示例整合用户接口。
支付整合SDK 320可以包括支付整合结果数据322,诸如数据有效性结果、与支付交易相关联的交易数据、支付工具、授权结果、认证信息和欺诈评估信息,以及支付交易数据。本文参考图4的示例环境400进一步讨论实现如图3中所示的支付整合协议的示例说明。
图4图示了根据本发明实施例的在示例环境400中经由支付整合用户接口的示例支付整合过程。示例环境400图示了示例数据流以经由商家的网页在单个用户接口(例如,支付整合用户接口420)处提供对多个支付处理器(例如,图1的支付处理器服务器150)的访问。
示例环境400包括通过数据通信网络(例如,图1的网络102)通信的预订服务器120、支付整合服务器160、三个不同的支付处理器服务器(例如,支付处理器-1服务器430、支付处理器-1服务器440和支付处理器-1服务器450)。支付整合用户接口420包括与支付处理器-1服务器430相关联的支付处理器-1 SDK 432、与支付处理器-1服务器440相关联的支付处理器-2 SDK 442,以及与支付处理器-1服务器450相关联的支付处理器-3SDK 452。支付整合用户接口420被包括(嵌入)在托管在预订服务器120上的旅行预订支付UI 410内。附加地,或可替代地,支付整合用户接口420也可以托管在支付整合服务器上160。
在本发明的示例性实施例中,支付整合用户接口420为客户端设备110处的最终用户提供接触点访问,以便能够选择特定的支付方法(例如,信用卡、银行、数字货币等)和/或从特定支付处理器(例如,ABC银行与银行XYZ)选择。例如,商家的网页可以利用支付整合协议以通过将每个支付处理器的SDK(例如,SDK 432、442、452)直接集成到商家的网页(例如,旅行预订支付UI 410)内的支付门户(例如,支付整合UI 420)来向最终用户提供对多个不同支付选项的快捷访问,使得每个商家不需要在其接触点上单独集成各种SDK以接受支付。在本文中参考图5的过程500进一步讨论实现如图4中所示的支付整合协议的示例过程。
图5图示了根据本发明实施例的用于基于支付请求更新支付整合用户接口的示例过程500的流程图。过程500的操作可以例如由包括一个或多个数据处理装置(诸如图1的一个或多个支付整合服务器160)的系统利用支付整合指令集170来实现。过程500还可以通过存储在计算机存储介质上的指令来实现,其中由包括数据处理装置的系统执行指令使得数据处理装置执行过程500的操作。
系统接收来自旅行提供商服务器的包括旅行记录标识的支付请求(510)。在支付整合服务器处经由设备(例如,设备110)处的支付整合用户接口(例如,图4的支付整合UI420)接收支付请求,其中支付整合用户接口是第一级接口,其被配置为在相应SDK被集成在其中之后提供对多个支付处理器服务器(例如,支付处理器服务器430、440、450等)的访问。例如,如图2的序列图200中所示,客户端设备110向支付整合服务器160之一发起支付请求。支付标识与旅行记录标识相关联。预订系统(例如,预订服务器120)对旅行记录标识进行了处理。
系统从预订系统获得与旅行记录标识相关联的合格支付处理器信息(520)。例如,如图2的序列图200中所示,在方框212处,预订服务器120通过将合格的支付方法传送到支付整合服务器160之一来发起支付整合协议。
系统访问来自第一支付提供商的第一软件开发工具包(SDK)和来自第二支付提供商的第二SDK,其中第一SDK包括与第二SDK不同的配置(530)。例如,如图2的序列图200中所示,在方框212处,在支付整合服务器160从预订服务器120接收到合格的支付方法之后,支付整合服务器160动态加载和管理用于与合格的支付方法相关联的每个支付处理器的相关联的SDK。
系统用与第一SDK相关联的第一接口元素和与第二SDK相关联的第二接口元素更新支付整合用户接口(540)。例如,如图4中所示,为支付处理器-1服务器430(例如,银行服务器)加载支付处理器-1 SDK 432,并且为支付处理器-2服务器440(例如,数字支付服务器)加载支付处理器-2 SDK 442。
在本发明的一些实施例中,为了确定支付整合SDK包括与SDK相关联的接口元素,系统执行旅行记录标识和支付标识的授权检查,执行支付交易数据和旅行记录数据的欺诈检查,并基于授权检查和欺诈检查生成支付整合数据。例如,如图3中所示,支付整合指令集170发起支付整合协议314(例如,图2的方框212)以生成支付整合SDK 320,其中支付整合协议314包括授权检查和欺诈检查、支付处理和支付SDK集成。
系统在支付整合用户接口处经由第一SDK从设备接收支付数据(550)。例如,客户端设备110处的用户选择通过与支付处理器-1SDK 432相关联的支付处理器来选择支付。响应于从设备接收到支付数据,系统使用支付标识经由支付网关从支付处理器获得与旅行记录标识相关联的支付交易数据(560)。例如,支付交易数据(例如,FOP和支付信息)被录入客户端设备110,并且支付交易数据经由一个或多个支付网关服务器140传送到支付处理器服务器150之一。
系统通过将支付交易数据整合到旅行记录中来更新旅行记录(570),并将更新后的旅行记录提供给预订系统(580)。例如,如图2的序列图200中所示,在方框218处,在支付整合服务器160经由支付网关服务器140从支付处理器服务器150接收到支付状态之后,预订服务器120然后用支付状态更新旅行记录ID(例如,客户对预订进行了支付)。如图所示,然后可以经由支付整合服务器160将支付确认消息从预订服务器120发送到客户端设备110,以在支付整合用户接口上查看。
在本发明的一些实施方式中,执行旅行记录标识和支付标识的欺诈检查包括通过将支付标识与其它接收到的支付标识进行比较来确定尚未接收到支付标识。每个支付处理器SDK可以包括用于实现欺诈检查的嵌入式指令。例如,支付整合指令集170可以包括用于执行旅行记录标识和支付标识的欺诈检查的欺诈模块172。旅行记录标识和支付标识的欺诈检查可以包括经由欺诈数据库173基于第一支付提供商访问与旅行记录标识相关联的欺诈核实信息,并核实支付交易数据不是欺诈性的。
在本发明的一些实施方式中,执行旅行记录标识和支付标识的欺诈检查由另一个实体(例如,不是支付处理器)实现。因此,在本发明的示例性实施方式中,支付整合用户接口包括和与欺诈服务实体相关联的第三SDK相关联的第三接口元素,其中程序指令还使计算装置经由第三SDK接收与支付交易数据相关联的欺诈信息。例如,与欺诈预防实体相关联的SDK可以作为分离的用户接口元素嵌入到支付整合用户接口420中。
在本发明的一些实施方式中,每个支付处理器SDK(例如,支付处理器-1 SDK 432)可以包括用于实现基于旅行记录标识的认证协议的嵌入式指令。例如,作为认证协议的一部分执行支付交易数据和旅行记录数据的健全性检查可以包括确定旅行提供商服务器有权访问支付交易数据和旅行记录数据的特定数据集。在本发明的一些实施方式中,过程500还包括根据可以访问支付交易数据和旅行记录数据的特定数据集的旅行提供商服务器来确定配置数据。
在本发明的一些实施方式中,旅行记录标识和支付标识的有效性检查作为认证协议的一部分被执行。有效性检查可以包括通过将支付标识与其它接收到的支付标识进行比较来确定尚未接收到支付标识。在本发明的一些实施方式中,基于旅行记录标识和支付标识的有效性检查以及支付交易数据和旅行记录数据的健全性检查生成支付整合数据是可基于配置数据定制的。
在一些实施方式中,支付请求不包括支付标识。支付标识可以在支付请求已经做出之后由一个或多个支付整合服务器160发回,并且在设备110和一个或多个支付整合服务器160之间的完整支付过程期间用作密钥。支付标识可以在整个支付过程中使用并且与所有支付和旅行细节相关联,这些细节可以在任何时候从一个或多个支付整合服务器160恢复。在一些实施方式中,支付标识可以不包括在支付数据中,因为支付提供商不需要支付标识来处理支付。例如,一个或多个支付整合服务器160可以从支付标识中恢复必要的支付数据并将这个数据发送到支付提供商。因此,一个或多个支付整合服务器160可以将旅行记录与支付标识相关联并且在支付过程期间保持该关联。
在本发明的一些实施方式中,作为认证协议的一部分执行健全性检查包括记录定位符一致性检查,该检查包括支付标识和旅行记录标识之间的标识检查(例如,记录定位符(RLOC)一致性检查)。附加的健全性检查可以包括商家匹配、授权批准以及基于时间戳是否是最近的、检查后续或未决操作、确认支付的金额和货币以及支付工具匹配。例如,在本发明的一些实施方式中,执行支付交易数据和旅行记录数据的健全性检查包括确定与支付交易数据相关联的商家和与旅行记录数据相关联的商家匹配(例如,商家匹配)。附加地或可替代地,执行支付交易数据和旅行记录数据的健全性检查包括确定与支付交易数据相关联的支付授权是成功的(例如,授权批准确认)。另外或替代地,执行支付交易数据和旅行记录数据的健全性检查包括基于授权时间戳(例如,最近的授权核实,即,默认情况下为最旧14天)确定与支付交易数据相关联的授权是有效的。附加地或可替代地,执行支付交易数据和旅行记录数据的健全性检查包括确定不存在与支付交易数据相关联的已尝试的后续操作或未决的后续操作(例如,后续或未决动作的核实)。附加地或可替代地,执行支付交易数据和旅行记录数据的健全性检查包括确定与支付交易数据相关联的支付的金额和货币可用(例如,货币核实)。附加地或可替代地,执行支付交易数据和旅行记录数据的健全性检查包括确定与支付交易数据相关联的支付工具和与旅行记录数据相关联的支付工具匹配(例如,支付工具匹配)。
在本发明的一些实施方式中,基于生成支付整合数据,过程500还包括将与支付整合数据相关联的旅行记录存储在支付整合数据库(例如,支付记录数据库165)中。例如,数据映射过程可以包括存储更新后的支付记录,这将支付数据添加到旅行数据库中。
在本发明的一些实施方式中,支付整合用户接口的支付整合SDK包括第三方支付处理器SDK集成数据、数据有效性结果、与支付标识相关联的交易数据、支付工具、授权信息、认证信息、欺诈评估信息和支付数据中的至少一个。
图6图示了计算机602的示例计算机架构600,该计算机602能够执行本文描述的软件组件以用于任务的发送/接收和处理。图6中所示的计算机架构600(本文也称为“服务器”)图示了服务器计算机、工作站、台式计算机、膝上型计算机、在云环境中操作的服务器或其它计算设备,并且可以被用于执行本文呈现的被描述为在主机服务器或其它计算平台上执行的软件组件的任何方面。计算机602优选地包括基板或“母板”,其是印刷电路板,多个组件或设备可以通过系统总线或其它电气通信路径连接到该印刷电路板。在一个说明性实施例中,一个或多个中央处理单元(CPU)604与芯片组606一起操作。CPU 604可以是执行计算机602的操作所必需的算术和逻辑操作的可编程处理器。
CPU 604优选地通过操纵区分和改变这些状态的切换元件从一个离散的物理状态过渡到下一个来执行操作。切换元件一般可以包括维持两个二进制状态之一的电子电路,诸如触发器,以及基于一个或多个其它切换元件(诸如逻辑门)的状态的逻辑组合提供输出状态的电子电路。这些基本的切换元件可以组合起来以创建更复杂的逻辑电路,包括寄存器、加法器-减法器、算术逻辑单元、浮点单元等。
芯片组606提供CPU 604与基板上的其余组件和设备之间的接口。芯片组606可以提供到存储器608的接口。存储器608可以包括用作计算机602中的主存储器的随机存取存储器(RAM)。存储器608还可以包括计算机可读存储介质,诸如只读存储器(ROM)或非易失性RAM(NVRAM),用于存储有助于启动计算机602和在各种组件和设备之间传送信息的基本例程。ROM或NVRAM还可以存储根据本文描述的实施例的计算机602的操作所需的其它软件组件。
根据各种实施例,计算机602可以使用通过一个或多个网络612、局域网(LAN)、广域网(WAN)、因特网或本领域已知的将计算机602连接到设备和其它远程计算机的任何其它网络拓扑的到远程计算设备的逻辑连接在联网环境中操作。芯片组606包括用于通过一个或多个网络接口控制器(NIC)610(诸如千兆以太网适配器)提供网络连接性的功能性。例如,NIC 610可以能够将计算机602连接到公用事业提供商的系统中的其它计算机设备。应当认识到的是,任何数量的NIC 610可以存在于计算机602中,将计算机连接到本文所述的那些以外的其它类型的网络和远程计算机系统。
计算机602可以连接到为计算机602提供非易失性存储的至少一个大容量存储设备618。大容量存储设备618可以存储系统程序、应用程序、其它程序模块和数据,它们在本文更详细地描述。大容量存储设备618可以通过连接到芯片组606的存储控制器614连接到计算机602。大容量存储设备618可以由一个或多个物理存储单元组成。存储控制器614可以通过串行连接SCSI(SAS)接口、串行高级技术连接(SATA)接口、光纤通道(FC)接口或用于物理地连接计算机和物理存储设备并在其间传送数据的其它标准接口与物理存储单元接口。
计算机602可以通过变换物理存储单元的物理状态以反映正被存储的信息来将数据存储在大容量存储设备618上。在本描述的本发明的不同实施例中,物理状态的具体变换可以取决于各种因素。此类因素的示例可以包括但不限于用于实现物理存储单元的技术、大容量存储设备618被表征为主要还是辅助存储装置等。例如,计算机602可以通过经由存储控制器614发出指令以更改磁盘驱动器单元内特定位置的磁特点、光学存储单元中特定位置的反射或折射特点、或固态存储单元中的特定电容器、晶体管或其它分立元件的电特点而将信息存储到大容量存储设备618。在不脱离本描述的范围和精神的情况下,物理介质的其它变换是可能的,提供前述示例只是为了促进本描述。计算机602还可以通过检测物理存储单元内的一个或多个特定位置的物理状态或特点来进一步从大容量存储设备618读取信息。
大容量存储设备618可以存储用于控制计算机602的操作的操作系统620。根据一些实施例,操作系统包括LINUX操作系统。根据另一个实施例,操作系统包括来自华盛顿州雷德蒙德的微软公司的SERVER操作系统。根据进一步的实施例,操作系统可以包括UNIX或SOLARIS操作系统。应当认识到的是,也可以使用其它操作系统。根据本文描述的实施例,大容量存储设备618可以存储计算机602使用的其它系统或应用程序和数据,诸如执行支付整合过程的欺诈检查的欺诈模块622、用于管理支付整合过程的支付处理模块624,以及用于管理认证过程(例如,健全性检查、有效性检查等)的认证模块626。也可以提供由计算机602使用的其它系统或应用程序和数据(例如,安全性模块、用户接口模块等)。
在一些实施例中,大容量存储设备618可以用计算机可执行指令编码,当加载到计算机602中时,将计算机602从通用计算系统变换成能够实现本文描述的实施例的专用计算机。如上所述,这些计算机可执行指令通过指定CPU 604如何在状态之间过渡来变换计算机602。根据一些实施例,从(一个或多个)支付整合服务器160的角度来看,大容量存储设备618存储计算机可执行指令,指令在由计算机602执行时执行过程500的部分,用于实现如本文描述的支付整合系统。在进一步的实施例中,计算机602可以访问除大容量存储设备618之外或作为其替代方案的其它计算机可读存储介质。
计算机602还可以包括输入/输出控制器630,用于接收和处理来自多个输入设备(诸如键盘、鼠标、触摸板、触摸屏、电子指示笔或其它类型的输入设备)的输入。类似地,输入/输出控制器630可以向显示设备(诸如计算机监视器、平板显示器、数字投影仪、打印机、绘图仪或其它类型的输出设备)提供输出。将认识到的是,计算机602可以不包括图6中所示的所有组件,可以包括图6中未明确示出的其它组件,或者可以使用与图6中所示的架构完全不同的架构。
一般而言,被执行以实现本发明的实施例的例程(无论被实现为操作系统的一部分还是具体的应用、组件、程序、对象、模块或指令序列,或甚至其子集)可以在本文被称为“计算机程序代码”,或简称为“程序代码”。程序代码通常包括在各种时间驻留在计算机中的各种存储器和存储设备中的计算机可读指令,并且该计算机可读指令在由计算机中的一个或多个处理器读取和执行时,使该计算机进行执行操作所需的操作和/或实施本发明的实施例的各个方面的元素。用于执行本发明的实施例的操作的计算机可读程序指令可以是例如汇编语言或者以一种或多种编程语言的任意组合编写的源代码或目标代码。
在本文描述的任何应用/模块中实施的程序代码能够以各种不同形式作为程序产品单独或共同地分布。特别地,可以使用其上具有用于使处理器执行本发明的实施例的各方面的计算机可读程序指令的计算机可读存储介质来分发程序代码。
本质上是非暂态的计算机可读存储介质可以包括以用于存储信息(诸如计算机可读指令、数据结构、程序模块或其它数据)的任何方法或技术实现的易失性和非易失性以及可移动和不可移动的有形介质。计算机可读存储介质还可以包括随机存取存储器(RAM)、只读存储器(ROM)、可擦可编程只读存储器(EPROM)、电可擦可编程只读存储器(EEPROM)、闪存或其它固态存储器技术、便携式紧凑盘只读存储器(CD-ROM)或其它光学存储装置、磁带盒、磁带、磁盘存储装置或其它磁性存储设备或可以用于存储期望的信息并且可以由计算机读取的任何其它介质。计算机可读存储介质本身不应被解释为瞬态信号(例如,无线电波或其它传播的电磁波、通过诸如波导的传输介质传播的电磁波、或通过电线传输的电信号)。可以将计算机可读程序指令从计算机可读存储介质下载到计算机、另一种类型的可编程数据处理装置或另一个设备,或者经由网络下载到外部计算机或外部存储设备。
存储在计算机可读介质中的计算机可读程序指令可以用于指导计算机、其它类型的可编程数据处理装置或其它设备以特定方式工作,使得存储在计算机可读介质中的指令产生包括实现流程图、序列图和/或框图中指定的功能/动作的指令的制造品。可以将计算机程序指令提供给通用计算机、专用计算机或其它可编程数据处理装置的一个或多个处理器以产生一种机器,使得经由一个或多个处理器执行的指令引起执行一系列计算以实现流程图、序列图和/或框图中指定的功能和/或动作。
在某些替代实施例中,流程图、序列图和/或框图中指定的功能和/或动作可以重新排序、串行处理和/或并发处理,而不脱离本发明的实施例的范围。此外,流程图、序列图和/或框图中的任何一个可以包括比与根据本发明的实施例示出的相比更多或更少的方框。
本文使用的术语仅出于描述特定实施例的目的,并且不旨在限制本发明的实施例。如本文所使用的,单数形式“一”、“一个”和“该”也旨在包括复数形式,除非上下文另外明确指出。将进一步理解的是,当在本说明书中使用术语“包括(comprises)”和/或“包括(comprising)”时,其指定了所述特征、整数、步骤、操作、元素和/或组件的存在,但并不排除一个或多个其它特征、整数、步骤、操作、元素、组件和/或其组的存在或添加。此外,就在详细描述或权利要求中使用术语“包含”、“具有(having)”、“具有(has)”、“带有”、“由…组成”或其变体而言,这些术语旨在以类似于术语“包括”的方式是包含性的。
虽然已经通过各种实施例的描述图示了本发明的全部内容,并且虽然已经相当详细地描述了这些实施例,但是申请人无意将所附权利要求的范围限制或以任何方式限制于这样的细节。其它优点和修改对于本领域技术人员将是显而易见的。因此,本发明在其更广泛的方面不限于所示出和描述的具体细节、代表性装置和方法以及说明性示例。因此,可以从这些细节中进行偏离,而不脱离申请人的总体发明构思的精神或范围。
Claims (20)
1.一种计算装置,包括:
一个或多个处理器;
至少一个存储器设备,与所述一个或多个处理器耦合;以及
数据通信接口,与所述一个或多个处理器可操作地相关联,
其中所述至少一个存储器设备包含多个程序指令,所述多个程序指令在由所述一个或多个处理器执行时使所述计算装置:
在支付整合服务器处经由客户端设备处的支付整合用户接口接收来自旅行提供商服务器的包括旅行记录标识的支付请求,其中支付标识与旅行记录标识相关联,并且支付整合用户接口是提供对多个支付处理器服务器的访问的第一级接口;
在支付整合服务器处,从预订系统获得与旅行记录标识相关联的合格支付处理器信息,其中预订系统对旅行记录标识进行了处理;
基于合格支付处理器信息,访问来自第一支付提供商的第一软件开发工具包(SDK)以及来自第二支付提供商的第二SDK,其中第一SDK包括与第二SDK不同的配置;以及
用与第一SDK相关联的第一接口元素和与第二SDK相关联的第二接口元素更新支付整合用户接口。
2.如权利要求1所述的计算装置,其中所述程序指令还使所述计算装置:
在支付整合用户接口处经由第一SDK从客户端设备接收支付数据。
3.如权利要求2所述的计算装置,其中所述程序指令还使所述计算装置:
响应于从客户端设备接收到支付数据,在支付整合服务器处,使用支付标识经由支付网关从支付处理器获得与旅行记录标识相关联的支付交易数据;
由支付整合服务器通过将支付交易数据整合到旅行记录中来更新旅行记录;以及
由支付整合服务器将更新后的旅行记录提供给预订系统。
4.如权利要求3所述的计算装置,其中支付整合用户接口包括与第三SDK相关联的第三接口元素,第三SDK与欺诈服务实体相关联,并且其中所述程序指令还使所述计算装置:
经由第三SDK接收与支付交易数据相关联的欺诈信息。
5.如权利要求4所述的计算装置,其中所述程序指令还使所述计算装置:
经由欺诈数据库基于第一支付提供商访问与旅行记录标识相关联的欺诈核实信息;以及
核实支付交易数据不是欺诈性的。
6.如权利要求3所述的计算装置,其中所述程序指令还使所述计算装置:
确定与支付交易数据相关联的第一商家和与旅行记录数据相关联的第二商家匹配;
确定与支付交易数据相关联的支付的授权成功;
基于授权时间戳确定与支付交易数据相关联的授权是有效的;
确定不存在与支付交易数据相关联的尝试的后续操作或未决的后续操作;
确定与支付交易数据相关联的支付的金额和货币是可用的;和/或
确定与支付交易数据相关联的支付工具和与旅行记录数据相关联的支付工具匹配。
7.如权利要求2所述的计算装置,其中进一步使所述计算装置在支付整合用户接口处经由第一SDK从所述设备接收支付数据的所述程序指令包括:
进一步使所述计算装置基于旅行记录标识来执行对客户端设备的认证的程序指令。
8.如权利要求1所述的计算装置,其中所述程序指令还使所述计算装置:
通过将支付标识与其它接收到的支付标识进行比较来确定尚未接收到支付标识。
9.一种方法,包括:
在支付整合服务器处经由客户端设备处的支付整合用户接口接收来自旅行提供商服务器的包括旅行记录标识的支付请求,其中支付标识与旅行记录标识相关联,并且支付整合用户接口是提供对多个支付处理器服务器的访问的第一级接口;
在支付整合服务器处从预订系统获得与旅行记录标识相关联的合格支付处理器信息,其中预订系统对旅行记录标识进行了处理;
基于合格支付处理器信息,访问来自第一支付提供商的第一软件开发工具包(SDK)以及来自第二支付提供商的第二SDK,其中第一SDK包括与第二SDK不同的配置;以及
用与第一SDK相关联的第一接口元素和与第二SDK相关联的第二接口元素更新支付整合用户接口。
10.如权利要求9所述的方法,还包括:
在支付整合用户接口处经由第一SDK从客户端设备接收支付数据。
11.如权利要求10所述的方法,还包括:
响应于从客户端设备接收到支付数据,在支付整合服务器处,使用支付标识经由支付网关从支付处理器获得与旅行记录标识相关联的支付交易数据;
由支付整合服务器通过将支付交易数据整合到旅行记录中来更新旅行记录;以及
由支付整合服务器将更新后的旅行记录提供给预订系统。
12.如权利要求11所述的方法,其中支付整合用户接口包括与第三SDK相关联的第三接口元素,第三SDK与欺诈服务实体相关联,所述方法还包括:
经由第三SDK接收与支付交易数据相关联的欺诈信息。
13.如权利要求12所述的方法,还包括:
经由欺诈数据库基于第一支付提供商访问与旅行记录标识相关联的欺诈核实信息;以及
核实支付交易数据不是欺诈性的。
14.如权利要求11所述的方法,还包括:
确定与支付交易数据相关联的第一商家和与旅行记录数据相关联的第二商家匹配;
确定与支付交易数据相关联的支付的授权成功;
基于授权时间戳确定与支付交易数据相关联的授权是有效的;
确定不存在与支付交易数据相关联的尝试的后续操作或未决的后续操作;
确定与支付交易数据相关联的支付的金额和货币是可用的;和/或
确定与支付交易数据相关联的支付工具和与旅行记录数据相关联的支付工具匹配。
15.如权利要求10所述的方法,其中在支付整合用户接口处经由第一SDK从所述设备接收支付数据还包括:
基于旅行记录标识来执行客户端设备的认证。
16.如权利要求9所述的方法,还包括:
通过将支付标识与其它接收到的支付标识进行比较来确定尚未接收到支付标识。
17.一种用计算机程序编码的非暂态计算机存储介质,计算机程序包括多个程序指令,所述多个程序指令在由一个或多个处理器执行时使所述一个或多个处理器执行操作,包括:
在支付整合服务器处经由客户端设备处的支付整合用户接口接收来自旅行提供商服务器的包括旅行记录标识的支付请求,其中支付标识与旅行记录标识相关联,并且支付整合用户接口是提供对多个支付处理器服务器的访问的第一级接口;
在支付整合服务器处从预订系统获得与旅行记录标识相关联的合格支付处理器信息,其中预订系统对旅行记录标识进行了处理;
基于合格支付处理器信息,访问来自第一支付提供商的第一软件开发工具包(SDK)以及来自第二支付提供商的第二SDK,其中第一SDK包括与第二SDK不同的配置;以及
用与第一SDK相关联的第一接口元素和与第二SDK相关联的第二接口元素更新支付整合用户接口。
18.如权利要求17所述的非暂态计算机存储介质,其中所述程序指令使所述一个或多个处理器还执行包括以下的操作:
在支付整合用户接口处经由第一SDK从客户端设备接收支付数据。
19.如权利要求18所述的非暂态计算机存储介质,其中所述程序指令使所述一个或多个处理器还执行包括以下的操作:
响应于从客户端设备接收到支付数据,在支付整合服务器处,使用支付标识经由支付网关从支付处理器获得与旅行记录标识相关联的支付交易数据;
由支付整合服务器通过将支付交易数据整合到旅行记录中来更新旅行记录;以及
由支付整合服务器将更新后的旅行记录提供给预订系统。
20.如权利要求19所述的非暂态计算机存储介质,其中支付整合用户接口包括与第三SDK相关联的第三接口元素,第三SDK与欺诈服务实体相关联,并且其中所述程序指令使所述一个或多个处理器还执行包括以下的操作:
经由第三SDK接收与支付交易数据相关联的欺诈信息。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/498,184 US20230115713A1 (en) | 2021-10-11 | 2021-10-11 | Payment consolidation for a travel management system |
US17/498,184 | 2021-10-11 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115965374A true CN115965374A (zh) | 2023-04-14 |
Family
ID=83691307
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211232735.8A Pending CN115965374A (zh) | 2021-10-11 | 2022-10-10 | 用于旅行管理系统的支付整合 |
Country Status (3)
Country | Link |
---|---|
US (1) | US20230115713A1 (zh) |
EP (1) | EP4163843A1 (zh) |
CN (1) | CN115965374A (zh) |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100145861A1 (en) * | 2008-12-08 | 2010-06-10 | Palm, Inc. | Payment transaction processing for mobile computing devices |
US9710822B2 (en) * | 2012-09-16 | 2017-07-18 | American Express Travel Related Services Company, Inc. | System and method for creating spend verified reviews |
US20150228018A1 (en) * | 2014-02-10 | 2015-08-13 | Datalex (Ireland) Limited | System, method, and program products for compiling credits issued by a travel product provider |
US20150242835A1 (en) * | 2014-02-21 | 2015-08-27 | HomeAway.com, Inc. | Correlating transactions for an aggregated electronic transaction in association with split payment operations |
US20150242834A1 (en) * | 2014-02-21 | 2015-08-27 | HomeAway.com, Inc. | Split payment engine and method to facilitate electronic transaction aggregation |
US20160048864A1 (en) * | 2014-08-13 | 2016-02-18 | American Express Travel Related Services Company, Inc. | Third party digital wallet pay with points |
US20180046944A1 (en) * | 2016-08-12 | 2018-02-15 | Libera, Inc. | Travel Management System |
US11106515B1 (en) * | 2017-12-28 | 2021-08-31 | Wells Fargo Bank, N.A. | Systems and methods for multi-platform product integration |
US20210383489A1 (en) * | 2018-08-20 | 2021-12-09 | Shawn R. Hutchinson | Scheduling, booking, and pricing engines |
US11093912B1 (en) * | 2018-12-10 | 2021-08-17 | Wells Fargo Bank, N.A. | Third-party payment interfaces |
-
2021
- 2021-10-11 US US17/498,184 patent/US20230115713A1/en active Pending
-
2022
- 2022-10-04 EP EP22306474.2A patent/EP4163843A1/en active Pending
- 2022-10-10 CN CN202211232735.8A patent/CN115965374A/zh active Pending
Also Published As
Publication number | Publication date |
---|---|
EP4163843A1 (en) | 2023-04-12 |
US20230115713A1 (en) | 2023-04-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20220300937A1 (en) | Transaction flows and transaction processing for bridged payment systems | |
US20220292485A1 (en) | Systems and methods for payment management for supporting mobile payments | |
US10552822B2 (en) | System and method for processing financial transactions using a mobile device for payment | |
CN105706129B (zh) | 利用旋转应用交易计数器进行安全支付交易 | |
US10354246B1 (en) | Cash transaction machine | |
CN108780550B (zh) | 预先交易分期付款支付解决方案和分期付款模拟的方法和系统 | |
US20170270557A1 (en) | Method and system for tokenization of reward data | |
CN111357024B (zh) | 使用消费者数字钱包作为商家数字钱包中的支付方法 | |
US20150066651A1 (en) | Method and System for Secure Mobile Payment Processing and Data Analytics | |
US20150262166A1 (en) | Real-Time Portable Device Update | |
US20240185337A1 (en) | Systems and methods for collateral deposit identification | |
US20140089186A1 (en) | Mobile payment service for small financial institutions | |
US20220036347A1 (en) | Payment transaction process employing dynamic account expiry and dynamic token verification code | |
CN107710264B (zh) | 将报价动态链接到交易账户的方法和系统 | |
US20230115713A1 (en) | Payment consolidation for a travel management system | |
JP7241581B2 (ja) | システム及びプログラム | |
US20220374894A1 (en) | Integrated payment travel management system | |
CN116468432B (zh) | 订单的处理方法、装置、设备和介质 | |
US11870697B2 (en) | Methods and systems for parallel processing of batch communications during data validation | |
US20240257100A1 (en) | Real-time transactions using a virtual card token | |
US20230206197A1 (en) | Card to bank payments solution | |
EP3192043A1 (en) | System and method for processing financial transactions using a mobile device for payment | |
KR20200129748A (ko) | 발급된 카드를 이용하는 결제 시스템 및 결제 방법 | |
KR20210115449A (ko) | 계좌 기반의 신용 결제 서비스 제공 방법 | |
KR20210116189A (ko) | O2o 통합결제 서비스 플랫폼을 이용한 o2o 통합결제시스템 및 이를 이용한 o2o 통합결제방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40083492 Country of ref document: HK |