Method and system for managing data and enabling payment transactions between multiple entities

A system for conducting payment transaction includes a network-enabled server that communicates with one or more user devices, other network-enabled server computers, and a payment processing network server computer. The network-enabled server facilitates transactions between one or more merchants and users by a managing data flow and interactions between the merchants and the users, providing storage area for storing of all transaction related documents, and providing seamless integration with a payment processing network for payment processing.

BACKGROUND

In a traditional payment transaction scenario, a user uses a payment device at an access device to pay for a product or service. The payment device information is sent to a payment processing network, which communicates with an issuer of the payment device to authorize the transaction. The issuer merely checks if the user has enough balance/credit left in the account to cover the amount of transaction.

Thus, in the conventional method there is no validation of the transaction itself. For example, the issuer cannot request additional documentation from either the merchant or the user to verify whether the service/product that is subject of the transaction is actually required and/or provided to the user. In other words, nothing is done to check whether the transaction is genuine, proper, or actually initiated by the payment device holder. In the conventional system, if the user has enough balance/credit in his account and the required transaction details are provided by the merchant, the transaction is processed without additional verification. The problem is especially acute when there are more than two entities involved in a transaction where the entity paying for the product/service is not the entity that actually receives the product/service.

Currently, the existing payment processing systems are not equipped to handle the extra traffic that may be generated by the information/documentation related to each payment transaction that involves multiple entities. Thus, there is a need for a new infrastructure that can handle the increased traffic generated because of the extra validation processes and thereafter process payment once the transaction is validated.

SUMMARY

Embodiments of the present invention are generally related to processing payment transactions. In particular, certain embodiments of the present invention provide a system that enables end-user devices to interact directly with payment processing systems without having to go through another entity. Other embodiments of the present invention provide a method for performing payment transactions with added security and validation. The system provides a mechanism for managing all transactions associated with getting paid for performing a service or getting paid for selling a product. The system and method disclosed herein minimize the delay between performance of a service and getting paid for the performed service and/or selling a product and getting paid for selling a product.

Some embodiments of the present invention provide a system for processing transactions. The system comprises a payment processing network server computer configured to communicate with an issuer to process payment requests and a network-enabled server computer configured to communicate with one or more external systems. The network-enabled server computer is further configured to receive a payment request from a merchant computer for authorizing payment for a transaction, request additional information associated with the transaction from the merchant computer and send a validation request to a user device to validate the payment request. The network-enabled server computer further receives a response to the validation request and alias information about the user. Network-enabled server computer then determines payment account information based on the alias. The network-enabled server computer communicates the payment account information to the payment processing network server computer.

In some embodiments, the network-enabled server computer may also receive information from the payment processing network server computer indicating successful processing of the payment transaction and communicate the information to the merchant computer and/or the user device. In some embodiments, the network-enabled server computer communicates with the user device and the merchant computer using WSDL messaging techniques, RESTful computing techniques, and/or JSON.

Some embodiments of the present invention provide a network-enabled server computer. The network-enabled server computer includes an alias database comprising information about one or more aliases, an alias hierarchy database comprising association information between an alias and one or more objects associated with the alias, an application interface configured to communicate with one or more external devices, and a data storage configured to store data. In some embodiments, the one or more aliases comprise identifiers associated with a plurality of entities, wherein an entity includes an individual or a company. In some embodiments, the alias database includes payment account information associated with an alias. In some embodiments, the one or more objects include mobile communication devices, televisions, and gaming consoles. The application interface may be configured to communicate with the one or more external devices using WSDL and/or JSON messaging techniques.

Some embodiments of the present inventions provide a method for processing a payment transaction. The method includes receiving a first message from a merchant server computer requesting authorization for a transaction, sending a second message to the merchant server computer requesting additional information related to the transaction, and receiving a third message from the merchant server computer including the requested information. The method further includes sending a fourth message to a user device requesting a user to validate the transaction, receiving a fifth message from the user device including validation information, and receiving a sixth message from the user device including payment account information. Thereafter, the method further includes sending a seventh message to a payment processing network server computer including the payment account information and transaction information, receiving an eight message from the payment processing network server computer including results of the payment transaction processing, and sending a ninth message to the merchant server computer including the results of the payment transaction processing.

In some embodiments, the additional information related to the transaction may include documents, images, audio, video, or graphics. In some embodiments, one or more of the first message, the second message, the third message, the fourth message, the fifth message, the sixth message, and the ninth message are sent using WSDL techniques. In some embodiments, one or more of the first message, the second message, the third message, the fourth message, the fifth message, the sixth message, and the ninth message are sent using RESTful computing techniques. In other embodiments, one or more of the first message, the second message, the third message, the fourth message, the fifth message, the sixth message, and the ninth message are created using JSON. In some embodiments, the first message includes alias information of the user. In an embodiment, prior to sending the fourth message, the server computer may consult an alias database to determine the user device associated with the alias. In some embodiments, the payment account information is stored in the server computer.

DETAILED DESCRIPTION

Embodiments of the present invention provide a system for validating and processing payment transactions between multiple parties. The system includes a payment processing network sever computer, data management server computer, a user and one or more merchants.

In order to provide a better understanding of the present disclosure, a brief review of transaction processing as it exists today is provided with reference toFIG. 1. For ease of discussion, a transaction conducted in a physical store is described, however it should be understood that similar steps occur in any type of transaction, including online transactions. In a typical transaction, a user100may select goods or services to purchase at a merchant. The user may then pay for the goods or services by presenting a transaction card, such as a debit or credit card, to the merchant. The merchant may then swipe the transaction card through an access device102, e.g., a Point of Sale (“POS”) terminal, to read the account number from the transaction card.

Access device102may then send the account number to a merchant system, where other information related to the transaction, such as purchase amount, may be added. It should be noted that in some cases, the access device and the merchant system are a single device, in which the account number is read, and the purchase amount is keyed in by the merchant. The transaction details, such as the account number and purchase amount are then sent from the merchant system to an acquirer system104to request transaction authorization. An acquirer is generally a bank that holds an account for the merchant in which funds resulting from the transaction may eventually be deposited.

The acquirer system104then receives the transaction details, and determines a payment processing network106that may process the transaction. The acquirer104routes the transaction to the appropriate payment processing network106, which in turns determines the issuer108of the transaction card. As mentioned above, an issuer108may provide the user with an account that holds cash or a line of credit. The payment processing network106then routes the transaction to the correct issuer108for a transaction authorization decision. If the user has sufficient funds in the account or sufficient available credit, the issuer108may authorize the transaction. The authorization response is transmitted back to the merchant, through the payment processing network106, the acquirer104, and the access device102. The user has then completed the purchase of the goods or services. At a later point in time, a settling and clearing process may occur, in which the funds are actually transferred from the user's account (or drawn on the line of credit) to the merchant's account at the acquirer. The settlement and clearing process occurs using the account number, wherein a request for funds may be compared to a previous authorization, and if an authorization exists, the funds are transferred.

Transactions may become even more complicated when a Personal Identification Number (“PIN”) is required. For example, in the case of some debit card transactions, a PIN must be entered by the user. The PIN is typically entered into the access device in clear form by the user. The PIN is then encrypted using a Pin Encryption Key (PEK) in the access device and is sent to a merchant system, which also knows the PEK. The merchant system, then decrypts the PIN using the PEK, and encrypts it again using an acquirer working key (AWK), which is a key known by the merchant and the acquirer. The acquirer then decrypts the PIN using the AWK and encrypts again using a payment processor key. The payment processor in turn decrypts the PIN and encrypts using an issuer working key. The issuer then decrypts the PIN and determines if the PIN is correct.

In the traditional payment processing process described above, the transaction is usually between a single entity that is purchasing a product or a service and a single entity that is providing the product or a service. There is no mechanism to validate or request more information about a transaction, as part of payment processing process, before approving that transaction. For example, if a user is requesting a service from a first merchant which may be paid for by a second merchant contracted by the user, currently there is no mechanism by which the second merchant can ensure, as part of the payment processing operation, that (a) the service is actually needed and (b) proper documentation is available in order to authorize that service. In most of these situation, the first merchant, the second merchant, and the user end up exchanging information among themselves either prior to performance of the service or after the service is rendered in order to authorize payment for the service.

The traditional process is very cumbersome and slow. In many cases, it often takes weeks or months before the first merchant gets paid for the service he has provided. Also, since most of the processing for payment authorization involves printed paperwork and communication via regular mail, instances of lost documentation a plentiful, which further delays the performance of a service and/or payment for a service already performed. In addition, the traditional process is labor intensive and is costly for the merchants who generally recover part of the costs from the users. Embodiments of the present invention serve to alleviate these and many other issues with the current mechanism.

Embodiments of the current invention provide a mechanism for integrating the payment processing infrastructure with a new infrastructure for handling the supporting documentation and information needed to effect the payment processing. Many advantages can be realized with the system and methods described below. First, by automating most of the traditional mechanisms for service and payment authorization, the proposed system can greatly enhance the speed and efficiency of execution. Second, the system leverages use of billions of network connected servers and user devices such as cell phones, mobile computing devices, TVs', etc. to enable a user and a merchant to interact quickly and efficiently without having to resort to traditional methods like mailing of documents. This may greatly enhance the speed of processing both the transaction authorization and payment processing aspects of a transaction. Third, since the system uses a web-based cloud server configuration to store data, the data is available for access virtually anywhere in the world at anytime further reducing the delay in the entire process. Fourth, the system uses WSDL, JSON, and/or RESTful messaging, which are universally supported by virtually all the current network enabled servers and devices. This is may greatly reduce the cost/message for communicating with the cloud server computer(s). These cost savings can be passed on to the merchants/users. Finally, the system provides a secure means of conducting transactions in which the user need not provide his payment details to any merchant, but rather uses only an alias to conduct transactions. The user's payment details are stored safely on the cloud server computer. Thus there is virtually no payment details exchanged between a user and a merchant, which reduces the instances of fraud and identity theft.

FIG. 2illustrates a functional block diagram of a system200according to an embodiment of the present invention. System200includes a payment processing network server computer202that communicates with an acquirer204and an issuer206. Payment processing network server computer202can be implemented, e.g., using the computer system ofFIG. 5. Payment processing network server computer202receives payment authorization requests and communicates with acquirer204and issuer206to complete the payment transaction. In some embodiments, payment processing network server computer202is similar to the payment processing network server computer106ofFIG. 1.

Payment processing network server computer202also communicates with a data store208that stores payment related information. In some embodiments, data store208may include, for a particular account, account number, payment device identifier(s) associated with the account, the CVV code associated with the payment device(s), account holder information, etc. In operation, payment processing network server computer202consults with data store208to retrieve the information needed to process the payment transaction. In some embodiments, data store208may be integrated into the payment processing network server computer202. In other embodiments, data store208may be external to payment processing network server computer202and may comprise shared data resources. Data store208may be implemented using any non-volatile storage medium such as optical disks, HDD, or flash memory. In some embodiments, data store208may also include addressing and control circuitry for accessing the data in data store208.

System200may also include a cloud server computer210that may be operated by the same entity that operates payment processing network server computer202. Cloud server computer210may be implemented, e.g., by computer system ofFIG. 5. Cloud server computer210may include a database212, one or more application interfaces214, storage device216, and an alias database218.

Database212may have a subset of information present in data store208. In some embodiments, database212may include all the information from data store208. Periodically, database212is synchronized with data store208to ensure that database212has the most current information related to user accounts. In some embodiments, for security purposes certain information that is present in data store208may not be present in database212. Database212can be implemented using appropriate hardware and software components commonly available. In some embodiments, database212can used shared memory architecture. Shared memory is memory that may be simultaneously accessed by multiple programs with intent to provide communication among them or avoid redundant copies. Shared memory is an efficient means of passing data between programs. Depending on context, programs may run on a single processor or on multiple separate processors.

Application interface214can include hardware and software for communicating with various external devices. In some embodiments, application interface may include requisite functionality for sending and receiving WSDL messages, JavaScript Object Notation (JSON), and RESTful computing messages. WSDL (Web Services Description Language) is an XML-based language that provides a model for describing Web services. WSDL is often used in combination with SOAP and an XML Schema to provide web services over the Internet. A client program connecting to a web service can read the WSDL file to determine what operations are available on the server. Any special data types used are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to actually call one of the operations listed in the WSDL file. WSDL is widely used for communications over a network. REST (Representational State Transfer) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. REST-style architectures consist of clients and servers. Clients initiate requests to servers; servers process requests and return appropriate responses. Requests and responses are built around the transfer of representations of resources. A resource can be essentially any coherent and meaningful concept that may be addressed. A representation of a resource is typically a document that captures the current or intended state of a resource.

JSON is a lightweight text-based open standard designed for human-readable data interchange. It is derived from the JavaScript scripting language for representing simple data structures and associative arrays, called objects. Despite its relationship to JavaScript, it is language-independent, with parsers available for most languages. The JSON format is often used for serializing and transmitting structured data over a network connection. It is used primarily to transmit data between a server and web application, serving as an alternative to XML.

Storage device216can be implemented using a non-transitory, non-volatile storage media such as hard disks, optical disks, flash memory, etc. In some embodiments, storage device216can include several individual storage media. In some embodiments, storage device can have a capacity in excess of 100 terabytes. In some embodiments, storage device216may store all the supporting information for a particular transaction.

Alias database218may include information about an alias. An alias may be a representation of an individual or a business. In some embodiments, alias database218may include biographical information about an alias, information about devices associated with the alias, etc. A detailed description of an alias database is provided in the pending commonly-owned U.S. patent application Ser. No. 12/846,767, filed on Jul. 29, 2010, the contents of which are incorporated by reference herein in its entirety for all purposes. In some embodiments, alias database218may be part of database212.FIG. 2Aillustrates an example of data that may be store in alias database218.

As illustrated inFIG. 2A, alias hierarchy and data structure tree250includes a top-level alias251to which all other aliases and objects are linked. As described above date illustrated inFIG. 2Amay be stored in alias database218. The alias251may be associated with an entity/organization, a person/individual, or a device. In some embodiments, alias251may be linked to other aliases within or outside a particular tree. Alias251may be linked to various hierarchy groups260,270, and280. The hierarchy groups are used to arrange the data in a manageable form and for ease of search using standard database queries. Each of these hierarchy groups may represent a particular area, e.g., devices, household, individual, entity/business, etc. InFIG. 2A, the hierarchy group260is referred to as the business domain. This hierarchy group relates to a business entity that may be owned or operated by owner of the alias251. The hierarchy group260may have several objects linked to it. Each of the objects linked to the hierarchy group260in turn may have an alias associated with them. As illustrated, the hierarchy group260may have an object261associated with it. The object261may be a network used by the business entity. The object261may further have objects262and263associated with it. In an embodiment, object262may be the internet service provider (ISP) used by the business entity and the object263may be the telephone company that provides telephone service to the business entity. In addition, the hierarchy group260may have other network type objects linked to it. The object263may also have other objects264and265linked to it. The object263may represent a financial institution, e.g., a bank, which issues a credit card264and where the business entity has its checking account265. Each of the objects264and265may also have an alias associated with them. Similarly, hierarchy group260may have another financial institution266associated with it that may represent a different bank where the business entity has an account.

Hierarchy group270is related to an individual domain. Hierarchy group270includes information about an individual and his household. For example, hierarchy group270may have an object271that represents the spouse of the individual, an object272that specifies the gender of the individual, an object273that represent the children of the individual, and an object274that represents the household of the individual. The object274may be further liked to one or more objects that represent, the address of the household, the parcel number of the household, etc. Similarly, object271may be further linked to other objects that represent the spouse's age, gender, any other children of the spouse, etc.

Hierarchy group280is related to devices that may be used by a business entity or an individual. The hierarchy group280may also have various subjects associated with it. In an embodiment, the hierarchy group may have objects281,282,283, and284associated with it. The object281may represent the vehicle owned by the individual or the business entity. The object282may represent the computer owned by the individual or the business entity. The object283may represent various other electronic devices owned by the individual or the business entity. The object284may represent a cell phone owned by the individual or the business entity. In some embodiments, the object284may have additional objects associated with it that may represent various attributes of the object284. For example, the object284may have attributes that represent a phone number, serial number of the cell phone device, a serial number of a SIM card installed in the cell phone, associated with the object284. In some embodiments, each of the attributes may be an object and have a unique alias associated with the object. As described earlier, each of the objects associated with any of the hierarchy groups may have a unique alias associated with them.

In some embodiments, an object in one hierarchy group may also be associated with another object in a different hierarchy group. For example, object284(cell phone) may be associated with object264in the instance where the cell phone is also a payment device, e.g., implementing contactless card technology. In some embodiments, one hierarchy group may be linked to another hierarchy group for the same alias or a different alias. For example, if a husband and wife share the same household, the hierarchy group associated with the household may be linked to alias of the husband as well as the alias of the wife, or to any other hierarchy groups that are linked to the alias of the husband or the wife.

Thus it can be seen that each hierarchy group can include multiple levels of objects linked to each other within the same hierarchy group. In addition, objects in one hierarchy group can be linked to objects in different hierarchy groups. It is to be understood that the various objects and aliases illustrated inFIG. 2Aare exemplary and the type and amount of objects associated with an alias may depend on whether the alias is an individual or an entity such as a merchant described above.

Referring back toFIG. 2, system200may also include one or more user devices230and one or more merchant server computers232,234. User devices can include mobile communication devices, televisions, PDA's, PC's, and portable computing devices. Each user device230may be associated with an alias belonging to the user. In this manner, any transaction originating or terminating at user device230can be tracked and properly attributed to the corresponding user. Merchant server computers232,234can be any network enabled server computer that is associated with a merchant. A merchant as used herein can be a corporation (e.g., Google, Facebook, etc.), a service provider (e.g., an insurance company, auto body shop, gas station, etc.), retail outlets (e.g., Sears, Wal-Mart, etc.), a network-based information provider (e.g., search engines, social networks, etc.), or any other entity that provides either a product, a service, or information.

Now, the operation of system200will be described below using an example in which a user needs to get some dental work done, e.g., a root canal, and seeks authorization from his insurance company who may authorize payment for the service. It is to be understood that the scenario described below is given to explain the operation of system200and should not be construed to limit the embodiments described herein. Consider that inFIG. 2, user device230is a mobile device, merchant232is an insurance company, and merchant234is a doctor.

After the user associated with user device230visits the doctor, the doctor proceeds to get authorization from the insurance company for performance of the service. In order to accomplish this, the doctor (234) may send a service authorization message to cloud server computer210. Cloud server computer210then relays the message to the insurance company (232). The insurance company may need additional information in order to authorize the service, e.g., a dental x-ray of the user. The insurance company may request the additional information from the doctor via cloud server computer210. The doctor may then upload the x-ray to cloud server computer210where it may be stored in storage device216. The x-ray is then communicated to the insurance company, which may authorize the service. The authorization may be communicated to the doctor along with a transaction ID for that service request. The transaction ID may be used to track the service when a payment request for that service is made.

After the doctor provides the service to the user, the doctor may submit a payment request to cloud server computer210for the service along with the transaction ID for that service. Cloud server computer210may relay the payment request to the insurance company. Before the insurance company pays the doctor, it may want to verify that the user has indeed received the service. Accordingly, the insurance company may send a validation request to user device230via cloud server computer210. The user can validate that the service was provided by using user device230. Once the insurance company receives user validation, it can send payment details to cloud server computer210. In some embodiments, cloud server computer210may have payment details for the insurance company stored in database212. At this point cloud server computer210may send the payment details to payment processing network202for payment processing. Once the payment is successfully processed, payment processing network202may inform cloud server computer210of the results, which may be stored by cloud server computer210. In some embodiments, the results may be communicated to the user and the doctor.

As seen from above, for a single payment transaction for the dental service provided to the user, there are multiple steps that occur. In one embodiment of the present invention, cloud server computer210handles all the supporting data and interaction that occurs prior to the payment transaction being processed. In some embodiments, for every 1 payment transaction there may be up to 9 supporting transactions that may occur. Since all the supporting transactions occur directly between end-users (user device230, merchants232and234) and cloud server computer210, there is less delay and messages can be handled in an efficient manner. Cloud server computer210provides the individual entities with a much faster way of completing a transaction. For example, for the illustrative scenario described above it would have taken weeks for the entire transaction to be completed not counting any scheduling delays between the user and the doctor. However, with system200, the entire transaction can be completed in matter of minutes and almost real-time. In addition, having a neutral third-party, e.g., VISA, operate the cloud server computer provides all the stake holders with assurance that their information will be properly safeguarded. In addition, it reduces the burden on the merchants and the users of having to track the paperwork and manage multiple channels of communication for every transaction.

Another example where the embodiments of the present invention may be used are in a transactions that involves a user buying gas at a gas station. In this instance merchant232may be the gas station where the user intends to buy gas for his car. Even before the user drives to the gas station, the user can communicate with cloud server computer210using, e.g., a communication device in his car, to retrieve information associated with the gas station, e.g., gas price, gas availability, etc. The information associated with the gas station may be stored under the alias for the gas station in alias database218. This information may be updated periodically to reflect the most updated information. In an embodiment, the user device may communicate the alias of the gas station in order to retrieve the information. In addition to the information associated with the gas station, cloud server computer210may also gather information about the gas station from one or more information providers, e.g., merchant234. Such information may include travel time between user's current location to the gas station including traffic conditions, an optimal travel route, reputation of the gas station in terms of average wait time for fill-up, etc. All this information can be sent back to the user device.

The user may then drive to the gas station. The user device may determine that the user is nearing the gas station, e.g., based on location information of the user device, and send an indication to the gas station that the user is about to arrive at the gas station. The indication may include the user's alias information. The gas station server computer may use the user's alias information to request preauthorization from the user's payment card issuer for a potential gas purchase. Since the user's alias information is stored in alias database218, cloud server computer can determine user's payment device and communicate with the issuer of the payment device to obtain the preauthorization. When the user actually enters the gas station and drives up to a particular pump, the user device may communicate with the gas station server via cloud server computer210to indicate user's location. In response to this information, the gas station's server computer can enable that pump for use.

The user may immediately start pumping gas from that pump without having to swipe this card or present any payment device. Once the user has finished dispensing the gas, the gas station server may send the final amount of purchase to cloud server210to be communicated to the user's issuer. In some embodiments, the issuer may send a confirmation message to the user's device, via cloud server computer210, to verify that the user indeed purchased the gas. Once the user confirms the purchase, the payment authorization may proceed according to conventional processes.

Thus, in this exemplary scenario, the user may not have to provide his payment details to the gas station at all. All transactions can be conducted using an alias and the gas station gets paid without ever receiving the user payment details. In addition, providing a secure means for the user to conduct his transactions may result in encouraging user's to use the system.

FIG. 3is a functional block diagram of a cloud server computer300according to an embodiment of the present invention. Cloud server computer (or cloud server)300may include a payment application302that may be configured to interact with a payment processing network. The payment application can communicate a payment authorization request to the payment processing network and receive messages associated with payment processing, from the payment processing network.

Cloud server300may also include a data store304that includes a alias database306and alias hierarchy information308. Alias database306may include information about an alias. An alias can be some form of an identifier (e.g., e-mail address) associated with an entity. The entity can either be an individual or a company. In some embodiments, alias database306may include biographical information associated with an alias, such as contact information, address, etc. In some embodiments, alias database306may also include information about a payment device associated with an alias. As used herein, a payment device can be a credit card, a debit card, a smart card, an account number, etc. In some embodiments, alias database306may be synchronized with the database associated with the payment processing network (e.g., data store208ofFIG. 2).

Data store304may also include alias hierarchy information308. In an embodiment, alias hierarchy information may include associations between and alias and one or more objects (e.g., devices, real property, etc.) and between two or more aliases. For example, one of the objects may be the cell phone associated with the alias. So, in the example above, when the insurance company communicates with the user to validate that the service was provided by the doctor, it may send a message to the cloud server computer with the alias information for the user. The cloud server may look up the cell phone number of the user and send the message to the cell phone. When a reply is received from the user, the cloud server computer may verify that the cell phone from where the reply originated is associated with the user. Thus, this may provide an additional level of security and verification.

Cloud server300may also include data storage310. Data storage may include multiple storage devices working in synchronization to provide data storage capability. In some embodiments, data storage may have a storage capacity in excess of 100 terabytes. In some embodiments, most of the supporting documentation associated with a particular transaction may be stored in data storage310. For example, in the example discussed above, the dental x-ray and any other documentation related to the service provided by the doctor may be stored in data storage310. For this reason, it is desirable to have the storage capacity of data storage310as high as possible.

Cloud server300may also include an application interface312. Application interface312may communicate with external systems such as other network-enabled user devices and other network-enabled server computers that may reside at merchant locations. It is estimated that are approximately 1 billion network-enabled user devices are in operation currently and are projected to grow at an annual rate of 1 billion/year. In order to interact with all these external systems, application interface312may use WSDL messaging, JSON, and/or RESTful computing architecture. Use of these techniques ensures that the cost of processing the large amount of transactions with the external systems is kept at a minimum. Application interface312can be implemented using any suitable hardware and/or software components that are designed to utilize WSDL, JSON, and/or RESTful messaging.

FIG. 4is a flow diagram of a process400for processing a transaction according to an embodiment of the present invention. Process400may be performed, e.g., by cloud server computer300ofFIG. 3.

Initially, the cloud server may receive a request for authorizing a transaction from a merchant (402). The cloud server may request additional information about the transaction from the merchant (404). In some embodiments, the additional information may include documentation, images, audio, etc. The cloud server may communicate with the other entity or entities involved in the transaction for validating the transaction (406). For example, if the transaction is a request from a merchant for getting paid for an item purchased by a user, the user may be asked to validate that he/she indeed purchased the item for which payment is being requested. Once the other entity validates the transaction, the cloud server may receive payment details from the other entity (408). In some embodiments, payment details may include information about a payment device to be used for paying for the item purchased. Once the payment details are received, the cloud server may send the payment details to a payment processing network (410) for further processing. In some embodiments, prior to sending the payment details, the cloud server may verify that the payment details are associated with the other entity, e.g., by consulting the alias database306ofFIG. 3. Thereafter, the cloud server may receive results from the payment processing operation from the payment processing network (412). The cloud server may then communicate the results to the merchant and the user (414). In some embodiments, after completion of the transaction, the cloud server may archive all the data related to that transaction and associate an identifier to it for ease of retrieval later.

FIG. 5is a high level block diagram of a computer system that may be used to implement any of the individual components described above and may include one or more of the subsystems or components shown inFIG. 5, which is a block diagram of a computer apparatus. The subsystems shown inFIG. 5are interconnected via a system bus545. Additional subsystems such as printer544, keyboard548, fixed disk549, monitor546, which is coupled to display adapter582, and others are shown. Peripherals and input/output (I/O) devices, which couple to I/O controller541, can be connected to the computer system by any number of means known in the art, such as serial port584. For example, serial port584or external interface581can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus545allows central processor543to communicate with each subsystem and to control the execution of instructions from system memory542or fixed disk549, as well as the exchange of information between subsystems. The system memory542and/or fixed disk549may embody a computer readable medium.

FIG. 6is a block diagram of the basic components that may reside in an exemplary user device614, e.g., a mobile phone, a car stereo unit, etc. according to an embodiment of the present invention. User device614comprises a computer readable medium (CRM)652. CRM652may be present within a body670, or may be detachable from it. Body670may be in the form a plastic substrate, housing, or other structure. CRM652may be a memory that stores data and may be in any suitable form including a magnetic stripe, a memory chip, etc. The memory preferably stores information such as financial information, transit information (e.g., as in a subway or train pass), access information (e.g., as in access badges), etc. Financial information may include information such as bank account information, bank identification number (BIN), credit or debit card number information, account balance information, expiration date, user information such as name, date of birth, etc. Any of this information may be transmitted by user device614.

CRM652, or memory, may further comprise any suitable code. The code may be suitable to perform any or all of the functionality of user mobile device614as described herein. In some embodiments, CRM614, or memory, comprises: (a) code for receiving information from the cloud server computer; (b) code for sending information to the cloud server computer; (c) code for sending information to the issuer computer; (d) code for sending information to the payment processing network computer; (e) code for receiving information from the payment processing network computer; and/or (f) code for receiving information from the issuer computer.

User device614also comprises a camera654. Camera654is operable to take pictures (i.e., acquire images), video, etc. and may include any type of image-acquiring device known in the art. User device614may also comprise a GPS antenna656. GPS antenna656is operable to receive transmissions from GPS satellites for identifying a location of user device614. GPS antenna656may include any type of antenna operable to receive transmissions from GPS satellites as is known in the art.

User device614may also comprise other elements typically included in a user mobile communication device. For example, user device614may also include a processor650(e.g., a microprocessor) for processing the functions of the user device614and an output device658(e.g., a display) to allow a user to see phone numbers and other information and messages, e.g., an authentication request message or a verification message. User device614may further include input elements660to allow a user to input information into the device, a speaker662to allow the user to hear voice communication, music, etc., and a microphone664to allow the user to transmit his/her voice through user device614. User device614may also include a cellular antenna666for wireless voice and data transfer (e.g., voice and data transmission). User device614may also include a contactless element668, which is typically implemented in the form of a semiconductor chip (or other data storage element) with an associated wireless transfer (e.g., data transmission) element, such as an antenna. Contactless element668functions to permit the exchange of data and/or control instructions between user mobile device614and an optional contactless element included in a merchant access device.

User device614may also include an accelerometer672. Accelerometer672is typically implemented in the form of an integrated circuit chip. Accelerometer672can measure the proper acceleration of user mobile device614. In some embodiments, accelerometer672can be a multi-axis accelerometer. The accelerometer readings can be communicated to other external systems for further processing.

AlthoughFIG. 6shows a number of components, user device614according to embodiments of the present invention may comprise any suitable combination or subset of such components.