CN110462661A - 用于x-支付数字钱包的拉取和推送系统 - Google Patents

用于x-支付数字钱包的拉取和推送系统 Download PDF

Info

Publication number
CN110462661A
CN110462661A CN201880021793.1A CN201880021793A CN110462661A CN 110462661 A CN110462661 A CN 110462661A CN 201880021793 A CN201880021793 A CN 201880021793A CN 110462661 A CN110462661 A CN 110462661A
Authority
CN
China
Prior art keywords
account
payment
publisher
sponsor
transmission
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.)
Granted
Application number
CN201880021793.1A
Other languages
English (en)
Other versions
CN110462661B (zh
Inventor
M·D·里斯西亚
S·E·哈梅尔
S·R·拉卡
P·福雷
G·卡多尼
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mastercard International Inc
Original Assignee
Mastercard International Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Mastercard International Inc filed Critical Mastercard International Inc
Publication of CN110462661A publication Critical patent/CN110462661A/zh
Application granted granted Critical
Publication of CN110462661B publication Critical patent/CN110462661B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • 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/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • 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

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Pharmaceuticals Containing Other Organic And Inorganic Compounds (AREA)

Abstract

本公开提供了用于将基于QR和人到人的数字钱包支付扩展到非发行方数字钱包的系统和方法。在一个示例中，该方法可以包括接收从数字钱包的发送账户向接收账户发送支付的发送请求，在移动设备和发送账户的发行方之间执行认证协议，从发送账户的发行方到保荐人系统拉取所请求的支付，其中拉取将退款的责任移交到发送账户的发行方，并将所请求的支付从保荐人系统推送到接收账户的发行方。此外，如果商家是QR商家，那么方法可以包括从QR码访问PAN和商家信息，以根据非接触式轻击使用非发行方数字钱包凭证来处理拉取/推送交易。

Description

用于X-支付数字钱包的拉取和推送系统
对相关申请的交叉引用
本申请依据35 USC§119(e)要求于2017年3月27日提交的先前提交的美国临时专利申请No.62/476.971和2017年7月20日提交的美国临时专利申请No.62/534.734的权益，这两个申请都通过引用整体并入本文。
背景技术
诸如借记卡、信用卡和现金卡之类的支付账户被广泛用于在诸如商家场所之类的销售点或经由在线网站或门户结算购买交易。通常，商家在适当的位置具有销售点(POS)终端以帮助执行购买交易，包括从支付卡或启用支付的移动设备读取支付账户信息。通过读取支付账户信息并通过POS终端执行的后续活动，商家被说成“接受”所带来的支付账户系统交易。
在通过店内终端或在线门户等对支付卡/账户进行初始读取/刷卡期间，可以检查持卡人的账户以查看是否有足够的资金可用于支付交易。如果是，那么可以批准交易并允许商家授权交易。但是，不会立即执行从持卡人账户到商家账户的实际资金交换。更确切地说，在每个工作日结束时，商家将批准的授权成批发送给收单银行或支付处理器。然后，收单银行或支付处理器将成批的信息路由到信用卡支付网络以进行清算和结算。作为响应，信用卡支付网络将每个批准的交易转发给持卡人账户的适当发行银行。通常在交易的一到两个工作日内，发行银行将转移它与信用卡支付网络共享的资金，并且收单银行将针对持卡人购买而记入商家的账户。
但是，清算和结算过程通常需要一个或多个工作日才能完成。在清算和结算完全完成之前，商家无法获得资金。此外，在一些情况下，商家可能希望接受非接触式支付账户系统交易而无需在适当的位置具有非接触式支付基础设施。例如，小商家可能不希望花费在获得和安装非接触式硬件系统中涉及的成本。而且，在一些情况下，当商家拥有的POS终端已达到其使用寿命的终点时，商家可能希望通过替代渠道继续接受支付账户系统交易，而无需购买当前安装的POS终端的替代品。
附图说明
在结合附图考虑以下详细描述后，本公开的一些实施例的特征和优点以及实现它们的方式将变得更加显而易见，附图图示了优选和示例性实施例，并且没有必要按比例绘制，其中：
图1是图示根据示例实施例的用于执行拉取和推送支付过程的系统的图。
图2是图示根据另一个示例实施例的用于执行拉取和推送支付过程的系统的图。
图3是图示根据示例实施例的保荐人系统确定发行方的身份的过程的图。
图4是图示根据示例实施例的认证过程的示例的图。
图5是图示根据示例实施例的本地拉取和推送支付过程的图。
图6是图示根据示例实施例的拉取和推送支付的方法的图。
图7是图示根据示例实施例的可以使用的计算系统的图。
贯穿整个附图和详细描述，除非另有描述，否则相同的附图标记将被理解为指相同的元件、特征和结构。为了清楚、说明和/或方便，可以夸大或调整这些元件的相对尺寸和描绘。
具体实施方式
在以下描述中，阐述了具体细节以便提供对各种示例实施例的透彻理解。应当认识到的是，对于本领域技术人员来说，对实施例的各种修改是显而易见的，并且在不脱离本公开的精神和范围的情况下，本文中定义的一般原理可以应用于其它实施例和应用。而且，在以下描述中，出于解释的目的阐述了许多细节。但是，本领域普通技术人员应当理解的是，可以在不使用这些具体细节的情况下实践实施例。在其它情况下，未示出或描述众所周知的结构和过程，以免用不必要的细节模糊本描述。因此，本公开不旨在限于所示的实施例，而是符合与本文公开的原理和特征一致的最宽范围。
传统的支付处理需要隔夜清算和结算过程，这会花费至少一个工作日或更长时间。此外，当在周末或假日进行支付时，直到下一个工作日之后支付才被处理，从而导致在从持卡人(“消费者”)向商家转移资金之前的附加延迟。示例实施例通过在不到一小时(例如，10分钟、20分钟、30分钟等)内使资金在商家账户中可用而无需隔夜清算和结算来克服传统支付清算和结算过程中的这些缺陷。几乎实时的资金转移同时实现了责任转移。因而，商家账户可以在同一天(或甚至同一小时)内记入资金，以便随时获得资金。
如本文所述，诸如收单银行、发行银行、支付处理器、应用编程接口(API)等的保荐人系统可以与由持卡人操作的数字钱包通信并且可以代表持卡人动作，以通过拉取和推送过程将支付从持卡人的账户转移到商家的账户。拉取和推送是分开的单向交易，其将钱从发送账户的发行方转移到保荐人系统，然后从保荐人系统转移到商家账户的发行方。例如，持卡人可以选择数字钱包内的支付账户，并基于被执行以捕获商家快速响应(QR)码的QR码扫描向保荐人系统提交支付请求。嵌入在QR码内的可以是商家账户信息和商家信息。除了商家账户信息之外，持卡人设备还可以发送存储在数字钱包中的持卡人账户信息(加密的)。因而，保荐人系统可以接收持卡人和商家两者的发行账户信息。
在拉取过程期间，保荐人系统可以基于从数字钱包接收的持卡人PAN将持卡人请求的支付从持卡人账户的发行方拉取到保荐人系统。在推送过程期间，保荐人系统可以基于从数字钱包接收的商家PAN将拉取的资金从保荐人系统推送到商家账户的发行方。在一些情况下，可以在来自数字钱包的初始发送请求期间提供持卡人PAN和发行方PAN两者，或者可以在已经执行拉取过程之后提供者家PAN。此外，在执行拉取操作之前，持卡人账户的发行方和持卡人可以经由保荐人系统和支付网络执行认证协议，这可以将所拉取的资金的退款责任从保荐人系统转移到持卡人的发行银行，而无需隔夜结算和清算过程。以这种方式，拉取操作和推送操作中的每一个基本上都是单向交易，并且当转移支付时，责任从保荐人系统移交到发送方的发行银行。此外，资金几乎可以立即在商家账户中可用，这与传统的支付处理形成鲜明对比，在传统支付处理中，在完成清算和结算过程(通常需要一个或多个隔夜周期)之前，资金不可用。
在本文的示例中，各种设备和系统可以交互以执行这样的支付过程，包括例如具有伴随应用的移动设备(例如，非发行方数字钱包)、持卡人账户(或发送账户)发行方系统(诸如由发行包括在第三方钱包中的支付账户的金融机构控制的系统)、收单方(保荐人拉取/推送支付的金融机构)系统、支付发送API(例如，MasterCard发送API等)、商家账户发行方系统、可以包括支付网络设备的支付网络，以及其它系统(诸如支付网关、清算所、银行、支付处理器等)。
本文描述的系统和方法可以被用于使用具有数字钱包的基于QR码的支付系统来结算用于购买物品(例如，商品和服务)的交易。系统允许快速、安全、方便和成本有效的方法，并提供现金的可行替代方案，而无需销售点(POS)装备。此外，系统和方法可以解决围绕商家和收单银行的电子支付的许多痛点，并且是将电子支付服务扩展到当前被排除在他们之外的商家的可行方式。而且，本文描述的系统和方法可以实现拉取和推送支付，以促进近乎实时的资金向商家账户的移动。
QR支付调用要求商家向收单银行(即，收单方)注册，以接收QR码。通常，消费者持卡人需要向其支付卡的发行方的数字钱包注册，并将QR支付应用下载到他们的移动设备。商家可以显示QR码(例如，在收据上)，并且消费者可以使用他们的移动设备的相机扫描代码并且可选地，如果支付金额还没有包括在QR码内，那么输入支付金额。然后，消费者通过其移动设备上的基于QR的数字钱包应用来发起支付。在这种情况下，移动设备上的数字钱包由持卡人支付账户的发行方控制并拥有。因此，发行方可以直接访问持卡人的信息，诸如账户余额、认证信息、卡详细信息等。
但是，相关的基于QR码的支付仅可用于由基于发行方的金融提供者(诸如银行、信用机构和具有转账许可证的其它金融实体)支持/控制的数字钱包。特别地，即使资金实时地从持卡人的账户转移到商家的账户，发行方和收单方之间的交易也仍然必须通过支付网络(例如，在一天的结束时、在两天周期的结束时，等等)随后进行清算。因此，在发行方(持卡人的银行)和收单方(商家的银行)之间存在一定程度的信任，即，在清算时资金将可用。
为了改进相关的QR支付处理过程，示例实施例扩展了对非发行方数字钱包(也称为X-支付钱包)进行基于QR码的支付的能力，该X-支付钱包可以持有一个或多个基于发行方的支付卡和/或账户。如本文所述，非发行方数字钱包是指不由金融机构拥有和操作而是由不持有转账许可证的实体控制的数字钱包。因为每个州具有其自己的许可要求，所以各州的货币发送方要求存在差异。但是，几乎每个州都要求发送方满足被许可作为货币发送方的要求，诸如确保担保债券，以及金融犯罪执法网络(FinCEN)的联邦登记要求。此外，货币发送方必须在传输活动发生的每个州获得许可。因此，转账许可证可能消耗极多的时间和金钱。
非发行方数字钱包不需要转账许可证，因为他们不管理转账。有数十个基于非发行方数字钱包，包括基于原始装备制造商(OEM)的钱包，诸如Samsung Pay、Apple Pay、Android Pay等，以及其它非发行方的钱包，诸如MasterCard的MasterPass、GoogleWallet、Oracle Pay等。到目前为止，这些非发行方数字钱包还无法参与基于QR的拉取和推送交易。现在，示例性实施例使得这种非发行方数字钱包能够立即从持卡人向商家发送钱。
图1图示了根据示例实施例的用于执行拉取和推送支付过程的系统100。参考图1，系统100包括实现诸如非发行方数字钱包之类的数字钱包的移动设备110，但是实施例不限于非发行方数字钱包并且可以包括基于发行方的数字钱包。移动设备110可以是智能电话、平板电脑、膝上型计算机、记事本、电器、智能可穿戴设备等，其可以是执行一个或多个数字钱包的持卡人或账户持有者设备。数字钱包允许持卡人/用户通过数字化过程添加支付账户，该数字化过程可以安全地将支付账户的令牌化账户信息存储在移动设备110的安全元件上。根据各种实施例，持卡人(发送方)可以将钱发送到诸如商家账户之类的接收账户(接收方)。
系统100还包括保荐人系统120，其可以代表移动设备110的持卡人动作，以经由支付网络150执行拉取和推送支付过程，以从发送账户拉取钱并将钱推送到接收账户。保荐人系统120可以经由支付网络150与发送账户的发行银行(发送发行方130)和接收账户的发行银行(接收发行方140)通信。在一个示例中，保荐人系统120可以包括实现根据各种实施例的发送API的计算设备/服务器。发送API包括服务、库、代码等，其使得保荐人系统120能够与支付网络通信并发送拉取和推送支付消息。例如，发送API使得保荐人系统120能够基于来自移动设备110上的数字钱包的请求从发送发行方130拉取支付，并将拉取的支付从保荐人系统120推送到接收发行方140，其中接收发行方近乎实时地使得资金让接收方可用，而不需要完成隔夜结算和结算过程以发布资金。
作为另一个示例，保荐人系统120可以包括由收单银行或其它实体控制的计算设备/服务器，其被预先配置和授权进行发送支付交易而无需安装发送API。在这个示例中，保荐人系统120可以是与持卡人或交易中涉及的商家无关的实体。作为另一个示例，保荐人系统120可以是持卡人账户的发行方或商家接收账户的发行方。作为另一个示例，保荐人系统120可以是包括接收来自收单银行的请求的发送API的设备。在这个示例中，数字钱包可以连接到收单银行，并且收单银行可以连接到发送API以执行拉取/推送支付过程。
在API解决方案和收单银行解决方案中的任一个解决方案中，保荐人系统120从入口点接收消费者PAN和商家PAN，其中入口点在图1的示例中是非发行方数字钱包。例如，消费者可以使用他们的非发行方数字钱包扫描商家QR码，该非发行方数字钱包可以从QR码解析商家的账户信息，并且还存储消费者PAN的发行信息，并且将那些信息提供给保荐人系统120。这里，QR码可以由非发行方数字钱包解析，以获得商家PAN。同时，数字钱包可能已经在其中存储了消费者PAN的副本，其可以出于安全目的而被令牌化。
为了调用拉取和推送支付过程，移动设备110可以使用非发行方数字钱包扫描商家的QR码。例如，QR码可以与诸如商品、服务等物品的购买相关。QR码可以包括关于在其中编码的商家的信息，诸如商家账号(PAN)、交易金额、商家类别代码(MCC)、交易货币代码、商家国家、商家城市、商家名称、光学数据字段、CRC校验等。应当认识到的是，未具体讨论的附加信息也可以结合在QR码内。为了显示QR码，QR码可以显示在商家位置处的计算设备或其它物体(自助服务终端、电视机、POS终端等)的屏幕上。作为另一个示例，QR码可以包括在由商家打印的商品或服务的收据中，或者经由网页在线显示，使得它可以被远离商家的位置处的持卡人移动设备110扫描。
响应于扫描QR码，非发行方数字钱包可以解析QR数据以获得商家信息，诸如在QR中编码的商家PAN。此外，非发行方数字钱包向保荐人系统120发送拉取支付请求。这里，请求可以是非支付消息请求，或者它可以包括已经采用经由支付网络进行处理的格式的消息(ISO 8583)。如果不是准备好进行支付处理的格式，那么保荐人系统120可以将请求转换成为支付网络授权请求消息格式化的授权请求消息。从移动设备110上的数字钱包向保荐人系统120发送的请求可以包括交易字段内的一个或多个值，其指示该请求将作为拉取/推送支付过程被处理。
响应于接收到请求，保荐人系统120可以从作为发送账户的发行方的持卡人的发行银行(发送发行方130)确保支付资金。例如，数字钱包(或钱包提供者)可以向保荐人系统120发送QR码扫描请求，然后保荐人系统120尝试经由支付网络150从消费者的发行银行拉取钱。保荐人系统120可以通过经由支付网络150向发送发行方130发送授权请求消息(例如，ISO 8583)来执行拉取操作，并且经由支付网络150从发送发行方130接收授权响应消息。
此外，在拉取操作之前、期间和/或之后，移动设备110和发送发行方130可以经由保荐人系统120和支付网络150执行认证过程，以核实持卡人/账户是授权用户和/或卡。作为拉取转移的结果，认证过程可以将退款的责任从保荐人系统120(以及移动设备110上的X-支付钱包)移交到发送发行方130。相反，对于基于PAN的常规购买请求，在满足下一工作日清算和结算过程之前，责任不移交。
一旦从由发送发行方130发出的发送账户中拉取了支付并转移到保荐人系统120，保荐人系统120就可以经由支付网络150将拉取的支付推送到接收发行方140。接收发行方140是接收账户(诸如商家账户)的发行方。由于在拉取交易期间执行的认证过程，退款的责任从保荐人系统120移交到持卡人的发送账户130的发行方。拉取和推送过程基本上是连续的两步过程，其中每个步骤包括通常用隔夜清算过程执行的单向支付转移。但是，一旦接收发行方140批准推送授权，拉取和推送支付过程就使得资金在接收方账户中可用。换句话说，资金经由保荐人系统120在几分钟内从发送发行方130移动到接收发行方140，并且几乎实时地(例如，30分钟等)使资金在发送发行方140处让商家账户可用。
系统100使得来自第三方钱包提供者的QR支付不是金融账户的发行方并且没有转账许可证。在一个实施例中，保荐人系统120可以是代表非发行方数字钱包来处理拉取/推送交易的收单银行。作为另一个示例，保荐人系统120可以是实现发送API(例如，MasterCard发送API等)的设备，其代表非发行方数字钱包来执行拉取/推送交易过程。与传统的发送支付系统的不同之处在于，必须进行两次交易以实现拉取和推送。具有账户的消费者想要用那个账户向商家支付。资金需要退出消费者账户并推送到商家账户。当消费者使用基于发行方的数字钱包时，发行方可以直接访问持卡人账户信息。因此，发行方可以直接从账户中取钱，而无需担心处理拉取请求。但是，在非发行方数字钱包的上下文中，消费者提供PAN(其可以是令牌)，但非发行方数字钱包不具有将钱转出消费者账户的能力。由保荐人系统120代表移动设备110上的非发行方数字钱包执行的拉取和推送过程使得解决方案生效。
还应当认识到的是，示例实施例不限于由非发行方数字钱包触发的请求。作为另一个示例，不是从数字钱包接收请求，而是拉取/推送过程可以被诸如收单银行、发行银行等金融机构充分利用。因此，应当认识到的是，图1的示例不限于响应于来自非发行方数字钱包的请求而被执行。
图2图示了根据另一个示例实施例的用于执行拉取和推送支付过程的系统200的示例。在图2的示例中，拉取和推送网络与图1中的相同，但是进入点是商家的移动销售点(mPOS)终端210，其接收消费者的PAN并存储商家的发行方PAN。然后将其提供给保荐人系统120。在这个示例中，mPOS终端210可以从移动设备220上的数字钱包接收非接触式支付交易，而不需要商家安装非接触式支付装备和基础设施。例如，可以在持卡人(发送方)和商家(接收方)之间执行非接触式支付，其中支付凭证经由无线协议从移动设备220传送到商家mPOS终端210。当持卡人将移动设备220(或其它支付车辆，诸如发射卡等)带到商家mPOS终端210的附近或预定距离内时，可以从移动设备220向mPOS终端210无线地传送支付账户信息。
例如，非接触式支付系统包括信用卡和借记卡、密钥卡(key fob)、智能卡或其它设备，包括智能电话和其它移动设备，其使用射频识别(RFID)或近场通信(NFC)，诸如 等，进行安全支付。嵌入式芯片和天线使得消费者能够通过mPOS终端210处的读取器挥动或以其它方式刷卡、密钥卡或手持设备。非接触式支付是物理上接近地进行的，与使用广域蜂窝或Wi-Fi网络并且通常不涉及紧密的物理接近的移动支付不同。
通常，支持非接触式支付需要商家的收单银行的重要基础设施，以便遵守处置非接触式支付账户交易的要求。因此，收单方必须给从商家收到的支付信息添加开销，并且还对存储在其中的敏感金融账户信息采取某些预防措施，以防止敏感数据的欺诈或泄漏。但是，示例实施例通过启用无接触支付而不需要收单银行来改进这个要求。在图2的示例中，移动设备220上的非发行方数字钱包可以经由非接触式支付方法将持卡人的支付账户的非接触式交易细节传送到商家mPOS终端210，以结算持卡人和商家之间的交易。非接触式交易细节可以包括与持卡人相关联的支付账户的PAN、到期日期、CVC、姓名、地址等、商家信息、交易信息等。
保荐人系统120可以是实现发送API的支付处理器。因此，系统200可以省略收单方，而不是在商家mPOS终端210和支付网络150、发送发行方130和接收发行方140之间需要收单机构的基础设施。因此，系统200不需要支持收单方的基础设施，而且，商家mPOS终端210可以直接与可以实现发送API的支付处理器(保荐人系统120)通信。此外，该过程可以依赖于已经在支付网络内建立的设备，从而使得非接触式支付交易的支付处理明显更快。
由图1和2中的保荐人系统120实现的API可以通过支付处理器发送API(诸如MasterCard发送统一API)将交易细节(例如，非发行方数字钱包、非接触式交易细节等)打包到适当的消息(例如，授权请求/响应)中。API可以接受商家细节并处理消费者发行方130和商家发行方140之间的非发行方拉取推送交易(图1)和非接触式资金提供交易(图2)。此外，API还可以促进与消费者发行方130和商家发行方140的交易的清算和结算。
这个解决方案允许商家以多种形式处理支付。例如，在一种形式中，由于常规非接触式拉取交易充分利用其中商家接收资金作为标准清算和结算过程的一部分的系统。可替代地，如果商家也是QR商家，那么他们可以从QR访问他们的商家PAN连同其它商家信息并且提供消费者支付数据以便用API处理拉取和推送交易，这将允许商家近乎实时地接收资金而无需标准的清算和结算过程。
移除收单方的一些好处包括允许商家访问QR支付。此外，商家可以充分利用相同的现有核心数据系统并且处于执行非接触式交易而无需收单方的情况下。商家为了处理支付而需要的所有实体都需要满足针对非接触式支付的一系列要求。收单方基础设施不再需要这些要求，因为商家后台直接集成到支付处理器API中。另一个扩展的好处是，关于图5描述的本地拉取和推送过程几乎立即而不是在仅在一个工作日(24小时)或更长时间清算的传统结算过程之后使资金在商家账户中可用。
图3图示了根据示例实施例的保荐人系统120确定发行方的身份的过程300。参考图3，发送请求310从在移动设备110上执行的数字钱包发送到保荐人系统120。发送请求可以是包括移动设备110期望发起拉取/推送交易以及安全发送账户和接收账户信息的标识符或指示符的消息请求。发送请求310还可以包括持卡人主账号(PAN)的令牌化数据，其可以与发行方的表320进行比较，以确定哪个发行方是令牌的所有者。这里，在表320中为每个发行方指派一定范围的令牌值。
在一些实施例中，发送请求310可以不是能够进行支付网络传输的授权消息。在这个示例中，当发送请求不是支付网络格式时，保荐人系统120可以将支付信息转换成授权消息(ISO 8583)并将值插入授权消息的一个或多个字段中以指示该消息是拉取或推送请求，这取决于保荐人系统120正在执行哪种操作。作为非限制性示例，指示符可以包括文本值、位值、数值、符号等，其包括在构成发送请求的支付授权请求的交易字段内。
例如，处理代码值“00”以及具体商家类别代码(MCC)值可以确定该交易是拉取交易。例如，对于拉取交易，来自消息的DE3值可以是“00”，对于人到人，DE18值可以是6538，或者对于人到商家支付是实际商家MCC，并且对于人到人，DE48SE77值可以是“C07”并且对于人到商家是“C67”。类似地，对于推送交易，DE3和DE48SE77值可能与拉取交易相同，而DE18值可以对于国内的是6536、对于跨边界的是6537，并且对于人到商家支付是实际商家MCC。授权消息可以取决于是正在执行拉取还是推送而被发送到发送账户的发行方或接收账户的发行方。
图4图示了根据示例实施例的认证过程400的示例。参考图4，在移动设备110上执行的数字钱包和包括在数字钱包中的支付账户的发行方130之间执行认证过程400。这里，经由保荐人系统120和支付网络150执行认证过程400。认证处理器400可以是数字安全远程支付(DSRP)认证过程，其经由EMV协议认证存储在移动设备110上的EMV信息。可以在拉取/推送付款请求之前、在拉取/推送付款请求期间等执行认证过程400。
DSRP认证为在线购物实现令牌化和动态密码，以便实现与通过店内非接触式交易保持的相同级别的交易安全性。认证过程400可以利用移动设备110的能力，并且可以包括诸如认证、令牌检索和密码生成之类的功能。促进这一点需要移动设备110上的钱包应用与发行方130进行通信，并且双方可以实现相关的API和SDK来执行DSRP。
除了需要将其移动PIN用于支付认证(例如，经由移动设备110的用户接口)的消费者之外，所有DSRP交易还都通过移动设备110以便检索令牌。成功的认证导致令牌和生成的密码从设备到在线商家的发送，在线商家将处理这些密码作为卡片管理档案(card-on-file)数据的替代。认证过程400将所拉取的支付的退款责任从保荐人系统120移交到包括在移动钱包110中的支付账户的发送发行方130。例如，在拉取交易期间，可以通过利用基于设备的DSRP来获得责任移交。支付网络设备、发行方系统、在用户设备上执行的数字钱包等中的至少一个可以通过在ISO 8583授权/清算消息中插入安全级别指示符(例如，242、247等)来指示已经执行了认证并且已经通过DSRP移交了责任。在一些示例中，发行方系统、支付处理系统等可以在令牌化时通过ID和核实(ID&V)过程将持卡人的认证委托给设备钱包。
还应当认识到的是，认证过程400不限于DSRP，而是可以包括用于核实PAN的安全代码等。例如，在拉取交易期间，可以通过利用三维(3D)安全代码来获得责任移交，该安全代码是用于保护持卡人不存在交易的技术标准。支付网络设备、发行方系统、在用户设备上执行的数字钱包等中的至少一个可以通过在ISO 8583授权/清算消息中插入安全级别指示符(例如，212等)来指示已经执行了认证并且已经通过3D安全移交了责任。在一些示例中，发行方系统可以通过升级(step up)或通过充分利用认证请求中提供的数据(基于风险的认证)来认证持卡人。例如，3D安全可以使发行方访问控制服务器(或ACS)能够接收数据并在必要时发起持卡人升级。
图5图示了根据示例实施例的由保荐人节点520执行的本地拉取和推送支付过程500。在这个示例中，保荐人节点520也是由在移动设备510上执行的非发行方数字钱包使用的发送账户的发行方。这里，保荐人节点520执行自收单本地拉取操作，而不必经由支付网络向分开的发行系统发送和接收针对发送账户的授权。在这个示例中，保荐人节点520在拉取过程中执行收单方和发行方两者的角色。
图6图示了根据示例实施例的拉取和推送支付的方法600。例如，方法600可以由保荐人系统执行，诸如金融机构(收单银行)的计算系统、执行发送API的支付处理设备等。参考图6，在610中，该方法包括接收对于将钱从发送账户转移到接收账户的发送请求。在一个示例中，可以基于经由移动设备执行的QR码扫描操作，从在移动设备上执行的数字钱包(例如，非发行方数字钱包)接收发送请求。作为另一个示例，可以从mPOS终端接收发送请求，该mPOS终端从发送账户的移动设备接收非接触式触摸。在任一种情况下，发送请求都可以包括发送账户的PAN和接收账户的PAN。
此外，可以将发送请求转换成授权消息，该授权消息包括在请求的字段内的指示发送请求是拉取/推送支付请求的指示符(例如，授权请求)。作为非限制性示例，指示符可以包括文本值、位值、数值、符号等，其包括在构成发送请求的支付授权请求的交易字段内。例如，处理代码值“00”以及具体商家类别代码(MCC)值可以确定交易是拉取交易。例如，对于拉取交易，来自消息的DE3值可以是“00”，对于人到人，DE18值可以是6538，或者对于人到商家支付是实际商家MCC，并且对于人到人，DE48SE77值可以是“C07”并且对于人到商家是“C67”。类似地，对于推送交易，DE3和DE48SE77值可能与拉取交易相同，而DE18值可以对于国内的是6536、对于跨边界的是6537，并且对于人到商家支付是实际商家MCC。
在620中，该方法可以包括经由保荐人系统在移动设备和发送账户的发行方之间执行认证协议。例如，当从非发行方数字钱包接收到发送请求时，可以在移动设备上的数字钱包与发送账户的发行方之间执行认证，以核实持卡人身份中的至少一个(例如，经由PIN或用于PAN的安全代码)，或核实支付账户(例如，数字安全远程支付等)。例如，可以从不具有对访问由发送账户的发行方存储的发送账户的账户信息的授权的非发行方数字钱包(例如，OEM钱包等)接收发送请求。通过验证卡和用户中的一个，即使数字钱包不是由金融机构控制并且不直接与发行银行或支付网络通信，也可以验证账户和/或持卡人。
在630中，该方法包括基于发送请求中包括的发送账户的发行方信息经由支付网络将所请求的支付从发送账户的发行方拉取到保荐人系统，并且在640中，基于请求中包括的接收账户的发行方信息经由支付网络从保荐人系统向接收账户的发行方推送所请求的支付。拉取和推送中的每一个可以包括授权请求/响应的交换，其可以由保荐人系统基于从移动设备/持卡人接收的数据生成。作为示例，拉取可以包括将对于支付的授权请求从保荐人系统发送到发送账户发行方系统，以及接收包括支付授权的授权响应。作为另一个示例，推送可以包括将对于推送支付的授权请求发送到接收账户的发行方，以及来自接收账户的发行方的指示推送被授权的授权响应。
在一些实施例中，保荐人系统可以基于令牌范围来确定发送账户的发行方，该令牌范围包括与相应发行方ID配对的多个令牌范围当中的从持卡人数字钱包接收的令牌ID。这里，令牌ID可以表示令牌化的持卡人支付信息(例如，PAN、到期日期、CVC等)。此外，由于在620中执行的认证，经由支付网络拉取支付响应于正在执行成功的认证协议而将拉取的支付的退款的责任从保荐人系统移交到发送账户的发行方。
在一些实施例中，通过在保荐人系统上执行的应用编程接口(API)来执行所请求的支付的拉取和所请求的支付的推送。API可以实现服务和接口，其使得保荐人系统能够代表发送账户的持卡人或账户持有者经由支付网络与发送账户的发行方和商家账户的发行方进行通信。在一些实施例中，拉取所请求的支付和推送所请求的支付是由保荐人系统执行的，而无需隔夜结算过程来结算从发送账户的发行方到接收账户的发行方的支付的拉取和推送。
以上实施例可以以硬件、以由处理器执行的计算机程序、以固件或以上的组合来实现。计算机程序可以在计算机可读介质上实施，诸如存储介质或存储设备。例如，计算机程序可以驻留在随机存取存储器(“RAM”)、闪存、只读存储器(“ROM”)、可擦除可编程只读存储器(“EPROM”)、电可擦除可编程只读存储器(“EEPROM”)、寄存器、硬盘、可移动磁盘、光盘只读存储器(“CD-ROM”)或本领域已知的任何其它形式的存储介质。
存储介质可以耦合到处理器，使得处理器可以从存储介质读取信息和向存储介质写入信息。在替代方案中，存储介质可以是处理器的组成部分。处理器和存储介质可以驻留在专用集成电路(“ASIC”)中。在替代方案中，处理器和存储介质可以作为分立组件驻留。例如，图7图示了示例计算机系统架构，其可以表示在任何上述组件等或集成在其中。图7并不旨在对本文描述的本申请的实施例的使用范围或功能提出任何限制。计算系统700能够实现和/或执行上文阐述的任何功能。
计算系统700可以包括计算机系统/服务器，其可以与许多其它通用或专用计算系统环境或配置一起操作。可以适合用作计算系统700的众所周知的计算系统、环境和/或配置的示例包括但不限于个人计算机系统、服务器计算机系统、瘦客户端、胖客户端、手持或膝上型设备、平板电脑、智能电话、数据库、多处理器系统、基于微处理器的系统、机顶盒、可编程消费电子器件、网络PC、小型机系统、大型计算机系统、分布式云计算环境等，其可以包括任何上述系统或设备等。
计算系统700可以在由计算机系统执行的计算机系统可执行指令(诸如程序模块)的一般上下文中描述。一般而言，程序模块可以包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、逻辑、数据结构等。计算系统700可以在分布式云计算环境中实践，其中任务由通过通信网络链接的远程处理设备执行。在分布式云计算环境中，程序模块可以位于包括存储器存储设备的本地和远程计算机系统存储介质中。
如图7中所示，计算系统700以通用计算设备的形式示出。计算系统700的组件可以包括但不限于网络接口710、一个或多个处理器或处理单元720、输出端730(其可以包括端口、接口等)，或用于将数据信号输出到另一个设备(诸如显示器、打印机等)的其它硬件，以及存储设备740(其可以包括系统存储器等)。虽然未示出，但是计算系统700还可以包括将包括系统存储器的各种系统组件耦合到处理器720的系统总线。
存储装置740可以包括各种计算机系统可读介质。此类介质可以是计算机系统/服务器可访问的任何可用介质，并且它可以包括易失性和非易失性介质、可移动和不可移动介质。在一个实施例中，系统存储器实现其它附图的流程图。系统存储器可以包括易失性存储器形式的计算机系统可读介质，诸如随机存取存储器(RAM)和/或高速缓冲存储器。作为另一个示例，存储设备740可以读取和写入不可移动的非易失性磁介质(未示出并且通常称为“硬盘驱动器”)。虽然未示出，但是可以提供用于读取和写入可移动的非易失性磁盘(例如，“软盘”)的磁盘驱动器，以及用于读取或写入可移除的非易失性光盘(诸如CD-ROM、DVD-ROM或其它光学介质)的光盘驱动器。在这些情况下，每个都可以通过一个或多个数据介质接口连接到总线。如下面将进一步描绘和描述的，存储设备740可以包括至少一个程序产品，该程序产品具有一组(例如，至少一个)程序模块，这些程序模块被配置为执行本申请的各种实施例的功能。
如本领域技术人员将认识到的，本申请的各方面可以实施为系统、方法或计算机程序产品。因而，本申请的各方面可以采用完全硬件实施例、完全软件实施例(包括固件、驻留软件、微代码等)的形式或者组合软件和硬件方面的实施例，这些实施例一般在本文中全都可以被称为“电路”、“模块”或“系统”。此外，本申请的各方面可以采取在一个或多个计算机可读介质中实施的计算机程序产品的形式，该计算机可读介质具有在其上实施的计算机可读程序代码。
虽然未示出，但是计算系统700还可以与以下通信：一个或多个外部设备，诸如键盘、指点设备、显示器等；使用户能够与计算机系统/服务器交互的一个或多个设备；和/或使计算系统700能够与一个或多个其它计算设备通信的任何设备(例如，网卡、调制解调器等)。这种通信可以经由I/O接口发生。还有，计算系统700可以经由网络接口710与诸如局域网(LAN)、通用广域网(WAN)和/或公共网络(例如，互联网)之类的一个或多个网络通信。如图所描绘的，网络接口710还可以包括网络适配器，其经由总线与计算系统700的其它组件通信。虽然未示出，但是其它硬件和/或软件组件可以与计算系统700结合使用。示例包括但不限于：微代码、设备驱动程序、冗余处理单元、外部盘驱动器阵列、RAID系统、带驱动器和数据存档存储系统等。
参考图7，网络接口710可以从在移动设备上执行的数字钱包接收对于从包括在数字钱包中的发送账户向接收账户发送支付的发送请求。在这个示例中，处理器720可以执行移动设备与发送账户的发行方之间的认证协议。作为另一个示例，网络接口710可以从在移动设备上执行的商家的移动销售点(mPOS)系统接收将支付从发送账户发送到与mPOS相关联的接收账户的发送请求。
在任一种情况下，处理器720都可以控制网络接口710基于发送请求中包括的发送账户的发行方信息而经由支付网络将所请求的支付从发送账户的发行方拉取到保荐人系统。这里，经由支付网络拉取支付可以响应于正在执行成功的认证协议而将所拉取的支付的退款的责任从发送账户的发行方移交到保荐人系统。此外，处理器720可以控制网络接口710基于请求中包括的接收账户的发行方信息而经由支付网络将所请求的支付从保荐人系统推送到接收账户的发行方。
容易理解的是，如在附图中一般描述和示出的，本文的描述和示例可以以各种不同的配置来布置和设计。因此，实施例的详细描述不旨在限制所要求保护的本申请的范围，而仅仅代表本申请的所选择的实施例。本领域普通技术人员将容易理解的是，上述内容可以以不同次序的步骤和/或使用与所公开的配置不同的配置中的硬件元件来实践。因此，虽然已经基于一些优选实施例描述了本申请，但是对于本领域技术人员来说显而易见的是，某些修改、变化和替代构造将是显而易见的。

Claims (20)

1.一种执行推送-拉取支付的保荐人系统，包括：
网络接口，被配置为从在移动设备上执行的数字钱包接收对于从包括在数字钱包中的发送账户向接收账户发送支付的发送请求；以及
处理器，被配置为
在移动设备和发送账户的发行方之间执行认证协议，
控制网络接口以基于包括在发送请求中的发送账户的发行方信息经由支付网络从发送账户的发行方向保荐人系统拉取所请求的支付，其中经由支付网络的支付的拉取响应于正在执行成功的认证协议而将所拉取的支付的退款的责任从保荐人系统移交到发送账户的发行方，以及
控制网络接口以基于包括在所述请求中的接收账户的发行方信息经由支付网络从保荐人系统向接收账户的发行方推送所请求的支付。
2.如权利要求1所述的保荐人系统，其中处理器基于在保荐人系统上执行的应用编程接口(API)来执行所请求的支付的拉取和所请求的支付的推送。
3.如权利要求1所述的保荐人系统，其中处理器被配置为执行所请求的支付的拉取和所请求的支付的推送，而无需隔夜结算过程来结算支付从发送账户的发行方到接收账户的发行方的拉取和推送。
4.如权利要求1所述的保荐人系统，其中处理器控制网络接口以从发行方拉取所请求的支付包括控制网络接口以将授权请求发送到请求所请求的支付的发送账户的发行方的处理设备，并且接收由转移所请求的支付的发送账户的发行方的处理设备生成的授权响应。
5.如权利要求1所述的保荐人系统，其中发送请求包括对于将钱从数字钱包的持卡人账户发送到与快速响应(QR)码相关联的商家账户而无需隔夜结算过程来结算支付从持卡人账户的发行方到商家账户的发行方的拉取和推送的QR码扫描请求。
6.如权利要求1所述的保荐人系统，其中从非发行方数字钱包接收发送请求，所述非发行方数字钱包不具有对访问由发送账户的发行方存储的发送账户的账户信息的授权。
7.如权利要求1所述的保荐人系统，其中从原始装备制造商(OEM)钱包接收发送请求，所述OEM钱包不具有对访问由发送账户的发行方存储的发送账户的账户信息的授权。
8.如权利要求1所述的保荐人系统，其中由处理器执行的认证协议包括以下中的至少一个：认证发送账户的主账号(PAN)的数字安全远程支付(DSRP)过程以及安全代码在数字钱包和发送账户的发行方之间的传输以认证数字钱包的用户。
9.一种执行推送-拉取支付的保荐人系统，包括：
网络接口，被配置为从在移动设备上执行的移动销售点(mPOS)系统接收对于从发送账户向与mPOS相关联的接收账户发送支付的发送请求；以及
处理器，被配置为
经由保荐人系统的应用编程接口(API)处理发送请求，其中经由所述API，处理器被配置为基于包括在发送请求中的发送账户的发行方信息经由支付网络从发送账户的发行方向保荐人系统拉取所请求的支付，并且经由支付网络的支付的拉取响应于正在执行成功的认证协议而将所拉取的支付的退款的责任从保荐人系统移交到发送账户的发行方，以及
基于包括在所述请求中的接收账户的发行方信息经由支付网络从保荐人系统向接收账户的发行方推送所请求的支付。
10.如权利要求9所述的保荐人系统，其中发送请求由包括发送账户的数字钱包与在移动设备上执行的mPOS之间的非接触式支付触发。
11.如权利要求9所述的保荐人系统，其中拉取所请求的支付和推送所请求的支付由保荐人系统执行，而无需隔夜结算过程来结算支付从发送账户的发行方到接收账户的发行方的拉取和推送。
12.如权利要求9所述的保荐人系统，其中所述API使得mPOS能够通过移动设备接受非接触式支付并代表mPOS处理非接触式支付。
13.一种执行推送-拉取支付的方法，包括：
在保荐人系统处从在移动设备上执行的数字钱包接收对于从数字钱包的发送账户向接收账户发送支付的发送请求；
经由保荐人系统执行移动设备和发送账户的发行方之间的认证协议；
基于包括在发送请求中的发送账户的发行方信息经由支付网络从发送账户的发行方向保荐人系统拉取所请求的支付，其中经由支付网络的拉取响应于正在执行成功的认证协议而将所拉取的支付的退款的责任从保荐人系统移交到发送账户的发行方；以及
基于包括在所述请求中的接收账户的发行方信息经由支付网络从保荐人系统向接收账户的发行方推送所请求的支付。
14.如权利要求13所述的方法，其中拉取所请求的支付和推送所请求的支付由在保荐人系统上执行的应用编程接口(API)执行。
15.如权利要求13所述的方法，其中拉取所请求的支付和推送所请求的支付由保荐人系统执行，而无需隔夜结算过程来结算支付从发送账户的发行方到接收账户的发行方的拉取和推送。
16.如权利要求13所述的方法，其中拉取包括保荐人系统的处理器控制保荐人系统的网络接口将授权请求发送到请求所请求的支付的发送账户的发行方的处理设备并且从转移所请求的支付的发送账户的发行方的处理设备接收授权响应。
17.如权利要求13所述的方法，其中发送请求包括对于将钱从数字钱包的持卡人账户发送到与快速响应(QR)码相关联的商家账户而无需隔夜结算过程来结算支付从持卡人账户的发行方到商家账户的发行方的拉取和推送的QR码扫描请求。
18.如权利要求13所述的方法，其中从非发行方数字钱包接收发送请求，所述非发行方数字钱包不具有对访问由发送账户的发行方存储的发送账户的账户信息的授权。
19.如权利要求13所述的方法，其中从原始装备制造商(OEM)钱包接收发送请求，所述OEM钱包不具有对访问由发送账户的发行方存储的发送账户的账户信息的授权。
20.如权利要求13所述的方法，其中认证协议包括以下中的至少一个：认证发送账户的主账号(PAN)的数字安全远程支付(DSRP)过程以及安全代码在数字钱包和发送账户的发行方之间的传输以认证数字钱包的用户。
CN201880021793.1A 2017-03-27 2018-03-23 用于x-支付数字钱包的拉取和推送系统 Active CN110462661B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201762476971P 2017-03-27 2017-03-27
US62/476,971 2017-03-27
US201762534734P 2017-07-20 2017-07-20
US62/534,734 2017-07-20
PCT/US2018/024005 WO2018183108A1 (en) 2017-03-27 2018-03-23 Pull and push system for x-pay digital wallets

Publications (2)

Publication Number Publication Date
CN110462661A true CN110462661A (zh) 2019-11-15
CN110462661B CN110462661B (zh) 2023-12-05

Family

ID=61913663

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201880021793.1A Active CN110462661B (zh) 2017-03-27 2018-03-23 用于x-支付数字钱包的拉取和推送系统

Country Status (5)

Country Link
US (1) US20180276658A1 (zh)
CN (1) CN110462661B (zh)
RU (1) RU2727150C1 (zh)
SG (2) SG10202111921XA (zh)
WO (1) WO2018183108A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113177786A (zh) * 2020-01-24 2021-07-27 维萨国际服务协会 将交易作为推送支付交易进行处理的系统、方法和计算机程序产品

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10880288B2 (en) * 2018-06-05 2020-12-29 The Toronto-Dominion Bank Methods and systems for controlling access to a protected resource
US11551250B2 (en) 2019-05-01 2023-01-10 Mastercard International Incorporated Payment processing system for applying merchant promotions to a push payment transaction
US11354646B2 (en) * 2019-10-10 2022-06-07 Mastercard International Incorporated Methods and systems for supporting QR code transactions
US11514412B2 (en) 2019-12-17 2022-11-29 Mastercard International Incorporated Systems and methods for real time data rich cross border payment transactions
US11457011B2 (en) * 2020-06-29 2022-09-27 Capital One Services, Llc Using receipts for multifactor authentication
RU2761419C1 (ru) * 2020-11-11 2021-12-08 Акционерное общество "Национальная система платежных карт" Способ и система для перевода денежных средств со счета на счет
US20240054471A1 (en) * 2022-08-12 2024-02-15 Mastercard International Incorporated System and method for providing push payment transaction processing in a card-present environment

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012151590A2 (en) * 2011-05-05 2012-11-08 Transaction Network Services, Inc. Systems and methods for enabling mobile payments
US20140012749A1 (en) * 2012-06-29 2014-01-09 Kt Corporation Electronic wallet based remittance
CN104392355A (zh) * 2014-11-14 2015-03-04 青岛龙泰天翔通信科技有限公司 一种安全性高的电子支付方法
CN105580038A (zh) * 2013-07-24 2016-05-11 维萨国际服务协会 用于可互操作的网络令牌处理的系统和方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IL120585A0 (en) * 1997-04-01 1997-08-14 Teicher Mordechai Countable electronic monetary system and method
US20070125838A1 (en) * 2005-12-06 2007-06-07 Law Eric C W Electronic wallet management
US20150006385A1 (en) * 2013-06-28 2015-01-01 Tejas Arvindbhai Shah Express transactions on a mobile device

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012151590A2 (en) * 2011-05-05 2012-11-08 Transaction Network Services, Inc. Systems and methods for enabling mobile payments
US20130110658A1 (en) * 2011-05-05 2013-05-02 Transaction Network Services, Inc. Systems and methods for enabling mobile payments
US20140012749A1 (en) * 2012-06-29 2014-01-09 Kt Corporation Electronic wallet based remittance
CN105580038A (zh) * 2013-07-24 2016-05-11 维萨国际服务协会 用于可互操作的网络令牌处理的系统和方法
CN104392355A (zh) * 2014-11-14 2015-03-04 青岛龙泰天翔通信科技有限公司 一种安全性高的电子支付方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113177786A (zh) * 2020-01-24 2021-07-27 维萨国际服务协会 将交易作为推送支付交易进行处理的系统、方法和计算机程序产品
CN113177786B (zh) * 2020-01-24 2023-11-10 维萨国际服务协会 将交易作为推送支付交易进行处理的系统、方法和计算机程序产品

Also Published As

Publication number Publication date
US20180276658A1 (en) 2018-09-27
SG10202111921XA (en) 2021-12-30
WO2018183108A1 (en) 2018-10-04
RU2727150C1 (ru) 2020-07-21
SG11201908385WA (en) 2019-10-30
CN110462661B (zh) 2023-12-05

Similar Documents

Publication Publication Date Title
US11423390B2 (en) Systems and methods for providing transaction tokens for mobile devices
US11790332B2 (en) Mobile telephone transfer of funds
US20180068293A1 (en) Method and system for allowing offline peer-2-peer transactions using exchangeable provisioned tokens
CA2896755C (en) Systems and methods for providing secure data transmission between networked computing systems
US8565723B2 (en) Onetime passwords for mobile wallets
CN110462661A (zh) 用于x-支付数字钱包的拉取和推送系统
US20160048822A1 (en) Method and System for Delivering Funding Options to a User
WO2018148358A1 (en) System and method for processing a multi-account transaction
US11810097B2 (en) Systems and methods for use in enabling device-to-device communication, based on user interactions with the devices
US20130211937A1 (en) Using credit card/bank rails to access a user's account at a pos
US20150262166A1 (en) Real-Time Portable Device Update
US11049129B1 (en) Payment using rewards points
KR20160010042A (ko) 실시간 계좌 이체, 계좌 추심을 통한 결제 방법, 서버 및 컴퓨터 판독 가능한 기록 매체
KR20180106446A (ko) 결제자의 모바일 단말을 이용한 결제 시스템 및 방법
KR101751792B1 (ko) Ic 카드를 이용한 결제 처리 방법 및 그를 수행하기 위한 결제 단말 장치
WO2019203853A1 (en) Portable device loading mechanism for account access
TWI668647B (zh) Contactless offline transaction method, seller device and buyer device
US11494756B2 (en) Payment transactions with integrated point of sale terminals
US20230087986A1 (en) Inserting code into a document object model of a graphical user interface to enable sub-exchanges
TWM552145U (zh) 非接觸式離線交易賣方裝置及買方裝置
KR20180106456A (ko) 모바일 단말을 이용한 결제 시스템 및 방법
KR20200129748A (ko) 발급된 카드를 이용하는 결제 시스템 및 결제 방법

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant