System and method for credit-based split fee electronic payment network

Abstract

It allows for more efficient electronic payment transactions by reducing the number of participants and the number of communications. Credits are also provided as commissions to the payer's introducer and the payer's previous payee. The technology may include one or more of a payment service providing a payment application on a user device of the user, opening a financial account on the user's behalf at a financial institution affiliated with the payment service, transferring funds from the user's funding source to the financial account, associating a user profile of the user with credits equivalent to the balance in the financial account, receiving transaction data about the transaction, determining a payee fee for the transaction, transferring currency or credits equivalent to the transaction amount from the payer to the payee, 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]

[0001] This PCT application claims priority to U.S. Provisional Patent Application No. 63 / 168,228, filed March 30, 2021, and is incorporated herein by reference. [Background technology]

[0002] Traditionally, credit and debit card transactions have incurred costs for merchants, which can be a combination of interchange fees, assessment fees, service fees, and payment processor markups. In these traditional systems, merchants bear the cost of the convenience that customers enjoy by paying with a payment card.

[0003] Historically, merchant fees for payment card transactions have consisted of a percentage of the transaction amount plus a flat fee, often totaling approximately 2% of the transaction amount. Merchant fees have multiple components, which may be paid to various entities involved in processing and settling payments. The largest components of merchant fees are often interchange fees paid to the customer's payment card issuer and assessment fees paid to the payment card network. A percentage is often also paid to the payment processor. Thus, processing a payment card transaction traditionally required the participation of multiple entities beyond the merchant and the customer, and the payment of multiple fees.

[0004] Additionally, while digital payments can be performed using peer-to-peer technology and often have a lower cost per transaction for the recipient than payment card transactions, traditional peer-to-peer payment processors limit the total amount a single user can pay (or be paid) in a given period. Additionally, traditional peer-to-peer systems can take several days for funds to be transferred to the recipient's bank account, making digital payments an inappropriate solution for many transactions.

[0005] There is a need to minimize the cost to the payee of accepting payments, minimize the number of entities involved in processing a transaction, minimize the time it takes to transfer funds from payer to payee, minimize the number of fund transfers, and minimize processing resources. There is also a need to encourage participation in electronic payment systems. [Brief explanation of the drawings]

[0006] DETAILED DESCRIPTION OF THE INVENTION Referring now to the accompanying drawings, in which: The use of the same reference numbers in different drawings indicates similar or identical items or features.

[0007] [Figure 1] FIG. 1 illustrates an exemplary system for conducting split fee transactions within a community payment network, as described herein. [Figure 2] FIG. 2 is a flow diagram illustrating an exemplary process for registering a new user in a community payment network as described herein. [Figure 3A] FIG. 3A is a flow diagram illustrating an example process for conducting a split fee transaction in a community payment network, as described herein. [Figure 3B] FIG. 3B is a flow diagram illustrating an example process for conducting a split fee transaction in a community payment network, as described herein. [Figure 4] FIG. 4 is a flow diagram illustrating an exemplary process for determining payee fees and commissions for payment transactions as described herein. [Figure 5] FIG. 5 illustrates a block diagram of selected components of a payment services server device as described herein. [Figure 6] FIG. 6 illustrates a block diagram of selected components of a user device as described herein. DETAILED DESCRIPTION OF THE INVENTION

[0008] The technology described herein is directed, at least in part, to community payment networks that use currency-backed credits. In the technology described herein, a payee fee may be divided and distributed among multiple entities (e.g., one or more of the payment service, the user who introduced the payer to the community payment network, a bank, a charity, the payer, and the payee in the payer's most recent network transaction preceding the transaction for which the payee fee is being paid). Using the technology described herein, a payee who accepts a payment through the community payment network pays a payee 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 community payment network users, such as the introducing user or previous payees. In various examples, the other entities may also 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 communications. The unique configuration of devices and applications implemented with the technology described herein provides enhanced efficiency in electronic payment processing. Instead of payment processors having to communicate with card networks and issuers for each transaction, users of the present payment network can pre-fund financial accounts associated with payment services, and credit can be adjusted as users engage in transactions. Furthermore, payee fees can be lower than traditional electronic transactions, at least in part due to the simplification of such processes and systems.

[0010] Additionally, the technology described herein retains fees that would otherwise be paid to credit card issuers and card networks and distributes them to payment network users and / or other entities, which may be individuals, small businesses, etc.

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

[0012] In some examples, a "payment service" is a payment services entity that processes payments or other fund transfers, including authenticating payment information for a transaction, authorizing the transaction, effecting the transfer of value between parties to the transaction, and paying commissions to referring users and previous recipients. In examples, a payment service may provide other services such as inventory management, loyalty program management, discount distribution, cost analysis and / or tracking.

[0013] In some examples, a "user" is a member of the community payment network that uses the community payment network to receive or provide payments to another member of the community payment network. A user may be an end user of a community payment network application ("payment application") provided by the payment service. For purposes of this description, "member" and "user" are used interchangeably. Depending on the transaction, a user can be the payer or the payee. As used herein, a "payer" is a user that provides a payment in a transaction. As used herein, a "payee" is a user that receives payment in a transaction. A user can be the payer in some transactions and the payee in other transactions. In some examples, a merchant can be the payee when the merchant is receiving payment in a transaction. For purposes of this description, a "merchant" can be any entity that offers an item (e.g., a good or service) for acquisition (e.g., sale, lease, free of charge, etc.). In some examples, a transaction may be a peer-to-peer transaction where the payee is not a merchant but an individual receiving funds from another individual in their personal capacity as a member of the community payment network. For example, payments can be made for loans, private sales, or other peer-to-peer transactions.

[0014] In some examples, 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 examples, the referring user and referrer may be identified by the payment service using data submitted in connection with a registration request from the user. For example, an invitation from a first member to a second member may be in the form of a code (e.g., a QR code, an alphanumeric code, etc.) that includes data representing the first member's identifier. The data may be transmitted to the payment service when the second member includes the code in their request to register with the community payment network. In other examples, the referring user may be manually identified by the user as part of the registration process. Furthermore, a user need not have a referring user to become part of the community payment network. For example, a user can learn about the community payment network on their own and register without being introduced.

[0015] In some instances, a "prior payee" is the payee with whom the payer entered a transaction immediately prior to the ongoing transaction. In other words, the payee of the payer's most recent historical transaction is referred to as the "prior payee."

[0016] In some examples, a "recipient fee" is a fee charged to a recipient by a payment service for conducting a transaction through the community payment network. In other words, the recipient fee is the cost to the recipient for receiving a payment through the community payment network. The recipient fee may be a set amount, a percentage of the total transaction amount, a combination of a set amount and a percentage, etc. For example, the recipient fee may be 1% of the transaction amount (maximum fee). The recipient fee may be set by agreement between the payment service and the recipient at the time of registration of the recipient. The recipient fee may vary by specific recipient, by specific payer, by location of the transaction, by merchant category of the payer or payer, by date of the transaction, by transaction history of at least one of the payer or payee, and the like. The recipient fee for a specific recipient may depend on the specific transaction, and the recipient fee for a first recipient may not be the same as the recipient fee for a second recipient in an otherwise equivalent transaction. In examples, the recipient fee may be paid in credit, and in examples, the recipient fee may be paid in currency.

[0017] In some examples, a "community payment network" is multiple individuals and / or entities participating in a payment system in which credit is used instead of currency in transactions and a split commission arrangement exists that divides the payer fee among at least the payer's referring user, the prior merchant, and the payment service that manages the community payment network. A portion of the payer fee may also be allocated to one or more of a financial institution, a nonprofit or other charitable organization, etc. "Community payment network" is used interchangeably with "payment network" herein.

[0018] In some instances, a "bank account" is used interchangeably with a "financial account" and is a financial account at a financial institution. In some instances, a "financial institution" may include, but is not limited to, one or more of a commercial bank, a retail bank, an internet bank, a credit union, a savings and loan association, or a brokerage firm.

[0019] In some examples, a "funding source" is a repository of resources associated with a user. In some examples, a funding source may be a user's deposit or savings account at a financial institution. In some examples, a funding source may be a user's cryptocurrency account. A funding source may additionally or alternatively be a user's credit or debit card. A funding source may also be gold or other tangible assets owned by a member. In examples, a funding source may be used as a user's source of funds to fund a PSAB financial account. In some examples, a "payment-service-affiliated bank financial account," or PSAB financial account, is a financial account at a financial institution selected by a payment service that corresponds to a master account the payment service maintains with that bank. A PSAB financial account may be separate from a funding source and may be established in association with a user who has enrolled in the community payment network. Funds from a funding source may be transferred to a PSAB financial account, and vice versa. In examples, such transfers may be performed 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 payment network. The user profile may be stored in a data store associated with the payment service and / or on a storage device associated with the payment service server device. In one example, the user profile may include information regarding the user's identifier, funding source, 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, which may protect personally identifiable information, details regarding financial accounts, funding source, etc.

[0021] In some examples, a "credit" is a unit of value within a community payment network. In examples, one credit may be equivalent to 1 USD, 100 USD, 1000 USD, or any other dollar amount. In an example where one credit is equivalent to 1 USD, in a transaction in which a payer acquires goods or services valued at 100 USD from a payee, the payment service deducts 100 credits from the payer's credit balance, and the payment service can distribute the 100 credits to the payee, the payment service, a referring user, a previous payee, or others, according to example 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 may also be applied in other contexts. That is, the techniques described herein are not limited to retail merchant-customer relationships, but may also be applied to other contexts, such as peer-to-peer (P2P) money transfers, lending, bill payments, etc.

[0023] The technology described herein can provide many advantages and improvements over conventional technologies. Many of these improvements are technical improvements to computer capabilities or other types of technology. For example, by providing payments via credit transfer within a community payment network, multiple intermediate financial transfers can be avoided. That is, by using credit, a digital substitute for currency, funds do not need to be transferred between financial institutions (e.g., issuers, acquirers, merchants, customers, 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 a payment service. A transaction can simply involve a data update (representing a change in credit balance) performed by a single entity (the payment service). When a user desires to "cash out" (e.g., convert credits to currency), the user's credit balance is converted to currency. A transfer occurs from the user's PSAB financial account to the user's original funding source (e.g., a personal checking account, savings account, etc.) or to another account. However, a user can engage in multiple transactions in which credits, rather than currency, are transferred before cashing out. Traditionally, a payment transaction involves crediting or debiting multiple accounts (issuer, merchant bank, funds processor, etc.).

[0024] The technology described herein allows transactions to be consolidated due to the nature of a community payment network, as individual transactions within the payment network do not require "settlement" in the traditional sense. Furthermore, commission payments can accumulate without the user having to take any action, and credits do not need to be cashed until requested. Eliminating issuers, eliminating complex merchant fees, enabling simplified commissions, and eliminating or reducing the need for interbank communication benefits efficiency, memory, and processing on the payment service device, eliminating the need for other entities, such as card issuers and card networks, and their devices. In at least these ways, the technology is improved. Further benefits for users may include reduced transaction fees, fewer bank transactions, and no payment amount limits. Furthermore, a community payment network allows merchants and individuals to participate on an equal footing. In an example, a merchant user and an individual user could pay the same payee fee, receive the same conversion factor, and earn the same commission when acting as a referring user or "prior payee." Furthermore, the payment service can withhold value from commission payments to pay for taxes, the amount of which may be based on the country in which the transaction is taking place. In some examples, taxes may be paid directly to a government agency. Additionally, value from commission payments may be retained by the payment service and distributed by the payment service to other entities, such as charities, non-profit organizations, etc., at the user's choice or designation.

[0025] For at least the above reasons, the techniques described herein, and systems implementing the techniques described herein, are unconventional, unusual, and non-traditional, and represent improvements over the related art.

[0026] References herein to an "embodiment" do not limit the described elements to a single embodiment, but rather all described elements can be combined in any number of ways in any embodiment. For purposes of interpreting this specification, the use of "or" herein means "and / or" unless otherwise stated. The use of "a" or "an" herein means "one or more" unless otherwise stated. The use of "comprising" and "comprising" herein are interchangeable and are not intended to be limiting. Unless otherwise stated, the use of terms such as "first," "second," "third," "upper," "lower," etc., does not imply any spatial, sequential, or hierarchical order or importance, but rather is used to distinguish one element from another. The use of the terms "and / or" and "at least one," for example, "A and / or B" and "at least one of A and B," should be understood to include selecting only the first listed option (A), or selecting only the second listed option (B), or selecting both options (A and B). As a further example, in the case of "A, B and / or C" and "at least one of A, B and C," such phrases are intended to include selecting only the first listed option (A), or selecting only the second listed option (B), or selecting only the third listed option (C), or selecting only the first and second listed options (A and B), or selecting only the first and third listed options (A and C), or selecting only the second and third listed options (B and C), or selecting all three options (A, B and C). This may be expanded for the number of items listed, as would be readily apparent to one of ordinary skill in this and related arts.

[0027] Those skilled in the art should also understand that any block diagrams, steps, or subprocesses herein represent conceptual views of illustrative systems embodying principles of the present subject matter. Similarly, flowcharts, flow diagrams, state transition diagrams, pseudocode, and the like, substantially represented on a computer-readable medium, represent various processes that may be executed by a computer or processor, whether or not such a computer or processor is explicitly shown. The order in which the methods are described is not intended to be construed as limiting, and any number of the described method blocks may be removed, moved, added, subdivided, combined, and / or modified in any order to implement the methods, alternative combinations, or subcombinations. While steps, subprocesses, or blocks may be shown as being performed sequentially, some steps, subprocesses, or blocks may instead be performed in parallel or at different times, as will be recognized by those skilled in the art. Specific numbers described herein are merely examples; alternative implementations may use different values ​​or ranges. These methods may be implemented in any suitable hardware, software, firmware, or combination thereof.

[0028] 1 illustrates an exemplary system 100 for conducting split commission transactions within a community payment network, as described herein. System 100 includes payment service server devices 102(1)-102(N), user devices 104(1)-104(N) (including seller user device 104(1) and buyer user device 104(2), as well as other user devices 104(3)-104(N)), seller bank server devices 106(1)-106(N), buyer bank server devices 108(1)-108(N), other user bank server devices 110(1)-110(N), and payment service associated bank (PSAB) server devices 112(1)-112(N). The server devices may also be referred to herein as "server(s)." The devices of system 100 communicate with each other via networks 114(1)-114(N) (e.g., the Internet, cable networks, cellular networks, wireless networks (e.g., Wi-Fi) and wired networks, and short-range communications such as Bluetooth® and Bluetooth low energy).

[0029] Although a single seller user device 104(1) and buyer user device 104(2) are shown, in additional or alternative examples, system 100 can have multiple seller devices 104(1) and buyer devices 104(2). Furthermore, each of multiple users of payment services can be associated with a bank, and system 100 can include multiple user bank server device(s) (106(1)-106(N), 108(1)-108(N), 110(1)-110(N)) for the multiple users. Furthermore, for ease of reference, components may be referred to throughout this disclosure in the singular and in association with a single generalized reference number. For example, user devices 104(1)-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 can include the plural in certain embodiments.

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

[0031] A payment service associated with the payment service server devices 102(1)-102(N) may constitute an online payment service that processes payments for multiple users. The payment service server devices 102(1)-102(N) may expose network-based application programming interfaces (APIs) through which the payment service provides services to multiple users via the user devices 104(1)-104(N). For purposes of this description, the payment service and / or the payment service server devices 102(1)-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 the user devices 104(1)-104(N). In some embodiments, the payment service may offer various network-based (or "cloud-based") services to users to meet their computing needs. In some embodiments, the payment service may operate a payment service network including a cluster of managed servers (or other hardware-based computing devices) stored in data centers located across different geographic regions. The payment service server devices 102(1)-102(N) are further described below in the description of FIG.

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

[0033] The seller's bank server devices 106(1)-106(N) and the buyer's bank server devices 108(1)-108(N) may be associated with banks or other financial institutions at which the seller and buyer, respectively, have financial accounts.

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

[0035] In embodiments, PSAB devices 112(1)-112(N) are not included in system 100. In such embodiments, users may use their own funding sources (e.g., financial accounts held with their own financial institutions (e.g., 106(1)-106(N), 108(1)-108(N), or 110(1)-110(N)))) as financial backing for credit used in the community payment network.

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

[0037] FIG. 2 is a flow diagram illustrating an example 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 the community payment network. The payment service server device may receive the request from the user device via a web form, email, direct message, application notification, etc. In an example, the request may include or be associated with referencing user information. The referencing user information identifies an existing member of the payment network who referred the user to the payment service. The referring user information may be embedded as data in the registration request. In an example, the user may scan a QR code presented by a merchant user or activate a URL provided by the merchant that directs the user to a registration interface. In one example, scanning the QR code with the user device may launch a browser window on the user device, from which the payment service server device may obtain the registration information entered by the user. In an example, for a user to qualify as a referring user in the payment network, the referred person must register within a threshold time of the user providing the QR code or URL to the referred person. For example, the payment service may timestamp the QR code at its generation and compare that timestamp to the registered user's first contact with the payment service. Additionally or alternatively, the user may provide the code to the registered user. When the registered user provides the code to the payment service during registration, the user who provided the code to the registered user is recognized by the payment service as a referring user. Additionally or alternatively, the referring user information may be obtained by the payment service server device separately from the registration request. An identifier for the referring user may be stored by the payment service associated with the user's new user profile, which may be stored in a data store associated with the payment service server device.

[0039] In an example, a user may register at the time of a transaction with a referring user. The transaction data, registration link, and the referring user's identifier may be obtained by the user's user device (e.g., by scanning a QR code presented to the user by a merchant via a merchant device). In an example, a user may register before performing any transactions on the community payment network. In one example, a user device may scan a QR code displayed by a merchant device or posted at a merchant location, such that a merchant associated with the merchant device may qualify as a referring user even though a transaction has not yet occurred. In another example, a user may register by visiting a community payment network webpage without being directly referred, such that commissions from the user's transactions are split a maximum of two ways (payment network, previous merchant) rather than three or more ways (e.g., payment network, previous merchant, referring user). For a first transaction within the payment network by a user with a user profile without an associated referring user, the payment network retains the full payee fee (or equivalent credit) because there is no previous merchant or referring user. Once the user is registered, the user may conduct transactions within the payment network.

[0040] As part of the registration process, the payment service server device may request identifying information regarding the user's funding source. The funding source (e.g., a checking account, etc.) may be used to fund the user's PSAB financial account or to provide direct support for credits exchanged on the community payment network. The credits may be backed by U.S. dollars or another currency, cryptocurrency, or other value mechanism. Different users' credits may be 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 the user on behalf of the user. A bank can be selected by the payment service to be the PSAB, and the payment service can maintain a master or umbrella account at the PSAB for all accounts opened for users of the payment service. The payment service can store an association between the user's new PSAB financial account and the user's user profile within the community payment network. An association between the user's funding source and the user profile can also be stored, thereby enabling determination of the user's PSAB financial account and funding source given the user's identifier. In some examples, the payment service or PSAB communicates with the user (via email, direct message, application notification, etc.) to obtain additional information from the user after initial registration to open the PSAB financial account (e.g., to obtain direct approval from the user to open the PSAB financial account). In some examples, a PSAB financial account is not opened, but instead, a transfer is made directly between the payee and the payer's funding source (e.g., a checking account, etc.) or between one user's funding source and a second user's PSAB financial account. In instances where a user does not use or own a PSAB financial account, the user may consent to the user's funding source being debited to add credit to the user's credit balance associated with the user's user profile. The user may consent to additional funds being transferred to a payment service to increase the credit associated with the user if the credit balance falls below a minimum threshold. If the user desires to "cash out," funds may be transferred from the payment service to the user's funding source. Similarly, in instances where a PSAB financial account exists, the user may consent to automatic replenishment of the PSAB financial account from the user's funding source if the balance in the PSAB financial account falls below a minimum threshold.

[0042] Block 206 depicts transferring funds from the user's funding source to the user's PSAB financial account, initially funding the user's PSAB financial account. For example, the payment service may initiate an ACH transfer between the funding source and the 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 user device, direct message, email, web form entry, etc. In some examples, the payment service may suggest an amount for the transfer or require a minimum amount as initial funding for the PSAB financial account. The user may authorize an automatic transfer from the funding source to the PSAB financial account. In examples, the automatic transfer occurs when the PSAB financial account balance falls below a minimum threshold amount.

[0043] Block 208 depicts determining the number of credits equivalent to the PSAB financial account balance. As described below, credit-to-currency conversion factors can be used to determine how many credits a particular currency amount represents, and to determine the currency amount equivalent to a number of credits (e.g., when "cashing out" credits, as described below).

[0044] Block 210 depicts associating the determined number of credits with the user's user profile as the user's credit balance.

[0045] A user may "cash out" credit at any time. In an 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 should be transferred. The identified account may be the funding source that originally funded the PSAB financial account or another payment method. In response to receiving the request, the payment service transfers funds from the PSAB financial account to the identified account (or alternative type of payment). The amount of credit that can be cashed out may be limited by a minimum credit balance that must be maintained as part of the terms of the community payment network. However, if the user seeks to unenroll from the community payment network, all credit may be cashed out. In an example, full cash out occurs automatically when the user unenrolls.

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

[0047] 3A and 3B are a flow diagram illustrating an example process 300 for conducting split commission transactions within a community payment network, as described herein.

[0048] Block 302 illustrates receiving transaction data from a payment application executing on a user device for a pending transaction between a payer and a payee in a payment network. In an example, the transaction data from a payment application executing on a payer's user device (such as the buyer's user device 104(2)) for a transaction between the payer and the payee may be received by a payment service. In an example, the transaction data may be received by a payment service from a point-of-sale device. In an example, the payer may be a customer of the payee, which may be a merchant. The transaction data may include conventional information (e.g., transaction amount, transaction location, purchased item or service, merchant identifier, etc.). The transaction data may also include a payer identifier, which in some examples may be added to conventional transaction data by a particular instance of the payment application executing on the payer's user device. The transaction data may be obtained by an instance of the payment application executing on the payer's user device, from the payee's user device, or via manual entry, etc. Alternatively, the transaction data may be received from an instance of a payment application executing on the payee's user device (such as the seller's user device 104(1)) for a transaction between the payer and the payee. In one example, the payee user device obtains and adds the payor identifier via manual input by the payer or payee (e.g., entering a phone number on a user interface of the payee user device, scanning the identifier with an image capture component of the payee user device so that the identifier can be displayed on the display of the payer user device, etc.).

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

[0050] The payment service server device may cause one or more user interfaces to be presented on the user device via a payment application executing on the user device. The one or more user interfaces may display controls that enable the user to cause a transfer of funds between financial accounts associated with the user's user profile, indicate an intent to purchase or transfer value to another user, indicate an intent to accept value (e.g., credit) transferred from another user to the user, check a credit balance, modify a user profile, review a transaction history, search a transaction history, search participating users of the community payment network (e.g., searching by name, location, or other criteria), view conversion factors, determine exchange rates between different currencies, communicate with other users or the payment service, join a social network provided by the payment service, and initiate a scan with the user device of a barcode, QR code, or other graphic, which may, for example, represent transaction data of a pending transaction or may include an identifier of another user with whom the user wishes to enter into a transaction.

[0051] Block 304 depicts identifying user profiles of the payer and payee based at least in part on the transaction data. As discussed above, the payment services server device may receive the transaction data in any of a variety of ways, including those discussed above with respect to block 302. The transaction data may include identifiers for the payer and payee. The payment services server device may map the payer identifier to a user profile for the payer and may map the payee identifier to a user profile for the payee, which may be stored by the payment service.

[0052] Block 306 depicts determining a receiver fee associated with the transaction based at least in part on the transaction data and the terms of use between the receiver and the payment service. In some examples, the receiver fee may be calculated as a percentage of the transaction amount (e.g., 0.5%, 1.0%, 1.5%, etc.). For example, if the payer purchases $50.00 of shoes from the receiver and the seller agrees to a 1.0% receiver fee, the receiver fee is $0.50. Agreement to the receiver fee may be made during user registration, and the receiver fee may be adjusted by the payment service with the user's consent. In some examples, the receiver fee may be calculated as a flat fee plus a percentage of the transaction amount. For example, in the above example where the transaction amount was $50, a receiver fee of 1.0% plus $1.00 would result in a receiver fee of $1.50. In some examples, the total receiver fee is capped (e.g., $10.00, $15.00, $20.00, etc.).

[0053] Block 308 depicts determining a previous payee to whom the payer paid in the most recent historical transaction conducted in the payment network. Determining the most recent payee may be based on transaction records stored by the payment services server device. In examples, the payment services server device and the user device may be coupled via a network to a storage device (not shown) that stores transaction records, user profiles, etc. Additionally or alternatively, the storage device may be local to the payment services server device, the user device, or both. In certain implementations, the storage device may include one or a combination of computer-readable media. The payment services server device analyzes the payer's purchase history based at least in part on the payer's user profile to determine the identifier of the payee in a transaction conducted by the payer immediately prior to the pending transaction.

[0054] Block 310 depicts determining an identifier of the referring user who originally referred the payer to the payment network. The identifier of the referring user may be stored in the payer's user profile.

[0055] Block 312 illustrates deducting credits from the payer's credit balance. A user's credit balance (here, the payer's credit balance) may be stored in association with the user's user profile. The number of credits deducted from the credit balance is calculated by multiplying the transaction amount by a conversion factor of credits per currency unit. In an example where the transaction amount is 100 USD and the conversion factor of credits to USD is 1:1, 100 credits may be deducted from the payer's user profile. The conversion factor of credits to currencies may vary by date, location, user, type of product / service, transaction history, etc., and may be set by the payment service. The payment service may disclose the conversion factor to the user as part of the initial conditions of joining the community payment network. Similarly, the payment service may provide notice of changes to the conversion factor during the user's registration with the payment service. A 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., when the payer is in Mexico and the payee is in the United States), the credit calculation may be performed using the conversion factor applicable to the currencies used in the transaction. Alternatively or additionally, currency may be deducted from the payer's PSAB account for the transaction amount.

[0056] Block 314 indicates adding credits to the recipient's credit balance equal to the transaction amount minus the recipient fee. The credits may be calculated by multiplying the transaction amount minus the recipient fee by an applicable conversion factor. The number of credits may 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 currency of the transaction, F is the fee amount in the currency of the transaction, and R is the conversion factor for credits per currency unit. For example, if the transaction amount is 100 USD, the recipient fee is 1 USD, and there are 0.05 credits per USD, then C = 99 USD * 0.05 credits / USD = 4.95 credits. In another example, if the transaction amount is 100 EUR, the recipient fee is 5 EUR, and there are 0.08 credits per EUR, then C = 95 EUR * 0.04 credits / EUR = 3.8 credits. Alternatively or additionally, the currency may be added to the PSAB account or other financial account of the payer of the transaction amount.

[0057] Block 316 illustrates causing a transfer of the payee fee from the payee's PSAB financial account to the payment service's account. The payment service may maintain the financial account and / or store a credit balance of credits associated with the payment service. The payment service may receive the payee fee in credits, in an equivalent amount of currency, or in some combination of credits and currency. Credits may be transferred from the payee's credit balance and currency may be transferred from the payee's PSAB financial account.

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

[0059] Block 320 illustrates adding credits to the credit balance of the referring user. The referring user's credit balance may be stored in association with the referring user's user profile. The added credits may be a portion of the credits equivalent to the payee fee. In at least one example, this portion ranges from at least about 0.1% to a maximum of about 75.0%, or from at least about 10% to a maximum of about 50%, and / or from at least about 25% to a maximum of about 60%, although the percentage need not be limited to this range and can be set by the payment service (and agreed to by the user) in any amount. The previous payee portion and the referring user portion may be the same percentage or different percentages. If a referring user is not identified (e.g., if the payer registered without a referral), these credits simply cannot be paid. Thus, if both a previous payee and a referring user exist, the payee fee paid by the payee may, in effect, be divided among at least the payment service, the referring user, and the previous payee. In various examples, the payee fee may be split among the payment service, the referring user, the previous payee, and one or more other entities, which may include one or more financial institutions and / or one or more non-profit organizations. The percentage of the payee fee retained by the payment service may be equal to, or may be greater than, or less than, the percentage allocated to the previous payee and / or referring user. The payer may, in some examples, receive a portion of the commission (e.g., as "cash back"), which may reduce at least the portion allocated to the previous merchant and / or referring user.

[0060] Block 322 depicts performing post-transaction activities. The payment service may provide additional services after the transaction, such as storing transaction details, providing a receipt to the buyer, presenting transaction data on a user interface on the user device display, updating loyalty rewards, etc. The payment service server device may send the receipt to the buyer device via email, message, etc., may send a link, may cause a payment application on the buyer device to run a notification, or may enable access to the receipt within the payment application.

[0061] FIG. 4 is a flow diagram illustrating an example process 400 for determining payee fees and commissions for a payment transaction, as described herein.

[0062] Block 402 illustrates receiving transaction data associated with a transaction between a first user as a payer and a second user as a payee, the transaction data including an indication of the transaction amount. The transaction data can be relayed to a payment service by at least one participant in the transaction. The transaction data can include at least one of the transaction amount, a desired date and time of transfer, a payer identifier, a payee identifier, a user free-form note, a location, an item or service being purchased, etc.

[0063] Block 404 depicts determining a recipient fee associated with the transaction, where the recipient fee is based on the transaction amount. In examples, the recipient fee is a flat fee or a combination of a flat fee and a percentage of the transaction amount. The recipient fee is not limited to these amounts and may be set by the payment service.

[0064] Block 406 depicts determining a first number of credits proportional to the transaction amount and a second number of credits proportional to the recipient fee. The first number of credits and the second number of credits may be calculated using a conversion factor of credits to currency units.

[0065] Block 408 depicts transferring a first number of credits from a user profile associated with a first user to a user profile associated with a second user. The payment service may deduct the credits from the payer user. Although the term "transfer" is used herein, the change in credit balance may be considered a deduction or addition without reference to a "transfer" from or to another user. That is, a "transfer" from a payer to a payee may also be expressed as the payer being debited and the payee being provided with credit. Alternatively or additionally, a transaction amount may be transferred from a first user account to a second user account.

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

[0067] Block 412 depicts transferring a third number of credits from the payment service to the user profile of the first user's introducer, 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 payee to the third user without first being allocated to the payment service. In an example, a fourth number of credits can be transferred from the payment service to a user profile associated with a fourth user, where the first user paid the fourth user in a previous transaction occurring immediately before the transaction, and the fourth number of credits comprises a 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 payee to the fourth user without first being allocated to the payment service. However, in an example where there is no previous payee or introducing user, the allocation of credits to the previous payee or introducing user can be allocated to the payment service rather than remaining with the payee.

[0068] Additionally, in some examples, the payer may receive a portion of the payee fee (e.g., as a "cash back" on the transaction). The payer may pay the payee using credit or currency and receive credit or currency for the transaction. The payer's portion of the payee fee may be associated with the payer's user profile in credit or currency.

[0069] FIGS. 2, 3A, 3B, and 4 are flow diagrams illustrating example processes according to some embodiments. The processes in FIGS. 2, 3A, 3B, and 4 are illustrated as a collection of blocks in a logical flow diagram, which represent sequences of operations, some or all of which may be implemented in hardware, software, or a combination thereof. In the software context, the blocks may represent computer-executable instructions stored on one or more computer-readable media that, when executed by one or more processors, programs the processors to perform the described operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular data types. The order in which the blocks are described should not be construed as limiting. Any number of the described blocks may be combined in any order and / or in parallel to implement a process or alternative processes, although not all blocks need be performed. Furthermore, in some examples, some or all of the operations illustrated in one or more of FIGS. 2, 3A, 3B, and 4 may be combined with some or all of the operations illustrated in other diagrams of FIGS. 2, 3A, 3B, and 4. For purposes of explanation, the processes are described with reference to the environments, architectures, and devices described in the examples herein, although the processes can be implemented in a wide variety of other environments, architectures, and devices.

[0070] FIG. 5 illustrates a block diagram 500 of selected components of a payment services server device 502 as described herein.

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

[0072] Additionally, while the figures depict the components and data of payment services server device 502 as residing in a single location, these components and data may be distributed in any manner across different computing devices and locations. Multiple payment services server devices 502 may be located together or separately and organized as virtual servers, server banks, and / or server farms. The described functionality may be provided by the servers of a single entity or company, or by the servers and / or services of multiple different customers or companies.

[0073] In the depicted example, the payment services 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 single or multiple 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 execute the algorithms and processes described herein. The processor 504 may be configured to fetch and execute computer-readable instructions stored on the computer-readable media 506, which may program the processor 504 to perform the functions described herein.

[0074] Computer-readable media 506 includes computer storage media and computer-readable signals. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is 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 technology, CD-ROM, DVD, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices, or other non-transmission media that can be used to store information for access by a computing device. Furthermore, in some examples, computer-readable media may be associated with a transitory computer-readable signal (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 executing a computer program, including signals downloaded over the Internet or other networks, whether modulated using a carrier wave or not.

[0075] Depending on the configuration of the payment services server device 502, the computer-readable medium 506 may be an example of a tangible, non-transitory computer storage medium. Also, in some examples, the payment services server device 502 may have access to external storage, such as a RAID storage system, a storage array, network-attached storage, a storage area network, cloud storage, or any other medium that can be used to store information and that can be accessed by one or more processors directly or through another computing device or network. Thus, the computer-readable medium 506 may 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 executable by the processor 504. In many implementations, these functional components include instructions or programs executable by the processor 504. The functional components stored on 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 may constitute at least a portion of a community payment network application (payment application) 512. The payment application 512 may be provided by the payment services server device 502 and may be configured to enable a user to perform functions associated with community network payments.

[0077] The term "module" is intended to represent an example division of software for purposes of explanation and is not intended to represent any type of requirement, required method, manner, or mechanism. Thus, while various "modules" are described, their functionality, similar functionality, or both, may be arranged differently (e.g., combined into fewer modules, divided into more modules, etc.). The modules may include computer instructions / code that may be stored on the computer-readable medium 506 and executable by the processor 504.

[0078] The settlement module 514 may be configured to generate, receive, and / or transmit transaction data for electronic transactions conducted within the community payment network. In some examples, either user in a transaction can transmit the transaction data to the payment service via an instance of a payment application provided by the payment service running on a user device. For example, when the payee submits a transaction, the payee can obtain the payer's approval via controls on the payer's user device or by controls on the payee's user device before doing so. Additionally or alternatively, based at least in part on the transaction data, the settlement module 514 can deduct credits equal to the transaction amount from the payer's credit balance, determine a payee fee for the transaction, add credits equal to the transaction amount minus the payee fee to the payee's credit balance, add a portion of the payee fee (e.g., a credit equal to the payee fee) to the previous payee's credit balance, add a portion of the payee fee (the same or different from the portion for the previous payee) to the introducing user's credit balance, and retain the remaining payee fee for the payment service. Additionally or alternatively, the settlement module 514 can access an exchange factor or exchange rate between credits and currencies to perform the transfer described above. The exchange factor may be established 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 a user. In some examples, the user downloads a payment application before registering and submits the registration information using the payment application. The registration module 516 and user interface module 522 may display a form for the user to enter the registration information. The registration module may be configured to verify with the payment service that the user is not already registered (e.g., by requesting at least one of the user's email address, phone number, name, etc.) before requesting the registration information. The registration module may detect receipt of referring information from a referring user and associate the user's registration information with the referring user (either by the payment service server device when the registration information is received 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.

[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 authorization from the user, the funding module may trigger the transfer of funds between the funding source and the financial account. The financial account may be used to back credit allocated to the user by the payment service. In some examples, the payment service retains some or all control over the financial account, so that when the user's credit balance decreases, the funding module 518 may withdraw a proportional amount of funds from the financial account. When the user leaves the community payment 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 selected by the user. Additionally or alternatively, the funding module may manage credit balance adjustments corresponding to payment network transactions, including commissions.

[0081] The additional services module 520 may be configured to provide additional services of the payment service to the user. For example, the additional services module 520 may store transaction details in a storage device, provide a receipt to the user involved in the transaction, (in cooperation with the user interface module 522) display transaction data on a user interface of a user device display, update loyalty rewards that may be managed by the payment service, display transaction information via a social network associated with an external social network or community payment network, etc. In examples, the additional services module 520 may send a receipt to the user device via email, message, etc., send a URL link to the user device, cause a payment application on the user device to display a notification associated with the receipt, or enable access to the receipt via the payment application. Additionally or instead, the payment service may provide other additional services, such as inventory management, discount distribution, etc.

[0082] The user interface module 522 may be configured to perform operations that may include providing a user interface to a user via a display of a user device. In an example, the user interface module 522 may display a user interface that enables a user to at least one of: select a payee or payor for a transaction, enter a transaction amount, request a credit balance, request a balance for a PSAB financial account, send a message to a payment service or to another user of the payment network, request a transaction history for the user, request a mapping of nearby users of the payment network, request a list of other users the user has referred to the payment network, request identities of the user's referred users, request a summary view of a user profile or dashboard regarding the user's participation in the payment network, or collect information from multiple transactions determined to be associated with a user profile. Additionally or alternatively, the operations may include generating a user interface that enables a user to perform operations including one or more of displaying, sorting, filtering, or any combination thereof, at least a portion of the information at various levels of granularity. Additionally or alternatively, the user interface module 522 may provide a user interface to prompt the user for input of user credentials for a user profile and / or a PSAB financial account, for example. Additionally or alternatively, this action may include linking financial accounts and / or funding sources to the user's user profile.

[0083] In some examples, the user interface module 522 can be configured to provide a user interface that corresponds to the user device being used. For example, information may be displayed to a user differently when displayed on a mobile phone than when displayed on a personal computer.

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

[0085] The social network module 524 may be configured to enable users to interact in social forums regarding transaction activity within the community payment network. For example, the social network module 524 may provide integration to one or more social networks within the payment network. The social networks may be provided by the social network module 524 to enable users to interact with other users of the payment network. Additionally, external social networks may be integrated within the payment network via third-party applications, thereby enabling users of the payment network to collaborate with users of the external social networks.

[0086] Additional functional components stored on computer-readable medium 506 may include an operating system 530 that controls and manages various functions of payment services server device 502. In at least one example, 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, etc., and data used or generated by the functional components. Additionally, payment services server device 502 may include many other logical, programmatic, and physical components, the ones described above being 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, such as over a network or directly. For example, the communication interface 508 may enable communication over one or more networks, including, but 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, a wireless network such as a cellular network, a local wireless network such as Wi-Fi, and / or a near field communication such as Bluetooth, BLE, NFC, RFID, a wired network, or any other network, or combination thereof. The network may include both wired and / or wireless communication technologies, including Bluetooth, BLE, Wi-Fi, and cellular communication technologies, as well as wired or fiber optic 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 services 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 services server device 502 through one or more I / O devices. The I / O devices 510 may provide an interface to devices such as a display (not shown), 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 tactile output device (not shown), various user interface controls (e.g., buttons, joystick, keyboard, mouse, touch screen, etc.) (not shown), or any combination thereof.

[0089] Those skilled in the art will appreciate that the hardware components and various functional modules depicted in Figures 5, 6, and elsewhere may vary. The illustrated components are not intended to be exhaustive, but rather representative to highlight components that may be utilized to implement the subject matter disclosed herein. For example, other devices / components may be used in addition to or in place of the illustrated hardware. Furthermore, the various components depicted in storage and memory may alternatively be located in any storage or memory location via networks 114(1)-114(N). The illustrated examples are not intended to suggest architectural or other limitations with respect to the subject matter of the present disclosure.

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

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

[0092] In the depicted example, 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, 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 devices that manipulate signals based on operational instructions. In some examples, processor 604 may be one or more hardware processors and / or logic circuits of any suitable type that are specifically programmed or configured to execute the algorithms and processes described herein. Processor 604 may be configured to fetch and execute computer-readable, processor-executable instructions stored on computer-readable media 606, which may program processor 604 to perform the functions described herein.

[0093] Computer-readable media 606 includes computer storage media and computer-readable signals. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is 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 technology, CD-ROM, DVD, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices, or other non-transmission media that can be used to store information for access by a computing device. Furthermore, in some examples, computer-readable media may be associated with a transitory computer-readable signal (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 executing a computer program, including signals downloaded over the Internet or other networks, whether modulated using a carrier wave or not.

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

[0095] The computer-readable medium 606 may be used to store and maintain any number of functional components executable by the processor(s) 604. In some implementations, these functional components comprise instructions or programs executable by one or more processors that, when executed, implement operational logic for performing actions and services attributed to the user device 602. The functional components stored on 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 may constitute at least a portion of a community payment network application (payment application) 612. The registration module 614, the payment module 616, the user interface module 618, the social network module 620, and the community payment network application 612 (payment application) may correspond to the registration module 516, the payment module 514, the user interface module 522, and the social network module 524 of the payment application 512, as described above with reference to FIG. 5.

[0096] The term "module" is intended to represent an example division of software for purposes of explanation and is not intended to represent any type of requirement, required method, manner, or mechanism. Thus, while various "modules" are described, their functionality, similar functionality, or both may be arranged differently (e.g., combined into fewer modules, divided into more modules, etc.). The modules may include computer instructions / code that may be stored on the computer-readable medium 606 and executable by the processor 604.

[0097] The registration module 614 may be configured to prompt the user for registration information (e.g., name, address, phone number, funding source identification, social security number, amount of funds to be initially transferred to the financial account, referring user identifier, etc.). The registration module 614 may transmit the registration information to a payment services server device. The registration module 614 may cooperate with the user interface module 618 in collecting and transmitting the registration information via the payment application 612. The registration module 614 may communicate with another user device in identifying the referring user. For example, the registration module 614 may receive data from a user device scanning a QR code or other code from the referring user. The code may be displayed on the referring user's user device or in some other manner (e.g., via email, U.S. hardcopy mail, a hardcopy display at the user's business, etc.). The registration module 614 can detect receipt of referring information from a referring user and associate the user's registration information with the referring user (either by the payment services server device at the time the registration information is received or by the user device before the registration information is sent) so that the referring user can receive credit for the registered user's future transactions.

[0098] The settlement module 616 may be configured to generate or receive transaction data for processing by a payment service. In an example, the transaction data may be manually entered by a user and may include the transaction amount, the goods or services purchased, the location, the date or time the user desires the transaction to be processed, etc. In an example, the transaction data may be generated at a point of sale by a user device that is a POS device or that communicates with a POS device. The settlement module 616 may be configured to transmit the transaction data to a payment service server device. In an example, the transaction data may be uploaded, but the transaction may not be processed until the other user's consent to the transaction is received via an indication sent from the other user's user device or by a code presented by the user device that indicates to the payment service that the other user approves 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 cause a user interface to be provided that allows a 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 may perform actions corresponding to the user interface module 522 of the payment services server device 502. In a particular example, the user interface module 618 may be configured to provide a user interface that corresponds 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. 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 enable users to interact in social forums regarding transaction activity within the community payment network. For example, the social network module 620 can provide participation in one or more social networks with the payment network. The social networks can be provided by the social network module 620 to enable users to interact with other users of the payment network. Additionally, external social networks can be integrated within the payment network via third-party applications, thereby enabling users of the payment network to collaborate with users of the external social networks.

[0101] The computer-readable medium 606 may also include additional functional components, such as an operating system 626 for controlling and managing various functions of the user device 602 and enabling basic user interaction. The computer-readable medium 606 may also store data, data structures, etc. 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, which may include programs, drivers, etc., and data used by or generated by the 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. Additionally, the user device 602 may include many other logical, programmatic, and physical components, the illustrated ones of which are 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, such as over a network or directly. For example, the communication interface 608 may enable communication over one or more networks, including, but 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, a wireless network such as a cellular network, a local wireless network such as Wi-Fi, and / or a near field communication such as Bluetooth, BLE, NFC, RFID, a wired network, or any other such network, or a combination thereof. The network may include both wired and / or wireless communication technologies, including Bluetooth, BLE, Wi-Fi, and cellular communication technologies, as well as wired or fiber optic 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 a user to interface with the user device 602 via one or more I / O devices. The I / O devices 610 may provide an interface to devices such as a display 630, audio speakers (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 tactile output device (not shown), various user interface controls (e.g., buttons, joystick, keyboard, mouse, touch screen, etc.) (not shown), or any combination thereof.

[0105] In at least one example, user device 602 may include a display 630. Depending on the type of computing device used as user device 602, display 630 may employ any suitable display technology. For example, display 630 may 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 capable of presenting digital content thereon. In some examples, display 630 may have a touch sensor associated with it to provide a touchscreen display configured to receive touch input to enable interaction with a graphical interface presented on display 630. Accordingly, implementations herein are not limited to any particular display technology. Alternatively, in some examples, user device 602 may not include a display 630 and information may be presented by other means, such as auditory.

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

[0107] Other components included in the user device 602 may include a GPS device 634 that can indicate location information. Additionally, 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. Additionally, the user device 602 may include various other components not shown, examples of which include removable storage, a power source such as a battery and power control unit, a barcode scanner, a printer, a cash drawer, etc.

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

[0109] While the foregoing disclosure refers to user interaction via a UI presented via a device's display, the UI can be presented via any input / output device. For example, the UI can be output via speakers, an augmented reality projector, etc. Furthermore, while the foregoing disclosure refers to a user interacting with the UI via selectable controls, in additional or alternative examples, a user can indicate a selection via voice input or other types of input.

[0110] The foregoing merely illustrates the principles of the present disclosure, and various modifications may be made by those skilled in the art without departing from the scope of the present disclosure. The foregoing examples are presented for purposes of illustration and not limitation. The present disclosure may also take many forms other than those expressly described herein. It is therefore emphasized that the present disclosure is not limited to the methods, systems, and apparatus expressly disclosed, but is intended to cover all such variations and modifications within the spirit and scope of the appended claims.

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

[0112] Various instructions, methods, and techniques described herein may be considered in the general context of computer-executable instructions, such as program modules, stored on a computer-readable medium and executed by a processor herein. Generally, program modules include routines, programs, objects, components, data structures, etc., for performing particular tasks or implementing particular abstract data types. These program modules, etc., may be executed as native code or may be downloaded and executed, such as in a virtual machine or other just-in-time compilation execution environment. Typically, the functionality of the program modules may be combined or distributed as desired in various implementations. Implementations of these modules and techniques may be stored on computer storage media and transmitted over some form of communication medium. Example clauses Clause 1: receiving, by one or more servers associated with a payment service, from a first computing device associated with a first user of a plurality of users of the payment service via a first instance of a payment application, registration data associated with registering the first user with the payment service; determining, by one or more servers associated with the payment service, at least in part in response to receiving the registration data, that the first user is eligible to register with the payment service; and storing, by one or more servers associated with the payment service, a user profile associated with the first user in a data store associated with the payment service; identifying, by one or more servers associated with the payment service based at least in part on the registration data, a funding source indicated by the first user; sending, by one or more servers associated with the payment service, to a device associated with a financial institution, a request to open a financial account for the first user at the financial institution on behalf of the first user; causing one or more servers associated with the payment service to present on a display of the first computing device an indication of the financial account and a request for authorization to transfer funds from the funding source to the financial account; receiving, by one or more servers associated with the payment service, the authorization; and transferring funds from the funding source to the financial account by one or more servers associated with the payment service in response at least in part to receiving the authorization. receiving, by one or more servers associated with the payment service, 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 a second computing device associated with a second user, wherein the first user comprises a payer of the first transaction and the second user comprises a payee of the first transaction; receiving, by one or more servers associated with the payment service, from at least one of the first computing device and a third computing device of a third user via respective instances of a payment application running on the first computing device or the third computing device, second transaction data associated with a second transaction between the first user and the third user, the second transaction data including an indication of a transaction amount, the first user including a payer of the second transaction, and the third user including a payee of the second transaction; In response at least in part to receiving the second transaction data associated with the second transaction, determining, by one or more servers associated with the payment service, a payee fee based at least in part on a second transaction amount and a predetermined calculation; determining, by one or more servers associated with the payment service, a first number of credits corresponding to the second transaction amount and a second number of credits corresponding to a recipient fee; by one or more servers associated with said payment service; transferring a first number of credits from a user profile associated with the first user to a user profile associated with the third user; transferring a second number of credits from a user profile associated with the third user to the payment service; a transfer of credits from the payment service to a user profile associated with the referring user, the transfer being based at least in part on determining a referring user associated with a user profile associated with the first user; a transfer of credits equivalent to a second percentage of the payee fee from the payment service to a user profile associated with an immediate payee based at least in part on determining an immediate payee based at least in part on the first transaction data, wherein the immediate payee includes a second user. and causing a transfer of value, including A method for providing Clause 2: 10. The method of claim 1, further comprising transmitting, by one or more servers associated with the payment service, a transaction record of the second transaction to at least one of the first computing device and the third computing device. Clause 3: receiving, by one or more servers associated with the payment service, a request from the first computing device for a transaction summary of the first user; causing one or more servers associated with the payment service to display a summary of the transaction on a display of the first computing device; and The method of clause 1 or clause 2, further comprising: Clause 4: 4. The method of any one of clauses 1 to 3, wherein the terms of the agreement between the payment service and one or more of the plurality of users include a term requiring that the recipient fee be less than a minimum threshold recipient fee. Article 5: receiving, by one or more servers associated with the payment service, 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; causing, by one or more servers associated with the payment service, a transfer of a certain amount of currency from the financial institution to a funding source of the first user, the certain amount of currency including a number of one or more credits multiplied by a ratio of currency units per credit; decreasing a credit balance associated with a user profile associated with the first user by one or more credits; 5. The method of any one of clauses 1 to 4, further comprising: Article 6: transmitting, by one or more servers associated with the payment service, to the first computing device associated with the first user, a request for additional information associated with opening a financial account for the first user at the financial institution; receiving, by one or more servers associated with the payment service, the additional information from the first computing device associated with the first user; Furthermore, transmitting a request to open a financial account for the first user at the financial institution on behalf of the first user at least partially in response to receiving the additional information. 6. The method according to any one of clauses 1 to 5. Article 7: 7. The method of any one of clauses 1 to 6, wherein the registration data includes at least one of an identifier of the first user's referring user, an identifier of a funding source, an amount of funds to be transferred from the funding source to the financial institution, and personal identification information. Article 8: 8. The method of any one of clauses 1 to 7, wherein the payment application is provided to the first computing device by one or more servers associated with the payment service. Article 9: 9. The method of any one of clauses 1 to 8, wherein determining that the first user is eligible to register with the payment service includes determining that the first user has not previously registered with the payment service. Article 10: 10. The method of any one of clauses 1 to 9, wherein the funding source comprises a bank, credit union, savings and loan association, or brokerage firm. Article 11: 1. A method performed by one or more servers of a payment service, comprising: receiving transaction data associated with a transaction between a first user as a payer and a second user as a payee, the transaction data including an indication of a transaction amount; determining a recipient fee associated with the transaction, the recipient fee being based at least in part on the transaction amount; determining 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 a user profile associated with the first user to a user profile associated with the second user; transferring the second number of credits or the payee fee from a user profile associated with the second user to the payment service; and transferring a third number of credits from the payment service to a user profile associated with a third user, the third user having referred the first user to a community payment network, the third number of credits being a first portion of the second number of credits; A method for providing Article 12: The method of 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 that, when executed by one or more processors, cause the one or more processors to perform the method of clause 11 or clause 12. Article 14: one or more processors; one or more computer-readable media containing computer-readable instructions; A system comprising: 13. A system wherein the computer-readable instructions, when executed by the one or more processors, configure the system to perform the method of clause 11 or clause 12. Article 15: 13. The method of any one of clauses 1 to 10, 11 or 12, wherein the recipient fee comprises a flat fee, a percentage of the transaction amount, or a combination of a flat fee and a percentage of the transaction amount. Article 16: 16. The method of any one of clauses 1 to 10 or 15, wherein at least one of the recipient fee, the first percentage, and the second percentage is a term of an agreement between the payment service and the one or more users. Article 17: One or more computer readable media having computer readable instructions that, when executed by one or more processors, cause the one or more processors to perform the method of any one of 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; A system comprising: The computer-readable instructions, when executed by the one or more processors, configure the system to perform the method of any one of clauses 1 to 10, clause 15 or clause 16. Article 19: storing, by one or more servers associated with a payment service, user profiles associated with a plurality of users of the payment service in a data store associated with the payment service, the user profiles including information identifying a funding source of a first user; receiving, by one or more servers associated with the payment service, an amount of currency from the funding source; updating, by one or more servers of the payment service, a user profile associated with the first user to add a number of credits equivalent to the amount of currency based at least in part on a credit-to-currency ratio; receiving, by one or more servers associated with the payment service, from at least one of a first computing device associated with the first user or a second computing device associated with a second user via a respective instance of a payment application running on the first computing device or the second computing device, transaction data associated with a transaction between the first user and the second user, the transaction data including an indication of a transaction amount, the first user including a payer, and the second user including a payee in the transaction; In response at least in part to receiving second transaction data associated with the second transaction, determining, by one or more servers associated with the payment service, a payee fee based at least in part on the second transaction amount and a predetermined calculation; determining, by one or more servers associated with the payment service, a first number of credits corresponding to the transaction amount and a second number of credits corresponding to a recipient fee; by one or more servers associated with said payment service; transferring a first number of credits from a user profile associated with the first user to a user profile associated with the second user; transferring a second number of credits from a user profile associated with the second user to the payment service; a transfer of credits from the payment service to a user profile associated with the referring user, the credits corresponding to a first percentage of the payee fee, based at least in part on determining a referring user associated with a user profile of the first user; a transfer of credits equivalent to a second percentage of the payee fee from the payment service to a user profile associated with an immediate payee based at least in part on determining an immediate payee based at least in part on the first transaction data, wherein the immediate payee includes a second user. and causing a transfer of value, including A method for providing Article 20: One or more computer-readable media containing computer-readable instructions that, when executed by the one or more processors, cause the one or more processors to perform the method of clause 19. Article 21: one or more processors; one or more computer-readable media containing computer-readable instructions; A system comprising: the computer readable instructions, when executed by the one or more processors, configure the system to perform the method of clause 19. system.

Claims

1. A method performed by one or more servers associated with 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 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, Transfer of the first number of credits from the user profile associated with the first user to the user profile associated with the second user, The transfer of a second number of credits from the user profile associated with the second user to the payment service, and Transfer of a portion of the second number of credits as a credit allocation from the payment service to the user profile associated with the first user, This causes a transfer of values ​​that includes, A method for providing this.

2. The method according to claim 1, wherein the transfer of a portion of the second number of credits to the user profile associated with the first user reduces at least one of the portion of the second number of credits transferred to the user profile of a user referred by the first user, or the portion of the second number of credits transferred to the user profile of the first user's immediate recipient.

3. The method according to claim 1, wherein the portion of the second number of credits to be transferred to the user profile associated with the first user is calculated as a predetermined percentage of the second number of credits.

4. The method according to claim 1, wherein the portion transferred to the user profile associated with the first user includes at least one of credits or currency.

5. The method according to claim 1, further comprising associating the portion transferred to the first user with a user profile associated with the first user as a cumulative balance, wherein the cumulative balance is convertible to currency upon request by the first user.

6. A computer-readable medium having computer-readable instructions, wherein, when the computer-readable instructions are executed by one or more processors, the computer-readable medium causes the one or more processors to execute the method according to any one of claims 1 to 5.

7. One or more processors, A computer-readable medium containing computer-readable instructions, A system equipped with, A system wherein the computer-readable instruction, when executed by one or more processors, is configured to perform the method according to any one of claims 1 to 5.

Images