CN116472545A - 用于在下订单和交付之间进行安全数字支付拆分的方法和系统 - Google Patents

用于在下订单和交付之间进行安全数字支付拆分的方法和系统 Download PDF

Info

Publication number
CN116472545A
CN116472545A CN202180037688.9A CN202180037688A CN116472545A CN 116472545 A CN116472545 A CN 116472545A CN 202180037688 A CN202180037688 A CN 202180037688A CN 116472545 A CN116472545 A CN 116472545A
Authority
CN
China
Prior art keywords
payment
merchant
pns
customer
delivery
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
Application number
CN202180037688.9A
Other languages
English (en)
Inventor
埃哈卜·穆罕默德·易卜拉欣·克什
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.)
Ai HaboMuhanmodeYibolaxinKeshi
Original Assignee
Ai HaboMuhanmodeYibolaxinKeshi
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 Ai HaboMuhanmodeYibolaxinKeshi filed Critical Ai HaboMuhanmodeYibolaxinKeshi
Publication of CN116472545A publication Critical patent/CN116472545A/zh
Pending legal-status Critical Current

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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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
    • 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/24—Credit schemes, i.e. "pay after"
    • 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
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本发明涉及使用电子钱包、卡或任何数字支付方法的数字支付的领域；并且特别涉及电子商务在线支付。在电子商务领域，客户更喜欢在检查交付的货物之后交付时全额支付；这给商家带来了风险。相比之下，商家更愿意在发货前处理完全的下订单时全额支付；这给客户带来风险。下订单时全额支付或交付时全额支付这两个选项都不令人满意或对双方(客户和商家)不公平。本发明引入了一种具有支付方法的解决方案，该支付方法可以基于商家提供和客户接受的支付拆分策略自动拆分支付金额，以使商家能够在下订单时获得部分支付，然后在交付时索取其余部分支付。

Description

用于在下订单和交付之间进行安全数字支付拆分的方法和 系统
技术领域
本发明涉及使用电子钱包、卡或任何数字支付方法的数字支付领域；并且特别地，涉及在下订单和/或订单交付时基于商定的支付策略来处理电子商务在线订单的数字支付的方法和系统。
背景技术
随着智能设备和高速互联网的普及，利用电子商务平台在线购买商品和服务的客户的数量呈指数增长。客户可以选择多种支付模式来从电子商务商家购买商品和服务。客户可以在下订单时在线预付交易金额，使得客户经由信用卡、借记卡、数字钱包或银行账户中的一种或多种进行数字支付。如果交付的订单被损坏或缺少一些物品，那么客户将在漫长的退货和/或退款过程中遇到问题。
可替代地，客户可以在下订单时选择“交付时支付”支付模式。在这种情况下，客户只有在接收到商品或服务之后才以现金支付方式完成交易。虽然“交付时支付”支付模式是大多数电商客户的首选，但这种支付模式给电子商务商家和客户带来了多重问题。这些问题中的一些包括现金处置成本、现金和订单核对麻烦、现金接收延迟、现金管理中的损失以及来自客户的确切现金要求，而且，如果客户在没有支付的情况下退货，那么商家也会遇到运输成本问题。
因此，需要一种保留“交付时支付”支付模式的好处，同时消除所有上面讨论的问题并实现客户与商家之间的公平性的方法和系统。
附图说明
图1图示了根据本发明的某些实施例的基于支付拆分策略的数字支付处理方法。
图2示出了详细说明根据本发明的某些实施例的从客户到商家的实际支付转移的流程图。
图3示出了描述根据本发明的某些实施例的具有多重保留技术的数字支付保留管理的状态机。
图4描绘了连接电子钱包、商家和运营商以实现根据本发明的某些实施例的发明方法的支付网络系统。
具体实施方式
A.问题定义：
本发明所解决的问题是具有来自不同但相关角度的特点的复杂问题。
对于电子商务在线购买，客户更喜欢交付时支付，以降低先支付然后收到不正确订单并进入退款过程的风险。电子商务客户和商家更喜欢无现金支付，以避免“背景”部分中提到的现金问题。客户更喜欢通过他们最喜欢的电子钱包而不是不够安全的卡进行支付(每年数百万的欺诈案件)。客户对交付时支付的偏好与商家偏好相冲突。
商家确实更喜欢在他们发货之前的在线数字支付，以更早收到钱并限制由于多种原因而发生的订单退货(客户不再对订单感兴趣、客户无法接收订单等)。虽然商家在这些情况下没有错误，但由于将订单运送给客户并返回的成本以及许多其它处置和管理成本，它们给商家带来巨大的金钱损失。
这个问题有以下特点：
从商业角度看，下单时支付对客户不公平，交付时支付对商家不公平；因此，需要一个让双方都满意的解决方案。
从钱包的角度来看，虽然目前世界上有成千上万的钱包，而且数量每天都在增长，但只有极少数能被全球接受，其余的都是使用生成的虚拟卡让其用户在线购买。因此，需要一种解决方案将任何钱包轻松连接到全球商家，以便任何客户都可以使用任何钱包为任何商家支付。
从安全性的角度来看，具有全球认可的所述少数钱包是基于内部卡(信用卡/借记卡或任何类型的卡)。那些钱包中的一些与不安全的商家共享卡信息，而其它钱包(像PayPal)则获取订单信息并直接从客户的卡中提取所需金额，然后将金额转移给商家而不共享卡信息。这种解决方案满足安全性要求，但因为在下订单时付全款，所以无法达到客户与商家之间的公平性。
从交付的角度来看，在大多数情况下，商家自己不交付，他们使用如Aramex、FedEx等专业的交付公司，并不是所有的交付代理都有销售点[POS]设备来接受通过钱包的数字支付。即使交付代理有POS设备，它也只能促进不满足公平性要求的全部交付时支付。
从客户体验的角度来看，客户希望以一致的方式使用同一个钱包进行在线、交付和店内购买。对于在线购买，客户每次购买都需要进行单笔交易；因此，如果解决方案提出客户应当为在线购买进行两次交易(一次用于下订单，另一次用于交付)以实现期望的公平性，这意味着糟糕的客户体验，而且不能为商家保证交付交付。
从上面的分析可以容易地推断出，所解决的问题不仅是技术问题，也不仅仅是业务问题；更确切地说，这是个组合问题，其中存在业务需求的集合，而当前的技术和解决方案无法同时满足该需求的集合。
B.解决方法：
本发明解决方法基于以下三个主要思想：
支付拆分策略[PSP]：
这个策略确定了商家要求在下订单时(在下订单时)支付的百分比或金额，以及将在订单交付时支付的其余的百分比或金额。例如，PSP可以是10％-90％，这意味着总订单价值的10％应在下订单时支付，并且90％将在交付时收取。可替代地，它可以是确切的金额而不是百分比；比如如果订单价值是100美元，那么10-90，这意味着10美元将在下订单时支付，90美元在交付时支付。简而言之，可以只提到下订单时拆分，并且其余的被推导；这意味着如果商家将PSP设置为10％，那么方法和系统应当自动将其解释为10％下订单时和90％交付时。
商家可以基于他自己的业务规则/参数(如产品类别、订单价值、客户群、国家等)自由决定不同的PSP。PSP可以被一次性设置或按订单确定；如果两者都被提供，那么后者将取代。
预支付引用[PPR]：
客户可以使用其信用卡账户中的信用、银行账户中的金钱、电子钱包中的金钱、忠诚度账户中的忠诚度积分或任何其它类型的账户余额进行支付。所述账户中的任何一个都具有控制系统，例如，如果客户支付账户是信用卡账户，那么控制系统是卡的发卡银行系统。如果支付账户是电子钱包账户，那么账户控制系统是电子钱包系统，以此类推。
PPR是预支付[PP]的完全合格引用；换句话说，它是包含用于PP的完整地址的全局唯一标识符。当客户账户的控制系统搁置支付金额时，认为支付已准备好，并确定该支付的接收者。例如，如果客户想在某个商家网站下一个价值100美元的订单，并想使用他在电子钱包中的钱来支付这个订单，那么他应当使用电子钱包来选择商家作为支付的接收者并将支付金额设置为100美元，因此电子钱包系统将通过为所述商家持有所述金额来准备支付并为这个PP生成唯一的引用。以这种方式，当客户将PPR给予商家时，对于商家而言支付(通过电子钱包系统)得到保证，但尚未处理。随后，商家根据本发明方法使用PPR连同PSP来收取支付金额。
多重保留技术[MHT]：
多重保留是一种管理如何保留支付金额以及如何在多方之间发放支付金额的新技术。在本发明的上下文中，重点是客户和商家之间的PP保留和发放。当被创建时，PP有一个作为客户保留[CH]的保留，因此如果客户在将其PPR给予商家之前想取消它，那么保留将被移除，并且该金额将再次可供客户使用。如果向商家给予PPR(没有取消)并且该商家将其发送到发行方系统(例如，电子钱包系统)，那么所述系统在PP上添加第二个保留，即，商家保留[MH]。
在这种状态下，未经另一方同意，PP金额不会发放给任何一方。这意味着，对于商家收取支付金额，客户应当移除他的CH，例如当订单被交付并且客户接受它时会发生这种情况。PP的完整保留/发放生命周期将在本节后面更详细地解释。
支付网络概述：
可以在一个或多个商家与使用任何数字支付方式(信用卡、电子钱包等)的客户之间应用上述三个构思。例如，电子钱包可以直接与多个商家集成，并应用PPR生成将其给予任何商家，然后在支付过程结束时应用商家的PSP和MHT将支付发放给商家。
电子钱包与商家之间的直接连接不是高效的解决方案，因为在这种情况下：
1、每个电子钱包都必须通过其商家网络来实现整个解决方案，这会导致有许多不同的解决方案，没有责任方来标准化或统一。这增加了电子钱包系统的成本，因此限制了它们对大量商家的应用。
2、如果商家想要与多个电子钱包合作，那么这个商家应当单独集成每个电子钱包。这增加了任何商家支持更多电子钱包的成本，并迫使客户使用少数具有全球影响力的电子钱包，从而限制了电子商务业务的敏捷性和动态性。
优选的解决方案是具有以一致的方式轻松地将电子钱包连接到商家并且反之亦然的支付网络。任何电子钱包要覆盖整个商家网络所需要做的就是加入这个支付网络并符合其标准。而且，任何商家支持所有电子钱包所需要的就是加入同一个支付网络并符合其标准。因为许多商家经由交付承运商交付订单货物，所以这个网络还支持具有所述承运商。
上述优选方案的描述并不意味着本发明仅限于此；更确切地说，如前所述，主要构思以多种方式适用，以支持在下订单时和交付之间的支付拆分。将三个主要构思一起或分开使用的任何解决方案都被认为是本发明范围内的变体。
方法：
图1图示了根据本发明的优选实施例的支付场景：
1、当客户(A)想要在商家(F)的网站或应用中结账时，该方法开始。在商家应用的结账支付步骤，客户选择电子钱包支付方法并选择他想要用来支付的电子钱包；所述商家必须是支付网络(G)中的注册商家(H)之一，并且所述电子钱包必须是同一网络中的注册电子钱包(I)之一。客户前往他的电子钱包(B)，确定(1)他要支付的商家，以及总订单金额，然后确认。
2、电子钱包(B)创建预支付(C)，在PP上应用客户保留，生成其PPR，并将其返回给客户，然后客户将所述PPR经由商家的应用/网站发送(2)给商家(F)。
3、商家(F)基于其业务规则决定支付拆分策略，然后将PPR和PSP都发送(3)给支付网络(G)
4、支付网络(G)将所述PPR和PSP转发(4)回电子钱包(B)。注意：如前所述的PPR是PP的完全限定参考，包括电子钱包标识符，因此支付网络可以确定发行方电子钱包并将PPR转发给它。
5、电子钱包(B)通知客户(A)确认他接受商家的PSP。当客户确认(5)时，电子钱包在PP上应用商家保留。
6、电子钱包(B)基于PSP将PP(C)拆分(6)为在下订单时支付(D)和在交付时支付(E)。
7、电子钱包(B)基于客户对PSP的接受情况从下订单时支付(D)中移除客户保留，然后将下订单时支付(D)转移(7)到商家(F)。如稍后详细描述的，所述转移实际上是经由支付网络(G)进行的。
8、商家(F)执行订单装运过程，并将货物交给(8)承运商的代理(K)以将其交付给客户(A)。
9、代理(K)将货物交付(9)给客户(A)。
10、代理(K)向商家(F)发送(10)订单交付单。所述交付单可以经由商家的应用或与商家的系统集成的承运商的应用发送。可替代地，代理(K)可以将交付单直接发送到支付网络(G)，然后所述网络将交付单转发给商家。替代场景的优点是，如果承运商代表许多商家运交付货物，那么最好只与网络集成，而不是与所有所述商家集成。在这种情况下，所述承运商应当是支付网络(G)中的注册承运商(J)之一，以便能够与所述网络集成。
11、商家(F)将交付单连同订单的PPR一起转发(11)到支付网络(G)以收取交付时支付(E)。
12、支付网络(G)将交付单连同PPR一起转发(12)到客户的电子钱包(B)以收取商家的交付时支付(E)。
13、电子钱包(B)通知客户(A)确认他接受订单发货。当客户确认(13)时，电子钱包从交付时支付(E)中移除客户保留。
14、电子钱包(B)将交付时支付(E)转移(14)到商家(F)。所述转移实际上是经由如下所述的支付网络(G)进行的。
支付转移流程：
在方法步骤(7)和(14)中，应当将一定数量的钱从客户转移到商家。
图2图示了经由支付网络从客户到商家的典型资金转移流程：
1、包含/控制客户账户(L)的电子钱包(B)将部分PP(C)转移(1)到被指定用于支付网络(G)的电子钱包账户(N)。在支付网络中注册的任何电子钱包都必须为所述网络创建内部账户。PP转移的支付部分可以是在下订单时(D)或在交付时(E)；两种情况的转移流程相同。电子钱包(B)通过在所述账户中创建指定PPR、支付金额和商家ID(M)的信用记录来将所需支付转移到账户(N)。在所述电子钱包执行第二步之前，网络中的所有电子钱包对于指定的时间间隔(例如，一整天)继续为所有商家的所有支付进行这种转移。
2、电子钱包(B)将全天的汇总余额从账户(N)转移(2)到网络汇总账户(O)；这种转移是从电子钱包(B)的金融系统到支付网络(G)的金融系统的真实资金转账。网络汇总账户(O)接收所有已注册电子钱包的每日支付转移，并将其转发给其目标注册商家；这意味着所述账户(O)包含一天的全网支付。
3、支付网络(G)对每个注册商家记录(R)都有内部商家账户(P)。支付网络(G)将每个商家的全天支付分组，然后将每组支付转移(3)到其商家账户(P)。
4、支付网络(G)将网络内部商家账户(P)中的每日商家支付的总额从网络金融系统转移(4)到商家(F)的金融系统中的真实商家账户(Q)。注意：商家真实账户是任何注册商家的记录的一部分。
这个描述假设用于三个主要实体(电子钱包、支付网络和商家)的分离的金融系统。例如，如果这个解决方案是在区块链平台上使用数字货币账户来实现的，那么所述转移应当容易得多而且间隔可以更短，或者甚至可以逐笔支付立即执行，但无论如何都必须经由支付网络以在将支付转发给商家之前扣除其费用。而且，电子钱包在其将支付金额转移到支付网络之前会扣除其费用。
方法异常场景(订单拒绝场景)：
图1和2图示了客户接受整个订单货物的正常场景。
还有其它一些情况，如订单完全错误，或者某些订单物品丢失或损坏。在所有这些情况下，客户都拒绝商家要求交付时支付的请求。支付网络将客户拒绝通知商家，因此商家可以联系客户并根据在商家之间不同的特定过程处置问题，这超出了本发明的范围。
在与客户达成协定之后，商家在支付网络上采取动作以应用与客户达成的结算。商家动作基于情况而有所不同，具体如下；假设收取的下订单时支付为100美元并且剩余的交付时支付为400：
1、客户在装运之前拒绝整个订单或取消订单：
a、商家移除他对要发放给客户的交付时支付的保留。
b、商家根据商家的退款政策将下订单时支付或其一部分退还给客户。退款政策可以是PSP的一部分，例如在这种情况下PSP是20％，如果商家有10％的不退款政策(不退款必须最多等于下订单时拆分)，因此PSP将是20％-10％。支付网络将所述PSP解释为20％下订单时、80％交付时和10％不可退款。网络不应当基于不可退款部分采取任何动作，仅在支付进行之前转发给具有PSP的客户以供同意。
2、客户部分拒绝订单(接受部分的值大于下订单时支付)：
a、商家将部分交付时支付作为最终索要的钱。例如，如果客户接受了总价值为300美元的订单的部分，那么商家从剩余的400美元中索要200美元，因为200+100(下订单时支付)＝300。
最终索要：有时，在正常情况下，商家会分批交付大宗订单，并且更愿意按批次要求支付，因此商家能索要多个部分(但不是最终)交付时支付。这就是为什么在这个拒绝案例中，必须将部分索要标记为最终，因此电子钱包可以将剩余的200发放给客户
(400–200＝200)。
3、客户部分地拒绝订单(接受部分的价值小于下订单时支付)：
a、商家移除他对要发放给客户的交付时支付的保留。
b、商家根据商家的退款政策退还下订单时价值与接受订单价值之间的差额。假设政策允许，如果客户接受的订单部分价值为80美元，那么商家应当退还100–80＝20。
为了总结商家在所有描述的场景中可以采取的一系列动作，商家在正常情况下要求全额支付，如果客户拒绝一些物品，那么要求部分支付，如果客户拒绝订单的全部/大部分，那么要求为零并退还下订单时支付的全部/部分。这意味着商家或者要求全额/部分/零交付时支付，退还全额/部分下订单时支付，或两者兼而有之。
5、支付索要案例：
图3图示了根据多重保留技术[MHT]的所有索要案例，如下所示：
1、当任何支付准备就绪时，在客户保留[CH]状态(S0)下创建它(方法步骤2)。如果客户取消(1)支付，那么它进入发放给客户状态(S1)。
2、从(S0)开始，如果客户将PPR给予商家，那么商家将其发回电子钱包，并且客户确认PSP(方法步骤5)，系统向要处于状态(S2)CH-MH的支付添加(2)商家保留[MH]。
3、当客户在正常情况下收到货物之后确认交付时(方法步骤13)，系统从支付中移除(3)CH并将其移至状态(S3)MH。
4、系统自动发放(4)对商家的支付(方法步骤14)并将其移至状态(S4)发放给商家。
5、在商家不要求交付时支付的例外场景的情况下，商家应当向支付网络发送零金额或百分比的索要(方法步骤11)，因此系统从支付中移除(5)MH，将它从(S2)移回到状态(S0)CH，然后通知客户，因此客户可以在任何时候取消它以根据第1点得到发放的他的钱。
6、在商家将部分索要交付时支付的例外场景的情况下，商家索要带有最终索要标志的期望金额(方法步骤11)。在客户确认之后(方法步骤13)，系统将(S2)中的支付拆分(6)成两部分；商家索要的部分和客户的其余金额。商家部分将处于状态(S21)MH，而客户部分将处于状态(S22)CH。
7、系统自动将商家部分发放(7)给商家(方法步骤14)并将其从(S21)移至状态(S4)发放给商家。
8、系统自动将客户部分发放(8)给客户并将其从(S22)移至状态(S1)发放给客户。
如果未设置最终索要标志，那么系统将处于(S2)的支付拆分为(S21)MH，然后将其发放给商家，并且金额的其余部分将保留在(S2)等待进一步的商家索要。在商家的请求中设置最终索要标志之前，不应当向客户退还任何东西。
支付退款方法：
正如支付转移流程描述中提到的，该解决方案可以使用区块链平台上的数字货币账户来实现，因此对于每次支付都可以立即执行转账。基于此，这种实施方式中的退款可以遵循与图2相同的流程，但方向相反：
1、商家从其账户向支付网络账户发出退款转账，所述转账应当附有被退款支付的PPR。
2、给定PPR，支付网络可以获取包括发行方电子钱包在内的详细信息，然后发出从网络账户到电子钱包账户的转移(电子钱包账户是任何注册的电子钱包记录的一部分)。
3、所述发行方电子钱包在内部将接收到的退款金额转移到拥有该PPR的客户的账户。
如果针对三个主要实体(电子钱包、支付网络和商家)使用分离的传统金融系统来实现该解决方案，那么退款场景可以如下(参考图2)：
1、商家(F)向支付网络(G)发出退款订单，并附上PPR和退款金额(此处没有转账)。
2、支付网络(G)将所述退款订单记录为网络内商家账户(P)中的借记记录。然后，所述网络向发出所述PPR的电子钱包(B)发出相同金额的退款订单(此处也没有转账)。
3、电子钱包在电子钱包系统内的网络的账户(N)中记录所述退款订单作为借记记录，指示商家ID(M)。然后，所述电子钱包将退款金额记入拥有PPR的客户账户(C)。以这种方式，一旦商家发出退款，客户就立即接收到金额。
4、为了闭合循环，当第二天到来时，电子钱包将每日净余额转移(2)到网络汇总账户(O)。净余额等于当日总支付金额减去退款借记金额。
5、支付网络(G)将商家当天的总支付转移(3)到他的账户(P)，然后将账户(P)的净余额转移(4)到真实商家账户(Q)。账户(P)净余额等于商家的总支付金额减去退款借记金额。
在订单退回的情况下，商家可能需要时间来接收和检查它，这个时间依赖于商家的内部过程，这超出了本发明的范围。上述退款方法保证一旦商家发出退款订单，客户就会收到退款金额。
注意：同样的方法适用于任何时候退款，即使在商家100％收款后，客户可以联系商家以退回订单的全部/部分，并且如果商家接受，那么商家根据上述方法中的任何一个发出退款订单/转账到支付网络。
C.解决方案相对于背景技术的优势：
1、公平性：本发明的解决方案使用由第三方申请的MHT(电子钱包/支付-网络的组合)在商家需要信任支付和客户需要信任交付之间取得平衡。这个组合不是客户方或商家方；它是公平的第三方。如有争议，那么MHT鼓励商家和客户双方达成协定，因为如果没有这样的协定，那么支付将不会到达他们任何一方。而且，商家与客户之间商定的PSP是另一种公平性/信任工具，其让商家在一定程度上控制货运成本损失和现金流瓶颈的风险(现金流并不意味着现金支付，它是关于收款的时间和速率)，同时它让客户可以自由地接受或拒绝并在竞争以提供更好的PSP的商家之间进行比较。
2、安全性：由于PPR的概念，本发明的解决方案保证100％安全的数字支付。PPR不包含有关客户账户或卡的任何信息，它是向特定目的地商家准备支付的引用。因此，没有人可以操纵它；即使被嗅探或被黑，黑客也没有方式使用它来得到钱。如果客户有银行账户并使用那个银行的电子钱包，那么他不需要卡或PayPal钱包或其它任何东西来执行100％安全支付，而无需与任何一方共享账户信息；如果客户银行的电子钱包注册在支付网络中，那么客户可以使用从其银行电子钱包生成的PPR向同一网络中的任何商家支付。
3、解耦的连接性：支付网络将任何注册的电子钱包连接到任何注册的商家，同时应用完全解耦；电子钱包不依赖于商家并且商家也不依赖于电子钱包。商家和电子钱包仅依赖于支付网络。支付网络和电子钱包不必知道任何订单细节(在如PayPal的以前的解决方案中，电子钱包依赖于商家来获取订单信息)。本发明的解决方案使任何电子钱包(不仅是少数全球性的)能够安全地为任何商家支付，而不需要不完全安全的虚拟卡。
4、三方网络：除了将商家和电子钱包以解耦的方式连接外，支付网络还将交付承运商与商家以解耦的方式连接。如果承运商系统已经与商家系统耦合，那么所述网络也可以支持这种场景，如方法步骤10中所述，承运商可以向网络或直接向商家发送交付单。
5、无POS：交付承运商的代理不需要具有POS来收取数字支付。
6、立即退款：如“支付退款方法”部分所述，一旦商家发出退款订单/转账，客户账户将立即入账。
7、客户体验：
a、客户可以看到他账户中的保留，没有资金移到商家或第三方的另一个账户，直到他在接受后收取支付。
b、在交付时，客户可以推迟交付确认，直到他检查所有订单物品；交付代理不必等待，他可以发送交付单并移动。
c、客户可以一致地使用相同的支付方法进行其它类型的支付：
i、如果商家在下订单时没有强制要求获得PPR，那么客户可以在交付时生成它并与承运商代理共享以代表商家将其发送到支付网络以要求支付。PPR可以作为号码共享给代理以插入代理的应用或作为QR码进行扫描。
ii、在店内，客户可以生成PPR并以号码或QR码的形式与商家的收银应用共享，因此所述应用将其发送到支付网络以要求支付。
可以添加“即时全额支付”标志以绕过支付拆分和交付确认。
用于执行本发明的最佳模式：
图4图示了促进执行本发明方法的支付网络系统[PNS](G)组件和集成。
PNS集成&组件：
PNS集成了三种类型的系统；电子钱包系统、商家系统和承运商系统。PNS提供了用于与每种类型的系统交互的网关和核心系统组件的集合来支持/服务所述网关，如下所示：
1、电子钱包网关(BG)：这是系统组件，它负责与所有电子钱包的所有通信，包括在PNS中的电子钱包注册以及支付和退款场景中的所有交互。这个组件依赖于电子钱包(B)和其它PNS组件：
a、支付编排器(U)：这是管理用于所有支付和退款场景的工作流的主要系统组件；网关(BG)在所述场景期间依赖于它；例如，当向PNS通知客户交付确认时。
b、查询引擎(X)：这是通用查询工具，它从数据存储库中为任何组件提供它需要的任何数据。网关(BG)依赖于它来获取注册商家的列表以显示给客户以选择一个进行支付准备。
c、对账引擎(Y)：这是负责交叉检查记录的支付与转移金额的组件。每日转账之后收到电子钱包通知，以开始交叉核对。
如果出现任何不一致，那么会通知电子钱包以解决问题。
d、PPR生成器(V)：这是负责统一跨所有注册的电子钱包生成的PPR的格式的集中式组件；因此，电子钱包在支付准备期间依赖于它来获得PPR。可替代地，电子钱包可以基于商定的格式生成PPR，而无需参考所述集中式组件。
2、承运商网关(TG)：这是负责与所有承运商进行所有通信的系统组件；包括PNS中的承运商注册，并在支付场景期间接收交互通知；所述通知由代理(K)经由承运商系统(T)发送。这个组件依赖于另一个PNS组件：
a、支付编排器(U)：这是管理用于所有支付和退款场景的工作流的主要系统组件；网关(TG)依赖于它来处置基于交付通知的交付时支付收取。
3、商家网关(FG)：这是个系统组件，负责与所有商家的所有通信，包括PNS中的商家注册以及支付和退款场景期间所有系统到系统(即，PNS到商家系统)的交互。这个组件依赖于商家(F)和其它PNS组件：
a、支付编排器(U)：这是管理用于所有支付和退款场景的工作流的主要系统组件；网关(FG)在所述场景期间依赖于它；例如，为商家收取下订单时和交付时支付。
b、查询引擎(X)：这是通用的查询工具，它从数据存储库中为任何组件提供它需要的任何数据。网关(FG)依赖于它来获取已注册的电子钱包的列表以显示给客户以选择一个进行支付。
c、对账引擎(Y)：这是用于交叉检查记录的支付与转移的金额。它在每日转账之后通知商家开始交叉检查。如果有任何不一致，那么商家通知它来解决问题。
4、商家门户(FP)：这是系统可视化组件，以支持商家(F)报告和监视支付，设置PSP业务规则，指派承运商代表所述商家索要交付时支付等。这个组件依赖于其它PNS组件：
a、支付编排器(U)：这是管理用于所有支付和退款场景的工作流的主要系统组件；门户(FP)依赖于它；例如，指派允许代表商家(F)索要交付时支付的承运商。
b、查询引擎(X)：这是通用的查询工具，它从数据存储库为任何组件提供它需要的任何数据。门户(FP)依赖于它来获取支付的列表、注册承运商的列表等。
c、PSP规则引擎(Z)：这是通用的可选规则引擎，它支持商家建立自己的帮助他们基于某些属性在不同情况下决定不同PSP的业务规则。商家可以在其内部系统中使用规则，使用这个可选引擎，或同时使用两者。
5、支付编排器(U)：这是管理用于所有支付和退款场景的工作流的主要系统组件。它依赖于网关与三方(电子钱包、商家和承运商)进行交互。它还依赖于其它PNS组件：
a、PSP规则引擎(Z)：这是通用的规则引擎，支持商家建立他们的帮助他们决定PSP的业务规则。如果商家没有发送PSP，那么编排器(U)依赖于它，这意味着应当使用所述引擎来决定PSP。
b、查询引擎(X)：这是通用的查询工具，它从数据存储库为任何组件提供它需要的任何数据。编排器(U)依赖于它来获取电子钱包信息、商家信息、承运商信息、支付信息等。
c、MHT引擎(W)：这是内置有MHT逻辑的状态管理框架。编排器(U)依赖于这个引擎，以基于经由网关(BG)从电子钱包(B)接收的动作使用其PPR来管理PP状态。以这种方式，只要由PNS提供，就不要求电子钱包(B)在其系统内部构建MHT逻辑。电子钱包(B)不会在内部改变PP状态，除非它首先在引擎(W)中改变，然后发送回钱包(B)以改变PP状态并采取相应措施。

Claims (9)

1.一种支付网络系统[PNS]，用于电子商务的安全数字支付处理，特征在于，基于支付拆分策略[PSP]将数字支付金额自动拆分为下订单时支付和交付时支付；所述PNS特征还在于连接三方：参与处理所述支付的电子钱包(电子/数字钱包)、商家的系统和发货承运商的系统；PNS包括以下组件：
a.电子钱包网关，负责与所有电子钱包的所有交互，
b.商家网关，负责与所有商家的系统的所有交互，
c.承运商网关，负责与所有承运商的系统的所有交互，
d.支付编排器，用于管理所有支付处理工作流，经由组件(分别为a、b和c)与电子钱包、商家的系统和承运商的系统进行交互，
e.商家门户，用于支持商家建立/改变PSP业务规则，并指派承运商代表所述商家索要交付时支付，
f.PSP规则引擎，用于执行PSP业务规则，经由组件(e)构建，并决定PSP，
g.预支付引用[PPR]生成器，用于统一跨所有电子钱包生成的PPR的格式，
h.多重保留技术[MHT]引擎，用于根据MHT管理预支付[PP]的状态转变，
i.对账引擎，用于在电子钱包、PNS和商家的系统之间交叉检查记录的支付和转账金额，
j.查询引擎，用于其它PNS组件所需的任何查询执行。
2.如权利要求1所述的系统，其中组件“f”为每个PP决定PSP；所述PSP确定商家要求在下订单时支付的PP百分比或金额，以及商家要求在交付时支付的PP百分比或金额。
3.如权利要求1所述的系统，其中组件“g”为每个PP生成PPR；所述PPR是全局唯一标识符，其包含用于PP的完全合格电子地址；当支付人账户的控制系统通过确定所述支付的接收者而将支付金额保留时，支付被视为已准备好。
4.如权利要求1所述的系统，其中组件“h”根据MHT管理PP状态；所述MHT使多方能够在同一PP上独立地为每一方添加保留；在PP上添加多个保留为所述PP创建多重保留状态；在所述状态下，任何一方都能索要PP金额的全部/部分，MHT要求其它各方必须同意从索要的金额移除其保留，以便发放给索要方。
5.一种用于电子商务的安全数字支付处理的方法，其特征在于，基于支付拆分策略[PSP]将数字支付金额自动拆分为下订单时支付和交付时支付，包括以下步骤：
a.设置支付属性，其中客户使用电子钱包准备对于商家的支付以支付订单；所述客户设置用于所述支付的支付金额和收款商家，
b.准备支付，其中所述电子钱包创建预支付[PP]，生成预支付引用[PPR]，根据MHT在所述PP上添加客户保留[CH]，并向客户显示生成的PPR，然后所述客户将所述PPR提交给收款商家的系统，
c.决定PSP，其中所述商家的系统决定用于订单支付的PSP，
然后将决定的PSP与所述PPR一起发送到支付网络系统[PNS]，
d.向电子钱包发送PSP，其中所述PNS将从所述商家的系统接收的所述PPR和PSP转发回最初生成所述PPR的所述电子钱包，
e.确认PSP，其中所述电子钱包向所述客户通知确认接受所述PSP；一旦确认，所述电子钱包就根据MHT在所述PP上添加商家保留[MH]，
f.拆分PP，其中所述电子钱包基于客户对所述PSP的接受将所述PP拆分为下订单时支付和交付时支付，
g.收取下订单时支付，其中所述电子钱包基于所述客户接受、
根据MHT从所述下订单时支付中移除CH，然后所述电子钱包将所述下订单时支付转移到所述收款商家；所述转移实际上是经由所述PNS进行的，
h.发货订单，其中所述商家将货物交给交付代理以将其交付给所述客户，
i.交付订单，其中所述代理将货物交付给所述客户，
j.将交付通知给商家，其中所述代理向所述商家的系统发送交付单，
k.索要交付时支付，其中所述商家的系统将所述交付单连同所述PPR一起转发到所述PNS以收取所述交付时支付，
l.向电子钱包发送交付单，其中所述PNS将所述交付单连同所述PPR一起转发到所述电子钱包，
m.确认交付，其中所述电子钱包向所述客户通知确认订单接受；
一旦确认，电子钱包就根据MHT从所述交付时支付中移除CH，
n.收取交付时支付，其中所述电子钱包将所述交付时支付转移给所述商家；所述转移实际上是经由所述PNS进行的。
6.如权利要求5所述的方法，其中所述电子钱包向所述商家进行支付转移；所述转移实际上是经由所述PNS进行的，所述转移的流程包括以下步骤：
a.电子钱包将支付从客户账户转移到电子钱包中的PNS指定的账户；所述支付指定收款商家；所述电子钱包针对在PNS、
电子钱包和商家之间商定的统一的时间间隔在所述PNS指定的账户中汇总所有支付，直到所述间隔到期，
b.电子钱包将针对整个间隔支付的汇总的余额从所述PNS指定的账户转移到真实的PNS银行账户，
c.PNS根据针对每个商家的支付记录，将所述PNS银行账户中汇总的余额分发到商家在PNS中的账户，
d.PNS将所述商家在PNS中的账户中的余额转移到商家的真实银行账户。
7.如权利要求6所述的支付转移，其中正常的支付流程是从客户在电子钱包中的账户到商家，但如果所述客户决定退货，那么所述支付需要从所述商家退还到所述客户的账户；退款流程，特征在于即时记入所述客户的账户，包括以下按顺序的步骤：
a.商家向PNS发出退款，指示PPR和退款金额，
b.PNS记录接收到的退款，作为商家在PNS中的账户中的借记记录，
c.PNS向已发出所述PPR的电子钱包发出另一笔相同金额的退款，
d.电子钱包记录接收到的退款，作为指示商家的所述电子钱包中的PNS指定的账户中的借记记录，
e.电子钱包将所述退款金额记入拥有PPR的客户的账户，
f.电子钱包在扣除退款金额之后将所述PNS指定的账户中的汇总的净余额转移到PNS银行账户，这个步骤在当前时间间隔到期时进行，
g.PNS将所述余额分发到PNS中的商家的账户，然后在扣除退款金额之后将所述商家的账户中的净余额转移到商家的真实银行账户。
8.如权利要求5所述的方法，其中步骤“j”：交付代理向商家的系统发送交付单；如果所述代理是使用承运商的系统的承运商的代理，那么所述步骤能经由PNS进行，以将所述交付单发送到PNS，然后所述PNS将所述交付单转发到商家的系统。
9.如权利要求5所述的方法，其中电子钱包、商家的系统和承运商的系统这三方正在与PNS交互；所述各方必须在所述PNS中注册以被允许参与支付处理。
CN202180037688.9A 2021-11-16 2021-11-16 用于在下订单和交付之间进行安全数字支付拆分的方法和系统 Pending CN116472545A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2021/060613 WO2023089355A1 (en) 2021-11-16 2021-11-16 Method and system for secure digital payment split between on-order and on-delivery

Publications (1)

Publication Number Publication Date
CN116472545A true CN116472545A (zh) 2023-07-21

Family

ID=86396314

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180037688.9A Pending CN116472545A (zh) 2021-11-16 2021-11-16 用于在下订单和交付之间进行安全数字支付拆分的方法和系统

Country Status (2)

Country Link
CN (1) CN116472545A (zh)
WO (1) WO2023089355A1 (zh)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100010906A1 (en) * 2007-01-23 2010-01-14 William Grecia Point of sale payment method for multiple recipients using a digital payment service
SG193481A1 (en) * 2011-02-16 2013-10-30 Visa Int Service Ass Snap mobile payment apparatuses, methods and systems
AU2013206449A1 (en) * 2012-06-20 2014-01-16 Visa International Service Association Multi-channel remote payment apparatuses, methods and systems
US9082119B2 (en) * 2012-10-17 2015-07-14 Royal Bank of Canada. Virtualization and secure processing of data
KR20140100840A (ko) * 2013-02-07 2014-08-18 주식회사 케이티 그룹 결제 시스템 및 방법
SG10201706267UA (en) * 2017-08-01 2019-03-28 Mastercard International Inc Method, system, and device for processing digital payments via digital wallet upon delivery of item

Also Published As

Publication number Publication date
WO2023089355A1 (en) 2023-05-25

Similar Documents

Publication Publication Date Title
AU2003243516B2 (en) Value processing network and methods
JP6032617B2 (ja) クレジット提供システム及び方法
TWI522947B (zh) 結算業務支援系統及結算業務支援方法
US20120330744A1 (en) Real-Time Multi-Merchant Multi-Payer Multi-Bucket Open Loop Debit Card, Credit Card or Mobile Payment Device Value Tracking and Discount Processing Systems and Related Methods
AU2002340294B2 (en) Method and system for conducting a commercial transaction between a buyer and a seller
JP2005527046A (ja) 動的割引合意を備えた購入者と供給業者の間の電子決算を変更するシステム及び方法
JP2008511085A (ja) 自動化した支払い認証及び決済の方法及びシステム
WO2009058526A1 (en) System and method for processing multiple methods of payment
JP6815234B2 (ja) 汎用携帯端末を利用した決済システム
WO2019204123A1 (en) Method and system for pre-authorizing a delivery transaction
US20130297398A1 (en) Systems for and methods of establishing closed-loop business payment services
AU2002340294A1 (en) Method and system for conducting a commercial transaction between a buyer and a seller
CN112435019A (zh) 多业务平台通用结算方法、结算服务器、系统和存储介质
JP2001243400A (ja) 関連口座を用いた口座管理システム
US20020046162A1 (en) Method and system for managing accounts receivable and payable and recording medium for storing program to realize the method
CN116472545A (zh) 用于在下订单和交付之间进行安全数字支付拆分的方法和系统
KR20000037228A (ko) 전자상거래의 지불유보 시스템
JP2002189862A (ja) 決済装置及び方法
CN101595507A (zh) 支付处理系统债务转变通知
KR20190048153A (ko) 송금 기반 결제를 위한 에스크로 서비스 제공 방법 및 그를 수행하기 위한 서버
JP7389291B1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
WO2019221664A1 (en) Methods, systems, and devices for managing communication requests from a plurality of users
US20140379447A1 (en) Method and apparatus for streamlined offer processing
NZ564135A (en) Automated reconciliation of transaction records
KR20010096577A (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