CN105830106A - 用于分割散列化支付账户处理的方法和系统 - Google Patents

Abstract

用于以下操作的方法和系统：接收与交易相关联的授权请求，所述授权请求包括账户代码；接收与所述账户代码相关联的用户代码；将所述账户代码和所述用户代码关联在一起以形成支付账户代码；确定与所述支付账户代码对应的账户标识符；确定是否将所述支付账户代码映射到主账户号(PAN)；响应于确定所述支付账户代码将被映射到所述PAN，将所述支付账户代码映射到所述PAN以查明与所述支付账户代码对应的PAN；并且发送包括所述PAN的所述授权请求以被授权。

Description

用于分割散列化支付账户处理的方法和系统

背景技术

传统上，信用卡、借记卡和其他类型的卡的商家、持卡者和开户机构以及在其上或其中包括主账户号(PAN)的表示的支付装置的主要关心的问题是使用PAN的欺诈的安全防护和预防。通常，PAN被印刷和/或压印在表面上和/或被编码在支付装置的磁条上。在一些包括电子元件(诸如，举例来说，具有集成电路和存储器组件的非接触式支付信用卡(即，芯片卡))以及用于移动装置的电子钱包应用的支付装置中，PAN可以被以电子格式存储。大量各种各样的欺诈预防措施和方案已经被提出和/或实现来努力预防被提供给常规的支付装置的PAN表示的欺诈性使用。

一些以前的对抗PAN的欺诈性使用的欺诈预防措施和技术包括例如在涉及PAN的交易的处理中除了PAN之外还需要一条信息。一些支付处理技术除了被印刷在或者被编码在信用卡上的PAN之外或者在该PAN之上还需要卡安全代码，并且借记卡交易可能除了被印刷在或者被编码在借记卡上的PAN之外还需要用户输入个人识别号(PIN)。在卡安全代码被印刷在支付装置上、被存储在支付装置中或者被支付装置(例如，芯片卡)产生的情况下，得到支付装置或者支付装置上和/或中的信息也导致获得PAN以及理应对抗欺诈的附加信息。

此外，核心账户号仍是PAN活动的关键标识符并且PAN可以在分布式在线处理系统中被各种实体发送和存储的事实，PAN可能处于被不讲道德的实体检索到的风险之中，这些不讲道德的实体可能购买、销售、利用、使用以及以其他方式危害与分布式系统相关联的支付处理系统。作为以上提及的问题和其他问题的结果，用于账户开户机构的与新卡的欺诈管理、退单和重新发放相关的成本持续增加。

因此，将期望的是提供高效地便利和处理支付卡交易的改进方法和系统，在这些改进方法和系统中，PAN的相关性在分布式支付交易处理系统中降低。

附图说明

本发明的一些实施方案的特征和优点，以及完成同样的特征和优点的方式，将会在结合附图考虑以下对本发明的详细的描述后变得更加容易明白，在附图中：

图1是图示根据本文中的一些实施方案的本公开的各个方面的示意图；

图2是根据本文中的一些实施方案的处理的流程图；

图3是根据本文中的一些实施方案的用于处理支付交易的分布式系统的框图；

图4是根据本文中的一些实施方案的图示与本文中的操作相关联的实体的处理的流程图；以及

图5是根据本文中的一些实施方案的设备的示意性框图。

具体实施方式

一般而言，并且为了引入本公开实施方案的概念的目的，支付资产一般而言是指可以包括被印刷在信用卡、借记卡、储值卡、礼品卡以及其他支付卡上、被存储在这些卡中或者被编码在这些卡中的支付卡号的表示的任何实施方案的支付装置(例如，卡、移动电话、钥匙链等)。如本文中所使用的，支付卡号被称为主账户号(PAN)。尽管传统的支付装置可以包括被压印、被印刷或者被存储在其上的PAN，本公开的各种实施方案不使PAN被印刷、被压印在可以被发放给持卡者用户的支付资产(一个或多个)上或者被存储在这些支付资产(paymentasset)中。

如本文中所使用的，即使主题的支付装置可以体现为除了卡之外的构造，该支付装置被发放给的用户或顾客在本文中也被称为“持卡者”。

根据本文中的一些实施方案，对于由例如金融机构发放的并且与由该开户机构(issuer)管理的支付账户相关的支付装置提供2因素认证处理。在一些方面，本文中的方法和系统的实施方案可以包括发放具有印刷或存储在其上的支付账户代码(PAC)的第一部分的支付卡资产或装置。如果支付装置具有将PAC以编码格式存储在例如存储芯片、磁条等中的能力，则PAC的第一部分可以被存储在支付装置上或之中。PAC可以与识别某一支付账户相关联的PAN相关联。虽然PAC可以与PAN相关联，但是对于资金支付账户的特定来源来说，PAC与PAN是不同的，或者是PAN的截断版本或改动版本。PAN、PAN的截断版本或改动版本均不被包括在本文中的各种实施方案的发放的支付装置上或之中。如本文中所使用的，PAC的第一部分被称为账户代码(AcctCode)。

AcctCode可以由开户机构针对用户持卡者创建。AcctCode可以基于在一些实施方案中与银行识别号(BIN)和/或PAN的其他参数和字段相关的算法来产生。

PAC的第二部分可以被产生并且被分配给用户持卡者。PAC的这个第二部分不被包括在支付装置上或之中，并且通常不随着支付装置的交付分发给用户。如本文中所使用的，PAC的这个第二部分被称为用户代码(UserCode)。UserCode可以由支付网络运营商分配给用户以用于与由开户机构针对特定支付账户发放的AcctCode相关联。UserCode可以从支付网络运营商仅被传送给用户持卡者。以这种方式，UserCode可以仅被支付网络运营商和用户持卡者知道。UserCode通常可以被用户知道(即，记住)。

AcctCode和UserCode共同构成PAC。PAC可以通过将AcctCode和UserCode彼此关联而形成。在一些实施方案中，AcctCode可以包括12个数字，UserCode可以包括4个数字，并且AcctCode和UserCode可以被连结来形成16位数字串PAC。类似于若干个现有的PAN编号方案，PAC的长度可以为16个数字。然而，与特定支付账户相关联的PAC和PAN彼此完全不同，并且PAC的值不同于PAN的值。

在一些方面，类似于一些PAN，PAC的长度可以为16个数字。就这一点而言，本公开的一些方面可以被涉及支付交易处理的至少一些现存的旧有系统和装置更容易地、更高效地适应，所述现有的旧有系统和装置包括但不限于商家POS(销售点)系统、收单机构系统以及支付网络系统。反映PAC的总长，在一些实施方案中，AcctCode可以为10个数字长，UserCode可以为6个数字长，使得PAC(例如，AcctCode+UserCode)为16个数字长。在一些方面，PAC可以包括16位(或其他长度的)数字，这些数字由具有第一组数字的AcctCode和包括第二组数字的UserCode形成。在一个实施方案中，AcctCode可以长于UserCode，因为用户可以负责知道(即，记住)UserCode。但是，在另一个实施方案中，UserCode可以长于AcctCode。

参照在本文中上面介绍的支付装置的2因素认证方面，被印刷、被存储在支付装置上的或者由支付装置产生的AcctCode可以构成“拥有”因素，因为它通常将由用户持卡者携带，UserCode可以构成“知悉”因素，因为它通常将被用户所知道。

图1是图示根据本文中的一些实施方案的可以支持并且便利本公开的若干个方面的系统100的各个方面的示意图。系统100包括开户机构105、支付网络运营商110以及用户持卡者115。

开户机构105可以为由开户机构管理和维护的支付账户产生PAN。开户机构105可以进一步为该支付账户产生AcctCode120，并且如经由线135所示的，将支付装置发放给用户持卡者115。在一些实施方案中，AcctCode120可以包括12个数字。发放给用户持卡者115的支付装置可以使AcctCode120被印刷和/或被存储在其上，PAN除外。与AcctCode120相关联的PAN的记录可以在PAN储存库130中被维护，PAN储存库130可以由开户机构105管理。开户机构105可以将在发放的支付装置上使用的AcctCode120的记录、消息或其他指示转发给支付网络提供商110。基于在发放的支付装置上使用的AcctCode120，支付网络提供商110可以产生并且分配账户标识符(AcctID)117以与AcctCode120相关联。在一些方面，支付网络提供商110可以存储与AcctCode120和对应的AcctID117相关的关联的记录或指示。在一些方面，该记录可以包括维护AcctCode及其对应的AcctID之间的关联的记录的查找表、映射、数据库条目以及其他数据结构。

支付网络运营商110可以为将被用于构成PAC的支付账户产生UserCode125，并且将该UserCode分配给持卡者115。在一些实施方案中，UserCode125可以包括4个数字。在一些实施方案中，支付网络运营商110可以将UserCode124传送给持卡者115。在一些方面，UserCode125不是同时地、以与用于将AcctCode120递送给持卡者的方式相同的方式传送给持卡者115的。用于将AcctCode120和UserCode125递送给用户持卡者115的时间和通信渠道中的至少一个可以有隔开。

作为说明性的用户情况的实施例，用户可以在商家的POS终端处刷他们拥有的接触式支付装置或者“轻叩”非接触支付装置以便与支付交易结合使用支付装置。因为本公开的支付装置包括AcctCode120(不是PAN)，所以AcctCode120可以在诸如用于目前的支付交易的授权请求消息的消息中被转发给支付网络运营商110。与支付交易进一步结合地，持卡者115可以将他们知道的UserCode125提供给支付网络运营商110。在一些方面，UserCode125可以经由手动按键、触摸屏、语音识别系统的输入以及其他用户界面输入机构而被提交给商家的POS终端以用于转发给支付网络运营商110。

在一些实施方案中，AcctCode120和UserCode125可以在共同的或相同的消息中被转发给支付网络运营商110，所述共同的或相同的消息诸如举例来说可以包括与支付交易相关的附加细节的授权请求消息。在一个实施方案中，AcctCode120和UserCode125可以在分开的消息中被转发给支付网络运营商110。

支付网络运营商115接收、获得或确定包括AcctCode120和UserCode125的PAC。在一些实施方案中，诸如收单机构或收单机构服务者(图1中未示出)的实体可以操作来便利至少将AcctCode120和UserCode125关联以形成PAC。在一些方面，UserCode(例如，4个数字)被连结到包括AcctCode(例如，12个数字)的数字串的末尾以形成PAC(例如，16个数字)。

在一些实施方案中，支付网络运营商110可以确定与接收的PAC相关联的特定AcctID117。在一些方面，与接收的PAC相关联的特定AcctID117可以至少部分基于AcctID117与构成接收的PAC的AcctCode120的关联的记录或映射而被确定。

在一些实施方案中，由开户机构120产生并且发放的实际的PAN在PAN储存库130中被管理和维护。PAN储存库130可以包括一个或多个数据存储设施，包括例如数据库管理系统和一个或多个存储器系统。在一些方面，PAN不被除了开户机构105之外的实体(诸如商家、收单机构或支付网络运营商115)分发或存储，因为在授权请求消息被发送给开户机构105之前，PAN本身未被部署给支付装置或者未被用在支付交易处理中。

在一些实施方案中，由开户机构120产生并且发放的实际的PAN由开户机构120管理，并且在PAN储存库130中被维护，其中开户机构可以管理PAN到支付网络运营商的分发。开户机构105可以将PAN分发给支付网络运营商110，使得支付网络运营商110可以将接收的PAC映射到PAN。在一些方面，支付网络运营商110可以至少部分基于AcctID117与包括接收的PAC的AcctCode120的关联的记录或映射来确定PAC和PAN之间的映射或关联。支付网络运营商110确定的PAN可以在授权请求消息中被传递或发送给开户机构105以用于授权。

在一些方面，一旦PAN被发送或者被开户机构105确定，授权请求消息的全部处理以及清算、结算(例如，退单等)、卡管理和许可可以通过实际的PAN执行。

图2是根据本文中的一些实施方案的处理200的流程图。具体地说，处理200可以反映根据本文中的一些方面的处理支付网络运营商、服务、服务器或服务者的支付交易或购买交易(即，交易)的方法。在操作205，接收与交易相关联的授权请求。授权可以从与参与交易的商家相关的收单机构或收单机构代理接收。与常规交易不同地，授权请求可以不包括开户机构发放的与支付账户对应的PAN。相反，操作205的授权请求可以包括开户机构发放的账户代码AcctCode，其中AcctCode与PAN是分开的且不同的，并且具有与PAN的值不同的值。开户机构可以发放PAN，可是，根据本文中的一些方面，PAN不被分发在支付装置上或者不被其他实体存储。

在操作210，从用户接收用户代码UserCode。UserCode将被与AcctCode关联，其中AcctCode和UserCode共同形成支付账户代码PAC，该PAC将被用在交易的处理中，并且充当开户机构所维护的支付账户的代表性标识符。在一些方面，UserCode可以由参与交易的用户持卡者供给。注意，与作为除了PAC之外还供给的值完全不同，UserCode可能需要形成PAC。在一些情况下，UserCode和AcctCode都可以在授权请求或一些其他的同一个消息中被接收。在某些方面来说，UserCode可以在与AcctCode分开的消息中被接收。

在操作215，将AcctCode和UserCode关联在一起以形成PAC。操作215的关联可以包括将UserCode连结到AcctCode的后(或前)缘。操作215的其他实施方案可以涉及基于AcctCode和UserCode来获得或确定PAC的其他方法，包括例如用UserCode的至少一部分替代至少接收的AcctCode、基于预定义关系或算法变换AcctCode和UserCode、以及其他技术。

在操作220，确定与PAC对应的账户标识符AcctID。AcctID可以是由支付网络运营商产生的与发放的包括AcctCode的支付装置相关联的特定的非PAN标识符。在一些实施方案中，AcctCode和映射到其的对应的AcctID的记录或其他指示可以由支付网络运营商维护。

继续处理200的操作225，可以进行确定来确定支付网络运营商是否将PAC映射到PAN。操作225的确定可以至少部分基于支付网络运营商是否为PAN的开户机构管理PAN或者开户机构(或者其代理)是否管理PAN。

在操作225确定支付网络运营商为PAN的开户机构管理PAN、结果支付网络运营商将要将PAC映射到PAN的情况下，PAC在操作230被映射到PAN。与PAC对应的PAN从而被获得。如操作235处所指示的，PAN然后可以被发送以在授权请求中被授权。PAN可以用在交易的进一步的处理中，包括例如清算、结算以及其他支付装置(例如，卡)管理功能。

在一些情况下，在操作225可以确定支付网络运营商不管理PAN或者不可以访问PAN。因此，支付网络运营商可以将PAC映射到AcctID，随后将与PAC对应的AcctID(因此，在目前的交易中使用的AcctCode)发送给开户机构，开户机构然后可以将AcctID映射到PAC。当支付网络运营商产生AcctID并且将它分配给AcctCode时，开户机构可以被支付网络运营商通知与AcctCode对应的AcctID。开户机构可以在交易的进一步处理中使用PAN，包括例如结算、结算以及其他支付装置(例如，卡)管理功能。

图3是可以支持并且便利本文中公开的处理的方面的系统300的说明性框图。在一些方面，系统300公开了可以涉及处理交易的若干个实体，所述交易依赖于在其上和/或其中具有账户代码(而不是PAN)的支付装置以及知悉用户代码的用户持卡者。在一些方面，系统300可以支持在线、电子商务或无卡(CNP)交易，在这些交易中，支付装置(例如，卡)在交易开始时在商家处不随用户持卡者物理地存在。

参照图3，用户持卡者305可以被发放具有被印刷在其上或者被编码在其中或其上的账户代码AcctCode的支付装置(例如，信用卡、供移动计算装置执行的个性化电子钱包应用等)。在开户机构发送具有对应的PAN的支付装置时，PAN不被分发给或者被部署给提供给用户持卡者305的支付装置。在一些方面，用户持卡者305可以选择性地且可选地向支付网络370注册以便参与本文中所公开的包括发放的具有AcctCode(而不是PAN)的支付装置的方法。

此外，用户持卡者305可以从支付网络370的运营商获得用户代码UserCode，其中支付网络运营商产生UserCode并且将该UserCode分配给用户持卡者305。支付网络370可以经由账户散列(hash)管理接口335接收对UserCode的请求，账户散列管理接口335提供对支付网络的访问。账户散列管理器340可以确定UserCode并且将UserCode映射到其相关联的AcctCode。

账户散列管理器340也可以产生AcctID并且将AcctID分配给AcctCode，并且在本文中的一些方面，提供其他散列化或映射功能。例如，账户散列管理器340可以操作来提供PAC(例如，AcctCode+UserCode)到AcctID的映射，并且在支付网络370将为开户机构管理PAN的情况下，提供PAC(例如，AcctCode+UserCode)到适当的对应的PAN的映射。

关于例如CNP交易，用户持卡者305可以选择性地且可选地向支付网络370预先授权一个或多个电子商务商家。该预授权处理可以包括用户持卡者305授权支付网络运营商未来当支付网络370接收到处理涉及特定的指定商家的CNP交易的请求时对来自这些指定商家的CNP交易进行处理。在一些方面，如果支付网络370接收到处理涉及指定的预授权的商家(一个或多个)的CNP交易的请求以及用户持卡者的AcctCode，则用户持卡者305可以预先授权支付网络370提供与持卡者的AcctCode相关联的UserCode。

为了开始CPN交易，用户持卡者305可以将被印刷在他们的信用卡上(或者被显示在芯片卡的显示器中、被呈现在电子钱包应用的用户界面屏幕中、等等)的由账户开户机构360发放的AcctCode(例如，12个数字)提交给商家的在线支付终端315。在这个实施例中，商家是对用户持卡者指定的预授权商家之一。在一些实施方案中，AcctCode可以经由在属于用户持卡者并且被用户持卡者所拥有的电子装置上执行的电子钱包应用而被部署。支付终端315可以产生授权请求，并且将该授权请求转发给支付收单机构320，支付收单机构320代表涉及交易的商家处理交易。支付收单机构320可以经由收单机构通信处理器325将包括至少商家的标识符和AcctCode的授权请求转发给支付网络370，收单机构通信处理器325与支付网络370建立接口连接，并且提供对支付网络370的访问。

当接收到授权请求时，支付网络370可以确定授权请求是否包含AcctCode(而不是PAN)。该确定可以至少部分基于在授权请求中接收的AcctCode的值。支付网络370还可以确定授权请求是否包含关于持卡者305的预授权商家，其中该确定可以至少部分基于在授权请求中接收的商家标识符的值。在确定当前交易确实包含AcctCode和关于持卡者305的预授权商家的情况下，支付网络370可以操作来将用户持卡者的UserCode与AcctCode关联以实现PAC(例如，AcctCode+UserCode)的形成。如以上所注意的，支付网络运营商可以将PAC映射到对应的AcctCode，并且在支付网络370将为开户机构管理PAN的情况下，支付网络运营商可以提供PAC到适当的对应PAN的映射。

支付网络370可以经由全局(global)授权处理模块345将授权消息提供给开户机构360，所述授权消息包括确定的AcctID(在开户机构360管理PAN的情况下)或者确定的PAN(在支付网络370为开户机构管理PAN的情况下)。包括AcctID或PAN的授权请求可以在开户机构通信处理器350和支付处理器355的帮助下被传送给开户机构，开户机构通信处理器350与支付网络370建立接口连接，支付处理器355可以被用来处理对于账户开户机构360的交易。当接收到包括AcctID的授权请求时，开户机构360可以通过参考其PAN储存库来确定与其相关联的PAN。在确定了PAN或者在授权请求中接收到PAN之后，开户机构360可以继续确定回复授权请求的授权响应。全局清算处理模块345可以被用在支付网络370执行的清算功能中。

图4是根据本文中的一些实施方案的图示与本文中的一些操作相关联的实体的处理400的流程图。图4示出了与账户持有者405(即，用户持卡者)、收单机构410、支付网络415以及开户机构420相关联的若干个操作。现在将在如本文中详细地公开的涉及被发放AcctCode(而不是PAN)的支付装置的交易的上下文下讨论由这些实体中的每个执行的操作。在操作425，账户持有者405在商家的地点(诸如POS终端)处向商家呈现包括AcctCode的支付装置。在操作430，账户持有者在商家地点处输入他们的与AcctCode相关联的UserCode。

收单机构410在操作435将AcctCode与UserCode关联以形成或者以其他方式确定PAC。操作435处的AcctCode与UserCode的关联可以包括但不限于收单机构将UserCode连结到AcctCode。

在操作440，支付网络415接收图4的实施例中的PAC以供用于使用确定的PAC来授权当前交易。基于PAC，支付网络可以在操作445检索或者以其他方式确定对应的AcctID。此外，支付网络415可以在操作450确定开户机构是否管理PAN。如果开户机构管理PAN，也就是说，如果开户机构单独存储并且知道PAN，则AcctID被发送给开户机构420，其中开户机构在操作460将PAN映射到AcctID。如果开户机构不管理PAN，而是支付网络管理PAN(即，开户机构将PAN分发给支付网络)，则支付网络在操作455将AcctID映射到PAN。在操作465，PAN被传递以供用于授权和结算。

授权响应在操作470被收单机构接收以完成交易的授权。当交易的结算结束时，交易在操作475被完成。

图5是根据一些实施方案的系统或设备500的框图概览。系统500可以例如与本文中所描述的装置中的任何一个相关联，包括例如商家系统装置；收单机构装置或服务器；支持或提供至少部分UserCode分配、PAC-AcctID映射和/或AcctID-PAN映射的支付网络运营商的应用或服务服务器；以及账户开户机构装置或系统。系统500包括处理器505，诸如一个或多个市售的单芯片微处理器或多芯处理器的形式的中央处理单元(CPU)，处理器505耦合到被配置为经由通信网络(图5中未示出)与另一个装置或系统进行通信的通信装置515。在系统500包括服务器(例如，支持支付网络运营商所提供的功能和服务)的情况下，通信装置515可以为系统500提供与客户端装置(例如，收单机构系统或装置)建立接口连接的手段。系统500还可以包括本地存储器510，诸如RAM存储器模块。该系统还包括输入装置520(例如，输入内容的触摸屏、鼠标和/或键盘)以及输出装置525(例如，触摸屏、显示的计算机监视器、LCD显示器)。

处理器505与存储装置530进行通信。存储装置530可以包括任何适当的信息存储装置，包括磁性存储装置(例如，硬盘驱动器)、光学存储装置和/或半导体存储器装置的组合。在一些实施方案中，存储装置可以包括数据库系统，诸如关系数据库管理系统和存储器内数据库。

存储装置530存储可以为映射引擎525提供计算机可执行指令的程序代码535，所述计算机可执行指令用于处理支付交易，根据本文中的一些处理，在一些方面，包括与在对特定交易的授权请求中接收到PAC相关联的PAC-AcctID映射和/或计算机可执行指令-PAN映射方面。处理器505可以执行程序代码535的指令，由此根据本文中所描述的实施方案中的任何一个进行操作。程序代码535可以被以压缩的、未被编译的和/或加密的格式存储。程序代码535还可以包括其他程序元件，诸如操作系统、数据库管理系统和/或被处理器505用于与例如外围装置建立接口连接的装置驱动器。存储装置530还可以包括数据540，诸如数据库记录或查找表。在一些方面，数据540可以被系统500用在执行本文中的处理中，包括PAC-AcctID映射和/或AcctID-PAN映射。

本文中所讨论的所有系统和处理都可以用存储在一个或多个非暂时性计算机可读介质上的程序代码来实施。这样的介质可以包括例如软盘、CD-ROM、DVD-ROM、磁带、固态随机存取存储器(RAM)或只读存储器(ROM)存储单元以及其他非暂时性介质，其中有形非暂时性介质可以支持“云”存储设施。而且，存储器内技术可以被使用，使得数据库等可以在处理器处在RAM存储器中被完全操作。实施方案因此不限于硬件和软件的任何特定组合。

在一些实施方案中，本文中的持卡者可以仅提交AcctCode(例如，12个数字)进行在线交易。在一些情况下，商家的电子商务系统可选地可以存储用户持卡者的AcctCode以用于未来的交易。商家的电子商务系统可以在交易时向持卡者提示他们的UserCode。以这种方式，AcctCode和UserCode的完整会计信息不被存储在商家(或商家收单机构)的储存库中。

在一些实施方案中，在持卡者的包括AcctCode的支付装置或资产(例如，信用卡、钥匙链迷你卡等)被盗或丢失的情况下，持卡者可以请求更换支付装置，与需要发放新的支付装置完全不同。在此，持卡者仅需要改变他们的用户代码(UserCode)，而不是依赖于具有新的PAN和到期日期的新卡被发放。在例如卡可以被每月预先注册或者按年支付的情况下，本文中的一些实施方案的这个方面可能是有益的。还注意到，在持卡者知道或怀疑他们的UserCode已经受损害(如被浏览了等等)的情况下，UserCode可以在任何时间实时地被持卡者选择性地改变。

在本文中的一些方面，支付装置的实施方案可以在应用、“app”、程序、浏览器(或启用浏览器的应用、扩展、附件)、在移动装置上执行的计算机可读指令等以及具有执行应用或程序指令的处理器的装置中被实施。在一些方面，即使在这样的电子装置可能不一定容易运送(例如，台式PC)的情况下，这样的装置也可以被说成是被本文中的提到电子装置或“移动装置”的公开内容所包含。在一些方面，移动装置可以是包括电话功能并且被实现为任何数量的不同的硬件、软件以及它们的组合配置的装置。

实施方案已经在本文中仅仅出于例示说明的目的而被描述。本领域技术人员从本描述将认识到，实施方案不限于所描述的那些，而是可以在仅由所附权利要求书的精神和范围限制的修改和更改的情况下被实施。

Claims (19)

1.一种计算机实现方法，所述方法包括：

接收与交易相关联的授权请求，所述授权请求包括账户代码；

接收与所述账户代码相关联的用户代码；

将所述账户代码和所述用户代码关联在一起以形成支付账户代码；

确定与所述支付账户代码对应的账户标识符；

确定是否将所述支付账户代码映射到主账户号(PAN)；

响应于确定所述支付账户代码将被映射到所述PAN，将所述支付账户代码映射到所述PAN以查明与所述支付账户代码对应的PAN；以及

发送所述授权请求以被授权，所述授权请求包括所述PAN。

2.根据权利要求1所述的方法，其中将所述账户代码和所述用户代码关联在一起以形成所述支付账户代码的步骤包括将所述账户代码和所述用户代码彼此连结。

3.根据权利要求1所述的方法，其中将所述账户代码和所述用户代码关联在一起以形成所述支付账户代码的步骤包括用所述用户代码取代所述接收的账户代码的至少一部分。

4.根据权利要求1所述的方法，其中所述支付账户代码包括16位数字串。

5.根据权利要求1所述的方法，其中所述用户代码被作为所述授权请求的一部分接收，并且不同于所述账户代码。

6.根据权利要求1所述的方法，其中所述用户代码是从用户接收的。

7.根据权利要求1所述的方法，其中确定是否将所述支付账户代码映射到所述PAN的步骤至少部分基于所述PAN的记录是否由第三方维护。

8.根据权利要求7所述的方法，在所述PAN由第三方维护的情况下，还包括：

确定不将所述支付账户代码映射到所述PAN；以及

发送包括所述账户标识符的授权请求以被授权，所述PAN将由所述第三方确定。

9.根据权利要求1所述的方法，还包括维护所述账户标识符和所述支付账户代码之间的映射的记录。

10.一种设备，所述设备包括：

处理器；以及

存储器装置，所述存储器装置与所述处理器进行通信，并且在其上存储程序指令，所述处理器与所述程序指令一起操作以执行以下步骤：

接收与交易相关联的授权请求，所述授权请求包括账户代码；

接收与所述账户代码相关联的用户代码；

将所述账户代码和所述用户代码关联在一起以形成支付账户代码；

确定与所述支付账户代码对应的账户标识符；

确定是否将所述支付账户代码映射到主账户号(PAN)；

响应于确定所述支付账户代码将被映射到所述PAN，将所述支付账户代码映射到所述PAN以查明与所述支付账户代码对应的PAN；以及

发送包括所述PAN的所述授权请求以被授权。

11.根据权利要求10所述的系统，其中将所述账户代码和所述用户代码关联在一起以形成所述支付账户代码的步骤包括将所述账户代码和所述用户代码彼此连结。

12.根据权利要求10所述的系统，其中将所述账户代码和所述用户代码关联在一起以形成所述支付账户代码的步骤包括用所述用户代码取代所述接收的账户代码的至少一部分。

13.根据权利要求10所述的系统，其中所述支付账户代码包括16位数字串。

14.根据权利要求10所述的系统，其中所述用户代码被作为所述授权请求的一部分接收，并且不同于所述账户代码。

15.根据权利要求10所述的系统，其中所述PAN的记录不被所述系统存储。

16.根据权利要求10所述的系统，其中确定是否将所述支付账户代码映射到所述PAN的步骤至少部分基于所述PAN的记录是否由第三方维护。

17.根据权利要求16所述的系统，其中在所述PAN由第三方维护的情况下，还包括：

确定不将所述支付账户代码映射到所述PAN；以及

发送包括所述账户标识符的授权请求以被授权，所述PAN将由所述第三方确定。

18.根据权利要求10所述的系统，还包括维护所述账户标识符和所述支付账户代码之间的映射的记录。

19.根据权利要求10所述的系统，其中所述用户代码是从用户接收的。