多租户争议服务

背景技术

本公开的实施例一般涉及软件架构领域，并且更具体地涉及管理如何在多租户系统架构中入驻(on-board)、管理和/或访问各种实体。

复杂的软件系统可以具有各种架构，包括单租户软件架构和多租户软件架构等。在单租户软件架构中，每个实体(例如一家公司或该公司的一部分)均可以拥有每个软件应用程序、数据和任何支持基础设施的自己的实例。在单租户架构中，每个租户实体的软件均可以根据需要进行定制。然而，使用单租户架构的缺点包括资源费用以及为每个租户托管、定制和维护单独的软件应用程序的要求。

相比之下，在多租户软件架构中，每个实体均可以共享应用程序、数据和/或基础设施的相同实例。多租户软件供应商可从单个软件架构向多个实体提供其应用程序和/或资源。在多租户软件架构中，可以在各个实体之间共享对数据的访问。通过共享大量应用程序、数据和软件，可以优化各种资源，例如安装、配置、物理服务器数量、维护甚至电力。然而，使用多租户架构的缺点包括管理多个软件应用程序如何在多个客户端之间配置和共享的复杂性。同样，设计提供对数据、资源、和/或使用数据和/或资源进行操作的交易服务的安全和可靠访问的多租户基于架构的软件系统可能是棘手的。此外，当在多租户架构系统中使用最初由不同企业管理和/或托管的软件应用程序时，可能会出现互操作性困难。

附图说明

通过参考附图，可以更好地理解本实施例，并且本领域技术人员可以清楚地了解许多目的、特征和优点。

图1是示出可以通过与用户设备进行通信来访问的多租户软件架构系统的实施例的系统示意图。

图2是示出图1的多租户软件架构的用于处理争议的实施例的系统示意图。

图3是示出由多租户市场架构系统使用的数据结构的示意图。

图4是示出用于多租户架构系统的多租户争议服务的模型的实施例的示意图。

图5是示出在多租户架构系统中使用多租户争议服务的操作流程的实施例的时序图。

图6是示出在多租户架构系统中使用多租户争议服务的操作流程的实施例的示意图。

图7是示出图1-图6的通信系统中使用的电子设备的实施例的框图。

具体实施方式

下面的描述包括体现本公开的技术的示例性系统、方法、技术、指令序列和/或计算机程序产品。然而，应当理解，可以在没有这些具体细节的情况下实践所描述的实施例。例如，虽然一些示例涉及访问租户服务，但也考虑了其他类型的服务供应商，例如软件即服务(SaaS)等。此外，虽然讨论主要涉及向访问多租户系统的各种实体提供争议服务，但也考虑了使用类似方法提供其他服务。

在本文描述的多租户软件架构中，每个租户均可以共享应用程序、数据和/或基础设施。多租户软件供应商可以使用多租户软件平台向多个实体提供应用程序和/或资源。多租户软件平台可以促进添加新租户以及入驻由这些新租户提供的数据和/或服务。多租户软件平台可以通过跨租户的各个实体来实现数据访问的规则和策略。多租户软件平台可以使用身份服务(identity service)来提供对这些服务的访问，例如从关联一个租户的实体到另一个租户提供的服务。多租户软件平台可以促进租户之间的交易业务，例如源自访问另一租户的资源的一个租户的交易业务。多租户软件平台还可以向任何租户的实体(例如，客户)提供争议解决能力。

同一租户或不同租户的实体之间可能会发生争议。例如，第一个租户(例如，PAYPAL)的顾客可能会与另一个租户(例如，BRAINTREE)的商家进行交易，例如购买某种产品并付款。再举一个例子，另一个租户(例如，VENMO)的客户可以发起一笔交易，将资金从客户的账户转移到另一个客户(例如，个人对个人的P2P交易)。因此，交易可能涉及P2P或企业对消费者(B2C)交易中的资金转移。在某些情况下，这些交易可能会产生争议。

争议可能是由于第一实体与第二实体之间的分歧。在上面讨论的第一示例中，顾客可能声称其没有收到从商家购买的物品。顾客可能会声称该互动是欺诈性的，并且其没有参与互动。顾客可能会声称向顾客账户收取的交易金额与预期或约定的不同。作为另一个示例，顾客可能声称收到的物品与描述不符、损坏、有缺陷和/或从商家收到的物品存在另一个问题。顾客可能会声称交易发生了重复收费。客户可能会声称商家没有按照先前解决的争议所承诺的那样处理退款。对于上面讨论的第二个示例(即P2P)，可能会出现类似的争议原因，取决于基础交易的类型。

多租户软件平台(也称为多租户平台)可以包括多个先前已入驻的租户。多租户平台可以使用与用户相关联的统一身份来促进对这些租户的实体、策略和服务的访问。租户可以由服务供应商托管和管理。可以基于统一身份的特权以及每个租户的策略来确定对服务的访问。服务可以包括各种商家服务，例如经由(与统一身份相关联的)用户设备(在某个租户处)在店内结账、访问租户的在线商店、在租户的某个商店提前订购、特定租户处的现金流入过程(例如，在自动柜员机(ATM)上)、现金流出过程(例如，在ATM上)、以及在租户的油泵边支付加油站处的自助加油结账等。

这些服务可以包括SaaS和平台即服务(PaaS)服务和/或用户设备可访问的其他云服务。例如，解决方案供应商可以提供对用户设备、各种软件应用程序的访问，或者将此类软件交付给用户设备。服务还可以包括租户间交易服务，其中源自第一租户的交易服务需要访问第二租户的交易资源。多租户平台可以访问其他服务，例如多租户身份服务和/或多租户交易资源服务，以确定如何处理租户间交易(以及租户内交易)。

多租户平台因此可以利用统一身份服务来基于与每个租户相关联的策略提供对租户的选定服务和/或数据的访问。多租户平台可以使用单独的数据库来存储数据以实现隔离，例如当新租户入驻现有平台时，并提供逻辑和/或物理数据隔离。通过入驻租户和选择性地交叉公开服务，可以实现共享数据访问。例如，对于由PAYPAL管理的多租户平台，多租户平台的某些功能，例如风险即服务(RaaS)和/或争议即服务(DaaS)，可以被提供给第三方入驻租户，如FACEBOOK、GOOGLE及其相应的组织，如市场、商店等。因此，在一些实施例中，多租户平台可以包括核心租户(例如PAYPAL)和/或从该租户访问多租户平台的用户，该核心租户提供核心服务和基础设施(包括身份即服务(IaaS)功能)以及对选定租户的任何附加数据访问。可以通过每个租户和/或多租户平台的规则和/或策略，来确定对核心服务和/或基础设施的访问级别。

多租户平台可以通过利用使用一个或多个数据结构的身份管理器来入驻新租户。在一些实施例中，多租户平台可以基于用户请求为用户应用程序展示适当的用户体验。多租户平台可以实现向各种实体和/或租户提供IaaS服务的方法。多租户平台可以通过访问经由各种分层数据结构建模(或使用其他实现方式建模)的服务和实体来提供IaaS和其他服务(例如，DaaS)。多租户平台可以入驻第三方租户，并为这些租户及其相应的组织提供入站服务和出站服务。例如，多租户平台可以入驻GOOGLE和GOOGLE的各种组织，例如，INSTAGRAM和SHOPS、它们相应的商家、以及每个商家的客户。

在一些实施例中，多租户平台可以向任何租户的实体提供争议解决能力。多个租户可以入驻多租户平台，包括第一服务供应商和第二服务供应商。多租户平台可以包括身份管理器，该身份管理器管理与第二服务供应商的多个顾客的实体身份相对应的顾客表示。第一服务供应商可以从管理多个顾客的实体身份的第二服务供应商接收争议请求。争议请求指示多个顾客中的一个顾客与另一实体之间的有争议的交易。多租户平台可以将争议请求与顾客表示一起传播到确定争议结果的争议管理引擎。争议管理引擎可以基于有争议的交易的特征和顾客的特征来确定结果。争议管理引擎可以将确定传播到第二服务供应商。下面的描述和相关的图例示出了针对上面列出的想法的各种实施例。

图1是示出可以通过与用户设备通信来访问的多租户软件架构系统的实施例的系统示意图。在系统图的概览中，用户设备104可以与包括多租户平台102的处理系统100通信。处理系统100可以使用多租户交易处理器(MT-交易处理器)101来处理请求。多租户平台102可以提供对多个服务供应商108、110和112的访问。在一些实施例中，多租户平台102可以对服务供应商108-112中的每一个进行建模，使得MT交易处理器101可以访问服务供应商的服务116-124、策略123-127和/或资源162-166。

多租户平台102包括元素132-148处的核心服务以及附加服务130(1)-130(5)。多租户平台102可以向服务供应商108-112提供服务，例如访问其他服务(包括DaaS)可能需要的IaaS服务。因此，多租户平台102可以管理多个租户，每个租户可以与一个或多个服务相关联，然后暴露这些服务以供访问。在一些实施例中，服务供应商108-112中的每一个可以是实际供应商，该实际供应商随后在多租户软件架构中(即，在多租户平台102中)表示(例如，通过建模)的。尽管未在图1中示出，但是服务供应商108-112中的每一个均可以包括相应交易处理器，该相应交易处理器用于处理自己的请求。MT交易处理器101可以是完全集成到多租户平台102上的交易处理器。MT交易处理器101可以是用于处理交易的默认交易处理器。

多租户平台102可以在账户142处存储用户的用户信息。在一些实施例中，账户142包括核心租户的用户(也称为“核心用户”)的信息。核心租户可以是服务供应商108-112之一，或者是完全集成到多租户平台102中的服务供应商。多租户平台102可以促进向核心用户提供各种核心服务。核心服务可以包括身份服务132、风险服务138、合规服务140、支付服务148(包括支出服务)、MT-MKT(多租户市场)154、MT-XO(多租户结账服务)158、MT-活动(多租户活动跟踪器)172、和/或MT-争议180(多租户争议服务，又名MT-DaaS)。

在一个实施例中，多租户平台102在身份服务132元素处提供IaaS服务。身份服务132可以生成并维护用于管理其核心实体的核心分层数据结构。核心服务还可以包括对策略配置136的访问以及对帐户142、商家144和消费者146的访问。账户142与身份服务132相关联。多租户平台102还可以提供租户间交易服务，例如在租户108和110之间，其中租户108和110不需要完全集成。

服务供应商108可以包括实体114、策略123、服务116和交易资源162。类似地，服务供应商110和112分别包括实体118和122、策略125和127、服务120和124、和/或交易资源164和166。服务供应商108的元素114、123、116和162以及服务供应商110和112的类似元素可以由多租户平台102建模，如下所述。在一些实施例中，MT-MKT 154可以建模和管理服务供应商的商家/卖家之间的关系，而身份服务132建模和维护跨多租户平台102的各种实体的身份。在一些实施例中，某个服务供应商可以完全集成到多租户平台102上，即可以包括为核心租户生成核心分层数据结构的过程。在该示例中，身份服务132可以管理核心用户(例如，在其自己的命名空间中)，这意味着服务供应商108对于其自己的用户没有其自己的身份服务。

服务供应商108、110和112可以入驻到多租户平台102上并继续管理他们自己的身份(例如，使用他们预先存在的3P-IdP，如下面参考图2所讨论的)。来自服务供应商110的用于访问除其自己的服务120之外的服务的任何访问(例如，访问服务130(1))使用统一身份来访问跨多租户平台102的服务和/或数据。在入驻过程中，多租户平台102可以通过身份服务132和MT-MKT 154生成各个服务供应商的模型。在一些实施例中，MT-MKT 154被逻辑建模为身份服务132的一部分(例如，作为其分层数据的子集)。在一些实施例中，MT-MKT 154可以在逻辑上与身份服务132分离，但与身份服务132中的相应实体具有链接/关联。

入驻过程可以包括访问身份服务以确定正在由相应身份服务管理的实体的至少一部分。如果实体没有被迁移(例如，通过完全集成)到身份服务132，则身份服务可以生成在核心分层数据结构中被入驻的实体的表示。这些表示随后被IaaS服务用于确定和使用跨多租户平台102的统一身份(对于某个用户)。表示可以包括轻量级元素和/或链接元素。下面更详细地解释了生成和使用用户表示的过程。

身份服务132可以管理和访问策略配置136，例如强制访问某些顾客和/或商家域。可以通过每个实体的分层数据结构(下面讨论)访问策略配置136。多租户平台102可以通过多租户API 126与服务供应商108-112和/或用户设备104通信。多租户平台102可以基于某个统一身份，通过多租户的租户API 126向请求实体提供与租户、关联服务和/或关联用户体验相关的信息。此外，多租户平台102可以例如通过提供IaaS服务而促进各种租户108-112之间的通信(即，通过它们相应的表示)。

例如，新的租户，例如服务供应商112，可以由多租户平台102入驻。一个或多个核心服务132-148可以存储关于新租户的信息。在一些实现方式中，在入驻时，与每个租户相关联的命名空间(例如，其实体，例如商家和/或顾客)可以入驻到身份服务132上。在一些实施例中，新租户的一项或多项服务，例如服务124，可以被暴露(例如，作为模型)以供多租户平台102的其他用户访问。在一个实施例中，核心服务供应商(被集成到多租户平台102中)可以处理由服务供应商108提供并经由在UI 106访问的用户体验提供的产品/服务的支付和订单履行。核心服务供应商还可以通过MT-Dispute 180为交易提供争议解决能力，该交易由MT-Platform 102处理或由注册服务供应商108-112之一处理。因此，MT-争议180可以促进独立于租户及其实体的争议管理服务。MT-争议180可以与入驻租户的任何现有争议管理系统对接，并提供包括风险评估能力在内的争议解决，以及对每个入驻租户的交易资源的退款功能。

在一个实施例中，多租户平台102还可以在多租户平台102处生成服务124的表示130(5)。因此，从其他租户(例如从用户设备104或从服务供应商110)到服务124的任何访问是经由服务表示130(5)处的统一身份(例如，通过使用IaaS)来执行的。在一些实施例中，对于完全集成的入驻租户，可以由MT交易处理器101直接执行对该租户的服务的访问，而不使用完全集成的服务的表示。在一些实施例中，对于未完全集成的入驻租户，MT交易处理器101可以通过调用入驻(但未完全集成)服务的表示130(5)来执行对该租户的服务的访问。表示130(5)然后可以访问实际服务124。

用户设备104可以是能够将用户请求传送到多租户平台102的任何类型的计算设备。用户设备104可以被实现为自助服务终端、销售点(PoS)终端、移动设备等。用户设备104包括用户界面(UI)106，通过该用户界面(UI)106，用户可以与显示的用户体验交互，例如访问通过多租户平台102提供的某些服务。用户设备104可以在多租户平台102处生成和传送对特定服务的用户请求。用户设备104可以与服务供应商108-112和/或与处理系统100对接。交易处理器然后可以例如通过多租户API 126与多租户平台102的各种组件通信。

多租户平台102可以通过合规服务140提供CaaS，以确保服务供应商108的商家的合规。多租户平台102可以(例如，通过风险核心服务138)提供风险分析，以确定是否执行服务和/或处理由服务供应商108的商家提供的产品/服务的支付。核心服务供应商可以处理来自与用户设备104相关联的用户账户的支出。核心服务供应商可以向与每个商家相关联的组织的账户提供支出服务。

一旦作为核心租户入驻，核心服务供应商的账户就可以直接在多租户平台的账户142元素处存储和访问。例如，买方(例如，用户设备104的用户)可以与一个支付账户相关联，并且卖方(例如，租户之一)可以与支付系统处的另一个支付账户相关联(其可以是使用处理系统100来实现的)。在对所请求的服务(例如，支付交易)成功执行风险分析后，核心服务供应商可以(例如，通过支付核心服务148)执行从买方的支付账户到商家的支付账户的资金转移。

支付系统可以通过PAYPAL或其他允许用户发送、接受和请求资金转账的在线支付系统来实现。在一些实施例中，用户体验还可以提供对某些服务的访问。因此，除了支付服务之外，或者代替支付服务，用户体验可以包括对于特定租户来说是独特的其他功能，例如选择用于订购的项目、对特定SaaS功能的访问等等。因此，解决方案供应商可以从支付系统向用户设备的用户提供基于位置数据确定的资金注入/资金流出服务。

为简单起见，图1仅示出了单个用户设备104。然而，如本文所讨论的，多租户平台102与多个用户设备对接，因此向许多不同的用户提供对服务的访问。类似地，除了所示的租户之外，多租户平台102还可以入驻多个租户。多租户平台102还可以具有作为核心服务132-148的一部分并入的多个核心租户。

图2是示出图1的多租户软件架构的用于处理争议的实施例的系统示意图。图2示出了服务供应商108和110的某些组织的身份服务如何由多租户平台102建模的实施例。如图所示，(实际)服务供应商108的市场组织可以包括第三方身份供应商(3P-IDP)204，该第三方身份供应商(3P-IDP)204管理商家206(1)和206(2)的实体以及消费者202(1)和202(2)的实体。类似地，(实际)服务供应商表示110可以包括管理消费者214(1)和214(2)的实体的3P-IDP 204。

在一些实施例中，服务供应商可以至少部分地独立于多租户平台102操作，例如，服务供应商108可以(例如，基于策略123)使用资源162为实体114执行服务116，而不访问多租户平台102的数据和/或服务。在一些实施例中，在入驻之后，入驻服务供应商可以独立于多租户平台102继续执行一些服务。例如，入驻服务平台可以继续向用户提供UI等服务，并且可以发起和执行许多租户内交易(例如，仅在该入驻租户的顾客和商家之间的交易)。入驻服务平台可以(例如，通过与MT活动172通信)将这些交易通知给多租户平台102以及使用身份服务132更新任何实体改变。入驻服务平台可能需要访问多租户平台102以获得各种多租户服务，例如争议服务180、风险服务138等。在一些实施例中，一旦服务供应商完全集成(即，迁移)，完全集成的服务供应商就不能独立于多租户平台102运行。

图2示出了多租户平台102包括身份服务132、账户元素142、风险元素138、合规元素140、MT-争议180、支付148、MT-活动172以及服务130(1)。注意，为了简单起见，图1的一些服务没有在图2中示出。服务供应商108可由身份服务132建模为分层数据结构244的一部分。如下所述，身份服务132可以对服务供应商108的一些部分进行建模，包括3P-IDP 204的表示，其指示商家206(1)和206(2)的表示、消费者202(1)和202(2)的表示、和/或金融机构209(1)和209(2)的表示。尽管当前公开讨论了使用分层数据结构来管理和促进对各种实体表示的操作的身份管理器，但是预期其他实施方案，包括表格、链接表和/或图形等。因此，术语分层数据结构涵盖各种实现方式，并不意味着是限制性的。

身份服务132可以类似地对服务供应商110的一些部分(例如，其可以表示VENMO)建模。身份服务132可以将服务供应商108和/或110中的每一个建模为能够在相应服务供应商108和/或110的入驻期间生成的服务供应商表示。3P-IDP 308和310(图3)可以在分层数据结构244中分别表示服务供应商108和110的实际IDP 204和212。身份服务132包括访问层242和由MT-IDP 246管理的分层数据结构244。访问层242是身份服务132的一部分，当被多租户平台102入驻时，其定制与服务供应商相关联的数据。例如，访问层242包括与由服务供应商108提供的产品和/或服务以及用于访问由服务供应商108提供的服务(例如，服务116)的服务端点有关的信息。服务端点可以由表示服务供应商108的分层数据结构244中的对应节点引用。

由于服务供应商108和110中的每一个均分别包括自己的3P-IDP 204和212，这些租户中的每一个均可以继续管理他们自己的相应实体的身份。例如，服务供应商110可以继续管理实体214(1)-214(2)，包括管理消费者214(1)和214(2)的身份信息、联系人数据以及任何特征。FI 209(1)和209(2)中的每一个均可以与相应的商家206(1)和206(2)相关联，例如以便接受支出服务。

下面参考图3讨论如何生成和访问分层数据结构244的各种实施例。MT-IDP 246可以生成和管理入驻租户的实体的表示，即实体206(1)、206(2)、202(1)和202(2)，以及服务供应商108的3P-IDP 204。类似地，MT-IDP 246可以生成和管理服务供应商110的实体214(1)、214(2)、212的表示。服务供应商110可以例如通过分层数据结构244中的3P-IDP 204的表示将实体214(1)和214(2)的任何改变更新到多租户平台102。这些源自3P-IDP 212的更新用于保持它们相应表示的数据是最新的。类似地，经由分层数据结构244的表示执行的任何服务(例如核心服务)可以传播回3P-IDP 212。

身份服务132允许用户作为实体入驻到服务供应商108-112的任何表示上。由于服务供应商本身是多租户架构102中的租户，用户的表示将由身份服务132创建(例如在分层数据结构244中该租户表示的3P-IDP表示下)。该3P-IDP可以表示为该入驻用户的记录系统(SOR)。多租户平台102可以使用身份服务132来识别同一用户和他/她跨越各种命名空间的交易资源，从而使同一用户能够在不同的命名空间中拥有多个账户，并可能链接或联合这些账户。

在一些实现方式中，多租户平台102可以实现多个身份名称空间(例如，与服务供应商108、服务供应商110相关联的分离的名称空间，以及与多租户平台102的完全集成服务供应商相关联的另一个名称空间)的协调，以在与这些名称空间的实体相对应的身份之间有效且安全地转移交易资源。例如，一个域(例如，与服务供应商108相关联的命名空间)中的用户可以通过多租户平台102查找其他命名空间中的用户(例如，与服务供应商110相关联的命名空间中的用户、或与服务供应商112关联的商家)并建立包括交易资源转移的关系。多租户平台102可以将单独的身份和市场域等用于单独的交易类型。

MT活动172可以记录由入驻服务供应商108和110的实体(以及完全集成的租户的任何实体)执行的租户间和/或租户内交易。在一些实施例中，MT-活动172可以从入驻服务供应商108和/或110接收关于任何本地租户内交易的指示，例如消费者214(1)和214(2)之间可能不使用多租户平台102的服务的P2P交易。服务供应商110可以发送任何租户间交易的通知，例如，租户110和108的实体之间(例如消费者214(1)和商家206(1)之间)或租户110的实体与多租户平台102的实体之间。例如使用多租户平台102的服务的至少一些交易可以由MT-活动172自动记录。交易信息可以包括交易的一些细节，例如涉及的实体、交易时间、交易金额、交易类型、收据等。MT-活动172可以内部地标准化记录的交易信息，因为每个租户可能提供具有不同类型数据的不同类型的通知。

在接收到争议请求时，多租户平台(例如，MT-争议180)可以访问MT-活动172以获得关于有争议的交易的信息。对于某些有争议的交易(例如，其中没有交易信息或不完整的交易信息被MT-活动172记录)，MT-争议180确定访问发起服务供应商(例如，发起争议请求的服务供应商110)，以获取有争议的交易信息。

MT-争议180可以对争议请求做出争议确定。争议确定可以包括与风险138通信，以确定涉及争议的实体的风险特征。例如，MT-争议180可以调用风险138(使用消费者214(1)的表示)来确定消费者214(2)的风险级别。在一些情况下，风险138可以基于消费者214(1)的表示(例如，如下面参考图4所讨论的轻量级消费者)来执行该确定。在其他情况下，风险138确定访问服务供应商110的3P-IdP 212，以获得关于消费者214(2)的附加信息。MT-争议180可以确定争议结果，然后可以将其传播到请求服务供应商。多租户平台102还可提供可由MT-争议180访问的支付服务148，以处理任何支付，例如退款。支付服务148还可以访问服务供应商的FI，例如FI 166(1)。

图3是示出由多租户市场架构系统使用的分层数据结构的示意图。图3示出了几个分层数据结构302、303和304(它们可以统称为分层数据结构274)，它们可通过MT-IDP 246访问。图3示出了分层数据结构302-306的实体之间的关系。图3的分层数据结构的组织和链接可以称为依赖图。注意，分层数据结构302-306的组织和类型仅出于说明目的而示出，并且3P-IDP表示308和310中的一个或多个可以根据需要使用不同的数据结构来实现。

第一分层数据结构302示出了完全集成的服务供应商312。注意，通过身份服务132，完全集成的服务供应商可以向多租户架构的各种用户提供核心服务。如图所示，服务供应商312包括商家表示320(1)-320(3)，该商家表示320(1)-320(3)可以包括关于实际商家的完整信息。完全集成的商家表示320(1)-320(3)可以由多租户平台102直接操作。例如，商家表示320(1)-320(3)可以是完全集成的PAYPAL商家。

分层数据结构304可以对应于已入驻服务供应商108的各种实体，并且能够对卖家、商家和服务供应商108的各种组织实体(例如GOOGLE)之间的复杂关系进行建模。分层数据结构304由3P-IDP表示308管理。因此，3-IDP表示308可以是分层数据结构244中的3P-IDP204的一部分的表示，该部分对应于服务供应商108的各个组织的各个卖家和商家。身份即服务(IaaS)服务可以被MT-IDP 246用来适当地创建入驻的商家之间的关系。如图所示，3P-IDP 308本身可以与服务供应商312相关联。

分层数据结构304可以包括各种实体，包括管辖区316(1)和组织332和330(1)。分层数据结构304包括轻量级商家LW 334(1)-334(3)。轻量级商家是实体，该实体表示如使用另一个分层数据结构由另一个身份管理器管理的相应实体，并且包括该相应实体的一些数据。管辖区实体316(1)表示某个司法管辖区，例如美国或欧盟。

分层数据结构304包括组织332(其可以是服务供应商108的某个服务单位)中的LW商家334(1)，该LW商家334(1)(即，使用链接350)被链接到组织330(1)(其可以是服务供应商108的市场108)中。链接350可以指示对商家表示320(1)执行的所选入站服务可以传播到链接的LW商家334(2)上。因此，链接350在两个轻量级商家表示之间。

类似地，分层数据结构306可以对应于已入驻服务供应商110的各种实体，并且可以用于对卖家、商家和区域服务供应商110的各种组织实体之间的复杂关系进行建模。分层数据结构306由3P-IDP表示310管理。分层数据结构306可以包括各种实体，包括组织330(2)。分层数据结构306还包括顾客表示(例如，链接的顾客)334(4)和334(5)。

在使服务供应商108和110入驻的过程中，多租户平台102可以生成用于身份和用于共享入站/出站服务(这里称为市场服务)的分层数据结构。如图3所示，多租户平台102可以为该服务供应商的商家和卖家生成轻量级表示。在一些实施例中，身份服务生成单独的身份分层数据结构，其中管理了商家、他们的顾客和各种交易服务的综合身份。尽管商家的实际身份由该租户的3P-IDP管理，但交易是通过市场服务提供给服务供应商及其商家的。

MT-争议180可以从服务供应商110(或从另一个来源)接收争议请求。MT-争议180可以访问身份服务132，以访问顾客的身份(即，通过顾客的表示)。例如，MT-争议可以访问顾客表示334(5)。MT-争议可以使用争议请求，或基于争议请求创建内部争议请求(例如，MT争议请求)。MT-争议请求然后可以用作多租户服务调用，该多租户服务调用可以由多租户平台102的各种服务路由和处理。在一些实施例中，争议请求可以由服务供应商(例如服务供应商108)托管的供应商争议管理器创建。MT-争议180可以与此类供应商争议管理器交互，包括用于将争议请求的结果传送给提出请求的3P-争议管理器。

图4是示出用于多租户架构系统的多租户争议服务的模型的实施例的示意图。图4示出了MT-争议180的简化模型和用于处理争议请求的多租户平台102的一些元素。图4还示出了在处理争议请求时可以与MT-争议交互的服务供应商110的元素。服务供应商110可以包括各种服务120，包括退款120(1)和支付120(2)、本地身份服务212和供应商争议服务器412。注意，服务供应商110元素仅出于解释目的而示出，并且可以使用更少或附加的元素来实现所讨论的类似功能。MT-争议180可以包括拒付416、争议418、文档420、评论422和争议管理引擎424元素。MT-争议180可以与MT-活动172、风险138和身份服务132通信。

供应商争议服务器412可以向由身份212管理的实体(例如，由服务供应商110管理的顾客)提供争议管理功能。供应商争议服务器412可以提供在用户设备处访问的争议UI。例如，用户可以通过UI 106访问争议UI。供应商争议服务器412可以从UI 106接收用户对争议的选择。供应商争议服务器412可以(基于用户对某个争议的选择)创建服务争议请求，该服务争议请求可以(例如通过多租户API 126)被传送到MT-争议180。服务争议请求可以指示争议规范和顾客身份(例如，由身份212管理)。支付120(1)可用于管理租户110(例如其顾客)的各种交易的支付。退款120(1)可用于处理和/或接收来自MT-争议180的退款416元素的退款。

争议管理引擎424可以为任何内部租户(例如，完全集成的)或外部租户(例如，服务供应商108-112)及其实体做出争议确定。争议管理引擎424可以独立于交易是由多租户平台102处理还是由外部实体(例如由租户110)处理而做出这些确定。争议管理引擎可以访问身份服务132，以获得在服务争议请求中标识的顾客身份的表示(例如，在分层数据结构244中)。

争议管理引擎424可以(例如，通过退款120(1))支持针对内部资源和外部资源的退款和其他资金功能。争议管理引擎424可以基于访问MT-活动172来做出争议确定，该MT-活动172可以通过入驻和/或内部租户及其实体而具有关于内部和/或外部交易的交易记录。争议管理引擎424可以访问文档420，该文档420可以存储争议中涉及的实体的当前和/或先前交易的各种交易文档。争议管理引擎424可以访问文档以获得用于做出争议确定的附加上下文。争议管理引擎424可以与供应商争议服务器412通信，以提供争议确定的结果。这些结果然后可以由供应商争议服务器412通过UI 106提供给用户。

图5是示出在多租户架构系统中使用多租户争议服务的操作流程的实施例的时序图。图5图示了使用MT-争议180的多租户平台102的各个实体之间的示例性逻辑操作流程。图5图示了UI 106、供应商争议服务器412、争议API 126(1)(其可以是多租户API 126的一部分)、MT-争议180、MT-IDP 132(即，身份服务132)、MT-活动172、MT-风险138和FI 506(1)(其可以是租户110的资源164之一)之间的通信。

在511处，UI 106可以接收指示争议的用户输入，并将用户输入传送给供应商争议管理器412。在512处，供应商争议管理器412可以创建服务争议请求，该服务争议请求包括基于供应商的本地身份管理器212的顾客身份。在514处，供应商争议管理器412可以通过争议API 126(1)将服务争议请求传送到多租户平台102。

在一些实施例中，争议API 126(1)然后可以与MT-争议180通信服务争议请求。在一种实现中，MT-争议180然后可以处理服务争议请求，该服务争议请求包括访问MT-IDP132以获得多租户系统中的实体表示，以及访问MT-活动172以获得针对该实体表示记录的交易。或者，根据实现方式，代替MT-争议180执行529、522和522，争议API 126(1)可以执行524、526和530。争议API 126(1)可以在524处访问MT-IDP 132以获得多租户系统中的实体表示，并且在526处访问MT活动172以获得针对该实体表示记录的交易。在530处，争议API126(1)然后可以将多租户信息和服务争议请求通信给MT-争议180。

在532处，MT-争议180可以生成基于服务争议请求以及与多租户平台102相关的交易和实体表示信息的争议请求。在534处，MT-争议180可以与风险138通信以获得风险信息(通过身份表示，例如顾客214(1)的顾客表示334(4))。MT-争议180还可以通过实体表示访问文档420，以获得争议中涉及的实体的历史数据的任何记录。在532处，MT-争议180可以对所请求的争议做出争议确定。MT-争议180还可以将结果记录在文件420中以供将来参考。需要注意的是，所记录的争议确定可用于所涉及实体(包括作为另一租户的实体)的未来争议和其他服务(例如风险确定)。

在536处，可以将争议确定传送到争议API 126(1)。在538处，争议API 126(1)然后可以将争议确定传送给临时争议管理器412，包括转换确定结果和服务供应商110要求的实体身份。在540处，临时争议管理器可以处理确定结果并通过UI 106将它们提供给用户(在542处)。在544处，MT-争议180可以对服务供应商的金融工具506(1)(其可以实现FI 166(1))执行退款交易。

图6是示出在多租户架构系统中使用多租户争议服务的操作流程的实施例的示意图。参考图1-图5中描述的系统和组件来描述图6的方法(用于说明目的而不是作为限制)。示例性操作可以由使用多租户平台102的交易处理器来执行。

在602处，MT-争议180从服务供应商接收争议请求。参考图2，MT-争议180可以从服务供应商110(例如，从供应商争议管理器412)接收服务争议请求。服务争议请求可以针对由身份212管理的实体身份(例如，顾客)。服务争议请求可以在服务供应商110的两个用户之间，或者在服务供应商110的用户和由另一个服务供应商管理的商家之间。

在604处，MT-争议180访问身份管理器，以确定争议请求中顾客的顾客表示。参考以上示例，MT-争议180可以访问身份服务132，以确定顾客表示(例如，顾客表示334(1))，该顾客表示对应于在服务供应商110处并由服务争议请求标识的顾客实体。

在606处，MT-争议180确定争议请求中的另一实体是否是多租户平台102的租户的商家。继续参考以上示例，服务争议请求可以在顾客表示334(1)与商家表示320(2)(由完全集成的服务供应商312管理)之间。如果MT-争议180确定另一个实体是另一个租户的商家，则流程在612处继续，否则流程在614处继续。在606的变体中，MT-争议180可以确定争议请求中的其他实体是另一顾客或其他实体(但不是商家)。

在608处，MT-争议180访问关于商家的商家表示的信息，以用于确定争议请求。参考上面的示例，MT-争议180可以访问身份服务132，以确定入驻的商家以及任何相关信息(例如，与多租户平台102相关的)。在608处，MT-争议180可以使用获得的商家信息来修改争议请求。

在612处，MT-争议180可以确定是否需要另一服务来生成争议请求。如果MT-争议180确定需要另一服务，则流程在614处继续，否则流程在616处继续。在614处，MT-争议180可以访问生成争议请求可能需要的另一服务，例如风险138、策略136、规则134。

在616处，MT-争议180生成争议请求。在614处，MT-争议180可以基于服务争议请求、(一个或多个)顾客表示、可选的商家表示、以及任何附加服务的结果来生成请求。在618处，MT-争议180处理争议请求，包括确定争议请求的结果。在618处和图6中所示的其他步骤处，MT-争议180可以实现到供应商争议管理器412的回调通信，以指示初始争议请求的进展。

应当理解，图1-图6和这里描述的操作是旨在帮助理解实施例的示例，不应用于限制实施例或限制权利要求书的范围。实施例可以不同地执行附加操作、更少的操作、不同顺序的操作、并行的操作以及一些操作。例如，参考图5和图6的流程图描述的一个或多个元素、步骤或过程可以被省略、以不同的顺序描述、或者根据需要或适当地组合。

如本领域技术人员将理解的，本公开的方面可以体现为系统、方法或计算机程序产品。因此，本公开的各方面可以采用完全硬件实施例、软件实施例(包括固件、常驻软件、微代码等)或组合软件和硬件方面的实施例的形式，这些方面可以在本文中统称为“模块”或“系统”。此外，本公开的方面可以采用包含在一个或多个计算机可读介质中的计算机程序产品的形式，该计算机可读介质具有包含在其上的计算机可读程序代码。

可以利用一种或多种计算机可读介质的任何组合。计算机可读介质可以是计算机可读信号介质或计算机可读存储介质。计算机可读存储介质可以，例如，但不限于，电子、磁、光、电磁、红外或半导体的系统、设备或装置或前述的任何合适的组合。计算机可读存储介质的更具体示例(非详尽列表)将包括以下内容：便携式计算机软盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程存储器只读存储器(EPROM或闪存)、便携式光盘只读存储器(CD-ROM)、光存储设备、磁存储设备或前述的任何合适组合。在本文档的上下文中，计算机可读存储介质可以是可以包含或存储由指令执行系统、装置或设备使用或与其结合使用的程序的任何有形和/或非暂态介质。

计算机可读信号介质可以包括具有计算机可读的程序代码的传播的数据信号，该计算机可读的程序代码包含在其中，例如包含在基带中或作为载波的一部分。此类传播的信号可以采用多种形式中的任何一种，包括但不限于电磁、光或其任何合适的组合。计算机可读信号介质可以是任何计算机可读介质，该任何计算机可读介质不是计算机可读存储介质，并且可以通信、传播或传输程序，该程序由指令执行系统、装置或设备使用或与其结合使用。

包含在计算机可读介质上的计算机程序代码可以使用任何合适的介质来传输，包括但不限于无线、有线、光纤电缆、RF等，或者前述的任何合适的组合。

用于执行本公开的各方面的操作的计算机程序代码可以用一种或多种编程语言的任意组合编写，包括面向对象的编程语言，例如Java、Smalltalk、C++等和传统的程序化程序语言，例如“C”编程语言或类似的编程语言。计算机程序代码可以完全在用户计算机上、部分在用户计算机上、作为独立软件包、部分在用户计算机上和部分在远程计算机上或完全在用户计算机或服务器上执行(例如，编译成计算机程序指令)。在后一种情况下，远程计算机可以通过任何类型的网络(包括局域网(LAN)或广域网(WAN))连接到用户的计算机，或者(例如，使用互联网服务供应商通过互联网)可以连接到外部计算机。

参照根据本公开的实施例的方法、装置(系统)和计算机程序产品的流程图图示和/或框图描述了本公开的方面。应当理解，流程图说明和/或框图的每个块以及流程图说明和/或框图中的块的组合均可以由计算机程序指令来实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理设备的处理器以生产机器，使得经由计算机的处理器或其他可编程数据执行的计算机程序指令处理设备，创建用于实现在流程图和/或框图块中指定的功能/动作的设备。

这些计算机程序指令也可以存储在计算机可读介质中，该计算机可读介质可以指导计算机、其他可编程数据处理装置或其他设备以特定方式运行，使得存储在计算机可读介质中的指令产生制品，该制品包括实现流程图和/或框图块中指定的功能/动作的指令。

计算机程序指令也可以加载到计算机、其他可编程数据处理装置或其他设备上，以导致在计算机、其他可编程设备或其他设备上执行一系列操作步骤，以产生计算机实现的过程，使得在计算机或其他可编程装置上执行的指令提供用于实现流程图和/或框图块中指定的功能/动作的过程。

图7是图1-图6的通信系统中使用的电子设备700的一个实施例的框图。在一些实施方案中，电子设备700可以是膝上型计算机、平板计算机、移动电话、自助服务终端、电力线通信设备、智能电器(PDA)、服务器和/或一个或多个其他电子系统。例如，用户设备可以使用移动设备来实现，例如移动电话或平板电脑。例如，可以使用一个或多个服务器来实现支付系统。电子设备700可以包括处理器单元702(可能包括多处理器、多核、多节点和/或实现多线程等)。电子设备700还可以包括存储单元706。存储器单元706可以是系统存储器(例如，高速缓存、SRAM、DRAM、零电容RAM、双晶体管RAM、eDRAM、EDO RAM、DDR RAM、EEPROM、NRAM、RRAM、SONOS、PRAM等中的一种或多种)或者任何一种或多种以上已经描述的可能实现的机器可读介质。电子设备700还可以包括总线710(例如，PCI、ISA、PCI-Express、

存储器单元706可以包含实现以上图1-图6中描述的实施例的功能。在一个实施例中，存储器单元706可以包括用于处理多租户架构系统中的争议的一种或多种功能。这些功能中的任何一种可以部分地(或完全地)在硬件中和/或在处理器单元702上实现。例如，一些功能可以用专用集成电路、在处理器单元702中实现的逻辑、在外围设备或卡上的协处理器等中实现。此外，实现可以包括未在图7中示出的更少或附加部件(例如，视频卡、音频卡、附加网络接口、外围设备等)。处理器单元702、存储器单元706、网络接口704和通信接口708耦合到总线710。尽管示出为耦合到总线710，但是存储器单元706可以耦合到处理器单元702。

尽管参考各种实现方式和利用来描述实施例，但是将理解这些实施例是说明性的并且本公开的范围不限于它们。一般而言，可以使用与任何硬件系统一致的设施来实现如本文所述的用于处理多租户架构系统中的争议的技术。许多变化、修改、添加和改进均是可能的。

可以为本文描述的部件、操作或结构提供多个实例作为单个实例。最后，各种部件、操作和数据存储之间的边界在某种程度上是任意的，并且在特定说明性配置的上下文中示出了特定操作。其他功能分配可以设想并且可以落入本公开的范围内。一般而言，在示例性配置中作为单独组件呈现的结构和功能可以实现为组合结构或部件。类似地，呈现为单个组件的结构和功能可以实现为单独的部件。这些和其他变化、修改、添加和改进可以落入本公开的范围内。