Card to Bank Payment Solutions

Abstract

Disclosed herein are system, method, and computer program product embodiments for a method of automated payment processing. In some embodiments, the method may receive a transaction request from a buyer to transfer a payment amount from a buyer account of the buyer to a supplier account associated with a supplier. The transaction request may be an invoice including a payment amount for a specific transaction and a supplier identification number that identifies the supplier. In response to the transaction request, the method debits the payment amount from the buyer account, identifies a supplier account based on the supplier identification number, and credits the payment amount to the identified supplier account. The buyer account may be linked to a transaction card that is used to pay the payment amount. The method enables automated payment processing without transmission of a transaction account number that is linked to the buyer account.

Description

[Technical field]

[0001] (Field) The present invention relates generally to methods of automated payment processing. [Background technology]

[0002] (background) (Related Technology) To complete a transaction, a credit card may be physically presented and swiped at the point of sale. When a physical credit card is not present at the point of sale (i.e., a "card not present" transaction), such as through an online commerce transaction, the credit card number may be transmitted from the purchaser to the supplier via email or telephone to be manually entered at the point of sale.

[0003] Security issues may arise with using a physical credit card and transmitting the credit card number to complete a transaction at the point of sale. Physical credit cards may be stolen or lost. Credit card numbers transmitted from a purchaser to a supplier during a "card not present" transaction may be compromised during a security breach. Because the same credit card number may be used to complete multiple transactions, unauthorized personnel may use a compromised credit card number to make fraudulent purchases. Furthermore, the process of transmitting a credit card number to be manually entered at the point of sale is time consuming and inconvenient. Suppliers may receive multiple emails containing sensitive credit card information for various transactions, thus creating room for confusion, delays, and human error. Summary of the Invention [Means for solving the problem]

[0004] (Brief summary) Disclosed herein are system, apparatus, devices, methods, and / or computer program product embodiments for automated payment processing methods, and / or combinations and subcombinations thereof.

[0005] The method of automated payment processing may transfer a payment directly from a buyer's buyer account to a supplier's supplier account without transmitting a transaction account number linked to the buyer account. The method may first receive a transaction request from the buyer to transfer a payment amount from the buyer's buyer account to a supplier account associated with the supplier. In some embodiments, the transaction request may allow the buyer to select, from an interface, a supplier or a supplier account into which to credit the payment amount. In other embodiments, the transaction request may be an invoice transmitted from the supplier to the buyer that specifies the payment amount and a supplier identification number that identifies the supplier. In this example, after receiving the invoice, the buyer may enter a transaction request to pay the requested amount. In response to receiving a transaction request from the buyer to transfer a payment amount from the buyer account to the supplier account, the method debits the payment amount from the buyer account, identifies a supplier account based on the supplier identification number, and credits the payment amount to the identified supplier account. The buyer account is linked to a transaction card that is used to pay the requested amount in the transaction. The source account may be a merchant account that allows the source to receive payments from transaction cards that are linked to the buyer account. The method may periodically reconcile the source account and deposit the balance into another bank account of the source, such as an external checking account. The reconciliation process may automatically settle processed transaction requests after a predefined period of time. For example, to simplify the reconciliation process, the method may automatically reconcile the source account at the end of each business day.

[0006] The method is further configured to notify the supplier and the buyer after completing the requested transaction, the supplier being notified after crediting the supplier account with the payment amount and the buyer being notified after debiting the buyer account with the payment amount.

[0007] Although a single transaction request is described in the above description, the method may also implement multiple transaction requests that are received simultaneously. Between one buyer and one supplier, one notification may be generated and used to coordinate multiple transaction requests, thus simplifying the payment process, increasing efficiency and reducing the room for delays and errors.

[0008] In this method, the process of transferring payment directly from the buyer account to the supplier account occurs substantially simultaneously with receiving the transaction request from the buyer. For example, automated payment processing may transfer the payment amount from the buyer account to the supplier account within seconds of receiving the transaction request. This provides an efficient and labor-free way for a supplier to quickly receive multiple payments from various buyers. The method also eliminates the potential lag time between the buyer transmitting credit card information to the supplier and the supplier manually keying in the credit card information at the point of sale.

[0009] In some embodiments, the method is further configured to determine whether the supplier account is enrolled in automated payment processing. If the method determines that the supplier account is enrolled in automated payment processing, the method then debits the payment amount from the buyer account, identifies the supplier account based on the supplier identification number, and credits the payment amount to the identified supplier account. On the other hand, if the method determines that the supplier account is not enrolled in automated payment processing, the method then generates a virtual account number that is unique with respect to a specific transaction request from the buyer. The virtual account number is then transmitted to the supplier for manual entry at the point of sale.

[0010] In some embodiments, virtual account numbers are generated to enhance security during the transmission of sensitive credit card information in "card not present" transactions. A virtual account number, also called a token, is a one-time number that is generated for a specific payment transaction and transmitted to the supplier for manual entry at the point of sale. During a "card not present" transaction, one credit card number may be transmitted to complete multiple transaction requests. On the other hand, when a virtual account number is used to complete a transaction, a different virtual account number is generated and transmitted for each transaction request from the same credit card number.

[0011] In some embodiments, the method is further configured to determine whether the supplier wishes to complete the transaction request using automated payment processing or virtual account numbers based on the stored supplier preferences. Optionally, when registering for automated payment processing, the supplier may specify whether they wish to process transactions using automated payment processing, virtual account numbers, or a combination of both. The supplier preferences may indicate different methods to be used to process transactions based on the buyer's identity or transaction type. For example, the supplier may specify in the supplier preferences that for some buyers, automated payment processing is used, while for other buyers, transactions are processed using virtual account numbers. The supplier may also specify that some transaction types are processed using automated payment processing, while other transaction types are processed using virtual account numbers. The supplier may be provided with an opportunity to specify the supplier preferences when registering for automated payment processing via a website, mobile application, or the like. [Brief description of the drawings]

[0012] The accompanying drawings are incorporated in and form a part of this specification.

[0013] [Figure 1] FIG. 1 depicts a flowchart illustrating a method for automated payment processing, according to some embodiments.

[0014] [Diagram 2] FIG. 2 depicts a flowchart illustrating a method for determining whether to perform the automated payment processing shown in FIG. 1 or whether to perform a token method by generating a virtual account number, according to some embodiments.

[0015] [Diagram 3] FIG. 3 depicts a flowchart illustrating a method for executing multiple transaction requests to be coordinated through one notification, according to some embodiments.

[0016] [Figure 4] FIG. 4 depicts an exemplary email notification sent to a supplier after completing a periodic reconciliation process, according to some embodiments.

[0017] [Diagram 5] FIG. 5 depicts a block diagram of an exemplary computer system for implementing various embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] In the drawings, like reference numbers generally indicate the same or similar elements. Additionally, the leftmost digit of a reference number generally identifies the drawing in which the reference number first appears.

[0019] (Detailed Description) Provided herein are system, apparatus, device, method, and / or computer program product embodiments, and / or combinations and subcombinations thereof, for automating virtual payment processes. Various embodiments of these features will now be discussed with respect to the corresponding figures.

[0020] FIG. 1 depicts a flow chart of a method 100 for automated payment processing, according to some embodiments. In step 110, a buyer may initiate automated payment processing and provide a transaction request to transfer a payment amount directly from the buyer's buyer account to a supplier account associated with the supplier. In some embodiments, the transaction request may allow the buyer to select, from an interface, a supplier or a supplier account into which to credit the payment amount. In other embodiments, the transaction request may be an invoice transmitted from the supplier to the buyer. The invoice may include, among other things, an invoice number that identifies the invoice, the payment amount for the specific transaction, and a supplier identification number that identifies the supplier. In this embodiment, the buyer may be able to initiate the transaction request by pressing a button labeled "Pay Amount" on the electronic invoice.

[0021] In response to receiving the transaction request, method 100 performs steps 120-130. In step 120, method 100 debits the payment amount from a buyer account. In some embodiments, the buyer account is tied to a transaction card, which may be a credit card used to pay the requested amount and complete the transaction. In these embodiments, debiting the buyer account is equivalent to the buyer using a credit card to pay the transaction amount without ever presenting the credit card (as required during a physical card transaction) or providing sensitive credit card information to a supplier (as required during a "card not present" transaction). Such a "card not present" transaction allows for a quick and simple transaction for the buyer, similar to a direct wire transfer of money, while still providing the buyer with credit card purchase protection. For example, in some embodiments, the transaction request may be protected by available protection procedures implemented by the merchant acquiring bank that issued the transaction card that is tied to the buyer account and used to pay the payment amount.

[0022] In step 125, the method 100 identifies a source account for receiving the payment amount based on the source identification number. The source account may be, for example, a merchant account used to process and receive payments using a point of sale. A merchant account is a type of account that allows a business to receive payments in multiple ways, typically debit or credit cards. A merchant account is established under an agreement between a recipient and a merchant acquiring bank for settlement of payment card transactions. In some embodiments, the merchant acquiring bank is the same entity that issued the transaction card that is tied to the buyer account and used to pay the payment amount. In some cases, such as when a virtual card number is used to pay the payment amount and complete the transaction, a payment agent, an independent selling organization (ISO), or a member service provider (MSP) are also parties to the merchant agreement. The merchant agreement includes operating rules established by the card association.

[0023] After obtaining a transaction card with a merchant acquiring bank, each supplier is assigned a unique supplier identification number. In some embodiments, this supplier identification number may be used to identify the supplier when performing method 100. Each supplier may be assigned a supplier identification number regardless of whether the supplier enrolls in automated payment processing. In some embodiments, the supplier identification number is a number that is randomly generated for each supplier. Thus, the supplier identification number alone identifies the supplier within a system such as the system described in this disclosure and does not contain confidential information about the supplier. For example, the supplier identification number is not generated based on the account number of the supplier's account.

[0024] In step 130, the method 100 credits the identified supplier account associated with the supplier and the supplier identification number with the payment amount, debited from the buyer account in step 120. The process of debiting the buyer account, identifying the supplier account, and crediting the identified supplier account occurs without transmitting any sensitive information regarding either the buyer or the supplier. For example, the performance of steps 120-130 does not include transmitting a transaction account number associated with the buyer account, transmitting a transaction account number associated with the supplier account, or transmitting sensitive card information of a transaction card tied to the buyer account. Steps 120-130 occur within a back-end system such that the buyer and supplier are not aware of the performance of steps 120-130 when they complete the transaction. Furthermore, the process of transferring the payment amount directly from the buyer account to the supplier account occurs substantially simultaneously with receiving the transaction request from the buyer. For example, in some embodiments, method 100 may transfer the payment amount from the buyer account to the supplier account in steps 120-130 within seconds of receiving the transaction request in step 110. This provides an efficient and effortless way for the supplier to quickly receive payment from the buyer.

[0025] After the payment amount has been transferred from the buyer account to the source account, method 100 performs step 135 to reconcile the source account. In some embodiments, the source account is a merchant account that allows the source to receive payments from a transaction card that is linked to the buyer account. In step 135, the source account is reconciled by depositing the balance of the source account into another bank account of the source, such as an external checking account. In some embodiments, this reconciliation process may occur periodically, such as at the end of each business day. The periodic reconciliation process is described in further detail below with reference to FIG. 3.

[0026] FIG. 2 depicts a flow chart illustrating a method 200 for determining whether to perform the method 100 for automated payment processing shown in FIG. 1 or whether to perform a token method by generating a virtual account number, according to some embodiments. In some embodiments, method 200 begins similarly to method 100. In step 210, a buyer provides a transaction request to transfer a payment amount from a buyer account to a supplier account. In some embodiments, the transaction request may be an invoice transmitted from the supplier to the buyer. The invoice may include, among other things, the payment amount for a specific transaction and a supplier identification number that identifies the supplier. A transaction card, such as a credit card, is linked to the buyer account and is used to pay the payment amount in the requested transaction. Method 200 then performs decision 215 to determine whether to proceed to steps 220-230, similar to steps 120-130 of method 100, or to steps 240-260 of the token method.

[0027] At decision 215, method 200 determines whether the supplier account is enrolled in automated payment processing. In some embodiments, method 200 may make this determination by retrieving a supplier identification number associated with the supplier's supplier account. Since a supplier identification number is generated and assigned to each supplier account when the supplier performs automated payment processing and obtains a transaction card that is used to pay the payment amount, an existing supplier identification number for the supplier may be an indication that the associated supplier account is enrolled in automated payment processing. In other embodiments, method 200 may make the determination at decision 215 by retrieving the supplier's name or other personal information of the supplier. In other embodiments, method 200 may make the determination at decision 215 by directly retrieving the supplier account associated with the supplier.

[0028] If method 200 determines in decision 215 that the supplier account is enrolled in automated payment processing, method 200 proceeds to perform automated payment processing by debiting the payment amount from the buyer account (step 220), identifying the supplier account based on the supplier identification number (step 225), and crediting the identified supplier account with the payment amount (step 230). In step 235, method 200 reconciles the supplier account for the completed transaction, similar to step 135 described above with reference to Figure 1. Steps 220-230 comprise the automated payment processing method described with reference to steps 120-130 of Figure 1.

[0029] On the other hand, if the method 200 determines in decision 215 that the source account is not enrolled in automated payment processing, the method 200 continues with the token method of steps 240-260. In step 240, a virtual account number, also referred to as a token, is randomly generated for the received transaction request. Each virtual account number is randomly generated and does not contain any sensitive credit card information, such as the original credit card number on the transaction card used to pay the payment amount. Using a virtual account number reduces exposure to the credit limit associated with the card. The virtual account number may also have other restrictions, such as restrictions limiting its use to a particular business. This still transmits the original sensitive credit card information on the transaction card, but provides increased security over using only an encryption method that relies on an encoding process prior to transmission and a decoding process upon receipt at the point of sale to secure the transmission process. While the encryption method can be reversed to recover sensitive card information captured during transmission, the virtual account number that is randomly generated for each transaction does not contain any sensitive card information at all. By generating and transmitting a unique virtual account number for each transaction, sensitive credit card information no longer needs to be transmitted, thus reducing the likelihood that credit card numbers will be compromised and reused fraudulently. In some embodiments, encryption methods may be used in addition to the virtual card number to secure transactions where the payment amount exceeds $25,000. Furthermore, multiple people sharing a single corporate credit card may avoid the errors and confusion of sharing one physical credit card, which in turn saves time and reduces the need for manual reconciliation to ensure accuracy of accounting after completing a transaction. However, the virtual account number still must be transmitted and manually typed in by the supplier at the point of sale. This process is time-consuming, inconvenient, and prone to human error, thus making the token method a less desirable option than automated payment processing methods.

[0030] In some embodiments, the virtual account number is a 15-digit number that is unique to identify the received transaction request. The virtual account number is randomly generated and is not based on encrypting sensitive credit card information on the transaction card tied to the buyer account used to pay the payment amount in the received transaction request. Thus, when the virtual account number is transmitted to the source in step 245, any original sensitive credit card information on the transaction card is not transmitted. This increases the security of processing the transaction request by protecting the transaction card used to pay the payment amount even when the virtual account number is leaked or captured during transmission.

[0031] After receiving the virtual account number transmitted in step 245, the supplier may manually enter the virtual account number for the transaction request at the point of sale (step 250). Once entered, method 200 proceeds to steps 255-260, which debit the payment amount from the buyer account (step 255) and credit the payment amount to the supplier account (step 260). Steps 255-260 are similar to conventional business methods available for transferring money between two accounts and therefore are not described in specific detail herein. After transferring the payment amount from the buyer account to the supplier account, method 200 reconciles the supplier account (step 265), similar to steps 135 and 235, described above.

[0032] In some embodiments, decision 215 may also include determining source preferences for the supplier. The source preferences may include guidelines provided by the supplier when enrolling in the automated payment processing of method 100. In some embodiments, optionally, the source preferences may include instructions to process transaction requests using automated payment processing for some buyers or transaction types (steps 220-230), while using a token method for other buyers or transaction types (steps 240-260). For example, the source preferences may specify using automated payment processing for buyers on a first list and a token method for buyers on a second list. In this example, a transaction request provided by a buyer on the second list will be processed using the token method (steps 240-260) even though in decision 215 it is determined that the supplier is enrolled in automated payment processing. The suppliers may further specify different source preferences for different buyers based on their relationship with the buyer or based on the type of transaction with the buyer. For example, a supplier may specify in its supplier preferences that for a first purchaser who has a long-standing business relationship with the supplier, transaction requests should always be completed using the automated payment processing method, and for a second purchaser who does business with the supplier only occasionally, transaction requests should always be completed using the token method. Similarly, a supplier may specify in its supplier preferences that a first type of transaction request from a purchaser should be completed using the automated payment processing method, and a second type of transaction request from the same purchaser should be completed using the token method. The ability to mix and match the methods used to complete each transaction request based on the specified categories gives the supplier great flexibility and control over the transaction process.

[0033] In addition, the transaction card tied to the buyer account may be a closed-loop card in some embodiments. A closed-loop transaction card limits transaction requests to those between a buyer and a supplier, both of which are on a predefined list of accepted parties. This closed-loop system simplifies the process for suppliers when enrolling in automated payment processing. Smaller suppliers, who may not have the resources to negotiate independent agreements with each buyer to perform direct pushes of payments from the buyer account to the supplier account, may enroll more easily and efficiently with the automated payment processing described in this disclosure. Thus, suppliers enrolled in automated payment processing may achieve higher efficiency and higher buyer-to-buyer acceptance of transaction requests.

[0034] FIG. 3 depicts a flow chart illustrating a method 300 for executing multiple transaction requests to be reconciled through one notification, according to some embodiments. Method 300 begins similarly to method 100. In step 310, method 300 receives a transaction request initiated by a buyer and transfers a payment amount from a buyer account to a supplier account. In some embodiments, the transaction request may be an invoice that includes the payment amount for the specific transaction and a supplier identification number that identifies the supplier. The payment amount is then debited from the buyer account (step 315), a supplier account is identified based on the supplier identification number (step 320), and the payment amount is credited to the identified supplier account (step 325). Method 300 then proceeds to decision 330 to determine whether a predetermined time period has elapsed.

[0035] If the predetermined time period has not yet elapsed, method 300 repeats steps 310-325 to process another transaction request for another payment amount between the buyer and the supplier. Thus, multiple transaction requests can be completed between one buyer and one supplier within the predetermined time period. If the predetermined time period has elapsed, method 300 proceeds to step 335 to reconcile the supplier account. In step 335, method 300 reconciles all transaction requests completed during the predetermined time period by depositing the entire balance of the supplier account into the supplier's other bank account. In this embodiment, the entire balance of the supplier account includes all payment amounts received per transaction request during the predetermined time period. Since the entire balance of the supplier account is deposited all at once into the supplier's other bank account, only one notification is needed to reconcile multiple transaction requests completed during the predetermined time period. This streamlines and simplifies the reconciliation process for suppliers, especially when dealing with buyers who frequently initiate multiple transaction requests with suppliers during the course of business.

[0036] In some embodiments, the predetermined time period may be 1 day. In other embodiments, a different time period may be selected, such as 2 days or 3 days.

[0037] Method 300 then continues with step 340, notifying the supplier of a notification including the transaction requests completed during the predetermined time period. After completing the reconciliation process in step 335, method 300 sends a notification to the supplier, the notification including a bank invoice used to reconcile the transaction requests completed during the predetermined time period. The notification provided may be any electronic notification, such as email, text message, push notification on a mobile application, etc. An exemplary email notification sent to the supplier after completing the periodic reconciliation process is shown in FIG. 4.

[0038] FIG. 4 depicts an exemplary email notification 400 sent to a supplier after completing a periodic reconciliation process, according to some embodiments. The periodic reconciliation process may be similar to the method 300 described above with reference to FIG. 3. As shown in FIG. 4, the exemplary email notification 400 sent to the supplier includes a bank invoice used to reconcile multiple transaction requests during a predetermined time period. The email notification 400 may include a header section 405, a greeting section 410, a payment summary section 415, a payment details section 420, and a contact information section 425.

[0039] In the header section 405, the email notification 400 includes a brief subject and a preview. The header section 405 lets the supplier know that the payment amount for at least one transaction request initiated by the buyer is being transferred from the buyer account to the supplier account. In the greeting section 410, the supplier name and the buyer name are identified. In the payment summary section 415, the total balance of the supplier account, as reconciled by the bank statement, is shown within the email notification 400. This total balance includes the payment amount for each transaction request completed during a given period of time before starting the reconciliation process.

[0040] Details of up to 25 invoice balances may be listed in the payment details section 420, including the number for each transaction request ("Invoice Number"), the date each transaction request is processed ("Invoice Date"), and the amount due for each transaction request ("Amount Due"). For example, in the embodiment provided in FIG. 4, the email notification 400 shows bank invoices for two transaction requests, namely, $900.00 transferred from the buyer account to the supplier account on 15 May 2019, and $1,000.01 transferred from the buyer account to the supplier account on 20 May 2019. Contact information for the merchant acquiring bank, which completes the multiple transaction requests, is provided in the contact information section 425 for easy access to the merchant acquiring bank.

[0041] By providing one email notification 400 containing one bank statement for multiple trade requests completed during a given time period, suppliers can reconcile their supplier accounts much more efficiently and accurately than by receiving notifications after processing each individual trade request from a purchaser.

[0042] 5 depicts a block diagram of an exemplary computer system 500 for implementing various embodiments of the methods described above. One or more computer systems 500 may be used to implement, for example, any of the embodiments discussed herein, as well as combinations and subcombinations thereof. The computer system 500 shall be described with reference to FIGS. 1-4, however, the computer system 500 is not limited to the exemplary embodiments described in the foregoing figures.

[0043] In some embodiments, computer system 500 may receive power from an external power supply 505. The computer system may include one or more processors (also referred to as central processing units or CPUs), such as processor 510. Computer system 500 may also include memory 515, such as random access memory (RAM). Memory 515 may include one or more levels of cache. Memory 515 may store control logic (i.e., computer software) and / or data therein. Processor 510 may execute program code using instructions stored in memory 515 to perform operations implementing various embodiments described herein.

[0044] The computer system 500 may include a transmitter / receiver 520 for transmitting and receiving communications between the buyer 525 and the supplier 535. For example, referring to the method 100 of FIG. 1, the transmitter 520 may transmit an invoice including a payment amount and a supplier identification number from the supplier 535 to the buyer 525 according to some embodiments. The transmitter / receiver 520 may also receive a transaction request from the buyer 525 at step 110. The computer system 500 may also include a notification module 530 for providing notifications to the buyer 525 and the supplier 535. For example, referring to the method 300 and FIGS. 3 and 4, the notification module 530 may provide an email notification 400 to the supplier 535 at step 340 so that the supplier 535 may reconcile multiple transaction requests completed during a predetermined time period at decision 330.

[0045] The computer system 500 further includes a payment routing module 540 and a virtual account number generator 545. In some embodiments, the payment routing module 540 is configured to implement various embodiments of automated payment processing described with reference to methods 100-300 of FIGS. 1-3. The payment routing module 540 may store various information required to implement automated payment processing, including, but not limited to, invoices 550, invoice numbers 555 assigned to each invoice 550, payment amounts 560 per transaction request, supplier identification numbers 565 associated with each supplier 535, and supplier preferences 570. In some embodiments, the invoices 550 and invoice numbers 555 may be optional and other methods of receiving the payment amount 560 and supplier identification number 565 may be used (e.g., the purchaser 525 may select the payment amount 560 or supplier identification number 565 from a drop-down menu in an online portal without having to receive the invoice 550 or invoice number 555). The computer system 500 is in communication with the buyer account 575 and the supplier account 580 such that the payment amount 560 of the invoice 550 may be transferred directly from the buyer account 575 to the supplier account 580. The buyer account 575 may be linked to a transaction account number 585, which identifies the buyer account 575, and a transaction card 590, such as a credit card, used to pay the payment amount 560. The supplier account 580 may be linked to a supplier bank account 595, which may be a second bank account of the supplier, such as a checking account. In some embodiments, the balance of the supplier account 580 may be deposited into the external supplier bank account 595 to adjust the supplier account 580.

[0046] The processor 510 of the computer system 500 may determine whether to execute an automated payment processing method or a token method based on various considerations, including, but not limited to, instructions stored in the supplier preferences 570 or the presence of a supplier identification number 565 or a supplier account 580 associated with the supplier 535. For example, with reference to the method 200 of FIG. 2, the processor 510 of the computer system 500 may make the determination whether to execute an automated payment processing method or a token method in decision 215. If an automated payment processing is executed, the payment routing module 540 executes steps 220-230, including debiting the payment amount 560 from the buyer account 575 (step 220), identifying a supplier account 580 based on the supplier identification number 565 (step 225), and crediting the identified supplier account 580 with the payment amount 560 (step 230). If a token method is executed, the virtual account number generator 545 generates a virtual account number in step 240. After the virtual account number is transmitted to the supplier 535 (step 245) and the supplier 535 types in the virtual account number at the point of sale (step 250), the payment routing module 540 may then subsequently transfer the payment amount 560 directly from the purchaser account 575 to the supplier account 580 (steps 255-260).

[0047] Computer system 500 may also be any or any combination of a personal digital assistant (PDA), a desktop workstation, a laptop or notebook computer, a netbook, a tablet, a smartphone, a smartwatch or other wearable, a consumer electronics device, part of the Internet of Things, and / or an embedded system, to name a few non-limiting examples.

[0048] Computer system 500 may be a client or server that accesses or hosts any application and / or data through any delivery paradigm, including, but not limited to, remote or distributed cloud computing solutions, local or on-premise software ("on-premise" cloud-based solutions), an "as a service" model (e.g., Content as a Service (CaaS), Digital Content as a Service (DCaaS), Software as a Service (SaaS), Management Software as a Service (MSaaS), Platform as a Service (PaaS), Desktop as a Service (DaaS), Framework as a Service (FaaS), Backend as a Service (BaaS), Mobile Backend as a Service (MBaaS), Infrastructure as a Service (IaaS), etc.), and / or a hybrid model including any combination of the foregoing examples or other service or delivery paradigms.

[0049] Any applicable data structures, file formats, and schemas in computer system 500 may be derived from standards, including, but not limited to, JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations, alone or in combination. Alternatively, proprietary data structures, formats, or schemas may be used, either exclusively or in combination with known or open standards.

[0050] In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer usable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 500, processor 510, memory 515, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 500), may cause such data processing devices to operate as described herein.

[0051] Based on the teachings contained in this disclosure, it will be apparent to one of ordinary skill in the art how to make and use embodiments of the present disclosure using data processing devices, computer systems, and / or computer architectures other than those shown in Figure 5. In particular, embodiments may operate using software, hardware, and / or operating system implementations other than those described herein.

[0052] It is understood that the Detailed Description section, and not any other section, is intended to be used to interpret the claims, as the other sections may describe one or more, but not all, example embodiments as contemplated by the inventors, and are therefore not intended to limit the disclosure or the appended claims in any way.

[0053] Although the present disclosure describes exemplary embodiments with respect to exemplary fields and applications, it should be understood that the present disclosure is not limited thereto. Other embodiments and modifications thereto are possible and within the scope and spirit of the present disclosure. For example, without limiting the generality of this paragraph, the embodiments are not limited to the software, hardware, firmware, and / or entities illustrated in the figures and / or described herein. Furthermore, the embodiments (whether or not explicitly described herein) have significant utility for fields and applications other than the examples described herein.

[0054] The embodiments are described herein with the aid of functional structural blocks that illustrate implementations of specified functions and relationships thereof. The boundaries of these functional structural blocks are arbitrarily defined herein for convenience of description. Alternative boundaries may be defined so long as the specified functions and relationships (or their equivalents) are appropriately performed. Alternative embodiments may also implement functional blocks, steps, operations, methods, etc. using different orderings than those described herein.

[0055] Reference herein to "one embodiment," "an embodiment," "an example embodiment," or similar phrases indicates that the described embodiment may include a particular feature, structure, or characteristic, but not all embodiments may necessarily include the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of one of ordinary skill in the art to incorporate such feature, structure, or characteristic in other embodiments, whether or not it is explicitly mentioned or described herein. In addition, some embodiments may be described using the terms "coupled" and "connected," along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms "connected" and / or "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

[0056] The scope and breadth of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

1. A computer-implemented method for automated payment processing, comprising: receiving a transaction request from a buyer device to transfer a payment amount from a buyer account to a source account, said buyer account being associated with at least a transaction account number; generating a virtual supplier account number associated with the supplier account, wherein the virtual supplier account number is randomly generated and does not contain confidential information associated with the supplier account; encrypting the virtual source account number associated with the source account based on the payment amount exceeding a threshold amount; transmitting the encrypted virtual supplier account number associated with the supplier account to a supplier device and triggering the supplier device to key in the encrypted virtual supplier account number at a point of sale device associated with the supplier device; decrypting the encrypted virtual supplier account number associated with the supplier account; in response to decrypting the encrypted virtual supplier account number transmitted by the point of sale device associated with the supplier device, crediting the payment amount debited from the buyer account to the supplier account without transmitting the confidential information associated with either the buyer device or the supplier device, wherein the crediting occurs simultaneously with receiving the transaction request from the buyer device; 11. A computer-implemented method comprising:

2. Determining a first purchaser, a second purchaser, and a third purchaser based on preferences associated with the source account, wherein the first purchaser is associated with the source account, the second purchaser is associated with a virtual source account, and the third purchaser is associated with a combination of the source account and the virtual source account; selecting at least one of the supplier account based on the first buyer, the virtual supplier account based on the second buyer, or the combination of the supplier account and the virtual supplier account based on the third buyer as a new supplier account; The computer-implemented method of claim 1 , further comprising:

3. Receiving a second transaction request from a second buyer device, the second transaction request including a second identification corresponding to a second supplier account; determining, based on the second identification, that the second supplier account is not enrolled in the automated payment processing; In response to said determination, generating a second virtual source account number specific to the second transaction request; transmitting the second virtual supplier account number associated with the second supplier account to a second supplier device; The computer-implemented method of claim 1 , further comprising:

4. automatically settling the trade request after a predetermined period of time; automatically settling said plurality of trade requests through a single notification; The computer-implemented method of claim 1 , further comprising:

5. The computer-implemented method of claim 1, further comprising transmitting an invoice from the supplier device to the buyer device, the invoice specifying the payment amount and an identifier corresponding to the supplier device.

6. Displaying an electronic invoice on a graphical user interface with a graphical user interface object; receiving an interaction with the graphical user interface object via the graphical user interface; generating an interface in response to receiving the interaction to enable the buyer device to submit the transaction request; The computer-implemented method of claim 1 , further comprising:

7. The computer-implemented method of claim 1, wherein the automated payment processing is configured to execute multiple transaction requests simultaneously.

8. A system for automated payment processing, comprising: a memory configured to store an operation; one or more processors configured to perform the operations, the operations comprising: receiving a transaction request from a buyer device to transfer a payment amount from a buyer account to a source account, said buyer account being associated with at least a transaction account number; generating a virtual supplier account number associated with the supplier account, wherein the virtual supplier account number is randomly generated and does not contain confidential information associated with the supplier account; encrypting the virtual source account number associated with the source account based on the payment amount exceeding a threshold amount; transmitting the encrypted virtual supplier account number associated with the supplier account to a supplier device and triggering the supplier device to key in the encrypted virtual supplier account number at a point of sale device associated with the supplier device; decrypting the encrypted virtual supplier account number associated with the supplier account; in response to decrypting the encrypted virtual supplier account number transmitted by the point of sale device associated with the supplier device, crediting the payment amount debited from the buyer account to the supplier account without transmitting the confidential information associated with either the buyer device or the supplier device, wherein the crediting occurs simultaneously with receiving the transaction request from the buyer device; one or more processors, A system comprising:

9. The operation is determining a first buyer, a second buyer, and a third buyer based on preferences associated with the supplier account, wherein the first buyer is associated with the supplier account, the second buyer is associated with a virtual supplier account, and the third buyer is associated with a combination of the supplier account and the virtual supplier account; selecting at least one of the supplier account based on the first buyer, the virtual supplier account based on the second buyer, or the combination of the supplier account and the virtual supplier account based on the third buyer as a new supplier account; The system of claim 8 , comprising:

10. The operation is receiving a second transaction request from a second buyer device, the second transaction request including a second identification corresponding to a second supplier account; determining, based on the second identification, that the second supplier account is not enrolled in the automated payment processing; In response to said determination, generating a second virtual source account number specific to the second transaction request; transmitting the second virtual supplier account number associated with the second supplier account to a second supplier device; The system of claim 8 further comprising:

11. The operation is automatically settling the trade request after a predetermined period of time; automatically settling said plurality of trade requests through a single notification; The system of claim 8 further comprising:

12. The system described in claim 8, wherein the operation further includes transmitting an invoice from the supplier device to the buyer device, the invoice specifying the payment amount and an identifier corresponding to the supplier device.

13. The operation is Displaying the electronic invoice on a graphical user interface with the graphical user interface object; receiving an interaction with the graphical user interface object via the graphical user interface; generating an interface in response to receiving the interaction to enable the buyer device to submit the transaction request; The system of claim 8 further comprising:

14. The system of claim 8, wherein the automated payment processing is configured to execute multiple transaction requests simultaneously.

15. A non-transitory computer-readable storage device having instructions stored thereon, wherein execution of the instructions by one or more processing devices causes one or more processors to: receiving a transaction request from a buyer device to transfer a payment amount from a buyer account to a source account, said buyer account being associated with at least a transaction account number; generating a virtual supplier account number associated with the supplier account, wherein the virtual supplier account number is randomly generated and does not contain confidential information associated with the supplier account; encrypting the virtual source account number associated with the source account based on the payment amount exceeding a threshold amount; transmitting the encrypted virtual supplier account number associated with the supplier account to a supplier device and triggering the supplier device to key in the encrypted virtual supplier account number at a point of sale device associated with the supplier device; decrypting the encrypted virtual supplier account number associated with the supplier account; in response to decrypting the encrypted virtual supplier account number transmitted by the point of sale device associated with the supplier device, crediting the payment amount debited from the buyer account to the supplier account without transmitting the confidential information associated with either the buyer device or the supplier device, wherein the crediting occurs simultaneously with receiving the transaction request from the buyer device; A non-transitory computer-readable storage device that causes operations to be performed, including:

16. Determining a first purchaser, a second purchaser, and a third purchaser based on preferences associated with the source account, wherein the first purchaser is associated with the source account, the second purchaser is associated with a virtual source account, and the third purchaser is associated with a combination of the source account and the virtual source account; selecting at least one of the supplier account based on the first buyer, the virtual supplier account based on the second buyer, or the combination of the supplier account and the virtual supplier account based on the third buyer as a new supplier account; 16. The non-transitory computer-readable storage device of claim 15, further comprising:

17. Receiving a second transaction request from a second buyer device, the second transaction request including a second identification corresponding to a second supplier account; determining, based on the second identification, that the second supplier account is not enrolled in the automated payment processing; In response to said determination, generating a second virtual source account number specific to the second transaction request; transmitting the second virtual supplier account number associated with the second supplier account to a second supplier device; 16. The non-transitory computer-readable storage device of claim 15, further comprising:

18. Automatically settling said trade request after a predetermined period of time; automatically settling said plurality of trade requests through a single notification; 16. The non-transitory computer-readable storage device of claim 15, further comprising:

19. Displaying an electronic invoice on a graphical user interface with a graphical user interface object; receiving an interaction with the graphical user interface object via the graphical user interface; generating an interface in response to receiving the interaction to enable the buyer device to submit the transaction request; 16. The non-transitory computer-readable storage device of claim 15, further comprising:

20. The non-transitory computer-readable storage device of claim 15, wherein the automated payment processing is configured to execute multiple transaction requests simultaneously.

Images