Credit-based installment fee electronic payment network system and method

Abstract

Techniques are described for executing electronic transactions using a split fee payment service. The techniques include using currency-based credits, which are also provided as commissions to introducers of the payer and previous payees of the payer. The techniques may include one or more of the payment service providing a payment application on a user device of a user, opening a financial account on behalf of the user with a financial institution affiliated with the payment service, transferring funds from a funding source of the user to the financial account, associating a user profile of the user with credits equivalent to the balance of the financial account, receiving transaction data for the transaction, determining a payee fee for the transaction, transferring currency or credits equivalent to the transaction amount from the payer to the payee, and dividing the payee fee among at least the payment service, the referring user, and the previous payee, and distributing the currency or credits accordingly.

Description

Technical Field

[0002]

[0001] This PCT application claims the priority of U.S. Provisional Patent Application No. 63 / 168,228, filed on March 30, 2021, which is incorporated herein by reference.

Background Art

[0002] Conventionally, credit card transactions and debit card transactions have been costly for merchants. The cost can be a combination of interchange fees, assessment fees, service fees, and the markup of payment processors. In these conventional systems, the merchant bears the cost of the convenience that customers can enjoy by paying with a payment card.

[0003] Conventionally, the merchant fee in a payment card transaction is a fixed fee plus a certain percentage of the transaction amount, and often amounts to about 2% of the transaction amount in total. There are many elements in the merchant fee, which can be paid to various entities necessary for payment processing and settlement. The largest portion of the merchant fee is often the interchange fee paid to the issuer of the customer's payment card and the assessment fee paid to the payment card network. Often, a certain percentage is also paid to the payment processor. Therefore, conventionally, processing a payment card transaction required the participation of multiple entities beyond the merchant and the customer and the payment of multiple fees.

[0004] Furthermore, digital settlement can be performed using peer-to-peer technology, and in many cases, the cost per transaction for the recipient is lower than that of a payment card transaction. However, in conventional peer-to-peer payment processors, the total amount that a single user can pay (or be paid) within a certain period is limited. Furthermore, in conventional peer-to-peer systems, it may take several days for funds to be transferred to the recipient's bank account. Therefore, digital settlement has been an inappropriate solution for many transactions.

[0005] There is a need to minimize the costs incurred by recipients in accepting payments, the number of entities involved in processing transactions, the time it takes for funds to move from payer to recipient, the number of fund transfers, and the overall processing resources required. There is also a need to encourage participation in electronic payment systems. [Brief explanation of the drawing]

[0006] Refer to the attached drawings for further details. The use of the same reference number in different drawings indicates similar or identical items or features.

[0007] [Figure 1] Figure 1 shows an exemplary system for performing split-fee transactions within a community settlement network, as described herein. [Figure 2] Figure 2 is a flowchart illustrating an exemplary process for registering a new user in a community payment network, as described herein. [Figure 3A] Figure 3A is a flowchart illustrating an exemplary process for executing a split-fee transaction in a community payment network, as described herein. [Figure 3B] Figure 3B is a flowchart illustrating an exemplary process for executing a split-fee transaction in a community payment network, as described herein. [Figure 4] Figure 4 is a flowchart illustrating an exemplary process for determining recipient fees and commissions for settlement transactions, as described herein. [Figure 5] Figure 5 shows a block diagram of selected components of a payment service server device as described herein. [Figure 6] Figure 6 shows a block diagram of selected components of a user device as described herein. [Modes for carrying out the invention]

[0008] The technologies described herein apply, at least in part, to community payment networks that use currency-backed credits. In the technologies described herein, recipient fees may be divided and distributed among multiple entities (e.g., the payment service, the user who referred the payer to the community payment network, the bank, the charity, the payer, and one or more recipients in the payer's most recent network transactions prior to the transaction in which the recipient fee is paid). Recipients who accept payments through a community payment network using the technologies described herein pay a recipient fee to the payment service, and a portion of the fee may be paid by the payment service as a commission to other entities, which may include other users of the community payment network, such as referring users and previous recipients. In various examples, other entities may also include, or instead include, one or more financial institutions and / or one or more nonprofit organizations.

[0009] The technology described herein enables more efficient electronic payment transactions by reducing the number of participants and the number of communications. The unique configurations of the devices and applications implemented with the technology described herein provide enhanced efficiency in electronic payment processing. Instead of a payment processor that must communicate with the card network and issuer for each transaction, users of the payment network of the present application can pre-fund a financial account associated with the payment service, and the credit can be adjusted as the user engages in the transaction. Furthermore, recipient fees can be lower than in conventional electronic transactions, at least in part, due to the simplification of such processes and systems.

[0010] Furthermore, the technologies described herein retain the fees that would otherwise be paid to credit card issuers and card networks, and distribute them to payment network users and / or other entities, which may include individuals, small and medium-sized enterprises, etc.

[0011] Paying commissions to referral users and previous recipients provides an incentive to recruit members and accept payments in the form of a payment network. In this way, membership in a community payment network can grow exponentially or virally. Additionally or alternatively, an incentive to join a community payment network is the lower recipient fees compared to those traditionally charged for credit card transactions or other electronic transactions.

[0012] In some examples, a “payment service” is a payment service entity that handles payments or other money transfers, including authenticating payment information for a transaction, approving transactions, initiating the transfer of value between the parties to a transaction, and paying commissions to referring users and previous recipients. In some examples, a payment service may also provide other services such as inventory management, loyalty program management, discount distribution, expense analysis, and / or tracking.

[0013] In some examples, “User” is a member of a community payment network that uses the community payment network to receive or provide payments to other members of the community payment network. A user may be an end user of a community payment network application (“Payment Application”) provided by a payment service. For the purposes of this description, “Member” and “User” are used interchangeably. Depending on the transaction, a user may be a payer or a payee. As used herein, “Payer” is a user who provides payment in a transaction. As used herein, “Payee” is a user who receives payment in a transaction. A user may be a payer in some transactions and a payee in others. In some examples, a merchant may be a payee when the merchant is receiving payment in a transaction. For the purposes of this description, “Merchant” may be any entity that provides an item (e.g., goods or services) for acquisition (e.g., sale, lease, free, etc.). In some examples, a transaction may be a peer-to-peer transaction in which the payee is not a merchant but a member of a community payment network who is an individual receiving funds from another individual in their capacity. For example, payments can be made for loans, private sales, or other peer-to-peer transactions.

[0014] In some cases, a user's “referring user” or “referrer” is another member of the community payment network who referred the user to register with the community payment network. In some cases, referring users and referrers may be identified by the payment service using data submitted in connection with the user’s registration request. For example, an invitation from a first member to a second member may take the form of a code (e.g., a QR code®, alphanumeric code, etc.) containing data representing the first member’s identifier. This data may be sent to the payment service when the second member includes the code in their request to register with the community payment network. In other cases, referring users may be manually identified by the user as part of the registration process. Furthermore, a user does not need to have a referring user to become part of a community payment network. For example, a user can learn about a community payment network on their own and register without being referred.

[0015] In some cases, the "previous payee" is the payee to whom the payer entered a transaction immediately before the ongoing transaction. In other words, the payee of the payer's most recent historical transaction is called the "previous payee."

[0016] In some examples, a “recipient fee” is a fee charged to a recipient by a payment service for conducting a transaction through a community payment network. In other words, a recipient fee is the cost to the recipient for receiving a payment through a community payment network. Recipient fees can be a set amount, a percentage of the total transaction amount, or a combination of a set amount and a percentage. For example, a recipient fee could be 1% of the transaction amount (maximum fee). Recipient fees may be set by agreement between the payment service and the recipient when the recipient registers. Recipient fees may vary by a particular recipient, a particular payer, the location of the transaction, the merchant category of the recipient or payer, the date of the transaction, the transaction history of at least one of the payer or recipient, and so on. A particular recipient’s recipient fee may depend on a particular transaction, and the recipient fee of a first recipient may not be the same as the recipient fee of a second recipient in a transaction that is otherwise equivalent. In the example, the recipient fee may be paid by credit, and in the example, the recipient fee may be paid in currency.

[0017] In some examples, a “community payment network” is a group of individuals and / or entities participating in a payment system in which credit is used instead of currency in transactions and a split commission agreement exists that divides the recipient fee among at least the payer’s referring user, the previous merchant, and the payment service managing the community payment network. A portion of the recipient fee may also be allocated to one or more of the following: financial institutions, non-profit organizations, or other charitable organizations. The term “community payment network” is used interchangeably with “payment network” herein.

[0018] In some instances, “bank account” is used interchangeably with “financial account” and refers to a financial account of a financial institution. In some instances, “financial institution” may include, but is not limited to, one or more of the following: commercial banks, retail banks, internet banks, credit unions, savings and loan associations, or intermediary companies.

[0019] In some examples, the “funding source” is a repository of resources associated with the user. In some examples, the funding source may be the user’s deposit or savings account at a financial institution. In some examples, the funding source may be the user’s cryptocurrency account. The funding source may also be, additionally or alternatively, the user’s credit or debit card. The funding source may further be gold or other tangible assets owned by the member. In some examples, the funding source may be used as the user’s source of funds to supply funds to a PSAB financial account. In some examples, a “payment-service-affiliated bank financial account,” i.e., a PSAB financial account, is a financial account at a financial institution selected by the payment service, corresponding to a master account maintained by the payment service at that bank. A PSAB financial account can be separate from the funding source and can be opened in association with a user registered in the community payment network. Funds from the funding source can be transferred to a PSAB financial account, and vice versa. In some examples, such transfers may be carried out using ACH payments or other mechanisms.

[0020] In some examples, a "user profile" is a collection of data associated with a user's membership in a community payments network. User profiles may be stored in data stores associated with the payment service and / or storage devices associated with the payment service server equipment. For example, a user profile may include information about the user's identifier, source of funds, PSAB financial account, transaction history, referring users, referrals made by the user, credit balance, etc. The stored data is encrypted and stored on a secure server that can protect personally identifiable information, details about financial accounts, source of funds, etc.

[0021] In some examples, a "credit" is a unit within a community payment network for representing value. In an example, one credit may be equivalent to 1 USD, 100 USD, 1000 USD, or any other dollar amount. In an example where one credit corresponds to 1 USD, in a transaction where a payer obtains goods or services valued at 100 USD from a payee, the payment service subtracts 100 credits from the payer's credit balance, and the payment service can distribute the 100 credits to the payee, the payment service, the referring user, a previous payee, or other persons according to the examples of the methods and systems described herein.

[0022] The techniques described herein are often described as occurring in a merchant-customer context where the merchant is the payee and the customer is the payer. However, the techniques described herein can also be applied in other contexts. That is, the techniques described herein are not limited to retail merchants, customers, etc., and can also be applied to other contexts such as peer-to-peer (P2P) money transfers, loans, invoice settlements, etc.

[0023] The technologies described herein can offer many advantages and improvements over conventional technologies. Many of these improvements are technical advancements to computer capabilities or other types of technologies. For example, multiple intermediate financial transfers can be avoided by providing payments via credit transfers within a community payment network. That is, by using credits, which are a digital substitute for currency, it is not necessary to transfer funds between financial institutions (e.g., issuer, acquirer, merchant, customer, etc.) after every transaction. Instead, a user's credit balance can be maintained. The credit balance can be represented by data in a database associated with the payment service. A transaction may simply involve a data update (representing a change in the credit balance) performed by a single entity (the payment service). If the user wishes to "cash out" (e.g., convert credits to currency), the user's credit balance is converted to currency. A transfer is made from the user's PSAB financial account to the user's original source of funds (e.g., personal checking account, savings account, etc.) or to another account. However, the user may be involved in multiple transactions in which credits, rather than currency, are transferred before cashing out. Traditionally, payment transactions have involved credit or debit to multiple accounts (such as the issuer, the merchant's bank, and the money processor).

[0024] In the technology described in this specification, individual transactions within the payment network do not require "settlement" in the traditional sense, so due to the nature of the community payment network, transactions can be integrated. Furthermore, commission payments can be accumulated without the user having to take any action, and credits do not need to be cashed until they are requested. Eliminating issues, eliminating complex merchant fees, enabling simple commissions, and eliminating or reducing the need for interbank communication bring benefits to the efficiency, memory, and processing on the payment service device, and eliminate the need for other entities such as card issuance, card networks, and their devices. At least in these ways, the technology is improved. Furthermore, there can be benefits for users, such as reducing transaction fees, reducing bank transactions, and lacking an upper limit on the payment amount. Furthermore, the community payment network enables merchants and individuals to participate equally. In an example, a merchant user and an individual user can pay the same recipient fee, receive the same conversion factor, and obtain the same commission when acting as a referral user or "previous recipient". Furthermore, the payment service can withhold value from commission payments to pay as tax on the amount that can be obtained based on the country where the transaction is conducted. In some examples, the tax can be paid directly to a government agency. Furthermore, the value from commission payments can be withheld by the payment service and distributed by the payment service to other entities such as charities and non-profit organizations at the user's choice or designation.

[0025] At least for the above reasons, the technology described in this specification and the system implemented with the technology described in this specification are not conforming, non-ordinary, and non-general, and bring improvements to related technologies.

[0026] References to “embodiments” in this specification are not intended to limit the elements described to a single embodiment, but rather all elements described can be combined in any number of ways in any embodiment. For the purposes of interpreting this specification, use of “or” in this specification means “and / or” unless otherwise specified. Use of “a” or “an” in this specification means “one or more” unless otherwise specified. Use of “constitutes” and “includes” in this specification is interchangeable and not intended to be limiting. Unless otherwise specified, use of terms such as “first,” “second,” “third,” “above,” and “below” does not indicate spatial, sequential, or hierarchical order or importance, but is used to distinguish one element from another. Use of the terms “and / or” and “at least one” should be understood to mean, for example, “A and / or B” and “at least one of A and B,” that this includes the selection of only the first option (A), or only the second option (B), or both options (A and B). As a further example, in the cases of "A, B and / or C" and "at least one of A, B and C," such wording is intended to include the selection of only the first-listed option (A), or only the second-listed option (B), or only the third-listed option (C), or only the first and second-listed options (A and B), or only the first and third-listed options (A and C), or only the second and third-listed options (B and C), or the selection of all three options (A, B, and C). This can be extended to the number of items listed, as will be readily apparent to those skilled in the art in this and related fields.

[0027] It will be understood by those skilled in the art that any block diagram, step, or subprocess in this specification may represent a conceptual diagram of an exemplary system embodying the principles of this subject. Similarly, flowcharts, flow diagrams, state transition diagrams, pseudocode, etc., which are substantially represented in computer-readable media, will be understood to represent various processes that may be performed by a computer or processor, whether such a computer or processor is explicitly indicated or not. The order in which the methods are described is not intended to be construed as a restriction, and any number of the described method blocks may be deleted, moved, added, subdivided, combined, and / or modified in any order to implement a method, alternative combination, or subcombination. While steps, subprocesses, or blocks may be shown to be executed sequentially, some steps, subprocesses, or blocks may instead be executed in parallel or at different times, as will be recognized by those skilled in the art. The specific numbers given herein are merely examples, and different values ​​or ranges may be used in different implementations. These methods can be implemented with any suitable hardware, software, firmware, or combination thereof.

[0028] Figure 1 shows an exemplary system 100 for performing split commission transactions within a community settlement network as described herein. System 100 includes settlement service server devices 102(1) to 102(N), user devices 104(1) to 104(N) (including seller user device 104(1) and buyer user device 104(2), and other user devices 104(3) to 104(N)), seller bank server devices 106(1) to 106(N), buyer bank server devices 108(1) to 108(N), other users bank server devices 110(1) to 110(N), and settlement service-associated bank (PSAB) server devices 112(1) to 112(N). Server devices may also be referred to herein as “servers”. The devices of system 100 communicate with each other via networks 114(1) to 114(N) (for example, the Internet, cable networks, cellular networks, wireless networks (e.g., Wi-Fi), and wired networks, as well as short-range communication technologies such as Bluetooth® and Bluetooth Low Energy).

[0029] While a single seller user device 104(1) and a buyer user device 104(2) are shown, in additional or alternative examples, system 100 may have multiple seller devices 104(1) and buyer devices 104(2). Furthermore, each of the multiple users of the settlement service may be associated with a bank, and system 100 may include multiple user bank server devices (plural) (106(1) to 106(N), 108(1) to 108(N), 110(1) to 110(N)) for the multiple users. Furthermore, for the sake of simplification of reference, components throughout this disclosure may be referred to in the singular form in relation to a single generalized reference number. For example, user devices 104(1) to 104(N) (i.e., plural) may be referred to as user device 104 (i.e., singular). Nevertheless, it should be understood that the use of the singular form may include the plural form in certain embodiments.

[0030] One or more of the payment service server device 102, user device 104, seller's bank server device 106, buyer's bank server device 108, other user's bank server device 110, and PSAB server device 112 may include any type of computer device that is commonly configured to perform operations. For example, one or more of the payment service server device 102, user device 104, seller's bank server device 106, buyer's bank server device 108, other user's bank server device 110, and PSAB server device 112 may be implemented as a laptop computer, desktop computer, server, smartphone, electronic reader device, mobile handset, personal digital assistant (PDA), portable navigation device, portable game device, tablet computer, watch, portable media player, television, set-top box, in-car computer system, home appliance, camera, robot, hologram system, home computer system (e.g., intercom system, home media system, etc.), projector, ATM, computing glasses, etc.

[0031] The payment service associated with the payment service server devices 102(1) to 102(N) can constitute an online payment service that processes payments for multiple users. The payment service server devices 102(1) to 102(N) can expose a network-based application programming interface (API) through which the payment service provides services to multiple users via user devices 104(1) to 104(N). For the purposes of this description, the payment service and / or the payment service server devices 102(1) to 102(N) may be any number of servers, entities, platforms, service providers, service provider networks, etc. The payment service may maintain a website, platform, database, etc., accessible by users via user devices 104(1) to 104(N). In some embodiments, the payment service may provide users with a variety of network-based (or "cloud-based") services to meet their computing needs. In some embodiments, the payment service may operate a payment service network that includes clusters of managed servers (or other hardware-based computing devices) stored in data centers located across different geographical areas. The payment service server devices 102(1) to 102(N) are described further below in the explanation in Figure 5.

[0032] The user devices 104(1) to 104(N) may be point-of-sale (POS) devices and may run payment applications that may be provided by the payment service server devices 102(1) to 102(N) to perform activities associated with the payment network. The user devices 104(1) to 104(N) are described further below in the description of Figure 5.

[0033] The seller's bank server devices 106(1) to 106(N) and the buyer's bank server devices 108(1) to 108(N) may be associated with banks or other financial institutions where the seller and buyer each have financial accounts.

[0034] The seller's bank server devices 106(1) to 106(N) and the buyer's bank server devices 108(1) to 108(N) can be associated with banks or other financial institutions where the seller and buyer each have financial accounts. The PSAB server devices 112(1) to 112(N) maintain PSAB financial accounts for users of the community payment network. The payment service can maintain a master account in the PSAB to which a user's financial account can be associated. The payment service server devices 102(1) to 102(N) can cause the PSAB server devices 112(1) to 112(N) to open a PSAB financial account for a user when the user registers with the community payment network. The payment service server devices 102(1) to 102(N) can provide PSAB banking information about the user (e.g., name, social security number, address, citizenship, etc.) which can be obtained through the registration process or through queries to the user, in order to open a PSAB financial account on behalf of the user. In this example, an alternative financial institution to the PSAB can be used (for example, if the user is not eligible to open a U.S. bank account).

[0035] In some embodiments, PSAB devices 112(1) to 112(N) are not included in System 100. In such embodiments, users may use their own sources of funds (e.g., financial accounts held at their own financial institutions (e.g., 106(1) to 106(N), 108(1) to 108(N), or 110(1) to 110(N))) as financial backing for credits used in the community settlement network.

[0036] At least some additional components and functions of the devices in the exemplary system 100, as well as the interactions between the devices, are described below (with respect to at least Figures 4 and 5).

[0037] Figure 2 is a flowchart illustrating an exemplary process 200 for registering a new user in a community payment network, as described herein.

[0038] Block 202 illustrates receiving a request from a user to register with a community payment network. The payment service server device can receive requests from user devices via web forms, email, direct messages, application notifications, etc. In the example, the request may include, or be associated with, referencing user information. Referencing user information identifies an existing member of the payment network who referred the user to the payment service. Referral user information can be embedded as data in the registration request. In the example, the user may scan a QR code presented by a merchant user or activate a URL provided by a merchant that directs the user to the registration interface. In one example, scanning a QR code using a user device may launch a browser window on the user device, from which the payment service server device can retrieve the registration information entered by the user. In the example, for a user to qualify as a referred user in the payment network, the referred person must register within a threshold time of the user providing the referred person with the QR code or URL. For example, the payment service may timestamp the QR code when it is generated and compare that timestamp to the first contact of the registering user with the payment service. Additionally or alternatively, a user may provide a code to a registered user. If a registered user provides a code to the payment service during registration, the user who provided the code to the registered user will be recognized as a referring user by the payment service. Additionally or alternatively, referring user information may be obtained by the payment service server device separately from the registration request. The referring user identifier may be stored by the payment service associated with the user's new user profile, or it may be stored in a data store associated with the payment service server device.

[0039] In the example, a user can register at the time of a transaction with a referring user. Transaction data, registration link, and the referring user's identifier can be obtained by the user's device (for example, by scanning a QR code presented to the user by the merchant via the merchant device). In the example, a user can register before performing any transaction on the community payment network. In one example, the user's device can scan a QR code displayed by the merchant device or posted at the merchant's location, and as a result, the merchant associated with the merchant device can be qualified as a referring user even though no transaction has yet occurred. In another example, a user can register by visiting the community payment network's webpage without being directly referred, and as a result, the commission from the user's transaction is split in a maximum of two ways (payment network, previous merchant) rather than three or more ways (e.g., payment network, previous merchant, referring user). In the first transaction within the payment network by a user with a user profile that does not have a referring user associated, there is no previous merchant or referring user, so the payment network retains the full recipient fee (or equivalent credit). Once a user is registered, they can perform transactions within the payment network.

[0040] As part of the registration process, the payment service server may request identification information regarding the user's source of funds. The source of funds (e.g., a current account) can be used to fund the user's PSAB financial account or to provide direct support for credits exchanged within the community payment network. Credits are backed by US dollars or another currency, cryptocurrency, or other value mechanism. Credits for different users are backed by different currencies or value mechanisms.

[0041] Block 204 illustrates sending a request to a PSAB server device to open a PSAB financial account for a user on behalf of the user. A bank may be selected to become a PSAB by a payment service, and the payment service may maintain a master or umbrella account in the PSAB for all accounts opened for users of the payment service. The payment service may store an association between a user's new PSAB financial account in the community payment network and the user's user profile. An association between a user's source of funds and their user profile may also be stored, thereby enabling the determination of a user's PSAB financial account and source of funds given the user's identifier. In some examples, the payment service or PSAB communicates with the user after initial registration (via email, direct message, application notification, etc.) to obtain additional information from the user in order to open a PSAB financial account (e.g., to obtain direct authorization from the user to open a PSAB financial account). In some examples, a PSAB financial account is not opened, but instead, transfers are made directly between the recipient's and payer's sources of funds (e.g., checking accounts), or between one user's source of funds and a second user's PSAB financial account. In cases where a user does not use or own a PSAB financial account, the user may agree that their source of funds may be deducted to add credit to the user's credit balance associated with their user profile. The user may also agree that if their credit balance falls below a minimum threshold, additional funds may be transferred to the payment service to increase the credit associated with them. If the user wishes to "cash out," the funds may be transferred from the payment service to the user's source of funds. Similarly, in cases where a PSAB financial account exists, the user may agree to the automatic replenishment of the PSAB financial account from their source of funds if the PSAB financial account balance falls below a minimum threshold.

[0042] Block 206 illustrates the transfer of funds from a user's source of funds to the user's PSAB financial account, thereby initial funding the user's PSAB financial account. For example, a payment service can initiate an ACH transfer between a source of funds and a PSAB financial account. In some examples, the user authorizes a specific amount for the transfer via input into a payment application running on the user's device, direct message, email, web form entry, etc. In some examples, the payment service can propose an amount for the transfer or require a minimum amount as initial funding for the PSAB financial account. The user can authorize an automatic transfer from a source of funds to a PSAB financial account. In the example, the automatic transfer occurs when the PSAB financial account balance falls below a minimum threshold amount.

[0043] Block 208 indicates the determination of the number of credits equivalent to the PSAB financial account balance. As explained below, the credit-to-currency conversion factor can be used to determine how much credit is equivalent to a given amount of currency, and to determine the amount of currency equivalent to a number of credits (for example, when "cashing out" credits, as explained below).

[0044] Block 210 indicates that the determined number of credits is associated with the user's user profile as the user's credit balance.

[0045] Users can "cash out" their credits at any time. In the example, to do so, the user submits a request to the payment service. The request may include the amount of credit the user wishes to cash out and may identify the account to which the funds need to be transferred. The identified account may be the source of funds that originally provided the funds to the PSAB financial account, or it may be another payment method. In response to receiving the request, the payment service transfers the funds from the PSAB financial account to the identified account (or alternative payment type). The amount of credit that can be cashed out may be limited by the minimum credit balance that must be maintained as part of the terms of the community payments network. However, if a user attempts to deregister from the community payments network, all credits can be cashed out. In the example, when the user deregisters, a full cashout occurs automatically.

[0046] If a transaction causes a user's credit balance to fall below the equivalent amount in their PSAB financial account (for example, if a user executes a transaction that causes their credit balance to fall below the equivalent of $10 in their PSAB financial account), the settlement service may request authorization for the transfer from the user's source of funds (e.g., via an ACH transfer). Alternatively, if the user profile allows automatic top-up of the PSAB financial account, authorization is not required. For example, with a 1:1 credit-to-dollar conversion rate, a $100 balance in the user's PSAB financial account, a $50 pending transaction, and a minimum balance of $75 in the PSAB financial account, the settlement service may trigger a transfer of $25 at or around the time of the transaction.

[0047] Figures 3A and 3B are flowcharts illustrating an exemplary process 300 for conducting a split commission transaction within a community settlement network, as described herein.

[0048] Block 302 indicates receiving transaction data from a payment application running on a user device for pending transactions between a payer and a recipient in a payment network. In the example, transaction data from a payment application running on the payer's user device (e.g., the buyer's user device 104(2)) for transactions between the payer and the recipient may be received by the payment service. In the example, transaction data may be received by the payment service from a POS device. In the example, the payer may be a customer of the recipient, who may be a merchant. Transaction data may include conventional information (e.g., transaction amount, transaction location, items or services purchased, merchant identifier, etc.). Transaction data may also include a payer identifier, which in some examples may be added to conventional transaction data by a specific instance of the payment application running on the payer's user device. Transaction data may be obtained from the recipient's user device or via manual entry, etc., by an instance of the payment application running on the payer's user device. Alternatively, transaction data may be received from an instance of the payment application running on the recipient's user device (e.g., the seller's user device 104(1)) for transactions between the payer and the recipient. In one example, the recipient's user device obtains and adds a payer identifier through manual input by the payer or recipient (for example, by entering a phone number on the user interface of the recipient's user device, or by scanning the identifier with the image capture component of the recipient's user device so that the identifier is displayed on the payer's user device's display).

[0049] In some examples, transaction data may be generated in the first instance by a point-of-sale (POS) application separate from the payment application. In some examples, transaction data may be generated in the first instance by a POS device that can be communicatively coupled to the recipient's user device. In the example, the recipient's user device may be a POS device.

[0050] A payment service server device may display one or more user interfaces on a user device via a payment application running on the user device. One or more user interfaces may enable the user to initiate the transfer of funds between financial accounts associated with the user's user profile, to indicate an intention to purchase or transfer value to another user, to indicate an intention to accept value (e.g., credit) transferred from another user to the user, to check credit balances, to modify user profiles, to review transaction history, to search transaction history, to search for participating users in a community payment network (e.g., by name, location, or other criteria), to view conversion factors, to determine exchange rates between different currencies, to communicate with other users or payment services, to participate in social networks provided by payment services, and to display controls that enable the user to initiate scanning of a barcode, QR code, or other graphic that may represent transaction data for a pending transaction, or may include an identifier for another user into which the user wishes to enter into a transaction.

[0051] Block 304 indicates that the user profiles of the payer and payee are identified, at least in part, based on the transaction data. As described above, the settlement service server device can receive transaction data in any of the various ways described above with respect to Block 302. The transaction data may include payer and payee identifiers. The settlement service server device may map the payer identifier to the payer's user profile and the payee identifier to the payee's user profile, and the user profiles may be stored by the settlement service.

[0052] Block 306 indicates that the recipient fee associated with a transaction is determined at least in part based on the transaction data and the terms and conditions between the recipient and the payment service. In some examples, the recipient fee can be calculated as a percentage of the transaction amount (e.g., 0.5%, 1.0%, 1.5%). For example, if a payer purchases shoes for $50.00 from a recipient and the seller agrees to a recipient fee of 1.0%, the recipient fee is $0.50. Agreement on the recipient fee can be made during user registration, and the recipient fee may be adjusted by the payment service with the user's consent. In some examples, the recipient fee can be calculated as a fixed fee plus a percentage of the transaction amount. For example, in the above example with a transaction amount of $50, if the recipient fee is 1.0% plus $1.00, the recipient fee would be $1.50. In some examples, there is an upper limit on the total recipient fee (e.g., $10.00, $15.00, $20.00).

[0053] Block 308 indicates that the payer determines the previous recipient to whom the payer made a payment in the most recent historical transaction made on the settlement network. Determining the most recent recipient may be based on transaction records stored by the settlement service server device. In the example, the settlement service server device and the user device may be connected via the network to a storage device (not shown) that stores transaction records, user profiles, etc. Additionally or alternatively, the storage device may reside locally with respect to the settlement service server device, the user device, or both. In certain embodiments, the storage device may include one or a combination of computer-readable media. The settlement service server device analyzes the payer's purchase history, at least in part, based on the payer's user profile, and determines the recipient identifier in the transaction made by the payer immediately preceding the pending transaction.

[0054] Block 310 indicates that the identifier of the referring user who initially introduced the payer to the payment network is determined. The referring user's identifier may be stored in the payer's user profile.

[0055] Block 312 indicates that credits are deducted from the payer's credit balance. The user's credit balance (in this case, the payer's credit balance) may be stored in association with the user's user profile. The number of credits to be deducted from the credit balance is calculated by multiplying the transaction amount by the credit conversion factor per unit of currency. The transaction amount is calculated. In an example where the amount is 100 US dollars and the credit conversion factor to US dollars is 1:1, 100 credits can be deducted from the payer's user profile. The credit conversion factor to a currency can vary depending on the date, location, user, type of goods / services, transaction history, etc., and can be set by the payment service. The payment service may disclose the conversion factor to the user as part of the initial conditions for joining the community payment network. Similarly, the payment service may provide notification of changes to the conversion factor during the user's registration with the payment service. The user's consent to the use of the conversion factor may be implied based on the user's continued use of the community payment network. In cross-border transactions (e.g., the payer is in Mexico and the recipient is in the United States), credit calculations may be performed using a conversion factor applicable to the currency used in the transaction. Alternatively or additionally, the currency may be deducted from the payer's PSAB account for the transaction amount.

[0056] Block 314 indicates that credit equivalent to the transaction amount minus the recipient fee will be added to the recipient's credit balance. Credit can be calculated by multiplying the transaction amount minus the recipient fee by an applicable conversion factor. The number of credits can be calculated using the following formula: C=(TF)*R, In this formula, C is the credit to the recipient, T is the transaction amount in the transaction currency, F is the fee amount in the transaction currency, and R is the conversion factor for credits per unit of currency. For example, if the transaction amount is 100 US dollars, the recipient fee is 1 US dollar, and the credit per US dollar is 0.05, then C = 99 US dollars * 0.05 credits / US dollars = 4.95 credits. In another example, if the transaction amount is 100 euros, the recipient fee is 5 euros, and the credit per euro is 0.08, then C = 95 euros * 0.04 credits / euro = 3.8 credits. Alternatively or additionally, the currency may be added to the payer's PSAB account or other financial account for the transaction amount.

[0057] Block 316 indicates that this will trigger the transfer of the recipient fee from the recipient's PSAB financial account to the settlement service's account. The settlement service may maintain a financial account and / or store the credit balance of the credit associated with the settlement service. The settlement service may receive the recipient fee in credit, or in an equivalent amount of currency, or in any combination of credit and currency. The credit may be transferred from the recipient's credit balance, and the currency may be transferred from the recipient's PSAB financial account.

[0058] Block 318 indicates adding credit to the previous recipient's credit balance. The added credit may be a portion of the credit equivalent to the recipient fee. In at least one example, this portion is in the range of at least approximately 0.1% to a maximum of approximately 75.0%, or at least approximately 10% to a maximum of approximately 50%, and / or at least approximately 25% to a maximum of approximately 60%. However, the percentage is not limited to this range and can be set by the payment service (and agreed upon by the user) at any amount. If the previous recipient is not identified (for example, if this is the first payment by this payer), these credits simply cannot be paid.

[0059] Block 320 indicates adding credit to the referrer's credit balance. The referrer's credit balance may be stored in association with the referrer's user profile. The added credit may be a portion of the credit equivalent to the recipient fee. In at least one example, this portion is in the range of at least approximately 0.1% to a maximum of approximately 75.0%, or at least approximately 10% to a maximum of approximately 50%, and / or at least approximately 25% to a maximum of approximately 60%, but the percentage does not have to be limited to this range and can be set by the payment service (and agreed upon by the user) at any amount. The previous recipient portion and the referrer portion may be the same percentage or different percentages. If the referrer is not identified (e.g., if the payer registered without a referral), these credits simply cannot be paid. Thus, if both a previous recipient and a referrer exist, the recipient fee paid by the recipient can in practice be divided among at least the payment service, the referrer, and the previous recipient. In various examples, the recipient fee may be split among the payment service, the referring user, the previous recipient, and one or more other entities, including one or more financial institutions and / or one or more nonprofit organizations. The percentage of the recipient fee held by the payment service may be equal to, greater than, or less than, the percentage allocated to the previous recipient and / or referring user. In some examples, the payer may receive a portion of the commission (e.g., as a "cashback"), which may reduce the portion distributed to at least the previous merchant and / or referring user.

[0060] Block 322 indicates the execution of post-transaction activities. The payment service can provide additional post-transaction services, such as storing transaction details, providing receipts to the buyer, displaying transaction data on the user interface of the user device's display, and updating loyalty rewards. The payment service server device can send receipts to the buyer's device via email, message, etc., send links, cause notifications to be executed in the payment application on the buyer's device, or enable access to the receipt within the payment application.

[0061] Figure 4 is a flowchart illustrating an exemplary process 400 for determining recipient fees and commissions for settlement transactions, as described herein.

[0062] Block 402 indicates the receipt of transaction data associated with a transaction between a first user as the payer and a second user as the payee, the transaction data including an indication of the transaction amount. The transaction data may be relayed to the settlement service by at least one of the participants in the transaction. The transaction data may include at least one of the following: the transaction amount, the desired date and time of transfer, the payer's identifier, the payee's identifier, a free-form note from the user, a location, and the items or services being purchased.

[0063] Block 404 indicates the determination of the recipient fee associated with the transaction, which is based on the transaction amount. In the example, the recipient fee is a fixed fee or a combination of a fixed fee and a percentage of the transaction amount. The recipient fee is not limited to these amounts and may be set by the settlement service.

[0064] Block 406 indicates the determination of a first number of credits proportional to the transaction amount and a second number of credits proportional to the recipient fee. The first and second number of credits may be calculated using a credit conversion factor for the currency unit.

[0065] Block 408 indicates the transfer of a first number of credits from a user profile associated with a first user to a user profile associated with a second user. The settlement service may deduct credits from the payer user. The term “transfer” is used herein, but changes in the credit balance may be considered deductions or additions without referring to a “transfer” from or to another user. That is, a “transfer” from payer to payee may also be expressed as the payer having credits deducted and the payee being offered credits. Alternatively or additionally, the transaction amount may be transferred from the first user account to the second user account.

[0066] Block 410 indicates the transfer of a second number of credits from the user profile associated with the second user to the payment service. In the example, the recipient fee can be paid to the payment service with credits deducted from the recipient's credit balance. In another example, the recipient fee can be paid to the payment service in the currency deducted from the recipient's PSAB financial account (or, if there is no PSAB financial account, the recipient's source of funds).

[0067] Block 412 shows the transfer of a third number of credits from the payment service to the user profile of the first user's referrer, where the third number of credits is a portion of the second number of credits. In some embodiments, the transfer of credits to the third user can be described as a direct transfer from the recipient to the third user without first being allocated to the payment service. In the example, a fourth number of credits can be transferred from the payment service to the user profile associated with the fourth user, where the first user paid the fourth user in a previous transaction occurring immediately before the transaction, where the fourth number of credits includes the second portion of the second number of credits. In some embodiments, the transfer of credits to the fourth user can be described as a direct transfer from the recipient to the fourth user without first being allocated to the payment service. However, in examples where there is no previous recipient or referrer, the credit allocation to the previous recipient or referrer can be allocated to the payment service rather than remaining with the recipient.

[0068] Furthermore, in some cases, the payer may receive a portion of the recipient fee (for example, as a "cashback" on the transaction). The payer may pay the recipient using credit or currency and receive credit or currency for the transaction. The payer portion of the recipient fee can be associated with the payer's user profile for credit or currency payments.

[0069] Figures 2, 3A, 3B, and 4 are flowcharts illustrating process examples according to several embodiments. The processes in Figures 2, 3A, 3B, and 4 are shown as a collection of blocks in a logical flowchart, representing a series of operations, some or all of which can be implemented in hardware, software, or a combination thereof. In a software context, a block can represent a computer-executable instruction stored in one or more computer-readable media that, when executed by one or more processors, programs the processors to perform the described operation. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc., that perform a specific function or implement a specific data type. The order in which the blocks are described should not be interpreted as a restriction. Any number of described blocks can be combined in any order and / or in parallel to implement a process or alternative process, but it is not necessary to execute all blocks. Furthermore, in some examples, some or all of the operations shown in one or more of Figures 2, 3A, 3B, and 4 can be combined with some or all of the operations shown in the other figures of Figures 2, 3A, 3B, and 4. For illustrative purposes, the process is described with reference to the environments, architectures, and devices described in the examples herein, but the process can be implemented in a wide variety of other environments, architectures, and devices.

[0070] Figure 5 shows a block diagram 500 of selected components of the payment service server device 502 as described herein.

[0071] The payment service server device 502 may include one or more servers, or other types of computing devices that can be embodied in any number of ways. For example, in the server example, other computer architectures may be used as additions or replacements, but modules, other functional components and data may be implemented as a single server, a cluster of servers, a server farm or data center, a cloud-hosted computing service, a cloud-hosted storage service, etc.

[0072] Furthermore, although the diagrams show the components and data of the payment service server device 502 as existing in a single location, these components and data can be distributed in any way to different computing devices and different locations. Multiple payment service server devices 502 can be located together or separately and organized as virtual servers, server banks and / or server farms. The functions described may be provided by a server of a single entity or company, or by servers and / or services of multiple different customers or companies.

[0073] In the illustrated example, the payment service server device 502 may include one or more processors 504, one or more computer-readable media 506, one or more communication interfaces 508, and one or more input / output (I / O) devices 510. Each processor 504 may be a single processing unit or multiple processing units, and may include one or more computing units or multiple processing cores. The processor 504 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on operational instructions. For example, the processor 504 may be one or more hardware processors and / or logic circuits of any suitable type that are specifically programmed or configured to perform the algorithms and processes described herein. The processor 504 may be configured to fetch and execute computer-readable instructions stored in the computer-readable media 506, which can be programmed to perform the functions described herein.

[0074] Computer-readable media 506 include computer storage media and computer-readable signals. Computer storage media include volatile and non-volatile, removable and non-removable media implemented in any way or technique for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to, solid-state memory, phase-change memory (PRAM), static RAM (SRAM), dynamic RAM (DRAM), other types of random-access memory (RAM), read-only memory (ROM), EEPROM, flash memory or other memory technologies, CD-ROM, DVD, or other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices, or other magnetic storage devices, or other non-transmission media that can be used to store information for access by computing devices. Furthermore, in some examples, computer-readable media may be associated with transient computer-readable signals (in compressed or uncompressed form). Examples of computer-readable signals include, but are not limited to, signals that can be configured to be accessed by a computer system hosting or running a computer program, including signals downloaded over the Internet or other networks, whether or not they are modulated using a carrier wave.

[0075] Depending on the configuration of the payment service server device 502, the computer-readable medium 506 can be an example of a tangible, non-temporary computer storage medium. In some examples, the payment service server device 502 can also access external storage devices such as RAID storage systems, storage arrays, network-attached storage, storage area networks, cloud storage, or any other medium that can be used to store information and can be accessed directly or through another computing device or network by one or more processors. Therefore, the computer-readable medium 506 can be a computer storage medium that can store instructions, modules, or components that can be executed by the processor 504.

[0076] The computer-readable medium 506 may be used to store any number of functional components that can be executed by the processor 504. In many implementations, these functional components include instructions or programs that can be executed by the processor 504. Functional components stored in the computer-readable medium 506 may include a payment module 514, a registration module 516, a funding module 518, an additional services module 520, a user interface module 522, and a social network module 524, which can constitute at least a portion of the community payment network application (payment application) 512. The payment application 512 can be provided by a payment service server device 502 and may be configured to allow users to execute functions associated with community network payments.

[0077] The term “module” is intended to represent an example of software division for illustrative purposes and is not intended to represent any type of requirement, necessary method, way, or mechanism. Therefore, various “modules” will be described, but their functions, similar functions, or both can be arranged in different ways (e.g., combined into fewer modules or divided into more modules). A module may contain computer instructions / code that can be stored in computer-readable medium 506 and made executable by processor 504.

[0078] The settlement module 514 may be configured to generate, receive, and / or transmit transaction data for electronic transactions conducted within a community settlement network. In some examples, any user in a transaction may send transaction data to the settlement service via an instance of a settlement application provided by the settlement service running on the user's device. For example, when a recipient submits a transaction, the recipient may obtain the payer's approval before doing so, either via controls on the payer's user device or by controls on the recipient's user device. In addition, or alternatively, based at least in part on the transaction data, the settlement module 514 may deduct a credit equivalent to the transaction amount from the payer's credit balance, determine the recipient fee for the transaction, add a credit equivalent to the transaction amount minus the recipient fee to the recipient's credit balance, add a portion of the recipient fee (e.g., a credit equivalent to the recipient fee) to the previous recipient's credit balance, add a portion of the recipient fee (same or different as the portion for the previous recipient) to the referring user's credit balance, and retain the remaining recipient fee for the settlement service. In addition, or alternatively, the settlement module 514 may have access to an exchange rate or exchange rate between credit and currency in order to perform the transfers described above. The exchange rate can be set by agreement between the payment service and one or more users participating in the community payment network.

[0079] The registration module 516 may be configured to receive registration information from the user. In some examples, the user downloads a payment application before registering and uses that payment application to submit the registration information. The registration module 516 and the user interface module 522 may display a form for the user to enter registration information. The registration module may be configured to verify with the payment service that the user is not yet registered (for example, by requesting at least one of the user's email address, phone number, name, etc.) before requesting registration information. The registration module may detect the receipt of referring information from a referring user and associate the user's registration information with the referring user (by the payment service server device when the registration information is received, or by the user device before the registration information is submitted), so that the referring user can receive credit for the registered user's future transactions.

[0080] The funding module 518 may be configured to transfer funds from a user's personal funding source to the user's PSAB financial account. In an example, the funding module 518 may determine the funding source based at least in part on information provided by the user. Based at least on user permission, the funding module may trigger a transfer of funds between the funding source and the financial account. The financial account may be used to back up credits assigned to the user by the settlement service. In some examples, the settlement service has some or all control over the financial account, so when the user's credit balance decreases, the funding module 518 can withdraw a proportional amount of funds from the financial account. When the user leaves the community settlement network, or at the user's request, the funding module 518 may transfer the balance of the financial account to the user's funding source or another account of the user's choice. In addition, or instead, the funding module may manage credit balance adjustments corresponding to settlement network transactions, including commissions.

[0081] The additional service module 520 may be configured to provide users with additional services to the payment service. For example, the additional service module 520 may store transaction details in a storage device, provide receipts to users involved in the transaction, display transaction data on the user interface of the user device's display (in cooperation with the user interface module 522), update loyalty rewards that may be managed by the payment service, and display transaction information via external social networks or social networks associated with community payment networks. In this example, the additional service module 520 may send receipts to the user device via email, message, etc., send URL links to the user device, display notifications associated with the receipts in the payment application on the user device, or enable access to the receipts via the payment application. Alternatively, the payment service may provide other additional services such as inventory management and discount distribution.

[0082] The user interface module 522 may be configured to perform actions that may include providing a user interface to the user via the display of the user device. For example, the user interface module 522 may display a user interface that allows the user to perform at least one of the following actions: select a recipient or payer for a transaction, enter a transaction amount, request a credit balance, request a PSAB financial account balance, send a message to a settlement service or to another user on the settlement network, request the user's transaction history, request a mapping of neighboring users on the settlement network, request a list of other users to whom the user has referred the settlement network, request identifiers of users referred by the user, request a summary view of the user profile or dashboard regarding the user's participation in the settlement network, or collect information from multiple transactions that are determined to be associated with the user profile. Additional or alternative, the action may include generating a user interface that allows the user to perform actions that include displaying, sorting, filtering, or any combination thereof one or more of the information at various levels of granularity. Additional or alternative, the user interface module 522 may provide the user with a user interface that prompts the user to enter user credentials for, for example, a user profile and / or a PSAB financial account. Additionally or alternatively, this action may include linking financial accounts and / or sources of funds to the user's user profile.

[0083] In one example, the user interface module 522 may be configured to provide a user interface corresponding to the user device being used. For example, information may be displayed to the user in a different way when displayed on a mobile phone than when displayed on a personal computer.

[0084] In some cases, the user interface may be provided to the user via a web browser (e.g., SaaS (software as a service)), a downloadable client application, or both.

[0085] The social network module 524 can be configured to allow users to interact with transaction activities within the community payment network in a social forum. For example, the social network module 524 can provide integration with one or more social networks within the payment network. Social networks can be provided by the social network module 524 to allow users to interact with other users of the payment network. Furthermore, external social networks can be integrated within the payment network via third-party applications, enabling users of the payment network to interact with users of external social networks.

[0086] Additional functional components stored in the computer-readable medium 506 may include an operating system 530 that controls and manages various functions of the payment service server device 502. In at least one example, the computer-readable medium 506 may further include or maintain other functional components and data, such as other modules and data 532, which may include programs, drivers, and data used or generated by the functional components. Furthermore, the payment service server device 502 may include many other logical, programmatic, and physical components, and those described above are merely examples relevant to the discussion herein.

[0087] The communication interface 508 may include one or more interfaces and hardware components that enable communication with various other devices, either over a network or directly. For example, the communication interface 508 may enable communication over one or more networks, which are not limited to any type of network known in the art, such as a local area network or a wide area network such as the Internet, but may include wireless networks such as cellular networks, local wireless networks such as Wi-Fi, and / or near-field communication technologies such as Bluetooth®, BLE, NFC, RFID, wired networks, or any other network, or a combination thereof. The networks may include both wired and / or wireless communication technologies, which include not only wired or fiber optic technologies but also Bluetooth, BLE, Wi-Fi, and cellular communication technologies. The components used for such communication may depend at least in part on the type of network, the selected environment, or both. Protocols for communicating over such networks are well known and will not be described in detail herein.

[0088] The payment service server device 502 may further include various input / output (I / O) devices 510. The I / O devices 510 may be configured to allow a user to interface with the payment service server device 502 via one or more I / O devices. The I / O devices 510 can interface with devices such as displays (not shown), audio speakers (not shown), microphones (not shown), cameras (not shown), connection ports (not shown), optical readers (not shown), touchpads (not shown), haptic output devices (not shown), various user interface controls (e.g., buttons, joysticks, keyboards, mice, touchscreens, etc.) (not shown), or any combination thereof.

[0089] Those skilled in the art will understand that the hardware components and various functional modules shown in Figures 5, 6 and elsewhere are modifiable. The exemplary components are not intended to be exhaustive, but rather representative to highlight the components used to implement the subject matter disclosed herein. For example, other devices / components may be used in addition to, or instead of, the illustrated hardware. Furthermore, the various components shown for storage and memory may be alternatively located in any storage or memory via the network 114(1)–114(N). The illustrated examples are not intended to imply any architectural or other limitations relating to the subject matter of this disclosure.

[0090] Figure 6 shows a block diagram 600 of selected components of the user device 602 as described herein.

[0091] In at least one example, the user device 602 may be any suitable type of mobile device, such as portable, semi-portable, or semi-stationary. Some examples of the user device 602 may include tablet computing devices, smartphones and mobile communication devices, laptops, netbooks, other portable or semi-portable computers, wearable computing devices or other body-worn computing devices, augmented reality devices, or other computing devices capable of transmitting communications and performing functions in accordance with the technologies described herein.

[0092] In the illustrated example, the user device 602 may include one or more processors 604, one or more computer-readable media 606, one or more communication interfaces 608, and one or more input / output (I / O) devices 610. Each processor 604 may itself include one or more processors or processing cores. For example, a processor 604 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on operation instructions. In some examples, a processor 604 may be one or more hardware processors and / or logic circuits of any suitable type that are specifically programmed or configured to perform the algorithms and processes described herein. A processor 604 may be configured to fetch and execute computer-readable processor-executable instructions stored in a computer-readable media 606, which can program the processor 604 to perform the functions described herein.

[0093] Computer-readable media 606 include computer storage media and computer-readable signals. Computer storage media include volatile and non-volatile, removable and non-removable media implemented in any way or technique for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to, solid-state memory, phase-change memory (PRAM), static RAM, dynamic RAM, other types of random-access memory (RAM), read-only memory (ROM), EEPROM, flash memory or other memory technologies, CD-ROM, DVD, or other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices, or other magnetic storage devices, or other non-transmission media that can be used to store information for access by computing devices. Furthermore, in some examples, computer-readable media may be associated with transient computer-readable signals (in compressed or uncompressed form). Examples of computer-readable signals include, but are not limited to, signals that can be configured to be accessed by a computer system hosting or running a computer program, including signals downloaded over the Internet or other networks, whether or not they are modulated using a carrier wave.

[0094] Depending on the configuration of the user device 602, the computer-readable medium 606 can be an example of a tangible, non-temporary computer storage medium. In some examples, the user device 602 can also access external storage devices such as RAID storage systems, storage arrays, network-attached storage, storage area networks, cloud storage, or any other medium that can be used to store information and can be accessed directly or through another computing device or network by one or more processors. Thus, the computer-readable medium 606 can be a computer storage medium that can store instructions, modules, or components that can be executed by the processor 604.

[0095] The computer-readable medium 606 may be used to store and maintain any number of functional components that can be executed by the processor 604. In some implementations, these functional components are executable by one or more processors and, when executed, comprise instructions or programs that implement operational logic for performing actions and services originating from the user device 602. Functional components stored in the computer-readable medium 606 may include a registration module 614, a payment module 616, a user interface module 618, and a social network module 620, which can constitute at least a part of the community payment network application (payment application) 612. The registration module 614, payment module 616, user interface module 618, social network module 620, and community payment network application 612 (payment application) may correspond to the registration module 516, payment module 514, user interface module 522, and social network module 524 of payment application 512, as described above with reference to Figure 5.

[0096] The term “module” is intended to represent an example of software division for illustrative purposes and is not intended to represent any type of requirement, necessary method, way, or mechanism. Therefore, various “modules” will be described, but their functions, similar functions, or both can be arranged in different ways (e.g., combined into fewer modules or divided into more modules). A module may contain computer instructions / code that can be stored in computer-readable medium 606 and made executable by processor 604.

[0097] The registration module 614 may be configured to prompt the user to enter registration information (e.g., name, address, telephone number, source of funds identification, social security number, initial amount of funds to be transferred to the financial account, referring user identifier, etc.). The registration module 614 can transmit the registration information to the payment service server device. The registration module 614 can cooperate with the user interface module 618 when collecting and transmitting registration information via the payment application 612. The registration module 614 can communicate with another user device when identifying a referring user. For example, the registration module 614 can receive data from a user device scanning a QR code or other code from a referring user. The code may be displayed on the referring user's user device or by other means (e.g., via email, US hard copy mail, user's company hard copy display, etc.). The registration module 614 detects the receipt of referring information from a referring user and can associate the user's registration information with the referring user (either by the settlement service server device at the time of receiving the registration information, or by the user device before the registration information is transmitted) so that the referring user can receive credit for the registered user's future transactions.

[0098] The payment module 616 may be configured to generate or receive transaction data for processing by the payment service. In the example, the transaction data may be manually entered by the user and may include the transaction amount, the goods or services purchased, the location, and the date or time the user wishes the transaction to be processed. In the example, the transaction data may be generated in point-of-sale management by a POS device or a user device communicating with a POS device. The payment module 616 may be configured to transmit the transaction data to the payment service server device. In the example, the transaction data may be uploaded, but the transaction may not be processed until the payment service receives consent from another user for that transaction, either via an indication sent from the other user's user device or by a code presented by the user device indicating that the other user has approved the transaction.

[0099] The user interface module 618 may be configured to provide a user interface to the user on the display 630 of the user device 602. In an example, the user interface module 618 may provide a user interface that allows the user to perform actions associated with the payment application 612 or, more generally, the community payment network. The user interface module 618 of the user device 602 can perform actions corresponding to the user interface module 522 of the payment service server device 502. In a particular example, the user interface module 618 may be configured to provide a user interface that is appropriate for the user device being used. For example, information may be displayed to the user in a different way when displayed on a mobile phone than when displayed on a personal computer. In some examples, the user interface may be provided to the user via a web browser (e.g., SaaS), a downloadable client application, or both.

[0100] The social network module 620 can be configured to allow users to interact with each other in social forums regarding transaction activities within the community payment network. For example, the social network module 620 can provide participation in one or more social networks with a payment network. The social network can be provided by the social network module 620 to allow users to interact with other users of the payment network. Furthermore, external social networks can be integrated into the payment network via third-party applications, enabling users of the payment network to interact with users of external social networks.

[0101] Furthermore, the computer-readable medium 606 may include additional functional components, such as an operating system 626, to control and manage various functions of the user device 602 and enable basic user interaction. The computer-readable medium 606 may also store data, data structures, and the like used by the functional components.

[0102] Depending on the type of user device 602, the computer-readable medium 606 may optionally include other functional components and data, such as other modules and data 628 that may contain programs, drivers, and data used or generated by functional components. For example, the computer-readable medium 606 of a user device associated with a merchant user may optionally include a point-of-sale (POS) module. Furthermore, the user device 602 may include many other logical, programmatic, and physical components, the ones described herein being merely examples relevant to the discussion herein.

[0103] The communication interface 608 may include one or more interfaces and hardware components that enable communication with various other devices, either over a network or directly. For example, the communication interface 608 may enable communication over one or more networks, which may not be limited to any type of network known in the art, such as a local area network or a wide area network such as the Internet, but may include wireless networks such as cellular networks, local wireless networks such as Wi-Fi, and / or near-field communication technologies such as Bluetooth®, BLE, NFC, RFID, wired networks, or any other such networks, or any combination thereof. The networks may include both wired and / or wireless communication technologies, which may include not only wired or fiber optic technologies but also Bluetooth, BLE, Wi-Fi, and cellular communication technologies. The components used for such communication may depend at least in part on the type of network, the selected environment, or both. Protocols for communicating over such networks are well known and will not be described in detail herein.

[0104] The user device 602 may further include various input / output (I / O) devices 610. The I / O devices 610 may be configured to allow the user to interface with the user device 602 via one or more I / O devices. The I / O devices 610 can interface with devices such as a display 630, an audio speaker (not shown), a microphone (not shown), a camera (not shown), a connection port (not shown), an optical reader (not shown), a touchpad (not shown), a haptic output device (not shown), various user interface controls (e.g., buttons, joysticks, keyboards, mice, touchscreens, etc.) (not shown), or any combination thereof.

[0105] In at least one example, the user device 602 may include a display 630. Depending on the type of computing device used as the user device 602, the display 630 may employ any suitable display technology. For example, the display 630 could be a liquid crystal display, a plasma display, a light-emitting diode display, an OLED (organic light-emitting diode) display, an electronic paper display, or any other suitable type of display on which digital content can be presented. In some examples, the display 630 may have a touch sensor associated with the display 630 and provide a touchscreen display configured to receive touch input to enable interaction with a graphic interface presented on the display 630. Thus, the implementations herein are not limited to any particular display technology. Alternatively, in some examples, the user device 602 may not include a display 630, and information may be presented by other means, such as auditory means.

[0106] Furthermore, the user device 602 may optionally include a card reader 632, or be connectable to a card reader 632. In some examples, the card reader 632 may be plugged into a port of the user device 602, such as a microphone / headphone port, a data port, or other suitable port. The card reader 632 may include a reading head for reading the magnetic stripe of a payment card, and may also include encryption technology for encrypting the information read from the magnetic stripe. Alternatively, depending on the type and configuration of the user device 602, many other types of card readers can be used with the user device 602 described herein.

[0107] Other components included in the user device 602 may include a GPS device 634 capable of indicating location information. Furthermore, the user device 602 may include one or more sensors 636, such as an accelerometer, gyroscope, compass, proximity sensor, camera, microphone, and / or switch, as described above. In addition, the user device 602 may include a variety of other components not shown, such as a power supply including removable storage, battery, and power control unit, a barcode scanner, printer, cash drawer, and the like.

[0108] This subject proposes integrating at least the aforementioned functions into a seamless and convenient mechanism for requesting and receiving administrator approval. With respect to the problems previously identified in conventional systems and methods, the software application itself becomes an active and cooperative component of the process, rather than the subject of the process. Furthermore, the above description applies to devices and applications related to payment technology. However, it is understood that this technology can be extended to any device or application. Moreover, the technology described herein can be configured to operate regardless of the type of user device, mobile application, POS topology, payment service server equipment, computer network, and environment. The technology described herein can be configured to operate in both real-time / online and offline modes.

[0109] The aforementioned disclosure refers to user interaction via a UI presented through the device's display, but the UI can be presented via any input / output device. For example, the UI can be output via speakers or augmented reality projectors. Furthermore, the aforementioned disclosure refers to a user interacting with the UI via selectable controls, but in additional or alternative examples, the user may indicate their selection via voice input or other types of input.

[0110] The foregoing is merely illustrative of the principles of this disclosure, and those skilled in the art can make various modifications without departing from the scope of this disclosure. The above examples are presented for illustrative purposes only and are not limiting. This disclosure can also take many forms other than those expressly described herein. Accordingly, it is emphasized that this disclosure is not limited to the methods, systems, and apparatus expressly disclosed, but is intended to include variations and modifications thereof within the spirit of the claims.

[0111] As a further example, modifications to the apparatus or process limitations (e.g., dimensions, configuration, components, sequence of process steps, etc.) can be made to further optimize the structures, devices, and methods provided herein, as shown and described herein. In any case, the structures, apparatus, and related methods described herein have many applications. Therefore, the subject matter disclosed should not be limited to any single example described herein, but rather should be interpreted broadly in accordance with the appended claims.

[0112] The various instructions, methods, and techniques described herein may be considered in the general context of computer executable instructions, such as program modules, which are stored on computer-readable media and executed by the processors described herein. Generally, program modules include routines, programs, objects, components, data structures, etc., for performing specific tasks or for implementing specific abstract data types. These program modules, etc., can be executed as native code or downloaded and executed in a virtual machine or other just-in-time compilation execution environment. Typically, the functionality of program modules can be combined or distributed as needed in various implementations. Implementations of these modules and techniques may be stored on computer storage media and transmitted via some form of communication medium. Example clauses Clause 1: One or more servers associated with a payment service receive registration data associated with registering a first user with the payment service from a first computing device associated with a first user among multiple users of the payment service, via a first instance of the payment application. In at least part in response to receiving the registration data, one or more servers associated with the payment service determine that the first user is eligible to register for the payment service, One or more servers associated with the payment service store the user profile associated with the first user in the data store associated with the payment service. Based at least in part on the registration data, one or more servers associated with the payment service identify the source of funds indicated by the first user, One or more servers associated with the payment service transmit a request to a device associated with a financial institution to open a financial account for the first user at the financial institution on behalf of the first user, One or more servers associated with the payment service cause the display of the first computing device to display an indication of the financial account and a request for approval to transfer funds from the source of funds to the financial account, Receiving the authorization by one or more servers associated with the payment service, In accordance with at least part of receiving the aforementioned approval, one or more servers associated with the payment service transfer funds from the source of funds to the financial account, Receiving first transaction data associated with a first transaction between the first user and the second user from at least one of the first computing device and the second computing device associated with the second user, by one or more servers associated with the payment service, wherein the first user includes the payer of the first transaction and the second user includes the payee of the first transaction. The payment service receives, by one or more servers associated with the payment service, second transaction data associated with a second transaction between the first user and the third user from at least one of the first computing device and the third user's third computing device, via each instance of the payment application running on the first computing device or the third computing device, wherein the second transaction data includes an indication of the transaction amount, the first user includes the payer of the second transaction, and the third user includes the payee of the second transaction. In response to receiving the second transaction data associated with the second transaction, one or more servers associated with the settlement service determine the recipient fee based at least in part on the second transaction amount and a predetermined calculation, One or more servers associated with the payment service determine a first number of credits corresponding to the second transaction amount and a second number of credits corresponding to the recipient fee, One or more servers associated with the aforementioned payment service, Transfer of a first number of credits from the user profile associated with the first user to the user profile associated with the third user, Transfer of a second number of credits from the user profile associated with the third user to the payment service, Based at least in part on determining the referring user associated with the user profile associated with the first user, the payment service transfers a credit equivalent to the first percentage of the recipient fee to the user profile associated with the referring user. A transfer of credit equivalent to a second percentage of the recipient fee from the payment service to a user profile associated with the immediate recipient, at least in part on determining the immediate recipient based at least in part on the first transaction data, wherein the immediate recipient includes a second user. This causes a transfer of values ​​that includes A method for providing this. Clause 2: The method according to Clause 1, further comprising transmitting a transaction record of the second transaction to at least one of the first computing device and the third computing device by one or more servers associated with the payment service. Clause 3: One or more servers associated with the payment service receive requests from the first computing device for a summary of the first user's transactions, One or more servers associated with the payment service cause the display of the transaction summary on the display of the first computing device. The method of Clause 1 or Clause 2, further comprising: Clause 4: The terms of the agreement between the payment service and one or more of the users are as described in any one of the provisions 1 to 3, including a condition that the recipient fee is less than a minimum threshold recipient fee. Article 5: One or more servers associated with the payment service receive from the first computing device a request to convert one or more credits associated with a user profile associated with the first user into the currency of the funding source, The payment service involves one or more servers associated with the payment service causing a transfer of a certain amount of currency from the financial institution to the first user's source of funds, wherein the certain amount of currency includes the number of one or more credits multiplied by the ratio of currency units per credit. The credit balance associated with the user profile associated with the first user is reduced by one or more credits at a time. The method described in any one of the clauses 1 to 4, further including the method described in any one of the clauses 1 to 4. Clause 6: One or more servers associated with the payment service transmit to the first computing device associated with the first user a request for additional information related to opening a financial account for the first user at the financial institution, One or more servers associated with the payment service receive the additional information from the first computing device associated with the first user. Furthermore, Sending a request to open a financial account for the first user at the financial institution on behalf of the first user is at least partially in response to receiving the additional information. The method described in any one of the clauses 1 through 5. Article 7: The method according to any one of the provisions 1 to 6, wherein the registration data includes at least one of the identifier of the first user's referral user, the identifier of the source of funds, the amount of funds to be transferred from the source of funds to the financial institution, and personal identification information. Clause 8: The payment application is provided to the first computing device by one or more servers associated with the payment service, as described in any one of the provisions of paragraphs 1 to 7. Article 9: The method described in any one of the paragraphs 1 to 8, wherein determining that the first user is eligible to register for the payment service includes determining that the first user has not previously registered for the payment service. Clause 10: The aforementioned sources of funding include banks, credit unions, savings and loan associations, or intermediary companies, as described in any one of the provisions 1 through 9. Clause 11: A method performed by one or more servers of a payment service, Receiving transaction data associated with a transaction between a first user as the payer and a second user as the recipient, wherein the transaction data includes an indication of the transaction amount. Determining the recipient fee associated with the transaction, wherein the recipient fee is based at least in part on the transaction amount, To determine a first number of credits proportional to the transaction amount and a second number of credits proportional to the recipient fee, Transferring the first number of credits or the transaction amount from the user profile associated with the first user to the user profile associated with the second user, Transferring a second number of credits or recipient fees from the user profile associated with the second user to the payment service, The transfer of a third number of credits from the payment service to a user profile associated with a third user, wherein the third user refers the first user to the community payment network, and the third number of credits is a first portion of the second number of credits. A method for providing this. Article 12: The method according to Clause 11, further comprising transferring a fourth number of credits from the payment service to a user profile associated with a fourth user, wherein the first user made a payment to the fourth user in a previous transaction that occurred immediately before the transaction, and the fourth number of credits is a second portion of the second number of credits. Article 13: One or more computer-readable media having computer-readable instructions, wherein, when executed by one or more processors, the computer-readable instructions cause the one or more processors to perform the method described in clause 11 or clause 12. Article 14: One or more processors, One or more computer-readable media containing computer-readable instructions and A system equipped with, The system, when the computer-readable instruction is executed by one or more processors, configures the system to perform the method described in clause 11 or clause 12. Article 15: The aforementioned recipient fee includes a fixed fee, a percentage of the transaction amount, or a combination of a fixed fee and a percentage of the transaction amount, as described in any one of the provisions 1 through 10, provision 11, or provision 12. Article 16: The method described in any one of Clauses 1 to 10 or Clause 15, wherein at least one of the aforementioned recipient fee, the first percentage, and the second percentage is a condition of the agreement between the payment service and the one or more users. Article 17: One or more computer-readable media having computer-readable instructions, wherein, when executed by one or more processors, the computer-readable instructions cause the one or more processors to perform the method described in any one of the clauses 1 to 10, clause 15, or clause 16. Article 18: One or more processors, One or more computer-readable media containing computer-readable instructions and A system equipped with, The system wherein, when the computer-readable instruction is executed by one or more processors, the system is configured to perform the method described in any one of the clauses 1 to 10, clause 15, or clause 16. Article 19: One or more servers associated with a payment service store user profiles associated with multiple users of the payment service in a data store associated with the payment service, wherein the user profiles include information identifying the source of funds of a first user. One or more servers associated with the payment service receive a certain amount of currency from the source of funds, One or more servers of the payment service update the user profile associated with the first user, adding a number of credits equivalent to a certain amount of currency, at least partially based on the credit-to-currency ratio. One or more servers associated with the payment service receive transaction data associated with a transaction between the first user and the second user from at least one of a first computing device associated with the first user or a second computing device associated with the second user, via each instance of the payment application running on the first computing device or the second computing device, wherein the transaction data includes an indication of the transaction amount, the first user includes the payer, and the second user includes the payee in the transaction. In at least part in response to receiving second transaction data associated with the second transaction, one or more servers associated with the settlement service determine the recipient fee based at least partly on the second transaction amount and a predetermined calculation, One or more servers associated with the payment service determine a first number of credits corresponding to the transaction amount and a second number of credits corresponding to the recipient fee, One or more servers associated with the aforementioned payment service, Transfer of a first number of credits from the user profile associated with the first user to the user profile associated with the second user, Transfer of a second number of credits from the user profile associated with the second user to the payment service, Based at least in part on determining the referring user associated with the user profile of the first user, the payment service transfers a credit equivalent to the first percentage of the recipient fee to the user profile associated with the referring user. A transfer of credit equivalent to a second percentage of the recipient fee from the payment service to a user profile associated with the immediate recipient, at least in part on determining the immediate recipient based at least in part on the first transaction data, wherein the immediate recipient includes a second user. This causes a transfer of values ​​that includes A method for providing this. Article 20: One or more computer-readable media containing computer-readable instructions, wherein, when executed by the one or more processors, the computer-readable instructions cause the one or more processors to perform the actions described in Clause 19. Article 21: One or more processors, One or more computer-readable media containing computer-readable instructions and A system equipped with, When the computer-readable instruction is executed by one or more processors, the system is configured to perform the method described in clause 19. system.

Claims

1. A method performed by one or more servers associated with a payment service, The aforementioned server, Receiving registration data associated with registering the first user with the payment service from a first computing device associated with a first user among multiple users of the payment service, via a first instance of the payment application, wherein the registration data includes information on referral users and funding sources associated with the first user. The data store of the server associated with the payment service stores a user profile associated with the first user based on the received registration data, wherein the referring user and source of funds in the registration data are associated with the identifier of the first user in the user profile, and the user profile includes a credit balance corresponding to the number of credits. The means of sending a request to a device associated with a financial institution to open a financial account for the first user at the financial institution on behalf of the first user, wherein the financial account for the first user is associated with the first user's source of funds, The display of the first computing device is to display a request for approval to transfer funds from the source of funds to the financial account, Receiving the aforementioned approval, Upon receiving the aforementioned approval, the funds will be transferred from the aforementioned source of funds to the aforementioned financial account, Receiving first transaction data associated with a first transaction between the first user and the second user from at least one of the first computing device and the second computing device associated with the second user, wherein the first user corresponds to the payer of the first transaction and the second user corresponds to the payee of the first transaction, Receiving second transaction data associated with a second transaction between the first user and the third user from at least one of the first computing device and the third user's third computing device, via each instance of a payment application running on the first computing device or the third computing device, wherein the second transaction data includes the transaction amount associated with the second transaction, the first user corresponds to the payer of the second transaction, and the third user corresponds to the payee of the second transaction. In response to receiving the second transaction data associated with the second transaction, the recipient fee is determined based on the transaction amount and the terms and conditions between the recipient and the payment service, The number of first credits corresponding to the transaction amount and the number of second credits corresponding to the recipient fee are determined based on the credit conversion factor per unit of currency. Transfer of the number of first credits from the user profile associated with the first user to the user profile associated with the third user, Transfer of the number of second credits from the user profile associated with the third user to the payment service, If the information of the referring user is included in the user profile associated with the first user, the payment service transfers a credit equivalent to the first percentage of the recipient fee to the user profile associated with the referring user. Based on determining the most recent recipient based on the first transaction data, the payment service transfers a credit equivalent to the second percentage of the recipient fee to the user profile associated with the most recent recipient, wherein the most recent recipient includes the second user. This causes a transfer of values ​​that includes, How to configure it to execute.

2. The method according to claim 1, further comprising transmitting the transaction record of the second transaction to at least one of the first computing device and the third computing device.

3. Receiving a request from the first computing device for a summary of the first user's transactions, Displaying a summary of the transaction on the display of the first computing device, The method according to claim 1 or claim 2, further comprising:

4. Receiving a request from the first computing device to convert one or more credits associated with a user profile associated with the first user into the currency of the funding source, The transfer of a certain amount of currency from the financial institution to the first user's source of funds, wherein the certain amount of currency includes the number of credits multiplied by the ratio of currency units per credit, Decreasing the credit balance associated with the user profile associated with the first user by one or more credits, The method according to claim 1 or claim 2, further comprising:

5. Sending a request for additional information associated with opening a financial account for the first user at the financial institution to the first computing device associated with the first user, Receiving the additional information from the first computing device associated with the first user, Furthermore, Sending a request to open a financial account for the first user at the financial institution on behalf of the first user is in response to receiving the additional information. The method according to claim 1 or claim 2.

6. The method according to claim 1 or 2, wherein the registration data includes at least one of the amount of funds to be transferred from the source of funds to the financial institution, and personal identification information.

7. The method according to claim 1 or 2, wherein the payment application is provided to the first computing device by one or more servers associated with the payment service.

8. The method according to claim 1 or 2, wherein the source of funds includes a bank, a credit union, a savings and loan association, or an intermediary company.

9. The method according to claim 1 or claim 2, wherein the recipient fee includes a fixed fee, a percentage of the transaction amount, or a combination of a fixed fee and a percentage of the transaction amount.

10. The method according to claim 1 or 2, wherein the terms of use between the recipient and the payment service include at least one of the recipient fee, a first percentage, and a second percentage.

11. One or more computer-readable media having computer-readable instructions, wherein, when executed by one or more processors, the computer-readable instructions cause the one or more processors to perform the method according to claim 1 or claim 2.

12. One or more processors, One or more computer-readable media containing computer-readable instructions, A system equipped with, A system wherein, when the computer-readable instruction is executed by one or more processors, it causes the system to perform the method according to claim 1 or claim 2.

13. A method performed by one or more servers associated with a payment service, The aforementioned server, The data store associated with the payment service stores user profiles associated with a first user of multiple users of the payment service, wherein the user profiles include information on referral users and funding sources associated with the first user. Receiving a certain amount of currency from the aforementioned source of funds, The user profile associated with the first user is updated to add a number of credits equivalent to a certain amount of currency based on the credit-to-currency ratio, Receiving transaction data associated with a transaction between the first user and the second user from at least one of the first computing device associated with the first user or the second computing device associated with the second user, via each instance of a payment application running on the first computing device or the second computing device, wherein the transaction data includes the transaction amount associated with the transaction, the first user corresponds to the payer, and the second user corresponds to the payee in the transaction. In response to receiving the transaction data associated with the transaction, the recipient fee is determined based on the transaction amount and the terms and conditions between the recipient and the payment service, The number of first credits corresponding to the transaction amount and the number of second credits corresponding to the recipient fee are determined based on the credit conversion factor per unit of currency. This involves causing a transfer of values, Transfer of the number of first credits from the user profile associated with the first user to the user profile associated with the second user, Transfer of a second number of credits from the user profile associated with the second user to the payment service, If the information of the referring user is included in the user profile associated with the first user, the payment service transfers a credit equivalent to the first percentage of the recipient fee to the user profile associated with the referring user. Based on determining the most recent recipient based on the transaction data, the payment service transfers a credit equivalent to a second percentage of the recipient fee to the user profile associated with the most recent recipient, wherein the most recent recipient includes a second user. This includes, How to configure it to execute.

14. One or more computer-readable media containing computer-readable instructions, wherein, when executed by one or more processors, the computer-readable instructions cause the one or more processors to perform the method according to claim 13.

15. One or more processors, One or more computer-readable media containing computer-readable instructions, A system equipped with, A system wherein, when the computer-readable instruction is executed by one or more processors, it causes the system to perform the method according to claim 13.

16. The method according to claim 1 or 2, wherein the transfer of the value further includes the transfer of a credit from the payment service to a fourth user equivalent to a third percentage of the recipient fee.

17. The method according to claim 1 or 2, wherein the transfer of the value further comprises transferring a third percentage of the recipient fee to the entity.

18. The method according to claim 17, wherein the other entity includes at least one of a financial institution, a non-profit organization, a charity, an individual, a small business, or a government agency.

19. The method according to claim 1 or claim 2, wherein the registration data includes an identifier of the referring user, and the identifier includes a QR code or URL associated with the referring user.

Images