Events such as war and natural disaster can affect millions of people's lives instantaneously; people watching the news want a fast, direct way to help. Collecting donations at self-checkouts and other point-of-sale (POS) systems is not uncommon. Typically, when ordering, a cashier asks a customer if the customer wants to donate or round up to the nearest dollar of their bill to donate to a predefined charity. This makes the customer feel uncomfortable with people standing in line behind them and with the cashier. Some customers feel pressure to donate even when they are not happy about the situation, other customers refuse to donate out of principle because of the pressure even when they would have otherwise donated if not asked by the cashier. Most customers do not like being asked by a cashier if they would like to donate to a charity at checkout.
People in need usually need help immediately and urgently. Infrastructures and resources, such as bank account access, can be compromised in times of natural disaster. People want to donate, but they want transparency in where their money is going to and how it is being allocated. It is difficult for people to verify which donation groups are the best. Furthermore, organizing funding campaigns is difficult and time consuming and most people do not want to take ownership of such tasks.
In various embodiments, methods and a system for donation-based transaction integration are presented. Charitable organizations are registered to receive donations from a store. During registration, the organization's cryptocurrency wallet identifier is obtained and a summary page of information about the organization and its charitable works are obtained. The charitable organizations are vetted using third-party services and/or a blockchain ledger to determine whether those organizations meet certain standards of a given retail store.
Interfaces are provided for store managers to add and search for vetted charitable organizations. A time period is set by the manager, which allows the manager to select a particular charitable organization for a current period of time at the store or at a group of stores. At the start of a current period of time, an agent on the transaction terminals of the store permits customers to read the summary page for the selected organization and add a charitable donation onto their transaction total to donate to the organization. The donated funds are used to purchase cryptocurrency into a wallet held by the store. At the end of each day or a preset elapsed period of time, the cryptocurrency in the store's wallet is transferred to the selected organization's wallet over the blockchain. The store can use the ledger maintained on the blockchain for the store's wallet to produce summaries and reports on the donations made by the store by charity and selected periods of time.
As stated above, current approaches to collecting donations can seem too public and can be associated with too much pressure such that many customers are uncomfortable with donation requests by cashiers during checkout. The approach taken herein and below is to pre-vet potential charitable organizations and integrate donation requests seamlessly into the transaction workflow without substantially modifying the transaction workflow at the transaction terminals. Charitable donation requests are only pursued upon the private and affirmative request of the customer during checkout. Donations received are managed in a store cryptocurrency wallet and sent, at predefined intervals of time, to designated wallets of the charitable organizations over the blockchain. A ledger maintained on the blockchain (BC) permits reports to be generated to illustrate the donations made by the store during user-defined periods of time and to which organizations the donations were given.
As used herein, a “fiat currency” is a government backed currency, such as U.S. dollars, European Euros, Mexican Pesos, Brazilian Reals, etc. A “cryptocurrency” includes different types, such as Bitcoin® (BTC), Ethereum® (ETH), Dodgecoin® (Dodge), etc.
The terms “consumer,” “customer,” and/or “donator” may be used synonymously and interchangeable herein. This is an individual who is performing a checkout at a transaction terminal and elects to make a donation to a store-selected charity by including a donation amount above the transaction total when paying for the transaction.
Moreover, various components are implemented as one or more software modules, which reside in non-transitory storage and/or hardware memory as executable instructions that when executed by one or more hardware processors perform the processing discussed herein and below.
System 100 includes a cloud 110 or a server 110 (hereinafter just “cloud 110”), transaction terminals 120, management terminals 130, charitable organization servers 140, and distributed BC devices/servers 150. Cloud 110 includes one or more processors 111 and a non-transitory computer-readable storage medium 112 (herein after just “medium”), which includes instructions for a transaction manager 113, a wallet manager 114, an application programming interface (API) 115, a donation manager 116, and a BC API 117. The instructions when provided to processor 111 cause processor 111 to perform operations discussed herein and below with respect to 113-117.
Each transaction terminal 120 includes one or more processors 121 and medium 122, which includes instructions for transaction manager 123 and donation agent 124. The instructions when provided to processor 121 cause processor 121 to perform operations discussed herein and below with respect to 123-124.
Each management terminal 130 includes one or more processors 131 and medium 132, which includes instructions for a donation interface 133. The instructions when provided to processor 131 cause processor 131 to perform operations discussed herein and below with respect to 133.
Each charitable organization server 140 includes one or more processors 141 and medium 142, which includes instructions for a wallet application 143 and a registration interface 144. The instructions when provided to processor 141 cause processor 141 to perform operations discussed herein and below with respect to 143 and 144.
Each distributed BC device/server 150 includes one or more processors 151 and medium 152, which includes instructions for BC APIs 152. The instructions when provided to processor 151 cause processor 151 to perform operations discussed herein and below with respect to 153. BC devices/servers 150 maintain the BC.
Initially, charitable organizations register to be included in donations being collected by a retailer or stores of the retailer using registration interface 144 which interacts with donation manager 116. During registration, a registering organization provides a cryptocurrency wallet identifier (e.g., wallet address) associated with that organization's wallet application (herein after just “app”) and the registering organization provides a summary page of information about the works and history of the organization.
Donation manager 116 then vets each registered organization. This can be done in a variety of manners, such as through third-party services that rate organizations based on their charitable giving and operational expenses relative to the giving. Donation manager 116 may also inspect the public ledger on the BC using the wallet identifier of the registering organization. This will show donations received and funds withdrawn and to what wallets withdrawn funds were sent. Based on third-party services and their ratings and an analysis of a registering organization's BC ledger, the registering organization receives a score, when the score is above a threshold value, the registering organization is accepted to receive consideration of donations from the retailer.
Alternatively or additionally, the retailer or a store of a retailer can register charities for consideration by donation manager 116 through donation interface 133. This can be done by scanning the cryptocurrency wallet identifier during registration at the management terminal 130 through the donation interface 133 and providing a link to a web page of the charity that provides a summary about the works of the charity. Again, donation manager 116 vets the suggested charity before inclusion in a list of charities available from donation manager 116.
Donation manager 116 maintains a data store or a table of vetted registered charities alone with their wallet identifiers and summary pages of information or links to their summary pages. At the conclusion of a predefined period of time, donation manager 116 selects a certain number of the charities for potential inclusion in a next period of time as a charitable organization that a store of a retailer can select for receiving donations from customers of a given store.
A manager of a retail store interacts with donation interface 133 for purposes of selecting a charity from the certain number of charities determined by the donation manager 133 for the next period of time. Once the manager selects the charity, donation manager 116 sends the selected charity's wallet identifier and link to its summary page to donation agent 124.
On a transaction splash screen associated with a transaction interface of transaction manager 123, a sub-screen is rendered by donation agent 124 that identifies the charity or the type of charity. This sub-screen is maintained within the transaction interface so as to not interface with transaction information or transaction options being presented by the transaction interface during the transaction as the transaction interface screens change during the transaction. It is noted that at this point there is no modification to the transaction manager 123 nor to the transaction interface since the sub-screen can be overlayed on top of and positioned by the donation agent 124 so as to not interfere with the transaction interface screens.
Whenever a customer touches the sub-screen during the transaction, donation agent 124 renders a new sub-screen overlaid on top of the transaction screens for the customer to enter an amount of the donation and/or for the customer to obtain the full summary page of information on the charity. The new sub-screen includes options processed by donation agent 124, the options can include to go back to the transaction screens which will stop the overlay of the new sub-screen and return the customer to the transaction screens with the original sub-screen occupying unused space of the transaction screens such that it is still visible to the customer for re-selection if desired. The sub-screen can also include a keypad for the customer to enter a donation amount along with an enter or “OK” option. Furthermore, an option to view the summary information page for the customer may be available that when selected renders the page via a link within yet another sub-screen. This further summary page can include a “go back” or “return option that will return the customer back to the new sub-screen where the customer is able to enter a donation or return back to the transaction interface screens without providing any donation.
When the customer enters a donation amount through the new sub-screen or the donation screen and selects enter or “OK,” the donation agent 124 receives the donation amount and communicates the donation amount via an API to transaction manager 123. Transaction manager 123 adds the donation amount to the running transaction total along with a line item indicating that the donation amount is to go to the charity. When a customer is set to pay, the transaction screen renders a line-item detail screen to the customer with options to remove items, the customer can elect to remove the donation line item before proceeding to pay.
Once the customer pays for the transaction, donation agent 124 notifies wallet manager 114 with the wallet identifier of the charity and with the amount. Wallet manager 114 initiates a cryptocurrency purchase operation with a cryptocurrency exchange for the donation amount which causes the exchange to collect the donation amount from a financial account registered to cloud 110, purchase the cryptocurrency, and transfer the cryptocurrency over the BC into a wallet identifier associated with a wallet of the store. The cloud 110 may also maintain a ledger indicating the funds that are to be received from the store for the donation amount and the amount of cryptocurrency that was purchased using the funds. The ledger may also include a variety of additional information such as store identifier, terminal identifier, transaction identifier, transaction details, calendar date, time of day, etc.
At a store-set interval of time, the cryptocurrency held in the store's wallet by wallet manager 114 for the charity is transferred over the BC using BC API 117 and BC APIs 153 to the charity's wallet using the charity's wallet identifier. The BC maintains a public ledger for the store's wallet using the store's wallet identifier which shows the funds moving into and out of the store's wallet and the wallet identifiers that received transfers from the store's wallet. This allows donation manager 117 to generate reports for the store and/or the retailer associated with the store and other stores that have other store wallets with cloud 110. Donation interface 113 can be operated to obtain the reports and define custom reports. For example, a report requested for store X may indicate that store X donated over $1,000,000 to Toys for Tots® in the last fiscal year.
System 100 integrates seamlessly and nearly transparently into the transaction workflow of a terminal 120. The donation screens and workflow are independent and separate from the transaction workflow. Integration is achieved through a single API call between the donation agent 124 and transaction manager 123 for purposes of communicating a line-item to add to the transaction running total for a charitable donation including any added service fee. Minimal changes are needed to the transaction manager 123 and no changes are required to the transaction workflow for purposes of achieving donation-based transaction integration.
System 100 permits retailers and customers of retailers to give back to their community and help those in need through a non-intrusive and transaction integration approach. Customers do not feel pressured for donations as customers affirmatively make the choice as to whether to donate or not and such decisions of the customers are maintained in privacy. The donations are made via cryptocurrency wallet-to-wallet transactions which incur minimal fees over the BC, leave audit trails, maintain ledgers, and provide enhanced security. Additionally, funds can be transferred worldwide without fiat currency conversion fees.
In an embodiment, terminal 120 is a self-service terminal (SST), self-checkout, automated teller machine (ATM), or a point-of-sale (POS) terminal. In the case of a cashier-assisted POS transaction, the customer can select the donation entry screen on a customer-facing display at any point during the transaction and before payment such that the cashier is unaware of the customer's donation until payment is requested. This alleviates the cashiers of feeling pressure to ask customers for donations.
In an embodiment, donation interface 133 permits a store manager to override charity selections and designate a charitable organization for vetting and for setting as the store's charity for a set-period of time. Donation manager 116 sets the charity overridden on donation agent 124. In this way, store employees can rally around a specific cause that is important to them and override available selections determined by the donation manager 116.
In an embodiment, a store manager can set the period of time during which a single charity is being offered for customer donations on their store terminals 120 via donation interface 133 through interaction with donation manager 116. For example, a single charity may be available for donations through donation agent 124 within the manager's store for 1 week, 1 month, 3 months, etc.
In an embodiment, a store manager can set the interval of time for wallet manager 114 to transfer cryptocurrency donations to the charities. For example, a selected charity's donations received are transferred from the store's wallet managed by wallet manager 114 to the charity's wallet once a day, twice a week, once a week, once a month, etc.
In an embodiment, the line-item detail provided by agent 124 to transaction manager 123 for a donation includes a legal entity name for the charitable organization and its registered business address. The transaction receipt printed for a customer transaction includes this level of detail for the donation. This permits the customer to use the receipt in support of taking a charitable donation on their taxes.
In an embodiment, an authorized retail user or regional manager can operate management terminal 130 for purposes of selecting a charitable organization for presentation by donation agent 124 via donation manager 116 on terminals 120 associated with a user-defined group of stores. Thus, a regional chain of stores can provide customers the same charitable organization to donate to during their transactions.
The embodiments of
In an embodiment, the device that executes the transaction donation manager is cloud 110. In an embodiment, the device that executes the transaction donation manager is server 110. In an embodiment, the remittance service is all or some combination of 114, 115, 116, 117, 124, 133, and/or 144, as discussed above with system 100.
At 210, the transaction donation manager receives a donation amount in a fiat currency from an agent 124 when a transaction is completed by a customer on a terminal 120. That is, when a transaction manager 123 indicates that payment was received for completion of the transaction, agent 124 reports the donation amount made by the customer in a fiat currency.
At 220, the transaction donation manager uses the donation amount in the fiat currency to purchase a second amount in cryptocurrency that is transferred to a wallet over a BC. The wallet is maintained by the transaction donation manager. In an embodiment, the cryptocurrency is BTC or ETH.
In an embodiment, at 221, the transaction donation manager provides the amount of fiat currency and a wallet identifier for the wallet of the transaction donation manager to an exchange to purchase the cryptocurrency and transfer the second amount of cryptocurrency to the wallet. A funds transfer can be initiated using an API of the exchange for the transaction donation manager to provide the amount of fiat currency from a financial account associated with the entity or retailer that operates the terminal 120 or that operates the transaction donation manager.
At 230, the transaction donation manager obtains a charity wallet identifier for a charity that is to receive the donation amount. In an embodiment, at 231, the transaction donation manager receives the charity wallet identifier from the agent 124. In an embodiment, the transaction donation manager knows the current charity available for donations on the terminal 120 and obtains the charity wallet identifier based on a charity identifier associated with the charity.
At 240, the transaction donation manager transfers the second amount of cryptocurrency from the wallet of the transaction donation manager to a charity wallet for the charity over the BC using the charity wallet identifier. This is a wallet-to-wallet transfer and experiences less fees and quicker response times from the BC.
In an embodiment, at 241, the transaction donation manager maintains a ledger separate from a BC ledger of the BC. The ledger records the amount in the fiat currency, the second amount of the cryptocurrency, and identifiers for the transaction, the transaction terminal and the charity.
In an embodiment, at 242, the transaction donation manager iterates to 210 for a next transaction and a next donation from another customer at a preconfigured period of time. In an embodiment of 242 and at 243, the transaction donation manager sends the agent a second charity wallet identifier for a second charity and a link to a summary page for the second charity at the end of the preconfigured period of time. That is, the charity available for donations changes at the end of each preconfigured period of time.
In an embodiment, at 250, the transaction donation manager reports on total donations made to the charity from the wallet using a ledger maintained on the BC. The wallet identifier for the wallet of the transaction donation manager and the charity wallet identifier each have ledgers that are publicly accessible on the BC. The transaction donation manager accesses these ledgers to report the total donations made to the charity by the retailer associated with the terminal 120.
In an embodiment, at 260, the transaction donation manager receives a new wallet identifier associated with a new charity. The transaction donation manager vets the new charity based at least in part on a ledger associated with the new wallet identifier maintained on the BC. The transaction donation manager maintains the new wallet identifier for the new charity in a list of vetted charities based on the vetting.
In an embodiment of 260 and at 261, the transaction donation manager maintains a link to a summary page associated with the new charity in the list. In an embodiment of 261 and at 262, the transaction donation manager selects a predefined number of the vetted charities from the list at a configured period of time. The transaction donation manager presents the predefined number of vetted charities for a selection through an interface 133. The transaction donation manager receives the selection and provides a corresponding wallet identifier and a link to a corresponding summary page for the selected vetted charity to the agent 124.
The transaction donation agent interacts with the method 200. In an embodiment, the device that executes the transaction donation agent is transaction terminal 120. In an embodiment, terminal 120 is an SST, a POS terminal, an ATM, or a self-checkout terminal. In an embodiment, the transaction donation agent is all or some combination of 123 and/or 124.
At 310, the transaction donation agent receives a wallet identifier for a charity wallet and a link to a summary page of information for a charity associated with the charity wallet. In an embodiment, at 311, the transaction donation agent obtains the summary page using the link and uses the summary page when rendering donation screens.
At 320, the transaction donation agent renders donation screens associated with donating to the charity on a display of a terminal 120. The donations screens are rendered alongside of or overlaid on top of transaction screens during a transaction at the terminal 120.
In an embodiment, at 321, the transaction donation agent renders a donation activation screen alongside transaction screens associated with a start of a transaction and during a transaction. A sample donation activation screen is illustrated in
In an embodiment of 321 and at 322, the transaction donation agent renders the donation entry screen overlaid on top of the transaction screens in response to a customer activation of the donation activation screen. A sample donation entry screen is illustrated in
In an embodiment of 322 and at 323, the transaction donation agent provided a keypad for entry of the donation amount within the donation activation screen. The keypad is illustrated in
In an embodiment of 323 and at 324, the transaction donation agent renders a predefined number of recent donation amounts made to the charity within the donation entry screen. The bottom left of the donation entry screen as illustrated in
At 330, the transaction donation agent reports a donation amount received from a donation entry screen to a transaction manager 123 of the terminal 120. The transaction manager 123 integrates the donation amount as a line-item charity donation being made by a customer with the transaction details presented to the customer before payment of the transaction.
At 340, the transaction donation agent provides the wallet identifier and the donation amount to a server 110. The server 110 purchases a second amount of cryptocurrency using a fiat currency associated with the donation amount and transfers the cryptocurrency from a server-maintained wallet to the charity wallet over a BC.
In an embodiment, at 350, the transaction donation agent receives a new wallet identifier and a new link to a new summary page for a new charity from the server 110. The transaction donation agent replaces the wallet identifier and the link with the new wallet identifier and the new link for subsequent transactions on the terminal 120. In an embodiment, at 360, the transaction donation agent iterates to 320 for each subsequent transaction.
It should be appreciated that where software is described in a particular form (such as a component or module) this is merely to aid understanding and is not intended to limit how software that implements those functions may be architected or structured. For example, modules are illustrated as separate modules, but may be implemented as homogenous code, as individual components, some, but not all of these modules may be combined, or the functions may be implemented in software structured in any other convenient manner.
Furthermore, although the software modules are illustrated as executing on one piece of hardware, the software may be distributed over multiple processors or in any other convenient manner.
The above description is illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of embodiments should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
In the foregoing description of the embodiments, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Description of the Embodiments, with each claim standing on its own as a separate exemplary embodiment.