WO2023089355A1 - Procédé et système pour une séparation de paiement numérique sécurisée entre « à la commande » et « à la livraison » - Google Patents

Procédé et système pour une séparation de paiement numérique sécurisée entre « à la commande » et « à la livraison » Download PDF

Info

Publication number
WO2023089355A1
WO2023089355A1 PCT/IB2021/060613 IB2021060613W WO2023089355A1 WO 2023089355 A1 WO2023089355 A1 WO 2023089355A1 IB 2021060613 W IB2021060613 W IB 2021060613W WO 2023089355 A1 WO2023089355 A1 WO 2023089355A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
merchant
pns
wallet
customer
Prior art date
Application number
PCT/IB2021/060613
Other languages
English (en)
Inventor
Ehab Mohamed Ibrahim EL-KERSH
Original Assignee
El Kersh Ehab Mohamed Ibrahim
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 El Kersh Ehab Mohamed Ibrahim filed Critical El Kersh Ehab Mohamed Ibrahim
Priority to US17/925,701 priority Critical patent/US20240220944A1/en
Priority to PCT/IB2021/060613 priority patent/WO2023089355A1/fr
Priority to CN202180037688.9A priority patent/CN116472545A/zh
Publication of WO2023089355A1 publication Critical patent/WO2023089355A1/fr

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/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • 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/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/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/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
    • 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
    • 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
    • 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]

Definitions

  • the present invention relates to the field of digital payments using e-wallets, cards, or any digital payment methods; and in particular, to method and system for processing digital payments for e- commerce online orders, upon order-placement and/or order-delivery, based on agreed payment policy.
  • a customer may opt for in order to purchase goods and services from an e-commerce merchant.
  • the customer may prepay the transaction amount online while placing the order, such that, a digital payment is made by the customer, via, one or more of credit card, debit card, a digital wallet, or a bank account. If delivered order is damaged or missing some items, customers suffer from problems in long processes for return and/or refund.
  • the customer may choose the 'cash on delivery' payment mode while placing the order.
  • the customer completes the transaction only after receiving the goods or services by paying in cash upon delivery.
  • the 'cash on delivery' payment mode is the preferred choice of most e- commerce customers, this payment mode causes multiple problems for the e-commerce merchants and the customers. Some of these problems include, cash handling cost, cash and order reconciliation hassles, delay in receipt of cash, losses incurred in cash management, and exact cash requirements from the customers, also merchants have shipment cost problems in case of customer returns the order without payment.
  • Figure 1 illustrates a digital payment processing method, based on a payment-split policy, according to certain embodiment of the present invention.
  • Figure 2 shows a flow diagram detailing the actual payment transfer from customer to merchant according to certain embodiment of the present invention.
  • Figure 3 shows a state-machine describing the digital payment hold management with multi-hold technique according to certain embodiment of the present invention.
  • Figure 4 depicts the payment network system that connects e-wallets, merchants, and carriers to implement the invention method according to certain embodiment of the present invention.
  • the problem addressed by the present invention is a complex problem that has characteristics from different, but related, perspectives.
  • the present invention solution method is based on Three Main Ideas hereunder:
  • This policy determines the percentage or the amount of money required by the merchant to be paid on-order (at order placement time), and the rest of percentage or amount that will be paid on-delivery of the order.
  • the PSP could be 10% -90% that means 10% of the total order value should be paid on-order and 90% will be collected on-delivery.
  • it can be by exact amount not percentage; like 10-90 if the order value is 100 USD, this means 10 USD will be paid on-order and 90 USD on-delivery.
  • the on-order split could be mentioned and the rest is deduced; this means if the merchant set the PSP to 10%, the method and system should automatically interpret it as 10% on-order and 90% on-delivery.
  • the merchant is free to decide different PSPs based on his own business rules/parameters like the product category, order value, customer segment, country, and so forth.
  • the PSP could be set one-time or determined per order; if both are provided, the latter will supersede.
  • Customer can pay using credit in his credit card account, money in a bank account, money in an e-wallet, loyalty points in a loyalty account, or any other type of account balance.
  • Any of said accounts has a controlling system, for example, if the customer payment account is a credit card account, so the controlling system is the card’s issuer-bank system. If the payment account is an e-wallet account, so the account controlling system is the e-wallet system, and so forth.
  • the PPR is a fully qualified reference for a Prepared-Payment [PP] ; in other words, it’s a global unique identifier that contains a full address for the PP.
  • a payment is considered prepared when the controlling system of the customer account puts the payment amount on-hold, and the receiver for this payment is determined. For example, if a customer wants to place an order of value 100 USD on a certain merchant website, and wants to use his money in an e-wallet to pay for this order, he should use the e-wallet to select the merchant as a receiver for the payment and set the amount to pay to 100 USD, so the e-wallet system will prepare the payment by holding said amount for said merchant and generate a unique reference for this PP.
  • Multi-Hold Technique [MHT] Multi-Hold Technique
  • the multi-hold is a new technique to manage how to hold a payment amount and how to release it between a number of parties.
  • the focus is on the PP hold and release between customer and merchant.
  • the PP when created, it has one hold that is customer-hold [CH] , so if the customer wants to cancel it before he gives its PPR to merchant, the hold will be removed and the amount will be available again to customer. If a PPR (with no cancellation) is given to merchant and that merchant sends it to the issuer system (e.g., e-wallet system), said system adds the second hold on the PP that is the merchant-hold [MH].
  • the issuer system e.g., e-wallet system
  • an e-wallet could integrate directly with several merchants and apply the PPR generation to give it to any of the merchants then apply the merchant’s PSP and the MHT to release the payment to the merchant at the end of the payment process.
  • Each e-wallet has to implement the whole solution with its merchant network, this could lead to having many different solutions with no responsible party to standardize or unify. This increases the cost on e-wallet systems, hence limits their reach to large number of merchants.
  • the preferred solution is to have a payment network that connects e-wallets to merchants and vice versa easily in a consistent way. What any e-wallet needs to do to reach to the whole network of merchants is to join this payment network and conform to its standards. Also, what any merchant needs to do to support all e-wallets is to join the same payment network and conform to its standards. Because many merchants deliver order shipments via delivery carriers, this network also supports having said carriers.
  • Figure 1 illustrates a payment scenario according to the preferred embodiment of the present invention
  • the method starts when a Customer (A) wants to checkout an order in the website or application of the Merchant (F).
  • the customer chooses the e-wallet payment method and selects the e-wallet he wants to pay with; said merchant must be one of Registered Merchants (H) in the Payment Network (G), and said e- wallet must be one of Registered E-Wallets (I) in same network.
  • Customer goes to his E-Wallet (B), determines (1) the merchant he wants to pay for, and the total order amount, then confirm.
  • E-Wallet (B) creates a Prepared Payment (C), applies the customer-hold on the PP, generates its PPR, and returns it to customer, then customer sends (2) said PPR to Merchant (F) via merchant’s application/website.
  • Merchant (F) decides the payment-split policy based on his business rules, then sends (3) both PPR and PSP to Payment Network (G) Payment Network (G) forwards (4) said PPR and PSP back to E-Wallet (B).
  • PPR as described before is a fully qualified reference for the PP including the e-wallet identifier so the payment network can determine the issuer e-wallet and forward the PPR to it.
  • E-Wallet (B) notifies Customer (A) to confirm his acceptance for the merchant’s PSP.
  • E-Wallet (B) splits (6) the PP (C) based on the PSP into on-Order Payment (D) and on-Delivery Payment (E).
  • E-Wallet (B) removes customer-hold from the on-Order Payment (D) based on customer acceptance for PSP, then transfers (7) the on-Order Payment (D) to Merchant (F). Said transfer actually takes place via the Payment Network (G) as described later in details.
  • Merchant (F) executes the order shipment process, and gives (8) the shipment to the Carrier’s Agent (K) to deliver it to Customer (A). Agent (K) delivers (9) the shipment to Customer (A).
  • Agent (K) sends (10) an order delivery note to Merchant (F). Said delivery note could be sent via a merchant’s application, or carrier’s application that integrates with merchant’s system. Alternatively, Agent (K) can send the delivery note directly to Payment Network (G), then said network forwards the note to merchant.
  • G Payment Network
  • the advantage of the alternative scenario is that in case the carrier delivers shipments on behalf of many merchants, it’s better to integrate only with the network instead of integrating with all said merchants. In this case, said carrier should be one of the Registered Carriers (J) in the Payment Network (G) to be able to integrate with said network.
  • Merchant (F) forwards (11) the delivery note along with the order’s PPR to Payment Network (G) to collect the on-Delivery Payment (E).
  • Payment Network (G) forwards (12) the delivery note along with the PPR to customer’s E- Wallet (B) to collect the merchant’s on-Delivery Payment (E).
  • E-Wallet (B) notifies Customer (A) to confirm his acceptance for the order shipment.
  • customer confirms (13) the e-wallet removes customer-hold from the on-Delivery Payment (E).
  • E-Wallet (B) transfers (14) the on-Delivery Payment (E) to Merchant (F). Said transfer actually takes place via the Payment Network (G) as described hereunder.
  • Payment Transfer Flow is described hereunder.
  • Figure 2 illustrates a typical flow for money transfer from customer to merchant via payment network:
  • E-Wallet (B) that contains/controls Customer Account (L), transfers (1) a part of PP (C) to an E-Wallet Account (N) that is designated for Payment Network (G). Any e-wallet registered in the payment network must create an internal account for said network.
  • the PP-transferred payment-part can be the on-Order (D) or the on-Delivery (E); the transfer flow is the same for both cases.
  • E-Wallet (B) transfers required payment to Account (N) by creating a credit record into said account specifying the PPR, the payment amount, and the Merchant ID (M). All e- wallets in the network continue to do this kind of transfers for all payments for all merchants for a specified time interval, for example one full day, before said e-wallets perform the second step.
  • E-Wallet (B) transfers (2) the aggregate balance for the whole day from Account (N) to the Network Aggregate Account (O); this transfer is areal money transfer from the financial system of the E-Wallet (B) to the financial system of the Payment Network (G).
  • Network Aggregate Account (O) receives the daily payment transfers from all registered e-wallets to forward them to their target registered merchants; this means that said account (O) contains the whole network payments for one day.
  • Payment Network (G) has an internal Merchant Account (P) for each Registered Merchant Record (R). Payment Network (G) groups the whole daily payments per merchant, then transfers (3) each group of payments to its Merchant Account (P).
  • Payment Network (G) transfers (4) the total amount of the daily merchant’s payments in the network-internal Merchant Account (P) from the network financial system to the Real Merchant Account (Q) in the financial system of the Merchant (F).
  • P network-internal Merchant Account
  • Q Real Merchant Account
  • F financial system of the Merchant
  • Figures 1 and 2 illustrate the normal scenario where the customer accepts the whole order shipment. There are some other cases like, the order is totally wrong, or some order items are missing or damaged. In all these cases, customer rejects the merchant’s request to claim the on-delivery payment. The payment network notifies the merchant about customer rejection, so merchant can contact the customer and handle the issue according to a certain process that differs from merchant to merchant and it’s out of scope of the present invention.
  • the merchant After reaching an agreement with the customer, the merchant takes an action on the payment network to apply the agreed settlement with customer. Merchant actions differ based on the situation as follows; assuming that collected on-order payment is 100 USD and the remaining on-delivery payment is 400:
  • FIG. 3 illustrates all claim cases according to the Multi Hold Technique [MHT] as follows:
  • System automatically releases (4) the payment to merchant (method step 14) and moves it to state (S4) Released-to-Merchant.
  • merchant should send claim with zero amount or percentage to the payment network (method step 11), so the system removes (5) MH from the payment, moves it from (S2) back to state (SO) CH, then notify the customer, so customer can cancel it anytime to get his money released according to point 1.
  • the system automatically releases (7) merchant part to merchant (method step 14) and moves it from (S21) to state (S4) Released-to-Merchant.
  • the system automatically releases (8) customer part to customer and moves it from (S22) to state (SI) Released-to-Customer.
  • the solution can be implemented using digital currency accounts on a blockchain platform, so transfers can be performed instantly for each payment. Based on that, refund in such implementation can follow same flow in figure 2 but in opposite direction:
  • the payment network can get its detailed information including the issuer e- wallet, then issue a transfer from network account to e-wallet account (e-wallet account is part of any registered e-wallet record).
  • Said issuer e-wallet internally transfer the refund amount it received to the account of the customer owning that PPR.
  • the refund scenario can be as follows (referencing figure 2):
  • the Payment Network (G) records said refund order as a debit record in the Merchant’s Account (P) within the network. Then said network issues a refund order with the same amount to the E-Wallet (B) that issued said PPR (no transfer here also).
  • the e-wallet records said refund order as a debit record in the Network’s Account (N) within the e-wallet system, indicating the Merchant ID (M). Then said e-wallet credits the PPR-owning Customer Account (C) by the refund amount. This way, once the merchant issues the refund, the customer receives the amount immediately.
  • the e-wallet transfers (2) the daily net balance to Network Aggregate Account (O).
  • the net balance equals the total payments amount of the day minus the refund debit amount.
  • Payment Network (G) transfers (3) total merchant’s payments of said day to his Account (P), then transfers (4) the net balance of Account (P) to Real Merchant Account (Q).
  • Account (P) net balance equals the total merchant’s payments amount minus the refund debit amount.
  • the solution of the present invention balances between merchant need to trust the payment, and customer need to trust the delivery, using the MHT applied by a third party (the combination of e-wallet/payment-network). This combination is not a customer party or a merchant party; it’s a fair third party. In case of dispute, the MHT encourages both merchant and customer to reach an agreement because without such agreement, the payment will go to neither of them.
  • PPR does not contain any information regarding customer account or card, it’s a reference for a prepared payment to a specific destined merchant. So, nobody can manipulate it; even if sniffed or hacked, the hacker has no way to use it to get money. If customer has a bank account and uses the e-wallet of that bank, he doesn’t need a card or PayPal wallet or anything else to perform a 100% secure payment without sharing account information with any party; if the e-wallet of customer bank registered in the payment network, customer can pay to any merchant in the same network using PPR generated from his bank e-wallet.
  • Decoupled connectivity the payment network connects any registered e-wallet to any registered merchant while applying full decoupling; e-wallets don’t depend on merchants and merchants don’t depend on e-wallets. Merchants and e-wallets depend only on the payment network. Payment network and e-wallets don’t have to know any order details (in prior solutions like PayPal, the e-wallet depends on merchants to get the order information).
  • the present invention solution enables any e-wallet (not only the few global ones) to pay securely for any merchant without the need for a virtual card that is not fully secure.
  • the payment network in addition to connecting merchants and e-wallets in a decoupled way, the payment network connects delivery carriers to merchants in a decoupled way. If a carrier system is already coupled with a merchant system, said network can support this scenario also, as described in the Method step 10 that carrier can send delivery note to the network or to merchant directly.
  • Customer Experience a. customer can see the hold in his account, no money movement to another account for merchant or third-party, until the payment gets collected after his acceptance. b. At delivery time, customer can postpone delivery confirmation till he checks all order items; delivery agent doesn’t have to wait, he can send the delivery note and move. c. Customer can use the same payment method consistently for other types of payment: i. If merchant does not mandate to get PPR at order placement time, customer can generate it on-delivery and share it with carrier agent to send it, on behalf of merchant, to the payment network to claim the payment. PPR can be shared to agent as number to insert in agent’s application or as a QR code to scan it. ii. In store, customer can generate PPR and share it with the merchant’s cashier application also as number or QR code, so said application send it to the payment network to claim the payment.
  • a flag for “instant full payment” can be added to bypass payment split and delivery confirmation.
  • FIG. 4 illustrates the Payment Network System [PNS] (G) components and integrations that facilitate carrying out the present invention method.
  • PPS Payment Network System
  • PNS integrates three types of systems; e-wallet systems, merchant systems, and carrier systems. PNS provides a gateway for interaction with each type of systems and a set of core system components to support/serve said gateways as follows:
  • E- Wallet Gateway this is the system component responsible for all communication with all e-wallets including the e-wallet registration in PNS and all interactions during payment and refund scenarios. This component depends on E- Wallet (B) and other PNS components: a. Payment Orchestrator (U): this is the main system component that manages workflows for all payment and refund scenarios; the gateway (BG) depends on it during said scenarios; for example, when notifying PNS about customer delivery confirmation. b. Query Engine (X): this is a generic query tool that provides any component with any data it needs from the datastore. The gateway (BG) depends on it to get the list of registered merchants to display to customer to select one for payment preparation. c.
  • Reconciliation Engine this is the component responsible for cross checking the recorded payments versus transferred amounts. It gets notified by e-wallets after daily transfer to start cross checking. In case of any inconsistency, it notifies the e-wallet back to resolve the issue.
  • PPR Generator this is a centralized component responsible for unifying the format of generated PPR across all registered e-wallets; therefore, e-wallets depend on it to get a PPR during payment preparation. Alternatively, e-wallets can generate PPRs based on agreed format without referring to said centralized component.
  • Carrier Gateway this is the system component responsible for all communication with all carriers; including the carrier registration in PNS, and receiving the delivery notification during the payment scenario; said notification gets sent by an Agent (K) via the Carrier System (T).
  • This component depends on another PNS component: a.
  • Payment Orchestrator (U) this is the main system component that manages the workflow for all payment and refund scenarios; the gateway (TG) depends on it for handling the on-delivery payment collection based on the delivery notification.
  • Merchant Gateway this is the system component responsible for all communication with all merchants including the merchant registration in PNS and all system-to-system (i.e., PNS- to-merchant system) interactions during payment and refund scenarios. This component depends on Merchant (F) and other PNS components: a.
  • Payment Orchestrator (U) this is the main system component that manages the workflow for all payment and refund scenarios; the gateway (FG) depends on it during said scenarios; for example, to collect on-order and on-delivery payments for merchant.
  • Query Engine (X) this is a generic query tool that provides any component with any data it needs from the datastore. The gateway (FG) depends on it to get the list of registered e-wallets to display to customer to select one to pay with.
  • Reconciliation Engine (Y) this is for cross checking the recorded payments versus transferred amounts. It notifies merchants after daily transfer to start cross checking. In case of any inconsistency, it gets notified back by merchant to resolve the issue.
  • Merchant Portal this is a system visual component to support Merchant (F) for reporting on and monitoring payments, setting PSP business rules, assigning carriers to claim on-delivery payments on behalf of said merchant, etc. This component depends on other PNS components: a. Payment Orchestrator (U): this is the main system component that manages the workflow for all payment and refund scenarios; the portal (FP) depends on it; for example, to assign the carriers allowed to claim on-delivery payments on behalf of merchant (F). b. Query Engine (X): this is a generic query tool that provides any component with any data it needs from the datastore. The portal (FP) depends on it to get the list of payments, the list of registered carriers, etc. c.
  • Payment Orchestrator U
  • Query Engine X
  • PSP Rule-Engine this is a generic optional rule engine that supports merchants to build their business rules that help them to decide different PSPs in different cases based on certain attributes. Merchants can use rules in their internal systems, use this optional engine, or use both.
  • Payment Orchestrator (U) this is the main system component that manages the workflow for all payment and refund scenarios. It depends on the gateways to interact with the three parties (e-wallets, merchants, and carriers). It also depends on other PNS components: a.
  • PSP Rule-Engine (Z) this is a generic rule engine that supports merchants to build their business rules that help them to decide PSPs.
  • the orchestrator (U) depends on it in case the merchant did not send a PSP, that means said engine should be used to decide PSP.
  • Query Engine (X) this is a generic query tool that provides any component with any data it needs from the datastore. The orchestrator (U) depends on it to get e-wallet information, merchant information, carrier information, payment information, etc.
  • MHT Engine (W) this is a state management framework that has the MHT logic built- in. Orchestrator (U) depends on this engine to manage PP state using its PPR based on the actions received from E-Wallet (B) via the gateway (BG). This way, E-Wallet (B) is not required to build MHT logic inside its system as long as it is provided by the PNS. E-Wallet (B) does not change a PP state internally unless it gets changed in the engine (W) first then sent back to wallet (B) to change the PP state and act accordingly.

Landscapes

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

Abstract

La présente invention concerne le domaine des paiements numériques utilisant des portefeuilles électroniques, des cartes, ou tout procédé de paiement numérique ; et en particulier, des paiements en ligne de commerce électronique. Dans le domaine du commerce électronique, les clients préfèrent un paiement complet à la livraison après la vérification de la marchandise livrée ; cela présente un risque pour les marchands. À l'inverse, les marchands préfèrent traiter le paiement complet à la commande avant l'expédition de la marchandise ; cela présente un risque pour les clients. Les deux options de paiement complet à la commande ou de paiement complet à la livraison ne sont ni satisfaisantes ni équitables pour les deux parties (clients et marchands). La présente invention présente une solution pour avoir un procédé de paiement qui peut automatiquement diviser le montant de paiement, sur la base d'une politique de partage de paiement que le marchand propose et que le client accepte, pour permettre à des marchands d'obtenir une partie du paiement à la commande, puis de réclamer le reste du paiement à la livraison.
PCT/IB2021/060613 2021-11-16 2021-11-16 Procédé et système pour une séparation de paiement numérique sécurisée entre « à la commande » et « à la livraison » WO2023089355A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US17/925,701 US20240220944A1 (en) 2021-11-16 2021-11-16 Method and system for secure digital payment split between on-order and on-delivery
PCT/IB2021/060613 WO2023089355A1 (fr) 2021-11-16 2021-11-16 Procédé et système pour une séparation de paiement numérique sécurisée entre « à la commande » et « à la livraison »
CN202180037688.9A CN116472545A (zh) 2021-11-16 2021-11-16 用于在下订单和交付之间进行安全数字支付拆分的方法和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2021/060613 WO2023089355A1 (fr) 2021-11-16 2021-11-16 Procédé et système pour une séparation de paiement numérique sécurisée entre « à la commande » et « à la livraison »

Publications (1)

Publication Number Publication Date
WO2023089355A1 true WO2023089355A1 (fr) 2023-05-25

Family

ID=86396314

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2021/060613 WO2023089355A1 (fr) 2021-11-16 2021-11-16 Procédé et système pour une séparation de paiement numérique sécurisée entre « à la commande » et « à la livraison »

Country Status (3)

Country Link
US (1) US20240220944A1 (fr)
CN (1) CN116472545A (fr)
WO (1) WO2023089355A1 (fr)

Citations (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
US20120209749A1 (en) * 2011-02-16 2012-08-16 Ayman Hammad Snap mobile payment apparatuses, methods and systems
US20130346302A1 (en) * 2012-06-20 2013-12-26 Visa International Service Association Remote Portal Bill Payment Platform Apparatuses, Methods and Systems
US20140108263A1 (en) * 2012-10-17 2014-04-17 Royal Bank Of Canada Virtualization and secure processing of data
US20140222663A1 (en) * 2013-02-07 2014-08-07 Kt Corporation Group payment
US20190043042A1 (en) * 2017-08-01 2019-02-07 Mastercard International Incorporated Method, system, and device for processing digital payments via digital wallet upon delivery of item

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10706380B2 (en) * 2014-05-08 2020-07-07 Visa International Service Association Split shipment processing

Patent Citations (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
US20120209749A1 (en) * 2011-02-16 2012-08-16 Ayman Hammad Snap mobile payment apparatuses, methods and systems
US20130346302A1 (en) * 2012-06-20 2013-12-26 Visa International Service Association Remote Portal Bill Payment Platform Apparatuses, Methods and Systems
US20140108263A1 (en) * 2012-10-17 2014-04-17 Royal Bank Of Canada Virtualization and secure processing of data
US20140222663A1 (en) * 2013-02-07 2014-08-07 Kt Corporation Group payment
US20190043042A1 (en) * 2017-08-01 2019-02-07 Mastercard International Incorporated Method, system, and device for processing digital payments via digital wallet upon delivery of item

Also Published As

Publication number Publication date
CN116472545A (zh) 2023-07-21
US20240220944A1 (en) 2024-07-04

Similar Documents

Publication Publication Date Title
US11455623B1 (en) Buyer routing arrangements and methods for disparate network systems
US20180315102A1 (en) Value processing network and methods
US12093906B1 (en) Profile based arrangements and methods for disparate network systems
US10546287B2 (en) Closed system processing connection
US9147184B2 (en) Control system arrangements and methods for disparate network systems
KR101662579B1 (ko) 시스템 내 가입자에게 크레딧을 제공하는 방법 및 시스템
US11748726B1 (en) Disparate network systems and methods
US20080021821A1 (en) System and method for reconciling credit card payments with corresponding transactions
US20090144165A1 (en) Seller Routing Arrangements and Methods for Disparate Network Systems
WO2008113093A9 (fr) Système de transactions de paiement
WO2013166204A1 (fr) Systèmes et procédés permettant de saisir et d'analyser les avantages dans les transactions commerciales
CN112997208A (zh) 购买管理系统和方法
US20020046162A1 (en) Method and system for managing accounts receivable and payable and recording medium for storing program to realize the method
US20240220944A1 (en) Method and system for secure digital payment split between on-order and on-delivery
KR20190048153A (ko) 송금 기반 결제를 위한 에스크로 서비스 제공 방법 및 그를 수행하기 위한 서버
US20210334800A1 (en) Methods, systems, and devices for managing communication requests from a plurality of users
JP7389291B1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
US20240185195A1 (en) Method for real-time transfer of funds between customer and seller including generating accounting entries
US20140379447A1 (en) Method and apparatus for streamlined offer processing
JP2002007920A (ja) 課金処理システム及び課金処理方法
KR20170064037A (ko) 공급망 관리에서의 매매보호 결제 시스템
CN116362736A (zh) 经营性支付方法、装置及系统
KR20180112634A (ko) 금융서비스 제공 방법 및 장치, 그리고 이에 적용되는 컴퓨터 프로그램 및 기록매체
JP2001250060A (ja) 電子商取引システム
KR20090006423A (ko) 복지 포인트 결제가 가능한 전자결제 시스템

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 202180037688.9

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 17925701

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21964659

Country of ref document: EP

Kind code of ref document: A1