PEER TO PEER EMAIL BASED FINANCIAL TRANSACTIONS
A method for peer-to-peer e-commerce transaction between a first user and a second user that is facilitated by a payment server is disclosed. The method including receiving a money request from a first user, wherein the money request identifies a second user from which money is requested. The method further including transmitting a money request email message to the second user, wherein the money request email includes a token and receiving a response email message to the money request email message, wherein the response email message includes the token. The method further including determining whether the second user is a member based on the received token and an email address associated with the response email message.
Latest @PAY IP HOLDINGS LLC Patents:
This application claims the benefit of U.S. provisional application No. 61/794,675, filed on Mar. 15, 2013, which is incorporated by reference as if fully set forth.
FIELD OF INVENTIONThe present invention is related to electronic payment systems.
BACKGROUNDSome email-based payment methods require cumbersome web-based authentication processes to complete a transaction. This requires the user to have an active internet connection or the transaction may typically not be completed. As mobile devices are used for a greater percentage of online transactions, this may present a problem since mobile or wireless internet access may be less reliable than wired access. Many users have their applications and accounts attached to more than one device. Current electronic payment systems may be cumbersome when utilized on mobile devices. There is a need for a method for making transactions that may be easily shared on devices from desktop, laptop, tablet, smartphone and mobile phones. Email is the perennial application that is shared and is the assumption of most of these devices. Virtually every online application requires an email address as the basis for signing up.
Individuals that need to collect money from large groups of people need a tool that is fast and easy to use and is designed for the nonprofessional. Small organizations, community groups, churches and families may not have the capacity to make a website with a payment page. These types of organizations may require an accessible tool for collecting and sending money. Many of these groups already organize communication through group email lists. A tool that enables the sending of a single email message to multiple users requesting payment may be a convenience. The capacity to request or send money from multiple recipients may be welcomed in the marketplace.
The driver of online monetary transactions is businesses collecting money from individual customers. Most individual customers have payment accounts with businesses that allow for transactions to happen in an expedited manner. These transactions are either a one-time transaction or an on-going registration. Although many businesses allow customers to register accounts and submit payments these accounts only allow for the transfer of funds in a single direction. They do not allow the customer to accept money and this is a logical outcome based on a perspective that the vendor provides the payment service. A vast population of online consumers register to pay money but not to receive money because it is a convenience provided by the vendor. As an alternative if the payment tool is provided by the customer and the network to which they are associated with new functional possibilities arise. Systems like PayPal integrate across vendors. However all of these methods are dependent on making payments on URL pages. In order to do any of these processes the users must already have an email account. As a number of registered email based transactions grow the integration of those users into a single connected network may be desired. Giving individual members the same abilities as the vendor may be desired.
There are numerous ways to send money and receive money through electronic messaging. PayPal and Western Union are examples of how to send money directly to an individual's bank account. In all of these systems there are inherent distinctions between businesses and individual users. How a user may interface with a business may vary from how individuals correspond with each other. Although all of these systems may utilize email messages to send receipts and status updates, they use URLs in order to submit the transaction. Organizing a social network of users based on their email accounts may be welcome in the market place. Designing a system where monetary transactions may be performed by email and a user receives updates on payment requests may eliminate the complicated setups and plugins that are required on web-based transactions. This web-based transaction may be replaced by a one-time sign up and the capacity to request payments with no fee and no integration of systems. Password secured email accounts may serve an additional function as a secure site to approve transactions eliminating redundant login information.
In an effort to expedite checkout many vendors may try and register an individual as a customer and store credit card information and delivery instructions so as to allow the user to skip many cumbersome steps. They may also use other plugins on the checkout page where the customer is already registered with a payment service. Both nonprofits and businesses promote their organizations through email advertising campaigns. Many customers also receive updates and invoices through email but are ultimately driven to web URLs to complete transactions. Businesses and nonprofits may benefit from an payment service that may allow customers to respond directly to an offer by sending the email with no need for a username or password. This may eliminate steps in the process of purchasing or donating. Being able to identify users with this ability may be to an organization's advantage in the marketplace. At the same time, it allows the customer to share the offer within that payment network. Vendors and nonprofits may welcome the new customer base that has access to the email payment gateway and create offers that incentivize the sharing and promotion of those deals with the community of the email payment gateway.
Sending money to a daughter in college, collecting money for a baseball team, buying clothes on target.com and paying rent all represent different levels of sending money. Each of them has a different way of making the payment. A payment method that may unify all of these methods into a single field in which all of the actors may participate in a network may be ideal. Although participation in many social networks vary and many automated payment systems limit their vendors, virtually all of these actors have email accounts as a given of online life. Forming a network of users that is based in an email payment system and that exploits the social interactions may be welcome in the market place. An email based financial transaction for individuals to send and receive money is the next logical step.
SUMMARYThe system described herein may comprise a network that allows registered individual customers to make financial transactions using email payment gateway. Registered individuals and organizations may send and receive payments from other members within the network with credit/debit cards and bank account information. Payments may be made by responding to emails. This network permits individuals and organizations to register and use the email payment gateway through online sign up without the need for a business to business integration. This allows both the sending and receiving of money to any member in the network. It also allows registered users to send a group email with the capacity for all of those recipients to pay them in email based responses. This allows for a similar functionality as email campaign management systems like MAILCHIMP or CONSTANT CONTACT but with the ability to do transactions built in. In this embodiment the email payment technology may take on aspects of social networking allowing for profile and public pay pages that may let campaigns and offers go viral. An offer from a vendor or individual may travel the network by virtue of the community's social interactions.
A method for peer-to-peer e-commerce transaction between a first user and a second user that is facilitated by a payment server is disclosed. The method including receiving a money request from a first user, wherein the money request identifies a second user from which money is requested. The method further including transmitting a money request email message to the second user, wherein the money request email includes a token and receiving a response email message to the money request email message, wherein the response email message includes the token. The method further including determining whether the second user is a member based on the received token and an email address associated with the response email message.
A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:
When used herein, the term “token” may refer a string or file used to authenticate a transaction. A token may be one or multiple encrypted strings, files, passwords, cyphers or other data which may contain information used to perform or authenticate a transaction when sent to payment servers. These tokens may be encrypted using a public-private key encryption system. The vendor or a party with knowledge of the vendor's private key may generate an encrypted token. Alternatively, a payment system or e-commerce site may generate this token on behalf of the vendor.
When used herein, the term “member” may refer to a person that is a registered with an account.
When used herein, the term “individual” may refer to people that are online.
When used herein, the term “initiator” may refer to a member that starts a transaction by contacting one or more recipients.
When used herein, the term “responder” may refer to a recipient that responds to a communication from an initiator regarding the transaction.
When used herein, the term “transaction request” may refer to a general term for receiving money or sending money.
When used herein, the term “email-targeted token” may refer to a token associated with a specific email address.
When used herein, the term “URL-targeted token” may refer to token not associated with a specific email address and that may be forwarded and used by other members.
When used herein, the term “pay page” may refer to a publicly accessible web page where individuals may make payments to members.
Disclosed herein are processor-executable methods, computing systems, and related technologies for peer to peer email based financial transactions. While the technologies described herein are discussed using e-mail as an example, they may also be applicable to similar communication mediums, such as SMS and MMS communication channels.
The peer to peer system described herein allows the payment server 140 to allow individual members the same ability to collect money as well as pay vendors. Members may quickly send each other money with minimum information. Members get a publicly accessible web page for receiving payments. Members may send their own email campaigns with the ability to send and collect money. Members may socialize and share offers.
As described hereinafter in greater detail, the system described herein allows a user to create a profile that has a public pay page. A user may generate a quick request for money in its simplest form with only two input fields. This user may be a member that is registered with an e-commerce website. A user may generate a quick send message to send money in its simplest form with only two input fields. A user may use an email blaster feature to design and send an email requesting money with multiple amounts, graphics, and buttons to one or multiple individuals. When a request to send out an email blast is received, the system may generate a type of email for members and a different type of email for non-members. A user may respond to other solicitations. For example, if the user is a member, they may respond directly using an email message and may not need to login whereas a nonmember user may be directed to an URL which asks them to register and/or login. A user may maintain email address book and email campaigns. A user may monitor email campaign responses. A user may schedule payments and reminders. A user may schedule email reminders to themselves with response mailto hyperlinks that let the user maintain the account from email. A user may select an interface that adapts the system to being more geared to a payroll or invoicing system. The system may be configured for competitive bidding or limited time offers that monitor quantities or expiration dates that members respond to as individuals or as communities.
The customer devices 150 and 156 may be, for example, a cellular phone, a smartphone, a desktop computer, a laptop computer, a tablet computer, or any other appropriate computing device. As shown in
Alternatively or additionally, the web browser unit 155 may implement Rich Internet Application (RIA) and/or multimedia technologies such as ADOBE FLASH and/or other technologies compatible with Internet based communications. The web browser unit 155 may implement RIA and/or multimedia technologies using one or web browser plug-in modules (e.g., ADOBE FLASH), and/or using one or more sub-modules within the web browser unit 155 itself. The web browser unit 155 may display data on one or more display devices (not depicted) that are included in or connected to the customer device 150, such as a liquid crystal display (LCD) display or monitor. The customer device 150 may receive input from the user of the customer device 150 from input devices (not depicted) that are included in, or connected to, the customer device 150, such as a keyboard, a mouse, a microphone or a touch screen, and provide data that indicates the input to the web browser unit 155.
The payment server 140 may include an HTTP server module 141, a token generator 142, a processor 143, memory 144, a token decoder 145, an order execution module 146, a DB module 147, a message processing module 148, and an interface module 149.
The HTTP server module 141 provides a website that may be accessed by a customer device 150. The HTTP server module 141 may implement the HTTP protocol, and may communicate Hypertext Markup Language (HTML) pages and related data from the website to/from the customer device 150 using HTTP. The vendor server 120 may be connected to one or more private or public networks (such as the Internet), via which the HTTP server module 141 communicates with devices such as the customer device 150. The HTTP server module 141 may generate one or more web pages and may communicate the web pages to the customer device 150, and may receive responsive information from the customer device 150.
The HTTP server module 141 may be, for example, an APACHE HTTP server, a SUN-ONE Web Server, a MICROSOFT INTERNET Information Services (IIS) server, and/or may be based on any other appropriate HTTP server technology. The payment server 140 may also include one or more additional components or modules (not depicted), such as one or more load balancers, firewall devices, routers, switches, and devices that handle power backup and data redundancy.
The token generator 142 may generate tokens for use in e-commerce transactions. Tokens may be encrypted strings which contain information to perform transactions. A token may be one or multiple encrypted strings, files, passwords, cyphers or other data which may contain information used to perform or authenticate a transaction. A token may include one or more of the following parameters or other parameters not listed below:
-
- a) private-key: The private key provided by the payment server 140.
- b) public-key: Payment server's 140 public key, provided by the payment server 140.
- c) partner-id: The partner ID given provided by the payment server.
- d) environment: The environment the vendor wants to generate buttons for.
This distinguishes whether the token is being used in a testing environment or in the live environment (and running real transactions).
-
- e) config: The path to a configuration file in yml format. This may hold a default set of information, e.g., private_key, public_key, partner_id, and other information—so they don't have to be entered separately each time a token is generated. The configure field may also contain information specific to an offer (e.g. dollar amount) or a customer (e.g., card token) if multiple tokens are being generated with similar components.
- f) type: The type of token to generate (site, email, universal). There are multiple types of tokens that a token generator may generate and decode. For example, site tokens may be used for website transactions, email tokens for two-click email payments, and universal tokens for email validations.
- g) card: The card token associated with the recipient of this token. When a customer is registered with the payment server 140, the vendor receives a credit card token—a unique identifier that references the specific card associated with that customer and vendor. When the vendor is generating a token to submit to payment server 140, they may include the card token as a customer identifier.
- h) email: The email associated with the receipt of this token.
- i) URL: The Signup URL the recipient should go to if customer doesn't have payment information registered with payment server 140.
- j) amount: The amount a user should be charged for the transaction the token is generated for.
- k) user-data: Data to pass back as a reference. This data may include custom data that the vendor may want to pass through the payment server 140 and receive back when a transaction has completed. It may include an item reference number or SKU, customer address, or other piece of data that is not required by payment server 140 to complete a transaction, but that the vendor wants associated with that transaction.
- l) expires: Expiration date for token, integer value of seconds since epoch.
- m) header-user-agent: The HTTP_USER_AGENT from the request header. HTTP headers are sent as part of a request from a customer's web browser unit 155 for a piece of information. These headers define the parameters that the web browser unit 155 is expecting to get back. The user-agent is the identifier of the software that is submitting the request—typically the identifier of the web browser unit 155 that is requesting the content.
- n) header-accept-language: The HTTP_ACCEPT_LANGUAGE from the request header. The accept-language is the acceptable language for the response—e.g. the language in which the web browser unit 155 is requesting the content be sent back.
- o) header-accept-charset: The HTTP_ACCEPT_CHARSET from the request header. The accept-charset is the character sets that are acceptable for the response—e.g. the character set in which the web browser unit 155 is requesting the content be sent back.
- p) ip-address: The IP address of the token recipient.
To confirm an e-commerce transaction via email, the customer sends an email embedded with a token to the payment server's 140 address. The system 100 is designed to allow the vendor flexibility to offer deals for a limited time or number or responsive to available inventory. For example, the token may be configured to expire by default after two weeks, or any predetermined time, or never expire.
The memory 144 may be configured to store information associated with e-commerce transactions. This may include inventory information, information used to generate web pages, customer information, and other e-commerce data.
The payment server 140 may also be in communication with the peer to peer (P2P) unit 130. The P2P unit 130 may comprise an offer creation unit 131 and an account management unit 132, and as described in greater detail hereafter, may facilitate P2P transactions.
The customer bank accounts 190 and 191 may be controlled by a third party system bank. The payment server 140 may communicate with the customer bank accounts 190 and 191 to verify that the customer has adequate funds or credit for the requested purchase. For example, the customer bank accounts 190 and 191 may be a controlled by VISA, AMERICAN EXPRESS, MASTERCARD or any other bank or banking or financial network that a customer may use for online payment. The customer bank accounts 190 and 191 may be a server for virtual currencies, such as BITCOIN, etc. While not shown in
The system 100 may also comprise a bank/escrow server 180 to store funds in escrow during transactions. While not shown in
A payment processing system 181 may serve to facilitate transactions by performing payment processing duties. While not shown in
As examples described below may use different types of tokens, an email-targeted token and URL-targeted (or shareable) tokens. These two are selected as examples, but other tokens may be used.
For email-target tokens, an initiator using a customer device 150 may compose an email request and add a list of recipients. When the initiator sends the email, the payment server 140 may determine which recipients are registered with payment server 140 and which are not. The payment server 140 may send two separate emails—one to members and one to non-members. The members get an email checkout with mailto hyperlinks and the non-members get a link to the URL pay page and a sign up. The mailto hyperlinks sent to members may contain a token for processing a two-click email checkout. The token may comprise an embedded identifier of the email address of the recipient (that is the intended responder), along with the other necessary information required to complete the transaction. The intended recipient/responder may send a response email, using e.g. customer device 156, to the payment server 140. If the response email contains the token, the payment server 140 decodes the token, confirms that the embedded email address matches the address the token was submitted from, and, assuming all checks pass, the payment server 140 processes the transaction. If an individual other than the intended recipient/responder returns the token to the payment server 140, the process may fail when the email address contained in the token is compared to the submitting email address. This individual may receive an error notification instructing them to complete their purchase by clicking on URL to a payment page on which they may fill out their payment information and simultaneously register for an account with the payment server 140.
For URL-targeted tokens (i.e. sharable tokens) the initiator, using a customer device 150, may compose an email request and adds the list of recipients. When the initiator sends the email campaign, the payment server 140 sends out an identical email to each recipient. Within this email is a mailto hyperlink, which contains a token for processing a two-click email checkout. This token contains necessary information required to complete the transaction, but it may not contain any identifier of the intended recipient/responder. If a member responds to the campaign, the payment server 140 recognizes the email address that is in the submitted email message (not in the token), reads the content of the token, and (if all other checks pass) processes the transaction. If the response is from a nonmember, the payment server 140 responds by sending an email with a URL link to the pay page of the initiator of the request. At that point the nonmember enters their payment information and completes the transaction.
URL-targeted tokens may be forwarded between individuals, it may be used by any member, and there is a built-in path for nonmembers to be directed to a URL at which they may complete a transaction.
In some embodiments, sending money may be processed differently than requesting money in regards to which token type is used. This may be for security reasons. For example, in sending money, the token used may be the email-targeted token. Whereas in requesting money, the email-targeted token and/or the URL-targeted token may be used.
The web browser window may include a control area 700 that includes a back button 702, forward button 703, refresh button 704, home button 705, and address field 706. The control area 700 may also include one or more additional control elements, such as bookmark page etc. An initiator or responder using a customer device 150 or 156 may select the control elements in the control area 700. The selection may be performed, for example, by clicking a mouse or providing input via keyboard, touch screen, and/or other type of input device. When one of the control elements is selected, the web browser unit 155 may perform an action that corresponds to the selected element. For example, when the refresh button 704 is selected, the web browser unit 155 may refresh the page currently viewed in the web browser window.
While not shown in
Once an individual is a member they are able to begin sending or receiving payments. Assuming they are logged into their member account, they may send email transaction requests to other individuals. A member may send a transaction request to one or many email addresses and those email addresses are stored in the profile page. A transaction request may be asking for money or sending money. When logged in their account the member may compose the content of the transaction request email and determine the email list of recipients. The email is sent from there. In the original design, the system sent an email message containing the details of the request, instructions on how to complete the transaction and at least one mailto hyperlink associated with the transaction amount to registered members or a URL link to a pay page for unregistered individuals. With the URL Targeted Token, all users may receive a mailto hyperlink for generating a response email.
In one embodiment, each registered address may be assigned to different payment options. Input fields 1326-1330 allow a user to change a password associated with the account. Input field 1332 allows a user to select an avatar (i.e. an image) to be displayed with the user's pay page. Input field 1334 solicits a user to enter organizational details, in case the account is associated with an organization. Further, as the selections are updated, the web browser unit 155 may update the web page 1310 to indicate additional, or more specific, questions that may be associated with the selections.
As shown in
As shown in
While the examples described herein show a customer device 150 accessing the e-commerce features using a web browser, it should be understood that this is just one example. The methods described herein may be performed by different types of customer devices 150 such as a mobile phone, tablet, personal computer etc. The customer device 150 may perform e-commerce transactions using, e.g., a web browser, an app, a program installed on a personal computer, etc.
In another embodiment the information included in the URL Targeted Token and the Email Targeted Token may be in a single token. This token may include additional data including an identifier of an intended use. The e-commerce system 170 may receive the response email with this token. The e-commerce system 170 may parse the information in the token. The e-commerce system 170 may be configured to determine, based on the included the intended use data the parameters of the action to be taken. In this example a send money email may contain both the data for URL and Email Targeted Token data and also include information dictating that the processing maintains the parameters required by email targeted tokens. The e-commerce system 170 may decode the token using this intended use data to determine the process and what other data in the token is relevant.
As used herein, the term “processor” broadly refers to and is not limited to a single- or multi-core processor, a special purpose processor, a conventional processor, a Graphics Processing Unit (GPU), a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, one or more Application Specific Integrated Circuits (ASICs), one or more Field Programmable Gate Array (FPGA) circuits, any other type of integrated circuit (IC), a system-on-a-chip (SOC), and/or a state machine.
As used to herein, the term “computer-readable medium” broadly refers to and is not limited to a register, a cache memory, a ROM, a semiconductor memory device (such as a D-RAM, S-RAM, or other RAM), a magnetic medium such as a flash memory, a hard disk, a magneto-optical medium, an optical medium such as a CD-ROM, a DVDs, or Bluray-Disc, or other type of device for electronic data storage.
Although the methods and features described above with reference to
Claims
1. A method for peer-to-peer e-commerce transaction between a first user and a second user that is facilitated by a payment server, the method comprising:
- receiving, by a receiver, a money request from a first user, wherein the money request identifies a second user from which money is requested;
- transmitting, by a transmitter, a money request email message to the second user, wherein the money request email includes a token;
- receiving, by the receiver, a response email message to the money request email message, wherein the response email message includes the token; and
- determining, by a processor, whether the second user is a member based on the received token and an email address associated with the response email message.
2. The method of claim 1, further comprising transmitting a URL pay email message to the email address associated with the response email message, if processor determines that the second user is not a member.
3. The method of claim 1, further comprising:
- processing the peer-to-peer e-commerce transaction if the processor determines that the second user is a member; and
- transmitting, by the transmitter a notification that the peer-to-peer e-commerce transaction was successful.
4. The method of claim 1, wherein the peer-to-peer e-commerce transaction is performed through a social network website.
5. The method of claim 1, wherein the peer-to-peer e-commerce transaction is integrated into an email server.
6. The method of claim 1, wherein the money request from the first user identifies a plurality of users from which money is requested.
7. A method for peer-to-peer e-commerce transaction between a first user and a second user that is facilitated by a payment server, the method comprising:
- receiving, by a receiver, a money request from a first user, wherein the money request identifies a plurality of recipients from which money is requested;
- determining, by a processor, whether each of the plurality of recipients are members; and
- transmitting, by a transmitter, a plurality of money request email messages to the plurality of recipients, wherein each of the plurality of recipients that is determined to be a member receives an email message comprising an email targeted token and each of the plurality of recipients that is not determined to be a member receives an email message comprising an URL targeted token.
8. The method of claim 7, further comprising receiving, by the receiver, a response email message to at least one of the plurality of money request email messages, wherein the response email message includes an email targeted token; and
- processing the e-commerce transaction based at least in part on the email targeted token and an email address associated with the response email message.
9. The method of claim 7, further comprising receiving, by the receiver, a response message to at least one of the plurality of money request email messages, wherein the response email message includes an URL targeted token;
- registering at least on user associated with the response message; and
- processing the e-commerce transaction based at least in part on the URL targeted token.
10. The method of claim 9, wherein the response message is received via a web page.
11. A system for peer-to-peer e-commerce transaction between a first user and a second user that is facilitated by a payment server, the system comprising:
- a receiver configured to receive a money request from a first user, wherein the money request identifies a second user from which money is requested;
- a transmitter configured to transmit a money request email message to the second user, wherein the money request email includes a token;
- the receiver further configured to receive a response email message to the money request email message, wherein the response email message includes the token; and
- a processor configured to determine whether the second user is a member based on the received token and an email address associated with the response email message.
12. The system of claim 11, wherein the transmitter is further configured to transmit a URL pay email message to the email address associated with the response email message, if processor determines that the second user is not a member.
13. The system of claim 11, further comprising:
- the processor further configured to process the peer-to-peer e-commerce transaction if the processor determines that the second user is a member; and
- the transmitter further configured to transmit a notification that the peer-to-peer e-commerce transaction was successful.
14. The system of claim 11, wherein the peer-to-peer e-commerce transaction is performed through a social network website.
15. The system of claim 11, wherein the peer-to-peer e-commerce transaction is integrated into an email server.
16. The system of claim 11, wherein the money request from the first user identifies a plurality of users from which money is requested.
Type: Application
Filed: Mar 17, 2014
Publication Date: Sep 18, 2014
Applicant: @PAY IP HOLDINGS LLC (Wilmington, DE)
Inventors: James Kassemi (Albuquerque, NM), Dave Walz-Burkett (Albuquerque, NM), Chad Person (Albuquerque, NM)
Application Number: 14/216,256
International Classification: G06Q 20/10 (20060101);