WO2019043550A1 - Système et procédé d'exécution d'une transaction financière - Google Patents

Système et procédé d'exécution d'une transaction financière Download PDF

Info

Publication number
WO2019043550A1
WO2019043550A1 PCT/IB2018/056483 IB2018056483W WO2019043550A1 WO 2019043550 A1 WO2019043550 A1 WO 2019043550A1 IB 2018056483 W IB2018056483 W IB 2018056483W WO 2019043550 A1 WO2019043550 A1 WO 2019043550A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
payment request
micro
account
control arrangement
Prior art date
Application number
PCT/IB2018/056483
Other languages
English (en)
Inventor
Louw Johann HOPLEY
Original Assignee
Fireid Inc
BEHARIE, Tertia
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 Fireid Inc, BEHARIE, Tertia filed Critical Fireid Inc
Publication of WO2019043550A1 publication Critical patent/WO2019043550A1/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/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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/356—Aspects of software for card 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/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
    • G06Q20/401—Transaction verification
    • G06Q20/4012—Verifying personal identification numbers [PIN]
    • 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
    • G06Q20/403—Solvency checks
    • G06Q20/4037—Remote solvency checks
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20—Automatic teller machines [ATMs]
    • G07F19/206—Software aspects at ATMs

Definitions

  • THIS invention relates to a system and method for handling/attending to a payment instruction, as well as to a method for performing/facilitating a financial transaction.
  • a system for handling/attending to a payment request to pay a particular entity wherein the system includes:
  • a communication module which is configured to receive a payment request from/on behalf of a client to pay the particular entity
  • micro-service control arrangement which is configured to retrieve a client-customised computer program for the particular client and execute it.
  • the system may include a transaction module which is configured to send information on the payment request to the micro-service control arrangement.
  • the micro-service control arrangement may be configured to retrieve the client-customised computer program for the particular client and execute it in an environment which is isolated from the transaction module.
  • the system may therefore be for handling/attending to a payment request to pay a particular entity, wherein the system includes:
  • a communication module which is configured to receive a payment request from/on behalf of a client to pay the particular entity
  • a transaction module which is configured to send information on the payment request to the micro-service control arrangement
  • micro-service control arrangement is configured to retrieve a client-customised computer program for the particular client and execute it in an environment which is isolated from the transaction module.
  • a system for performing/facilitating a financial transaction wherein the system includes:
  • a communication module which is configured to receive a payment request from/on behalf of a client to pay the particular entity
  • micro-service control arrangement which is configured to retrieve a client-customised computer program for the particular client and execute it.
  • the system may include a transaction module which is configured to send information on the payment request to the micro-service control arrangement.
  • the micro-service control arrangement may be configured to retrieve the client-customised computer program for the particular client and execute it in an environment which is isolated from the transaction module.
  • the system may therefore be for performing/facilitating a financial transaction, wherein the system includes: a communication module which is configured to receive a payment request from/on behalf of a client to pay a particular entity;
  • a transaction module which is configured to send information on the payment request to the micro-service control arrangement
  • micro-service control arrangement is configured to retrieve a client-customised computer program for the particular client and execute it in an environment which is isolated from the transaction module.
  • a “module”, in the context of the specification, includes an identifiable portion of code, computational or executable instructions, or a computational object to achieve a particular function, operation, processing, or procedure.
  • a module may be implemented in software, hardware or a combination of software and hardware. Furthermore, modules need not necessarily be consolidated into one device.
  • the micro-service control arrangement may be configured to retrieve the client-customised computer program for the particular client from a database.
  • the database may form part of the system.
  • a plurality of client-customised computer programs may be stored on the database. Each of the plurality of client-customised computer programs may refer to, or be associated with a specific client.
  • the micro-service control arrangement may be configured, by executing the client-customised computer program, to determine whether to accept or decline the payment request based on one or more custom rules which were created/added by the client, and send an indication of the decision to the transaction module.
  • the transaction module may be configured to receive the indication to proceed or decline with the payment request from the micro-service control arrangement;
  • the micro-service control arrangement may include a controller.
  • Each client-customised computer program may include one or more rules, preferably payment rules.
  • the communication module may be configured to receive the payment request via a communication network, preferably from a computing/payment terminal.
  • the first account may be the client's account.
  • the first and/or second accounts may be bank accounts.
  • the payment request may be received from a bankcard terminal.
  • the payment request may be a bankcard payment request.
  • the system may therefore refer to a system for attending to a bankcard payment request.
  • the information on the payment request may include information on the client (e.g. a client identifier/identification code) and/or a payment amount.
  • the client-customised computer program may be provided in a secure sandbox environment.
  • the micro-service control arrangement may be configured to provide a micro-service architecture within a secure sandbox environment.
  • the micro-service control arrangement may be configured to allow a client to change/add rule(s) which is/are specifically relevant to an account which is associated with the client (i.e. his/her account, e.g. the first account), which is then incorporated into the client-customised computer program for the particular client.
  • the micro-service control arrangement may be configured to:
  • the system may include a client interface via which a client can log into the system and change/add rule(s) which are specifically relevant to the account which is associated with the client (e.g. the first account), which is then incorporated into the client-customised computer program for the particular client (i.e. his/her specific computer program can be customised).
  • the micro-service control arrangement may therefore be configured to incorporate the changes/additions to the rule(s), instructed via the client interface, into the client-customised computer program for the particular client.
  • the transaction module may be a transaction processing module.
  • a method of handling/attending to a payment request or performing/facilitating a financial transaction includes: receiving a payment request from, or on behalf of, a client to pay a particular entity;
  • the execution step may more specifically include executing the client-customised computer program in an isolated environment.
  • the method may include determining whether to accept or decline the payment request based on one or more custom rules provided/included in the client-customised computer program.
  • the method may further include sending an indication of the decision to a transaction module/transaction facilitation module.
  • the method may then include, at the transaction module, either
  • the first account may be the client's account.
  • the first and second accounts may be bank accounts.
  • the client-customised computer program may be executable by a processor/controller, preferably by a processor of the micro-service control arrangement.
  • the information on the payment request may include information on the client (e.g. a client identifier/identification code) and/or a payment amount.
  • the client-customised computer program may be provided in a secure sandbox environment.
  • the micro-service control arrangement may be configured to provide a micro-service architecture within a secure sandbox environment.
  • the micro-service control arrangement may be configured to allow a client to change/add rule(s) to his specific client-customised computer program.
  • the method may include allowing a client to edit one or more rules which relate to payments from an account which is associated with the client (e.g. the first account), within a secure sandbox environment. More specifically, the method includes receiving instructions on one or more rules from a client for his specific client-customised computer program via a client portal.
  • a method of controlling/regulating at least part of a financial transaction wherein the method includes:
  • a system for facilitating a financial transaction includes: a communication module which is configured to receive a payment request from a client to pay a particular entity;
  • an identification module which is configured to determine whether an amount of the payment, or at least part thereof, is sponsored by a third party, and is so transferring the payment amount, or at least part thereof, from an account of the third party to either an account of the client or the entity.
  • the transfer should be made to the client, i.e. the client's account.
  • the system may include a transaction module/transaction facilitation module which is configured, after the payment amount or part thereof has been transferred into the client's account, to proceed to pay the entity from the client's account.
  • a method for facilitating a financial transaction includes: receiving a payment request from a client to pay a particular entity; determining whether an amount of the payment, or at least part thereof, is sponsored by a third party, and if so transferring the payment amount, or at least part thereof, from an account of the third party to either an account of the client or the entity.
  • the transfer should be made to the client, i.e. the client's account.
  • the method may then include, after the payment amount or part thereof has been transferred into the client's account, proceeding with the payment to the entity from the client's account.
  • Figure 1 shows a schematic layout of a system in accordance with the invention
  • Figure 2 shows an illustrative example of when a client/customer uses the system of Figure 1 to inform him/her of his weekly expense on coffee purchases;
  • Figure 3 shows a simplified, schematic flow diagram of the operation of the system of Figure 1 ;
  • Figure 4 shows a flow diagram of the operation of the system of
  • Figure 5 shows a schematic layout of a micro-service architecture which forms part of the system of Figure 1 ;
  • Figures 6 shows a screenshot of an interface with two custom solutions built by an end user/client.
  • Figure 7 shows a flow diagram of the operation of the system, when a sponsor pays on behalf of a client.
  • the present invention generally relates to a system which allows a particular bankcard of a client (i.e. the bankcard holder) to be linked to a unique client-customised computer program which implements certain rules and behaviour/purchase-related actions.
  • the term "bankcard” should be interpreted to include any payment card, whether it be a physical or virtual card, and includes debit cards, credit cards, cheque cards and gift cards.
  • These client-customised computer programs are customised by the clients themselves and are executed during a financial transaction in a secure, isolated environment. In other words, the client-customised computer programs of the clients are executed in an environment which is isolated from a transaction/transaction processing module of a payment processing system of a bank or a card processor (e.g. stripe).
  • reference numeral 10 refers generally to a system in accordance with the invention.
  • the system 10 includes a central transaction server/processor 12 which is configured to facilitate the processing of financial transactions.
  • the server 12 includes a transaction module.
  • the server 12 is typically implemented by a bank or card transaction processor and includes a database 14 on which details of various clients/customers are saved. The details include, for example, the name, unique identity number/code and one or more bank account numbers which are associated with each customer/client. The balances of each bank account are also saved on the database 14.
  • the system 10 can include various different banks which can communicate with each other over a communication network 105.
  • the system 10 further includes a secure sandbox architecture/environment 16 within which various custom-built/made computer programs can be executed for clients. More specifically, the sandbox environment includes a micro-service control arrangement/controller 18 and a database 20 on which a customised computer program for each client is stored.
  • the system 10 is configured to allow clients 100 of the bank to log into the system 10 by using a computing terminal, such as computer 102 or smart device 104, via a communication network 105 (e.g. the Internet).
  • a computing terminal such as computer 102 or smart device 104
  • the system 10 typically allows each client 100 to create a customised computer program with rules and other activity/behaviour related instructions within the secure sandbox environment 16.
  • the rules may dictate that the transaction only be allowed to proceed in certain predetermined scenarios, which adds an extra layer of security for the clients' financial dealings.
  • the rules can, for example, relate to a maximum expenditure on certain items or at certain stores (e.g. a maximum amount of coffee purchased on a monthly basis or the maximum amount of money spent in a specific store on a monthly basis).
  • the system 10 includes a portal 40 via which clients 100 can gain access to the system 10 and create their customised computer programs.
  • the portal 40 typically includes a server/processor 42 which is configured to provide a user interface for each client 100 which can log into the system with suitable login information (e.g. by using a web browser).
  • the login process is typically similar to standard logging procedures (e.g. used in current banking systems) and will therefore not be described in greater detail.
  • the user interface typically provides an integrated development environment (IDE) where source code from the programs can be created and edited.
  • IDE integrated development environment
  • Figure 6 shows two customised solutions for a client wherein the one declines all fast-food transactions and the other sends a weekly spend summary after each transaction.
  • Each client-customised computer program is typically stored on the database 20.
  • the server 12 when a purchasing request is received from/via another party/entity, such as a merchant 200, then the server 12, before proceeding with the financial transaction, send details of the transaction to the micro- service control arrangement/controller 18.
  • the details may include identification information of the specific client, transaction amount, the type of goods/services being purchased and the store at which it is being purchased.
  • the micro-service control arrangement/controller 18 then identifies the client-customised computer program of the particular client (which was created by the client) and designates a specific micro-instance environment 120.1 -120.3 (hereinafter collectively referred to as 120) within which the client-customised computer program can be executed (see also Figure 5).
  • This micro-instance environment 120.1 -120.3 is secure and isolated from the server 12.
  • Each micro-instance environment 120 typically includes a processor 130.1 - 130.3 which is configured to execute the client-customised computer program by utilising the transaction details received from the server 12. It will therefore be appreciated that the client-customised computer programs are executed in a sandboxed environment which helps for security purposes and to maintain fast execution time and scalability.
  • a client/cardholder 100 can use his bankcard to pay for a specific product (or service) at a merchant 200 at a pay point/card terminal 101 .
  • a card reader 103 at the terminal typically initiates the transaction by capturing details of the card, as well as a PIN code which is entered by the client 100 (see reference numeral 140).
  • An authorisation request which includes transaction details (e.g.
  • bank 300 which is associated with the merchant 200 (also referred to as the "acquiring bank”).
  • bank 300 then forwards the request to a bank 400 which is associated with the particular client 100 (also referred to as the "issuing bank”).
  • the server of the issuing bank then identifies the particular client 100 (e.g. based on details saved on a database) and checks the PIN (see block 142). If the PIN is invalid, then the transaction request is declined. If, however, the PIN is correct, then details of the authorisation request is sent to the micro-service control arrangement/controller 18 of the bank 400, which is provided within a secure sandbox environment 16. These details typically include identification information of the client 100, the payment amount, the merchant and the types of goods or services purchased. The controller 16 then retrieves an associated custom program of the client 100 (e.g. created by the client himself) and executes it in a secure micro- instance environment 120 (see block 144), e.g. by using a separate processor for the execution.
  • an associated custom program of the client 100 e.g. created by the client himself
  • a secure micro- instance environment 120 see block 144
  • the custom program can typically include certain rules which need to be complied with before the transaction request is authorised.
  • the program may instruct certain purchase related behaviour to be captured (e.g. purchasing behaviour) and reported to the client on a regular basis (e.g. each time a particular purchase is made or on a weekly/monthly basis).
  • the program may indicate that each time when coffee is purchased, that an SMS message be sent to a cell phone of the client 100 in order to indicate his/her weekly coffee spend.
  • the example shown in Figure 2 reference is made to the example shown in Figure 2.
  • rules are included in the custom program, then that part of the computer program (also referred to as the "pre-transaction program") is typically executed before sending a response (e.g. approving or declining the transaction) back to issuing bank 400. If the rules are complied with, and when the transaction is completed by the custom program, an update on the completion of the transaction is sent to the card terminal (see block 146). If the rules are not complied with, then the decision to decline the transaction is also communicated to the card terminal.
  • a response e.g. approving or declining the transaction
  • the custom program includes a part which indicates that certain purchase related behaviour should be communicated to the client 100, then that part of the programme (also referred to as the "after-transaction program") is executed after completion of the transaction (see block 148). For example, if a client purchased coffee and the custom program indicated that a summary of all coffee purchased during the last week should be communicated to the client 100, then the program will typically save updated information on the latest purchase on the database 20 and initiate a process by which an SMS is sent to the cell phone of the client 100 with the relevant details.
  • the program may therefore, for example, be configured to record certain relevant purchases in order to provide an updated report to clients, e.g. by SMS or email).
  • the system 10 can be configured to enable another entity (i.e. a so-called "sponsor") to pay for the particular financial transaction on behalf of the client 100.
  • the system 10 can be used as a type of "sponsored-purchase system” which allows a cardholder's transaction to be sponsored by another party in real time.
  • the program for implementing this aspect typically includes appropriate software for transferring the transaction amount or a portion/percentage thereof, from a bank account of the sponsoring party into the bank account of the cardholder, before a transaction is successfully completed.
  • the cardholder 100 will typically insert his bankcard into a bankcard terminal (see block 500).
  • the terminal checks that the card is valid (see block 502) and requests a PIN from the cardholder 100 (see block 504). Once the PIN has been entered by the cardholder 100, then the validity of the pin is checked (see block 506). This may be done on the bankcard terminal itself or the details can be sent to the bank of the cardholder 100 for checking. If invalid, then the transaction is declined (see block 508).
  • a designated program is executed in an isolated, secure environment 16, in order to check whether or not a sponsoring party should sponsor the purchase (see block 510). If not, then the transaction server of the bank checks whether or not the cardholder 100 has sufficient funds for the transaction (see block 516) and then either approves or declines the transaction (see blocks 508 and 518). If the program however determines that the purchase (or at least part thereof) should be paid by a sponsor, then the relevant funds are transferred from the bank account of the sponsor into the bank account of the cardholder 100 (see block 512). Once transferred, then the transaction server of the bank again checks whether or not there are sufficient funds in the account of the cardholder 100 and either decline or approve the transaction.
  • an after transaction program can typically also be implemented in a similar manner as mentioned earlier (see block 520).
  • the Inventor believes that by allowing clients/customers to create/customise their own computer programs in a secure, isolated environment, which are executed during a financial transaction, it provides an extra layer of security (if certain purchase rules are added) and can provide a user with useful and up-to-date information on their own purchasing trends (e.g. the amount spent on coffee on a weekly basis).
  • the system also allows third parties to sponsor certain payments on behalf of clients. This sponsored payment process is implemented in a secure and efficient manner. This can be particularly useful when, for example, someone wants to pay on behalf of a friend.

Abstract

L'invention concerne un système de gestion de/d'assistance à une demande de paiement pour payer une entité particulière. Le système comprend un module de communication qui est configuré pour recevoir une demande de paiement en provenance/au nom d'un client pour payer l'entité particulière. Le système comprend également un agencement de commande de micro-service qui est configuré pour extraire un programme informatique personnalisé par client pour le client particulier et pour l'exécuter. Le système comprend en outre un module de transaction qui est configuré pour envoyer des informations sur la demande de paiement à l'agencement de commande de micro-service. L'agencement de commande de micro-service peut être configuré pour exécuter le programme informatique personnalisé par client dans un environnement qui est isolé du module de transaction. L'environnement peut être un environnement de bac à sable sécurisé.
PCT/IB2018/056483 2017-08-28 2018-08-27 Système et procédé d'exécution d'une transaction financière WO2019043550A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201762550870P 2017-08-28 2017-08-28
US62/550,870 2017-08-28

Publications (1)

Publication Number Publication Date
WO2019043550A1 true WO2019043550A1 (fr) 2019-03-07

Family

ID=65525054

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2018/056483 WO2019043550A1 (fr) 2017-08-28 2018-08-27 Système et procédé d'exécution d'une transaction financière

Country Status (1)

Country Link
WO (1) WO2019043550A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113592471A (zh) * 2021-07-29 2021-11-02 中国人民银行清算总中心 支付交易应用系统及方法
CN113628028A (zh) * 2021-08-06 2021-11-09 上海浦东发展银行股份有限公司 一种基于微服务架构的批量清算系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080034231A1 (en) * 1995-02-13 2008-02-07 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US20090200012A1 (en) * 2008-02-11 2009-08-13 Davis John P Downhole Debris Catcher and Associated Mill
US20140040117A1 (en) * 2007-09-12 2014-02-06 Devicefidelity, Inc. Executing transactions secured user credentials
US20140074637A1 (en) * 2012-09-11 2014-03-13 Visa International Service Association Cloud-based virtual wallet nfc apparatuses, methods and systems
US20150310423A1 (en) * 2007-10-31 2015-10-29 Mastercard Mobile Transactions Solutions, Inc. Multi-domain mobile ecosystem tokenized transaction wrapper

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080034231A1 (en) * 1995-02-13 2008-02-07 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US20140040117A1 (en) * 2007-09-12 2014-02-06 Devicefidelity, Inc. Executing transactions secured user credentials
US20150310423A1 (en) * 2007-10-31 2015-10-29 Mastercard Mobile Transactions Solutions, Inc. Multi-domain mobile ecosystem tokenized transaction wrapper
US20090200012A1 (en) * 2008-02-11 2009-08-13 Davis John P Downhole Debris Catcher and Associated Mill
US20140074637A1 (en) * 2012-09-11 2014-03-13 Visa International Service Association Cloud-based virtual wallet nfc apparatuses, methods and systems

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113592471A (zh) * 2021-07-29 2021-11-02 中国人民银行清算总中心 支付交易应用系统及方法
CN113628028A (zh) * 2021-08-06 2021-11-09 上海浦东发展银行股份有限公司 一种基于微服务架构的批量清算系统
CN113628028B (zh) * 2021-08-06 2024-01-23 上海浦东发展银行股份有限公司 一种基于微服务架构的批量清算系统

Similar Documents

Publication Publication Date Title
US11694200B2 (en) Secure account creation
US10740843B2 (en) Systems and methods for controlling payment processing
US8589297B2 (en) Prepaid value account with reversion to purchaser systems and methods
US8762275B2 (en) Systems and methods providing multiple account holder functionality
US11475436B2 (en) System and method for providing a security code
AU2013221323B2 (en) System and method of registering stored-value cards into electronic wallets
US20200065783A1 (en) Multiple card payment process
AU2021261960A1 (en) System and method for providing a security code
US20180276656A1 (en) Instant issuance of virtual payment account card to digital wallet
US11715154B2 (en) Systems and methods for managing accounts in a financial services system
US11461770B2 (en) Active application of secondary transaction instrument tokens for transaction processing systems
US20210103910A1 (en) Multiple settlement options in payment system
US20190095922A1 (en) Cooperative fraud-detection processing
WO2019043550A1 (fr) Système et procédé d'exécution d'une transaction financière
US10140658B1 (en) Commodity backed virtual currency method and system for network transactions
CA3228058A1 (fr) Systeme et methode de recharge de cartes prepayees
US11176524B1 (en) Math based currency credit card
US20200394633A1 (en) A transaction processing system and method
US20200265414A1 (en) Methods, systems and computer program products for split payment card account transactions
US20190220848A1 (en) Linked Data Structures
WO2023140920A1 (fr) Traitement parallèle dans un réseau
TW202032455A (zh) 運用電子支付用戶之餘額的系統及方法

Legal Events

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

Ref document number: 18851485

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18851485

Country of ref document: EP

Kind code of ref document: A1