Digital payment systems, devices and methods

Abstract

A system and method for effecting a payment over a communications network is presented. The system effectuates the payment over the communications network using a payment element, the payment element including a user identifier string, the payment element being installed in a user's digital wallet on a user device to effectuate the payment.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) Some embodiments described herein relate generally to payment systems and methods, and more specifically to digital payments over digital networks. [Background technology]

[0002] Digital payment systems may enable purchases in virtual stores over the Internet and in physical stores using digital wallets. They allow users to pay for goods using their credit cards or other payment methods, such as Pay pal, crypto coins, etc.

[0003] However, to use a digital wallet, a payment card needs to be uploaded to the digital wallet application, so a user cannot use the digital wallet application without a payment card.

[0004] (overview) DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiments relating to systems, methods and products for purchasing goods and services are described below by way of example only.

[0005] An example embodiment may include a payment server including a processing circuit that issues a payment element including a user identifier string for one or more payments over a communications network, sends the user identifier string to a user application installed on the user device, receives a payment request message from the payment receiving unit when a payment is made by providing the user identifier string by the user device to the payment receiving unit, sends a purchase approval request message to a user account holding server, and sends a response message to the payment receiving unit in response to the payment approval request.

[0006] For example, the response message includes an approval message, and the processing circuitry is configured to send the requested payment to a payment receiving unit and receive payment from the user account holder server based on the requested payment.

[0007] For example, the user identifier string includes at least one of a user identifier number, a user code, an account number, and a mobile phone number.

[0008] For example, the user identifier string is encrypted.

[0009] For example, when the response message includes a denial message, the processing circuitry is configured to send the denial message to the payment receiving unit.

[0010] For example, when the response message includes an approval message, the processing circuitry is configured to send a payment request message to the user account holder server and receive a payment confirmation message from the user account holder server.

[0011] For example, the processing circuitry is configured to request deletion of the payment element after completion of a payment process in a user application on the user device, issue a new payment element including a new user identifier string to the user for use in a next payment, and send the new payment element to the user application on the user device.

[0012] For example, a payment request message may include a user identifier string, a payment request amount, a payment method, and payee data.

[0013] For example, a payment confirmation message may include the date of payment, user data, account holder details, payee data, the payment method and the amount requested to be paid to the payee.

[0014] For example, the authorization request message may include at least a user identifier string, payee data, a payment method, and a requested payment amount.

[0015] For example, the user account holder may include at least one of a bank and a banking hub.

[0016] For example, the user application includes a digital wallet.

[0017] For example, the user device may include at least one of a desktop computer, a laptop computer, a mobile device, or a mobile phone.

[0018] Other embodiments may include a product including one or more tangible, computer-readable, non-transitory storage media including program instructions for effecting a payment over a communications network, where execution of the program instructions includes issuing a payment element including a user identifier string for effecting one or more payments over the communications network, sending the user identifier string to a user application installed on the user device, receiving a payment request message from the payment receiving unit when a payment is made by the user device by providing the user identifier string to a payment receiving unit, sending a purchase approval request message to a user account holder server, and sending a response message to the payment receiving unit in response to the payment approval request.

[0019] For example, when the response message includes an approval message, execution of the program instructions includes sending the requested payment to a payment receiving unit and receiving payment from the user account holder server based on the payment request.

[0020] For example, when the response message includes a denial message, execution of the program instructions includes sending the denial message to the payment receiving unit.

[0021] For example, when the response message includes an approval message, execution of the program instructions includes sending a payment request message to the user account holder server and receiving a confirmation message from the user account holder server.

[0022] For example, execution of the program instructions may include requesting deletion of a payment element after completion of a payment process in a user application on the user device, issuing a new payment element including a new user identifier string to the user for use in the next payment, and sending the new payment element to the user application on the user device.

[0023] Another example of an embodiment includes a payment server including a processing circuit configured to receive a user identifier string from a user account holder server, where the user identifier string is configured to be connected to a user account without exposing other details of the user to the payment receiving unit, issue a payment element based on the user identifier string, send the payment element to a user application installed on a user device and configured to make a payment using the payment element at the payment receiving unit, and perform the payment transaction by the payment receiving unit.

[0024] For example, a payment transaction may include sending a payment request message to a payment server and receiving the payment request message from a payment receiving unit at the payment server, and when payment is made, the payment server is configured to send a purchase authorization request message to the user account holder server and send a response message to the payment receiving unit in response to the payment authorization request.

[0025] For example, the payment server is configured to conduct a registration session with a user device, the registration session including receiving a user identifier string from the user device and issuing a payment element based on the identifier string, the payment element being downloaded and installed on the user device into a payment application.

[0026] For example, a payment server might: The system is configured to conduct a registration session with the user device, the registration session including receiving user information from the user device and receiving an identifier string from a user account holder server, and to issue a payment element based on the identifier string, the payment element being downloaded and installed in a payment application on the user device.

[0027] For example, user information includes the user name, the user address, the user email address, a user identification number and the user's bank account details.

[0028] From the described disclosure, solutions to the shortcomings of the art are understood. More specifically, the embodiments described herein allow for payment for purchases using a user ID string. [Brief description of the drawings]

[0029] [Figure 1] FIG. 1 is a block diagram of a system for effecting payments over a network, according to some demonstrative embodiments. [Diagram 2] 1 is a flowchart of a method of making a payment over a network according to one illustrative embodiment. [Diagram 3] 11 is a flowchart of a method for making a payment over a network according to a second illustrative embodiment. [Figure 4] 11 is a flowchart of a method for making a payment over a network according to a third illustrative embodiment. [Diagram 5]11 is a frame structure of a payment request message according to some other demonstrative embodiments. [Figure 6] 11 is a frame structure of a payment confirmation message, according to some other demonstrative embodiments. [Figure 7] 11 is a frame structure of an authorization request message, according to some other demonstrative embodiments. [Figure 8] 11 is a frame structure of a response message according to some other demonstrative embodiments. [Figure 9] 1 is a frame structure of a user identifier string, according to some demonstrative embodiments. [Figure 10] 1 is an article of manufacture, according to some demonstrative embodiments. [Figure 11] FIG. 1 is a block diagram of another embodiment of a system for effecting payments over a network, in accordance with some demonstrative embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0030] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of some embodiments. However, it will be understood by those skilled in the art that some embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, units and / or circuits have not been described in detail so as not to obscure the description.

[0031] As used herein, descriptions made using terms such as, for example, "processing," "computing," "calculating," "determining," "establishing," "analyzing," "checking," and the like, may refer to actions and / or processes of a computer, computing platform, or other electronic computing device that manipulate and / or transform data represented as physical (electronic) quantities in the computer's registers and / or memory to other data similarly represented as physical quantities in the computer's registers and / or memory, or other information storage media capable of storing instructions for implementing the actions and / or processes.

[0032] As used herein, the terms "plurality" and "multiple" include, for example, "a plurality of" or "two or more." For example, "a plurality of items" includes two or more items.

[0033] References to "one embodiment," "an embodiment," "exemplary embodiment," "various embodiments," and the like indicate that the embodiment so described includes a particular feature, structure, or characteristic, but not all embodiments necessarily include that particular feature, structure, or characteristic. Further, repeated use of the phrase "in one embodiment" does not necessarily refer to the same embodiment, although it may.

[0034] As used herein, unless otherwise specified, the use of ordinal adjectives such as "first," "second," "third," etc. to describe a common object indicates merely that different instances of a similar object are being referred to, and is not intended to imply that the objects so described should be in a given order, whether in time, space, precedence, or otherwise.

[0035] As used herein, the term "circuitry" may refer to, be a part of, or include an application specific integrated circuit (ASIC), integrated circuit, electronic circuit, processor (shared, dedicated, or group), and / or memory (shared, dedicated, or group) that executes one or more software or firmware programs, combinatorial logic circuits, and / or other suitable hardware components that provide the described functionality. In some illustrative embodiments, a circuit may be implemented in, or functionality associated with a circuit may be implemented by, one or more software or firmware modules. In some illustrative embodiments, a circuit may include logic that is at least partially operable in hardware.

[0036] The term "logic" may refer to, for example, computational logic embedded in a circuit of a computing device and / or computational logic stored in a memory of the computing device. For example, the logic may be accessible by a processor of the computing device to execute the computational logic to perform computational functions and / or actions. In an example, the logic may be embedded in various types of memory and / or firmware, such as, for example, various chips and / or silicon blocks of a processor. The logic may be included in and / or implemented as part of various circuits, such as, for example, radio circuits, receiving circuits, control circuits, transmitting circuits, transceiver circuits, processor circuits, and / or the like. In an example, the logic may be embedded in volatile and / or non-volatile memory, including random access memory, read-only memory, programmable memory, magnetic memory, flash memory, persistent memory, and the like. The logic may be executed by one or more processors, for example, using memory, such as, for example, registers, stacks, buffers, and the like, coupled to the one or more processors as needed to execute the logic.

[0037] As used below, the term "module" is an object file that contains code that extends the running kernel environment.

[0038] As used herein, the term "software engine" as used hereinafter is an object file that has code that extends the running kernel environment.

[0039] As used herein, the term "loyalty club customer" is a business-to-business (B2B) customer that offers a loyalty club and operates loyalty-based mobile services, such as a loyalty card application, for its customer base.

[0040] The term “backend platform” as used herein refers to the cloud platform, backend server of the digital wallet system, configured to manage and control the digital wallet service, and configured to interact with selected third party systems, and with the digital wallet modules and / or digital wallet engine and / or digital wallet software development kits (SDKs).

[0041] The term "EMV" as used below is a payment method based on a technology standard for smart payment cards, and for payment terminals and automated teller machines. EMV was originally an acronym for "Europay, MasterCard and Visa", the three companies that created the global payment standard.

[0042] The term "EMV terminal" as used hereinafter is a payment terminal also known as a point-of-sale (POS) terminal, credit card terminal, etc. An EMV device is a device that interfaces with payment cards, e.g., Europay, MasterCard, Visa, etc., to conduct electronic funds transactions. The terminal typically consists of a secure keypad for entering a PIN, a screen, a means of capturing information from the payment card, and a network connection to access the payment network for authorization.

[0043] In some illustrative embodiments, the payment terminal may enable a merchant to receive requested credit and / or debit card information, transmit this data to a merchant service provider and / or bank for approval, and transfer funds to the merchant. The terminal may enable merchants and / or their clients to swipe, insert, and / or insert a card near the device to capture the information.

[0044] As used hereinafter, the term "issuer NFC-EMV SDK" may include, for example, an SDK that is published and managed by an issuer. For example, such an SDK may be supported by a single issuer that, when integrated into a mobile application, enables communication of a payment element to an EMV terminal via the NFC protocol.

[0045] The term "server-side SDK" as used hereinafter is a front-end digital wallet software program. In some illustrative embodiments, this program may reside and be integrated within a customer platform and may manage end-user front-end payment interactions via a connection between the customer platform and a customer mobile application. For example, transactions may be managed by the customer platform instead of a vendor POS to which the customer platform may be connected.

[0046] As used hereinafter, the term "customer relationship manager (CRM) application programming interface (API)" refers to an API configured to communicate with a customer CRM that is configured to manage one or more customer rewards programs.

[0047] The term "credit card issuer" as used hereinafter may be a global corporation, such as, for example, a credit union, that issues credit cards or payment cards, or that is configured to provide others, such as banks or other credit unions or other companies, with the rights to issue credit cards and distribute the cards to their customers ("issuers").

[0048] The term "Payment Service Provider (PSP)" as used hereinafter may be a global company, such as a credit union, that is configured to issue credit or payment cards and / or other payment instruments and to make payments to merchants on the issued cards.

[0049] The term "credit card scheme" as used hereinafter may include a bank and / or any other eligible financial institution and / or a payment network in which credit may be an element, such as a payment card, e.g., a credit card scheme element may issue cards and / or merchants that operate on the card scheme's network. This element may also set various rules and restrictions.

[0050] As used hereinafter, the term "issuer platform" may include servers configured to enable the issuance of cards, such as, for example, MasterCard, Visa, Europay, American Express, etc.

[0051] As used hereinafter, the term "card" may include, for example, prepaid cards, credit cards, debit cards, etc. that are created and issued by an issuer.

[0052] The term "merchant POS" as used hereinafter may include, for example, a credit card terminal of a particular member and / or shop and / or other, and various payment transactions may be conducted when an end user device decides to consume a payment transaction using their consumer mobile application.

[0053] The term "customer platform" as used hereinafter may include, for example, a technology platform of a Partner's customer configured to interface with a digital wallet for payment provisioning via a digital wallet platform. The backend technology platform communicates with customer mobile applications as well as digital wallet SDKs according to the payment structure chosen by the customer and / or partner. For example, this platform may be cloud-based, running on, for example, Amazon Web Services (AWS) and / or Microsoft AZURE.

[0054] As used hereinafter, the term "customer credit card terminal" may include a transaction terminal, EMV and / or EMV that may be used by the customer platform to generate payment elements for each end user credit card associated with the customer mobile application. For example, such a terminal may reside with a payment gateway company or a processor company.

[0055] The term "customer mobile application" as used hereinafter may include at least one application installed on a customer mobile device, such as, for example, a loyalty club application, an e-wallet application, etc. The customer mobile application may include a digital wallet SDK and may interact with a digital wallet platform and a customer platform. The customer mobile application may be configured to run on, for example, iOS and Android, or a mobile application such as React.

[0056] The term "customer CRM" as used hereinafter may include, for example, loyalty club platforms that customers use to manage their customer base and their reward structures, and other such programs across various segments and plans.

[0057] The term "digital wallet rules engine" as used hereinafter may include an administrator system that can define various rules including, for example, a Merchant Category Code (MCC), which includes a universal code in the card scheme that defines various purchase / merchant categories such as clothing, sports shoes, etc., codes, and limits for transactions made by an end user.

[0058] As used hereinafter, the term "end user" may include one or more users who use a Customer Mobile Application.

[0059] The term "payment element" as used hereinafter may include a unique placeholder called a payment element that is configured to contain encrypted information of a user's payment capabilities, such as, for example, credit card, debit card, bank transfer information, etc. For example, if the card number is 1234 5678 8765 4321, the payment element identifier may be, for example, E67TL8GC27X. In some illustrative embodiments, the payment element may be configured to access, retrieve, and retain, for example, a customer's credit card information to ensure a higher level of security for both the customer and the company. The payment element may be stored on the customer platform and / or on the customer's mobile application.

[0060] As used hereinafter, a "payment element service provider ("TSP")" is an entity authorized to generate EMV payment elements, e.g., certified by MasterCard, Visa, or any other issuer. A TSP may include a payment ecosystem configured to serve registered payment element requesters. For example, a merchant holding a card credential has a "surrogate" Primary Account Number (PNA) known as a payment element. For example, the service may be provided by a gateway service if desired.

[0061] Reference is first made to FIG. 1, which illustrates a block diagram of a system 100 for effecting payments over a network 175, according to some illustrative embodiments.

[0062] In some illustrative embodiments, the system 100 may include a payment administrator server 110 configured to manage payments over a network 175 by one or more payment applications 150. For example, the payment applications may be installed on a user device 140.

[0063] In some illustrative embodiments, the payment server 110 may include a processing circuit 120. For example, the processing circuit 120 may be operatively coupled to a payment component issuer module 130 and a communication unit 125.

[0064] For example, processing circuitry 120 may include circuitry, logic, memory, an operating system, a single or multiple core computer, a graphics processor, a digital signal processor, and the like.

[0065] In some illustrative embodiments, payment component issuer module 130 may be implemented by software and / or hardware and / or a combination of software and hardware.

[0066] In some illustrative embodiments, the communications unit 125 may include at least a wireless local area network (WLAN) transceiver, a local area transceiver (LAN), a cellular transceiver, a short-range communications transceiver such as a near field communication (NFC) transceiver, a satellite transceiver, or the like.

[0067] In some illustrative embodiments, the processing circuitry 120 may be configured to issue a payment element 132 for making one or more payments over a communications network, where the payment element 132 may include a user identifier string 135. For example, the processing circuitry 120 may be configured to operate the payment element issuer module 130 to issue the payment element 132, which may include a user identifier (ID) string 135. For example, the user ID string 135 may be encrypted and may include at least one of an identifier number, a user code, an account number, and / or a phone number.

[0068] In some embodiments, the processing circuit 120 may be configured to send the payment element 132 along with the user identifier string 135 to a user application 155 installed on the user device 150. For example, the user application 150 may include a digital wallet, if desired.

[0069] In some illustrative embodiments, user device 140 may include processing circuitry 145 and communication unit 160. For example, processing circuitry 145 may include circuitry, logic, memory, an operating system, one or multiple core computers, graphic processors, digital signal processors, etc. For example, communication unit 160 may include at least one of a wireless local area network (WLAN) transceiver, a local area network (LAN), a cellular receiver, a short-range communication transceiver, e.g., near field communication (NFC), a satellite transceiver, etc.

[0070] In some illustrative embodiments, a payment is made by the user device 140 at a payment receiving unit 165, for example, by providing a user ID string to a receiving unit 165 at a merchant point of sale and / or a payment terminal (not shown). The processing circuitry 120 may be configured to receive a payment request message 180 from the payment receiving unit 165 and, in response, may send a purchase authorization request message 190 to the user account holder server 170. For example, the payment receiving unit 165 may include a payment terminal, a digital wallet, a bank, a banking hub, a cryptocurrency, a blockchain server, etc. The payment receiving unit 165 may be implemented by hardware, software, and / or a combination of hardware and software.

[0071] In some illustrative embodiments, the user account holder server 170 may include a payment approval module 172. The payment approval module 172 may be configured to generate an approval confirmation message 195. For example, the user account holder server may include a bank, a bank hub, a cryptocurrency account, and any type of account. It should be understood that the payment approval module 172 may be implemented by software and / or by hardware and / or a combination of software and hardware.

[0072] For example, the payment request message 180 may include a user identifier string, a payment request amount, payee data, and any other data if desired.

[0073] For example, the payment authorization message 190 may include a user identifier string, the payment requested amount, payee data, and other data if desired.

[0074] For example, the authorization confirmation message 195 may include payment data, user data, account holder data, payment recipient data, the amount of the payment requested, and any other data, if desired.

[0075] In some illustrative embodiments, the processing circuit 120 may be configured to send a response message 185 in reply to the purchase approval request message 190 to the payment receiving unit 165 .

[0076] For example, the response message 185 may include an approval or rejection indication, user data, a payment date, a requested payment amount, payee data, and / or any other data, if desired. For example, when the response message includes an approval message 185, the processing circuitry 120 may be configured to send the requested payment to the payment receiving unit 165 and may receive payment from the user account holder server 170 based on the requested payment. In contrast, when the response message 185 includes a rejection message, the processing circuitry 120 may be configured to send a rejection message (not shown) to the payment receiving unit 165.

[0077] In some other illustrative embodiments, when the response message 185 includes an instructive approval message (not shown), such as a payment approval, the processing circuit 120 may be configured to send a payment request message 180 to the user account holder server 170 and may receive a payment confirmation message from the user account holder server 170.

[0078] In some illustrative embodiments, after the payment process is completed, the processing circuit 120 may be configured to request removal of the payment element 155 from the user device 150 and may issue a new payment element to be used in the next payment. For example, the new payment element may include a new user identifier string. The processing circuit 120 may send the new payment element to the user application 150 of the user device 140.

[0079] In some other embodiments, only the user ID string may be replaced in the user application 150 with a new user ID string.

[0080] In some other embodiments, the payment element 132 and the user ID string may remain after the payment process.

[0081] Advantageously, the system 100 may be configured to accept payments from a user in a simple manner, such as by credit card company payment methods, via a digital wallet application using the user ID string 135. The system 100 may provide the ability for users to more easily pay for products and services in stores or online via their bank accounts in the same manner that they are currently accustomed to paying for them via a credit card system.

[0082] In some illustrative embodiments, the system 100 includes an infrastructure with a high level of security that relies on encrypted payment elements that may be created by a central system that controls the payment for which the data elements are requested. The system 100 may increase transaction security by issuing a unique user ID string 135 for each and every transaction, providing a good model for each transaction to have its own "address" and its own definition.

[0083] In some illustrative embodiments, system 100 is configured to create a "payment instrument" for each transaction and for each customer. The infrastructure of system 100 may not require a unique integration for each and every fund and may operate generically with all funds and / or payment systems without limitations of type of company, fund, its hardware, its software, etc.

[0084] In some illustrative embodiments, system 200 is configured to connect banking systems to the corporate payment world, e.g., in stores and / or online, without having to create complex new systems for every business and without duplicating systems in the business. System 100 may be an all-encompassing system that is suitable for all, e.g., for direct payments from a bank account, and is configured to connect banking systems to businesses.

[0085] In accordance with some illustrative embodiments, and referring to FIG. 2, a flow chart of a method 200 of effecting a payment over a network 200 is illustrated. For each user 205 that may make a payment over a communications network, a server, such as, for example, the payment manager server 110 (FIG. 1), may issue a payment element, such as, for example, the payment element 132 (FIG. 1), for effecting the payment (text box 210). For example, the payment element may include a user ID string, such as, for example, the user ID string 135 (FIG. 1). The payment element may be sent to a user device, such as, for example, the user device 140 (FIG. 1), and may be installed and / or loaded into a user application, such as, for example, the application 155 (FIG. 1) (text box 220).

[0086] In some illustrative embodiments, the payment process 225 may begin at a payment administrator server when the server may receive, for example, a user ID string from a payee (text box 230) followed by a payment request, such as payment request 180 (FIG. 1). In response to the payment request, the server may send a payment authorization request (text box 240), such as, for example, payment authorization request 190 (FIG. 1), to an account holder server, such as, for example, account holder server 170 (FIG. 1).

[0087] In some illustrative embodiments, the payment manager server may receive a response message from the account holder server (text box 250), such as, for example, response message 185 (FIG. 1). When the response message may indicate that the requested payment has been approved (text box 270), the payee may receive payment from either the payment manager server or the account holder server (text box 275).

[0088] In some illustrative embodiments, the payment administrator server may send a payment confirmation message to the payee (text box 260). It should be understood that the method 200 described above may be applied to all payment requests.

[0089] According to some illustrative embodiments, reference is made to FIG. 3, which illustrates a flow chart of a method 300 of effecting a payment over a network. For each user 305 who may make a payment over a communications network, a server, such as, for example, the payment manager server 110 (FIG. 1), may issue a payment element, such as, for example, the payment element 132 (FIG. 1), to effect the payment (text box 310). For example, the payment element may include a user ID string, such as, for example, the user ID string 135 (FIG. 1). The payment element may be sent to a user device, such as, for example, the user device 140 (FIG. 1), and may be installed and / or loaded into a user application, such as, for example, the application 155 (FIG. 1) (text box 320).

[0090] In some illustrative embodiments, the payment process 325 may begin at a payment administrator server (text box 330) when the server may receive a user ID string from a payee followed by a payment request, such as, for example, payment request 180 (FIG. 1). In response to the payment request, the server may send a payment authorization request (text box 340), such as, for example, payment authorization request 190 (FIG. 1), to an account holder server, such as, for example, account holder server 170 (FIG. 1).

[0091] In some illustrative embodiments, the payment manager server may receive a response message from the account holder server indicating that the payment has been approved (text box 350), such as, for example, response message 185 (FIG. 1). In response, the payment manager server may send the requested payment to the payee (text box 360) and in return receive the payment amount paid to the payee from the user account holder server (text box 370).

[0092] In some illustrative embodiments, the payment administrator server may send a request to delete the payment element or the new user ID string, or both, and may issue a new payment element or a new user ID, or both (text box 380). It should be understood that the method 300 described above may be applied to all payment requests.

[0093] According to some other illustrative embodiments, reference is made to FIG. 4, which illustrates a flow chart of a method 400 of effecting a payment over a network. For each user 405 that may make a payment over a communications network, a server, such as, for example, the payment manager server 110 (FIG. 1), may issue a payment element, such as, for example, the payment element 132 (FIG. 1), to effect the payment (text box 410). For example, the payment element may include a user ID string, such as, for example, the user ID string 135 (FIG. 1). The payment element may be sent to a user device, such as, for example, the user device 140 (FIG. 1), and may be installed and / or loaded into a user application, such as, for example, the application 155 (FIG. 1) (text box 420).

[0094] In some illustrative embodiments, the payment process 425 may begin at a payment administrator server (text box 430) when the server may receive a user ID string from a payee followed by a payment request, such as, for example, payment request 180 (FIG. 1). In response to the payment request, the server may send a payment authorization request, such as, for example, payment authorization request 190 (FIG. 1), to an account holder server, such as, for example, account holder server 170 (FIG. 1) (text box 440).

[0095] In some illustrative embodiments, the payment manager server may receive a response message from the account holder server indicating that the payment has been approved (text box 450), such as, for example, response message 185 (FIG. 1). In this embodiment, the payment may be made, for example, by the user account holder server, and the payment manager server may receive a payment confirmation message from the user account holder server (text box 460). For example, the payment confirmation message may include an indication of the payment amount to be paid to the payment machine.

[0096] In some illustrative embodiments, the payment administrator server may send a request to delete the payment element or the user ID string or both, and may issue a new payment element or a new user ID or both (text box 470). It should be understood that the method 400 described above may be applied to all payment requests.

[0097] 5, according to some other illustrative embodiments, a schematic diagram of a frame structure of a payment request message 500. In some illustrative embodiments, the payment request message 500 may include fields such as a header 510, a user ID string 520, payment units 530, a requested payment total 540, payee data 550, payment method 560, and a footer 570. It should be understood that the above are merely examples and that other fields may be included in the payment request message.

[0098] In some illustrative embodiments, the header 510 may include a message ID and any other fields. The user ID string 520 may include, for example, a user identification number, a user code, an account number, a phone number, and / or any other data. The payment units 530 may include a coin type, for example, dollars, euros, crypto, and the like. The total field 540 may include a payment request amount. The payee data field 550 may include, for example, a payee name, a payee ID, a payee bank account number, a payee IBAN, a payee SWIPT, and the like. The payment method field 560 may include, for example, a payment number, a credit payment, a debit payment, a transfer, and the like.

[0099] 6, in accordance with some other illustrative embodiments, a schematic diagram of a frame structure of a payment confirmation message 600. In some illustrative embodiments, the payment confirmation message 600 may include, for example, the following fields: a header 610, account holder server data 620, user data 630, payment date 640, requested payment total 650, payee data 660, payment method 670, and a footer 680. It should be understood that the above are merely examples and that other fields may be included in a payment request message.

[0100] In some illustrative embodiments, the header 610 may include a message ID and any other fields. The user account holder data 620 may include, for example, a server IP address, a user account ID, and the like. The user data field 630 may include, for example, a user ID string, a user bank account data, and the like. The data field 640 may include, for example, a transaction date and time, and the like. The payment units 640 may include, for example, a coin denomination, such as dollars, euros, crypto, and the like. The total field 650 may include the payment amount requested. The payee data field 660 may include, for example, a payee name, a payee ID, a payee bank account number, a payee IBAN, a payee SWIPT, and the like. The footer 670 may include, for example, an error detection number, an error correction number, and the like.

[0101] Please refer to Figure 7, which is a schematic diagram of a frame structure of an authorization request message 700, according to some illustrative embodiments. In some illustrative embodiments, the authorization request message 700 may include, for example, the following fields: a header 710, a user ID string 720, a payment unit 730, a payment request amount 740, a payee data 750, a payment method 760, and a footer 770. It should be understood that the above are merely examples and that other fields may be included in the payment request message.

[0102] In some illustrative embodiments, the header 710 may include a message ID and any other fields. The user ID string 720 may include, for example, a user identification number, a user code, an account number, and a phone number, and / or any other data. The payment units 730 may include a coin type, for example, dollars, euros, crypto, and the like. The total field 740 may include a payment request amount. The payee data field 750 may include, for example, a payee name, a payee ID, a payee bank account number, a payee IBAN, a payee SWIPT, and the like. The payment method field 760 may include, for example, a payment number, credit payment, debit payment, early, and the like. The footer 770 may include, for example, an error detection number, an error correction number, and the like.

[0103] 8 for a schematic diagram of a frame structure of a response message 800, according to some illustrative embodiments. In some illustrative embodiments, the response message 800 may include the following fields, for example: a header 810, an approve / reject field 820, a user data field 830, a date field 840, a requested payment total 850, a payee data field 860, and a footer 870. It should be understood that the above are merely examples and that other fields may be included in a payment request message.

[0104] In some illustrative embodiments, the header 810 includes a message ID and an optional The field 820 may include other fields. The approve / reject field 820 may include an approve flag, and / or a reject flag, and / or any other indication. The user data field 830 may include a user ID string, user bank account data, etc. The data field 840 may include the date and time of the transaction, etc. The total field 850 may include the payment requested amount. The payee data field 860 may include, for example, payee name, payee ID, payee bank account number, payee IBAN, payee SWIPT, etc. The footer 870 may include, for example, an error detection number, an error correction number, etc.

[0105] 9 for a schematic diagram of a frame structure of a user ID string, according to some illustrative embodiments. In some illustrative embodiments, a user ID 900 may include a header 910, a user ID 920, a user code 930, a user payment account number 940, a user phone number 950, and a footer 960.

[0106] In some illustrative embodiments, the header 910 may include a message ID and any other fields. The user ID field 920 may include, for example, a national security number, a driving license number, a passport number, an ID number, etc. The user code field 839 may include, for example, a personal code issued to the user, etc. The user payment account number 940 may include, for example, a user bank account number, etc. The phone number field 950 may include, for example, a user mobile phone number, a user office phone, a user wireless phone number, etc. The footer 960 may include, for example, an error detection number, an error correction number, etc.

[0107] In some illustrative embodiments, the user ID string 940 may be included in protocol messages such as, for example, the payment request message 500 (FIG. 5), the authorization request message 700 (FIG. 7), the payment element 155 (FIG. 1), etc.

[0108] Referring to FIG. 10 for a schematic diagram of an article of manufacture 1000 according to some illustrative embodiments. The article of manufacture 1000 may include one or more tangible computer-readable non-transitory storage media 1010 that, when executed by at least one computer processor, may enable at least one processing circuit 120 (FIG. 1) to execute one or more program instructions for purchasing goods and / or services over a network, and / or may include computer-executable instructions 1030 implemented by a processing device 1020 operable to perform, induce, and / or implement one or more actions, communications, and / or functions as described above, with reference to FIGS. 1-9. The phrase "non-tangible machine-readable medium" is intended to include all computer-readable media, with the sole exception of transitory propagating signals.

[0109] In some illustrative embodiments, the article 1000 and / or the machine-readable storage medium 910 may include one or more types of computer-readable storage media capable of storing data, including volatile memory, non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or non-writable memory, etc. For example, the machine-readable storage medium 510 may include any type of memory, such as, for example, RAM, DRAM, ROM, programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, hard disk drive (HDD), solid state disk drive (SDD), fusion drive, etc. The computer-readable storage medium may include any suitable medium involved in downloading and transferring a computer program carried by a data signal embodied in a carrier wave or other propagation medium over a communications link, such as, for example, a modem, wireless or network connection, from a remote computer to a requesting computer.

[0110] In some illustrative embodiments, the processing device 1020 may include logic. The logic may include instructions, data, and / or code that, when executed by a machine, may cause the machine to perform the methods, processes, and / or actions described herein. The machine may include, for example, any suitable processing platform, computing device, processing device, computing system, processing system, computer processor, etc., and may be implemented using any suitable combination of hardware, software, firmware, etc.

[0111] In some illustrative embodiments, the processing device 1020 may include or be implemented as software, firmware, software modules, applications, programs, subroutines, instructions, instruction sets, computing code, words, values, symbols, etc. The instructions 1040 may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, etc. The instructions may be implemented according to a predefined computer language, means, or syntax for instructing a processor to perform a particular function. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language, such as C, C++, C#, Java, Python, assembly language, machine code, etc.

[0112] It should be understood that the systems and / or methods for generating a map of sub-surface utility are described above by way of example only, and other embodiments may be implemented based on the following detailed description and claims.

[0113] It should be understood that like numerals in the drawings represent like elements throughout the several views, and that not all components and / or steps described and illustrated with reference to the figures may be required for every embodiment or arrangement.

[0114] It should also be understood that embodiments, implementations and / or configurations of the systems and methods disclosed herein may be embodied as hardware, firmware and / or software algorithms, applications, programs, modules or code present on a computer usable medium (including software modules and browser plug-ins) and may be executed on a processor of a computer system or computing device to configure the processor and / or other elements to perform the functions and / or actions described herein.

[0115] It should be appreciated that, according to at least one embodiment, one or more computer programs, modules and / or applications implementing the methods of the present invention do not require presence on a single computer or processor when executed, but can be distributed in a modular manner among several different computers or processors to implement various aspects of the systems and methods disclosed herein.

[0116] Thus, exemplary embodiments and arrangements of the present systems and methods provide computer-implemented methods, computer systems, and computer program products for processing code. The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of the systems, methods, and computer program products according to various embodiments and arrangements. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or code portion that includes one or more executable instructions for implementing a particular logical function.

[0117] It should be apparent that in some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may in fact be executed concurrently, or the blocks may often be executed in the reverse order, depending on the functionality involved. It will also be apparent that each block of the block diagrams and / or flowchart illustrations, and combinations of the block diagrams and / or flowchart illustrations, may be implemented by a specific purpose hardware-based system performing a particular function or operation, or a combination of hardware and computer instructions for measurement purposes.

[0118] The terminology used herein should embody certain embodiments only and is not intended as a limitation of the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural unless the context clearly indicates otherwise. It will be further understood that the terms "comprise" and / or "comprising" as used in this specification specify claimed features, integers, steps, acts, elements, and / or components, but do not preclude the presence and addition of one or more other features, integers, steps, acts, elements, components, and / or groups thereof.

[0119] Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The words "including," "including," "having," "containing," "related to," and variations thereof herein are meant to encompass the items listed thereafter and equivalents thereof, as well as additional items.

[0120]

[0081] Referring to FIG. 11, FIG. 11 illustrates a block diagram of another embodiment of a system 1100 configured to effectuate payments over a network, according to some illustrative embodiments.

[0121] In some illustrative embodiments, the system 1100 may include a user device 1101. For example, the user device may include a payment application (not shown). The payment application may be configured to effect payments at a point of sale and / or over a network by using a user identifier (ID) string.

[0122] In some illustrative embodiments, the user device 1101 may include a mobile phone, a tablet, or a mobile computer, such as a laptop computer, for example.

[0123] In some illustrative embodiments, the system 1100 may include a payment server 1102. For example, the payment server 1102 may be configured to pay for purchases made through a payment application and / or to request payments to be made from another device at a storefront.

[0124] In some illustrative embodiments, the system 1100 may include a user account holder server 1103. For example, the user account holder server 1103 may be a bank, a banking hub, a loyalty club server, or the like.

[0125] In some illustrative embodiments, a user device 1101, e.g., a mobile device, cell phone, etc., may request to be issued a user ID string from a user account server 1103 (dotted line 1111). The user device 1101 may perform registration with a payment server 1102 (line 1114). For example, in this illustrative embodiment, the user device 1101, when performing registration, may forward the user ID string to the payment server 1102 without revealing any other information about the user. In return, the payment server 1102 may issue a payment element, e.g., for downloading to a payment application installed on the user device 1101 (line 1115).

[0126] In some other illustrative embodiments, a user device 1101, such as a mobile device, cell phone, etc., may perform a registration with a payment server (line 1114). For example, in this illustrative embodiment, the user device 1101 may provide usage and / or details to the payment server 1102 when performing the registration. For example, the user information may include a username, a user address, a user email address, a user ID number, the user's bank account details, and any other required details. The payment server 1102 may deliver the user information to a user account server 1103 and may receive a user ID string (1112). In return, the payment server 1102 may issue a payment element (line 1115), for example, to be downloaded to a payment application installed on the user device 1101, etc.

[0127] In some illustrative embodiments, the system 1100 may include a payment receiving unit 1104. For example, the payment receiving unit 1104 may include a payment terminal and / or a cash register at a storefront.

[0128] In some illustrative embodiments, the payment server 1102 can send the payment element to a user application installed on the user device 1101. For example, the payment application may be configured to effect a payment using the payment element at the payment receiving unit 1104.

[0129] In some illustrative embodiments, the payment server 1102 can conduct payment transactions with the payment receiving unit 1104 (line 1117).

[0130] For example, a payment transaction (line 1117) may include sending a payment request message (line 1116) to the payment server 1102 and receiving the payment request message (line 1116) at the payment server 1102 from the payment receiving unit 1104. When payment is to be made, the payment server 1102 may be configured to send a purchase authorization request message (line 1113) to the user account holder server and to send a response message (line 1113) to the payment receiving unit 1104 in response to the payment authorization request.

[0131] In another illustrative embodiment, the payment server 1102 may forward the requested payment to a payment receiving unit 1104 .

[0132] The above-described system and method include: A payment application may enable users to purchase goods and services without a credit card and / or debit card and / or any other payment card. Payments may be made directly from the user's bank account without exposing the user's details and / or bank account details to a payment server and / or payment receiving unit.

[0133] The above is provided only as an example of the method and should not be construed as limiting. Various modifications and changes can be made to the described subject matter without departing from the spirit and scope of the invention as set forth in the appended claims, without departing from the accompanying exemplary embodiments and applications shown and described.

Claims

1. A payment server including a processing circuit, the processing circuit comprising: issuing, via a communications network, a payment element for making one or more payments, said payment element including a user identifier string configured to identify a user account at a user account holder server without disclosing one or more details of said user to a payment receiving unit; sending said user identifier string to a user application installed on a user device; receiving a payment request message from a payment receiving unit when a payment is made by the user device by providing the user identifier string to the payment receiving unit; sending a purchase approval request message to the user account holder server; and sending a response message to the payment receiving unit in response to the payment authorization request. Payment server.

2. When the response message includes an acknowledgment message, the processing circuitry: sending said requested payment to said payment receiving unit; and receiving payment from the user account holder server based on the requested payment. The payment server of claim 1 .

3. The user identifier string is User identification number, user code, payment account number, and phone number at least one of The payment server of claim 1 .

4. The payment server of claim 1 , wherein the user identifier string is encrypted.

5. The payment server of claim 1 , wherein when the response message includes a rejection message, the processing circuitry is configured to send a rejection message to the payment receiving unit.

6. When the response message includes an acknowledgment message, the processing circuitry: sending said payment request message to said user account holder server; receiving a payment confirmation message from the user account holder server; The payment server of claim 1 , configured to execute:

7. The processing circuitry includes: - in the user application of the user device, requesting deletion of the payment element after completion of the payment process; issuing a new payment element for the user to be used on a next payment, the new payment element including a new user identification string; sending the new payment element to the user application of the user device; The payment server of claim 1 , configured to execute:

8. The payment request message: said user identifier string, payment requested amount, payment method, and payment destination data; The payment server of claim 1 , comprising:

9. 2. The payment server of claim 1, wherein the payment confirmation message includes at least one of a payment date, user data, account holder details, payee data, a payment method, and a requested amount for payment to the payee.

10. The payment server of claim 1 , wherein the authorization request message includes at least a user identifier string, payee data, a payment method, and a payment request amount.

11. The payment server of claim 1 , wherein the user account holder comprises at least one of a bank and a banking hub.

12. The payment server of claim 1 , wherein the user application comprises a digital wallet.

13. The payment server of claim 1 , wherein the user device comprises at least one of a desktop computer, a laptop computer, a mobile device, or a mobile phone.

14. a registration session with the user device, receiving a user identifier string from the user device; issuing a payment element based on the identifier string, the payment element being downloaded and installed into a payment application on the user device; configured to conduct the registration session including: The payment server of claim 1 .

15. a registration session with the user device, receiving user information from the user device; receiving an identifier string from the user-owned server; issuing a payment element based on the identifier string, the payment element being downloaded and installed into a payment application on the user device; configured to conduct the registration session including: The payment server of claim 1 .

16. 16. The payment server of claim 15, wherein the user information includes a user name, a user address, a user email address, a user identification number, and a user's bank account details.

17. 1. An article of manufacture comprising one or more tangible, computer-readable, non-transitory storage media containing program instructions for effecting payments over a communications network, the execution of said program instructions comprising: issuing a payment element for effecting one or more payments over said communications network, said payment element including a user identifier string configured to identify a user account at a user account holder server without disclosing one or more details of the user to a payment receiving unit; sending said user identifier string to a user application installed on a user device; receiving a payment request message from a payment receiving unit when a payment is to be made by the user device by providing the identifier string to the payment receiving unit; sending a purchase approval request message to a user account holder server; sending a response message to the payment receiving unit in response to the purchase approval request; Including the product.

18. When the response message includes an acknowledgment message, the execution of the program instructions includes: sending said requested payment to said payment receiving unit; receiving payment from the user account holder server based on the requested payment; 20. The article of manufacture of claim 17, comprising:

19. The user identifier string is User identification number, user code, user account number and phone number 20. The article of manufacture of claim 17, comprising at least one of:

20. 20. The article of manufacture of claim 17, wherein when the response message includes a rejection message, the execution of the program instructions includes sending a rejection message to the payment acceptance unit.

21. When the response message includes an acknowledgment message, said execution of said program instructions comprises: sending said payment request message to said user account holder server; receiving a payment confirmation message from the user account holder server; 20. The article of manufacture of claim 17, comprising:

22. The execution of the program instructions includes requesting deletion of the payment element after completion of the payment process in the user application of the user device; issuing a new payment element for the user to be used in the next payment, the new payment element including a new user identifier string; sending the new payment element to the user application of the user device; 20. The article of manufacture of claim 17, comprising:

23. The payment request message: the user identifier string, the payment requested amount, the payment method, and the payment recipient data 20. The article of manufacture of claim 17, comprising at least one of:

24. 20. The product of claim 17, wherein the payment confirmation message includes at least one of a payment date, user data, account holder details, payee data, a payment method, and a requested amount to be paid to the payee.

25. 20. The article of manufacture of claim 17, wherein the authorization request message includes at least the user identifier string, payee data, a payment method, and a requested payment amount.

26. Execution of the program instructions includes: a registration session with the user device, receiving a user identifier string from the user device; issuing a payment element based on the identifier string, the payment element being downloaded and installed in the user application on the user device; conducting said registration session including 20. The article of manufacture of claim 17, comprising:

27. Execution of the program instructions includes: a registration session with the user device, receiving user information from the user device; receiving an identifier string from the user account holder server; issuing a payment element based on the identifier string, the payment element being downloaded and installed into a payment application on the user device; Conducting a registration session, including 20. The payment server of claim 17, comprising:

28. 28. The article of manufacture of claim 27, wherein the user information includes a user name, a user address, a user email address, a user identification number, and the user's bank account details.

29. A payment server comprising: receiving a user identifier string from a user account holder server; said user identifier string being configured to be associated with a user account on said user account holding server without disclosing other details of the user to a payment acceptance unit; issuing a payment element based on the user identifier string; sending said payment element to a user application installed on a user device and configured to effect a payment using said payment element at a payment receiving unit; conducting a payment transaction at said payment receiving unit; A payment server configured to:

30. The payment transaction is sending a payment request message to said payment server; receiving, at the payment server, the payment request message from the payment acceptance unit; When a payment is to be made, the payment server is configured to send a purchase authorization request message to the user account holder server; sending a response message to the payment acceptance unit in response to the payment authorization request; 30. The payment server of claim 29, comprising:

31. a registration session with the user device, receiving a user identifier string from the user device; issuing a payment element based on the identifier string, the payment element being downloaded and installed into a payment application on the user device; performing the registration session, 30. A payment server according to claim 29, configured to:

32. a registration session with the user device, receiving user information from the user device; receiving an identifier string from a user account holder server; issuing a payment element based on the identifier string, the payment element being downloaded and installed into a payment application on the user device; configured to conduct the registration session, 30. A payment server according to claim 29.

33. 33. The payment server of claim 32, wherein the user information includes a user name, a user address, a user email address, a user identification number, and a user's bank account details.

Images