Providing payment credentials to a consumer

Abstract

The present invention relates to providing payment credentials to a consumer. A method and system for providing payment credentials to a consumer is disclosed. A remotely accessible server receives a request for payment credentials required for a transaction, the request originating from an electronic device of a consumer. A transaction type associated with the transaction is determined, the transaction type being one of a plurality of predefined transaction types, wherein each transaction type is associated with a predefined payment credential format. The remotely accessible server obtains payment credentials for the payment credential format associated with the determined transaction type, and transmits the obtained payment credentials to the electronic device of the consumer for use in the transaction.

Description

[0001] This application is a divisional application of a PCT patent application filed in China with Chinese patent application number 201480042162.X, entitled "Providing Payment Vouchers to Consumers", filed on July 23, 2014.

[0002] Cross-references to related applications

[0003] This application claims priority to South African Provisional Patent Application No. 2013 / 05673, filed on July 26, 2013, entitled “Authorization Based on Transaction Type”, and to South African Provisional Patent Application No. 2013 / 06923, filed on September 16, 2013, both of which are incorporated herein by reference. Background Technology

[0004] To conduct one or more financial transactions, various systems and methods are used to provide payment credentials to consumers.

[0005] Such payment credentials typically include payment account details, such as a card number in the form of a primary account number (PAN), card expiry date, and / or card verification value (CVV). Alternatively, in conjunction with payment account details, payment credentials may also include: a passcode, PIN, personal identification number (PIN), etc. For example, these payment credentials may be valid for a single use only (often referred to as a "one-time payment credential"), or valid for a predefined period of time.

[0006] In one example of such a system, a consumer uses a mobile device to request a payment credential. If authorized, a payment credential including a single-use PAN (Payment Entity Label) is sent to the consumer. The consumer can then provide the payment credential to the merchant to complete the transaction.

[0007] Providing payment credentials to consumers in this way may pose security risks. For example, payment credentials could be intercepted by criminals and used for fraudulent transactions. Furthermore, the systems and methods used to provide payment credentials to consumers are limited to single-use formats, which may not be accepted at all payment acceptance points, and in this sense, they may be inflexible.

[0008] The present invention aims to at least partially alleviate these and other problems. Summary of the Invention

[0009] According to the present invention, a method for providing payment credentials to consumers is provided, the method being performed at a remotely accessible server, and comprising the following steps: Receive requests for payment credentials required to conduct a transaction, originating from the consumer's electronic device; Determine the transaction type associated with the transaction, which is one of a plurality of predefined transaction types, wherein each transaction type is associated with a predefined payment voucher format; Obtain a payment voucher in the format associated with the determined transaction type; and The obtained payment credentials are transmitted to the consumer's electronic device for use in transactions.

[0010] Further features include: a request for a payment credential includes a consumer transaction selection; the transaction type is determined at least in part based on the consumer transaction selection included in the request; and the step of determining the transaction type associated with the transaction includes: examining the account type associated with the consumer's account, and determining the transaction type at least in part based on that account type. The transaction type can be obtained from a consumer profile stored in a database containing the consumer's account details.

[0011] The account type can be one of an account associated with a corresponding actual payment card and an account not associated with a corresponding actual payment card. Different predefined payment credential formats can be associated with accounts associated with corresponding actual payment cards and accounts not associated with corresponding actual payment cards, respectively.

[0012] Further features include: the account is a mobile wallet account; the remotely accessible server is operated by a mobile banking system; and the transaction is a mobile banking transaction.

[0013] A request for a payment voucher can be for a single-use payment voucher. Optionally, the payment voucher can be valid for transactions of multiple transaction types, or for transactions of one or more transaction types within a predefined time period.

[0014] Further features provide that the step of obtaining a payment voucher in a payment voucher format associated with a transaction type includes requesting a payment voucher from an external voucher generation module; optionally, the step of obtaining a payment voucher in a payment voucher format associated with a transaction type includes generating a payment voucher at the remotely accessible server.

[0015] Further features include: the request for payment credentials includes a consumer identifier; the consumer identifier is an identifier of the consumer's electronic device; and the consumer's electronic device is a mobile phone. The identifier of the consumer's electronic device may be the Integrated Services Digital Network Number (MSISDN) of the consumer's mobile phone.

[0016] The payment credential format associated with the identified transaction type may include one or a combination of the following: bank account number, main account number (PAN), pseudo PAN, card expiry date, card verification value (CVV), PIN, passcode, personal identification number (PIN), token, barcode, and quick response (QR) code.

[0017] The predefined transaction types may include: e-commerce transactions, online transactions, online banking transactions, transactions involving physical cards, mobile banking transactions, transfers, agent cash withdrawals, cardless withdrawals or purchases, ATM cash withdrawals, transactions for accounts associated with the corresponding physical payment card, or transactions for accounts not associated with the corresponding physical payment card.

[0018] Further features include: the predefined transaction type includes ATM cash withdrawal, and the payment voucher format associated with ATM cash withdrawal is PAN and PIN.

[0019] According to one aspect, the account type is an account associated with a corresponding physical payment card having a static PAN, the predefined transaction type includes ATM cash withdrawal, and the payment voucher format associated with ATM cash withdrawal is only PIN.

[0020] Further features include: the predefined transaction types include e-commerce transactions, and the payment voucher format associated with e-commerce transactions is PAN, card expiry date, and CVV.

[0021] According to one aspect, the account type is an account associated with a corresponding physical payment card having a static PAN, the predefined transaction type includes e-commerce transactions, and the payment credential format associated with the e-commerce transaction is card expiry date and CVV.

[0022] Further features include: the predefined transaction type includes agent withdrawal transactions, and the payment voucher format associated with agent withdrawal transactions is PAN.

[0023] Further features include: establishing a communication channel with the consumer's electronic device prior to receiving a request for a payment credential; and communication between the remotely accessible server and the consumer's electronic device being conducted via one of the following: Short Message Service (SMS) protocol, Unstructured Supplemental Data Service (USSD) protocol, secure internet connection, and data communication enabled by a mobile software application installed on the consumer's electronic device.

[0024] This invention extends to a system for providing payment credentials to consumers, the system including a remotely accessible server that communicates with the consumer's electronic device, the remotely accessible server comprising: A request receiving component is used to receive a request for payment credentials required to conduct a transaction, the request originating from a consumer's electronic device; A type determination component is used to determine the transaction type associated with a transaction, wherein the transaction type is one of a plurality of predefined transaction types, each of which is associated with a predefined payment voucher format; A document acquisition component for acquiring a payment document in a payment document format associated with a determined transaction type; and A transmission component, used to transmit the acquired payment credentials to the consumer's electronic device for use in transactions.

[0025] Further features include: the credential acquisition component is configured to request payment credentials required for a transaction from an external credential generation module; the external credential generation module is operated by the consumer's card issuer or by a payment processor; and the card issuer is the consumer's issuing bank; or, the credential acquisition component is configured to generate payment credentials.

[0026] The present invention also extends to a computer program product for providing payment credentials to consumers, the computer program product comprising a computer-readable medium storing computer-readable program code for performing the following steps: Receive requests for payment credentials required to conduct a transaction, originating from the consumer's electronic device; Determine the transaction type associated with the transaction, which is one of a plurality of predefined transaction types, wherein each transaction type is associated with a predefined payment voucher format; Obtain a payment voucher in the format associated with the determined transaction type; and The obtained payment credentials are transmitted to the consumer's electronic device for use in transactions.

[0027] The computer-readable medium may be a non-volatile computer-readable medium, and the computer-readable program code may be executed by processing circuitry.

[0028] To gain a more complete understanding of the invention, embodiments thereof will now be described with reference to the accompanying drawings. Attached Figure Description

[0029] Figure 1A A schematic diagram illustrating an embodiment of a system for providing payment credentials to consumers according to the present invention; Figure 1BA block diagram illustrating a first embodiment of a remotely accessible server according to the present invention; Figure 1C A block diagram illustrating a second embodiment of the remotely accessible server according to the present invention is provided. Figure 2 To demonstrate the use of Figure 1A The swimlane flowchart of the system's method for providing payment credentials to consumers; Figure 3 To demonstrate the use of Figure 1A The swimlane flowchart of the system's method for providing payment credentials to consumers; Figure 4 A flowchart illustrating an exemplary embodiment of a method for providing payment credentials to consumers according to the present invention; Figure 5 A flowchart illustrating an exemplary embodiment of a method for providing payment credentials to consumers according to the present invention; Figure 6 A block diagram of a computing device that can be used in various embodiments of the present invention is shown; and Figure 7 A block diagram of a communication device that can be used in various embodiments of the present invention is shown. Detailed Implementation

[0030] A system and method for providing payment credentials to consumers are provided. A remotely accessible server receives a request for a payment credential required to conduct a transaction, originating from a consumer's electronic device. A transaction type associated with the transaction is determined, which is one of a plurality of predefined transaction types, each associated with a predefined format of a payment credential. The remotely accessible server obtains a payment credential in the format of the payment credential associated with the determined transaction type. These payment credentials are then transmitted to the consumer's electronic device for use in completing the transaction.

[0031] Figure 1A An implementation scheme of a system 100 for providing payment credentials to consumers is shown. System 100 includes: a remotely accessible server 110, multiple consumers 120 (each consumer having an electronic device 122), and a card issuing institution 130.

[0032] The remotely accessible server 110 can access a database 112 that includes multiple consumer profiles 114. In one embodiment, the remotely accessible server 110 is one or more mobile money servers for a mobile banking system, typically operated by an entity referred to as a mobile money operator. In this case, each consumer 120 may have a registered mobile wallet account maintained at the remotely accessible server 110, and the consumer profile 114 contains details of that mobile wallet account, such as consumer account number, consumer account type, consumer personal information, available funds, details of payment receipts, format of payment vouchers, etc. In a further embodiment, the remotely accessible server 110 is a server of a traditional financial institution (such as a bank or other financial service provider).

[0033] Electronic device 122 can be any electronic communication device capable of communicating via a communication network (e.g., a cellular communication network). The term should be interpreted to specifically include all mobile phones or cellular phones (including so-called "feature phones" and smartphones), and may also include other electronic devices (e.g., computers, laptops, PDAs, personal digital assistants, tablets, etc.).

[0034] exist Figure 1A In this implementation, the electronic device 122 is the mobile phone of the consumer 120. Where the electronic device 122 is a mobile phone and the remotely accessible server 110 is associated with a mobile money operator, a mobile money or mobile banking platform can typically be used to allow the consumer 120 to conduct financial transactions via the electronic device 122.

[0035] Well-known examples of mobile money transactions include cash in transactions, cash out transactions, peer-to-peer payments, over-the-air top-up services, and bill payments. Cash out transactions can include cash withdrawals at mobile money agents and / or cash withdrawals at automated teller machines (ATMs).

[0036] The remotely accessible server 110 is configured to transmit or receive communications to or from the electronic device 122 over a communication network (in this embodiment, a mobile communication network 140). The remotely accessible server 110 is further configured to transmit or receive communications over a communication network (which may be a mobile communication network, etc., or similar). Figure 1A The implementation scheme receives or transmits communications from or to the card issuer 130 via the Internet 150.

[0037] The implementation scheme sets the communication between the remotely accessible server 110 and the electronic device 122 and / or between the remotely accessible server 110 and the card issuer 130 as secure communication over an encrypted communication channel (e.g., Hypertext Transfer Protocol (HTTPS), Transport Layer Security / Secure Sockets Layer (TLS / SSL), or one or more other secure channels).

[0038] Issuing institution 130 can be any entity authorized to send payment credentials to consumer 120. In this embodiment, issuing institution 130 is the issuing bank of consumer 120. In another embodiment, issuing institution 130 can be a secure financial gateway or a payment processing network. In some embodiments, issuing institution 130 is an issuing institution processor, in other words, an entity that can connect financial service providers (e.g., mobile money operators) to a payment processing network (e.g., VisaNet). TM The payment processing entity.

[0039] The remotely accessible server 110 may include a request receiving component 115, a type determining component 116, a credential acquisition component 117, and a transmission component 118. The request receiving component 115 is used to receive requests for payment credentials required for a transaction. The type determining component 116 is used to determine the transaction type associated with the transaction. The credential acquisition component 117 is used to acquire a payment credential in a payment credential format associated with the determined transaction type. The transmission component 118 is used to transmit the acquired payment credential to the electronic device 122 of the consumer 120 for use in the transaction.

[0040] In one implementation, the credential acquisition component 117 may include a generation component 117A and a storage component 117B. In this case, the credential acquisition component 117 is configured to generate payment credentials, and the remotely accessible server 110 can thereby generate payment credentials itself. This implementation... Figure 1B As shown in the image.

[0041] In another embodiment, the credential acquisition component 117 is configured to request a payment credential required for a transaction from an external credential generation module 132 (which can typically be operated by the card issuer 130). In this case, the credential acquisition component 117 may include an external request component 117C and a credential receiving component 117D, so as to be able to request and receive the requested payment credential from the external credential generation module 132, respectively. This embodiment is similar to... Figure 1B of Figure 1C As shown in the image. Figure 1A , Figure 1B as well as Figure 1C Similar reference numerals in the accompanying drawings refer to the same components and entities.

[0042] In some implementations, the external credential generation module can be provided by, for example, VisaNet. TM The payment processing network operates through a payment processing network. This network may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception handling services, and clearing and settlement services. (e.g., VisaNet) TM It can process credit card transactions, debit card transactions, and other types of commercial transactions. Furthermore, the payment processing network may include one or more servers and can utilize any suitable wired or wireless network (including the Internet).

[0043] System 100 enables consumer 120 to request payment credentials using electronic device 122 for use in transactions. System 100 can also be configured to execute at least part of a transaction or complete the transaction. Remotely accessible server 110 associates different payment credential formats with different types of transactions and provides credentials to consumers accordingly, as described in more detail below.

[0044] Figure 2 Flowchart 200 illustrates an example of a method for providing payment credentials to a consumer using the system of Figure 1. Consumer 120 has a mobile wallet account and is able to conduct mobile banking transactions using electronic device 122. In this example, the consumer requests a single-use (“one-time”) payment credential for use in a single transaction of a specific transaction type.

[0045] In the first phase 202, consumer 120 uses electronic device 122 to establish a communication channel with remotely accessible server 110. Communication between remotely accessible server 110 and consumer 120's electronic device 122 can typically be established via Short Message Service (SMS) protocol over a secure internet connection, Unstructured Supplemental Data Service (USSD) protocol, or via data communication enabled by a mobile software application installed on the consumer's electronic device. In this example, a USSD session is initiated.

[0046] In the next stage 204, the remotely accessible server 110 presents the electronic device 122 with the option to request a payment voucher. Typically, this option is presented as a menu option on the display of the electronic device 122. For example, the "Generate a one-time payment voucher" menu option from the USSD menu may be presented to the consumer 120.

[0047] In the next stage 206, consumer 120 requests the generation of a payment voucher. In this implementation, consumer 120 also specifies the type of transaction requiring the voucher. For example, consumer 120 may have the option to select one of the following transaction types: ATM cash withdrawal, e-commerce transaction, or agent withdrawal transaction to be performed at a mobile money agent. As used herein, the term "ATM cash withdrawal" can refer to a cash withdrawal or cash withdrawal performed at an ATM with or without a payment card. In other words, a consumer may be able to achieve the purpose of ATM cash withdrawal without a physical card. This type of withdrawal is referred to as cardless ATM cash withdrawal.

[0048] Requests for payment credentials are typically accompanied by a consumer identifier. In a preferred embodiment, such as in a USSD-based system, this identifier is the Integrated Services Digital Network Number (MSISDN) of the mobile phone used by consumer 120 to request the payment credential. Alternatively, the consumer identifier can be obtained by requiring the consumer to log in to a secure software application or website, for example, by entering a username and password.

[0049] The remotely accessible server 110 receives a request for a payment voucher originating from the electronic device 122, and then, in the next stage 208, examines the transaction type received from the consumer's electronic device 122 and searches the database 112 for the payment voucher format associated with the received transaction type. Therefore, in this embodiment, consumer transaction selection is used to determine the transaction type. A payment voucher format is selected from a plurality of predefined payment voucher formats, each transaction type available to the consumer being associated with a predefined payment voucher format.

[0050] It is conceivable that one or more verification steps may be performed before a payment voucher is generated and / or transmitted to consumer 120. For example, consumer 120 may need to enter a PIN, or go through a two- and / or three-factor authentication process.

[0051] The remotely accessible server 110 is configured to look up the payment voucher format corresponding to the transaction type. It then retrieves the payment voucher according to the specified format and transmits it to the consumer's electronic device 122. Many payment vouchers can be used, depending on which transaction or payment voucher requests support from the remotely accessible server 110.

[0052] For example, among many other types, supported transactions can include: e-commerce transactions, online transactions, online banking transactions, transactions involving physical cards, mobile banking transactions, transfers, agent cash withdrawals, cardless withdrawals or purchases, ATM cash withdrawals, transactions for accounts associated with a corresponding physical payment card, and transactions for accounts not associated with a corresponding physical payment card, etc. Each supported transaction type is associated with a specified, predefined payment credential format, which can be the same for two or more transaction types.

[0053] Payment credentials may be generated and transmitted to consumer 120 in any or any combination of the following formats, including but not limited to: bank account number, primary account number (PAN), pseudo PAN, card expiry date, card verification value (CVV), PIN, passcode, personal identification number (PIN), token, barcode, payment reference code, and quick response (QR) code. The term "pseudo PAN" should be interpreted broadly and includes tokens associated with a genuine PAN, credentials in PAN format, and obfuscated PANs. Any suitable token uniquely associated with a consumer's payment credentials (which can be used to complete transactions against the consumer's account) may be generated and transmitted to the consumer's electronic device 122.

[0054] For example, for a type "A" transaction, the associated payment voucher format could be a PAN or a PIN. For a type "B" transaction, the associated payment voucher format could be a QR code. For a type "C" transaction, the associated payment voucher format could be a pseudo-PAN. Therefore, consumers can receive different payment vouchers based on the proposed transaction type.

[0055] exist Figure 2 In the illustrated implementation, if the transaction type is an e-commerce transaction, then in the next stage 210, the remotely accessible server 110 requests the issuing institution 130 to generate a PAN, card expiry date, and CVV as a single-use payment credential. If the transaction type received from the consumer 120's electronic device 122 is an ATM cash withdrawal, then in the next stage 212, the remotely accessible server 110 requests the issuing institution 130 to generate a PAN and PIN as a single-use payment credential. Alternatively, if the transaction type received from the consumer 120's electronic device 122 is an agent cash withdrawal transaction, then in the next stage 214, the remotely accessible server 110 requests the issuing institution 130 to generate only a PAN as a single-use payment credential.

[0056] In this implementation, payment credentials are generated by issuing institution 130 and obtained from issuing institution 130 via remotely accessible server 110. In this scenario, upon receiving the credentials, when consumer 120 subsequently presents these payment credentials for a transaction, issuing institution 130 can typically verify that the presented payment credentials match the originally generated payment credentials before final authorization of the transaction. Alternatively, payment credentials can be generated using remotely accessible server 110 without requiring a request to be sent to issuing institution 130. In this case, one or both of the receiving bank or issuing institution 130 will request remotely accessible server 110 to verify any payment credentials received before authorization of the transaction, checking whether the received payment credentials are validly generated for the specified transaction or transaction type.

[0057] In the next stage 216, the issuing institution 130 generates payment credentials in the required format and transmits them to a remotely accessible server 110. Then, in the next stage 218, these payment credentials are transferred from the remotely accessible server 110 to the consumer 120's electronic device 122. In the final stage 220, the consumer 120 receives the payment credentials and can then use them for one or more transactions of only the specified type, or one or more transactions of different transaction types, provided that the payment credentials are acceptable for each specified transaction type.

[0058] After the payment voucher is transferred to the consumer 120's electronic device 122, it can be used for at least one financial transaction of a specific transaction type. The payment voucher can be a single-use ("one-time") payment voucher for a single transaction of a specific transaction type. For example, the consumer 120 can request a one-time payment voucher for an e-commerce transaction. The remotely accessible server 110 then associates the transaction type with a specified payment voucher format (e.g., a combination of PAN, card expiry date, and CVV). These vouchers can then be used once for the e-commerce transaction.

[0059] In some implementations, payment credentials can only be used for specified transaction types. However, it should be understood that in alternative implementations, payment credentials can also be used for any transaction that accepts a particular payment credential. For example, regarding a request for a payment credential for an e-commerce transaction, where only a PAN is required for such a transaction, consumer 120 can use the PAN received along with the card's expiry date and CVV to execute an agent withdrawal transaction at a mobile money agent in a mobile banking environment.

[0060] In addition, payment vouchers may be valid for transactions of multiple transaction types, or alternatively, payment vouchers may have a limited validity period and may be valid for transactions of one or more transaction types within a predefined time period.

[0061] The type of transaction requesting payment vouchers can be determined by a remotely accessible server 110, for example, as... Figure 2 As in the example, it can be determined based on user account information stored in database 112, or based on consumer selection in the request itself. Alternatively, it can be determined from more information in the request for payment credentials.

[0062] The remotely accessible server 110 can distinguish between transactions for accounts associated with a corresponding physical payment card and transactions for accounts not associated with a corresponding physical payment card. In this case, determining the transaction type associated with a transaction may include: examining the account type associated with the consumer's account, and determining the transaction type at least in part based on the account type.

[0063] For example, a consumer may have only a virtual account that is not associated with an actual payment card. When the consumer requests a payment credential, the transaction type can be retrieved from the consumer profile stored in a database containing details of the consumer's account, indicating that the consumer does not have an actual payment card. This feature will be described in more detail below.

[0064] In mobile banking systems or similar payment networks, some consumers may have an actual payment card or a "companion plastic card" with payment credentials (e.g., PAN, expiry date, and / or CVV) physically affixed to and / or stored on a chip and / or the card's magnetic stripe, while other consumers may only have payment credentials that are stored electronically or are dynamic and must be requested electronically. In this case, consumers may necessarily need different payment credentials to execute the transaction.

[0065] For example, in a mobile banking system that utilizes a PAN to handle so-called "open-loop" mobile payment transactions between various independent mobile money deployments, if a consumer has an account associated with an actual payment card and requests to execute an agent withdrawal, cash withdrawal, or payment transaction, the consumer should already have a PAN for the transaction because the PAN is typically set up in the payment card. This implementation is referred to as an account with a "static" PAN or a permanent PAN.

[0066] Conversely, if a consumer without a corresponding physical payment card requests to execute such a transaction, the consumer may not have a static PAN and the card issuer should be required to provide the consumer with a PAN so that the consumer can complete the desired transaction.

[0067] Figure 3 The swim lane flowchart 300 shows the use of Figure 1A A further example of a system for providing payment credentials to consumers. In this example, a remotely accessible server 110 is configured to distinguish between accounts associated with an actual payment card and accounts not associated with an actual payment card.

[0068] In the first stage 302, consumer 120 uses electronic device 122 to establish a communication channel with remotely accessible server 110. In the next stage 304, remotely accessible server 110 presents the option to request a payment voucher to electronic device 122.

[0069] In the next stage 306, consumer 120 requests the generation of a payment credential. In this implementation, consumer 120 chooses to receive a payment credential for executing a withdrawal transaction. Consumer 120 may have the option to choose between an ATM withdrawal or an agent withdrawal transaction executed at a mobile money agent. The remotely accessible server 110 then uses this choice and additionally determines whether consumer 120 has the corresponding physical payment card, in other words, whether it has a static PAN.

[0070] Then, in the next stage 308, the remotely accessible server 110 checks the transaction type received and / or obtained as described above and looks up the payment voucher format associated with the transaction type in the database 112. If the transaction type is for an account associated with the corresponding physical payment card, then in the next stage 310, the remotely accessible server 110 requests the card issuer 130 to generate only a one-time PIN. If the transaction type is for an account not associated with the corresponding physical payment card, then in the next stage 312, the remotely accessible server 110 requests the card issuer 130 to generate both a one-time PIN and a one-time PAN.

[0071] The remotely accessible server 110 typically examines the consumer profile 114 in the database 112 to determine whether the consumer 120 needs a one-time PAN to complete the transaction.

[0072] In the next stage 314, the issuing institution 130 generates a payment voucher in the required format and transmits it to a remotely accessible server 110. Then, in the next stage 316, these payment vouchers are transferred from the remotely accessible server 110 to the consumer 120's electronic device 122. In the final stage 318, the consumer 120 receives the payment vouchers and can then use them to perform one or more transactions of a specified type, or one or more transactions of different transaction types, provided that the payment voucher is an accepted payment voucher for each specified transaction type.

[0073] It should be understood that, in some implementations, consumer transaction options can be provided to a remotely accessible server, and the transaction type can be determined at least in part based on the consumer transaction options included in the request. Consumers do not need to explicitly provide consumer transaction options. Merchants can provide such options, or obtain them from any other suitable information in the request for payment credentials.

[0074] Furthermore, in some implementations, determining the transaction type may include: examining the account type associated with the consumer's account, and determining the transaction type at least in part based on the account type. In some implementations, determining the transaction type may include using both the transaction selection and account type described above to determine the transaction type, and thereby also determining the relevant payment voucher format.

[0075] Now refer to Figure 4 and Figure 5 This section describes implementations of two exemplary mobile phones. Figure 4 In the example shown in Figure 400, consumer 120 requests that a payment credential be provided to electronic device 122 for use in an e-commerce transaction.

[0076] In the first stage 410, consumer 120 uses electronic device 122 (a mobile phone in this example) to access a bank menu set up for USSD-based services. Various bank options are presented to consumer 120, and in the next stage 412, consumer 120 selects to generate a one-time payment voucher.

[0077] In the next stage 420, consumer 120 needs to select the type of transaction for which a payment voucher must be generated. In this case, and primarily for illustrative purposes, consumer 120 desires a payment voucher for conducting an e-commerce transaction and selects the appropriate menu option in the next stage 422.

[0078] In the next stage 430, a notification is presented to the consumer 120 that the request has been received and that authorization is in progress. Between the preceding stages 420 and 430, one or more verification steps as described above may, of course, be included.

[0079] In this implementation, consumer 120 receives the appropriate payment credentials via one or more SMS messages. For example... Figure 4 As shown, in the final stage 440, the consumer 120 is provided with a single-use PAN, card validity period, and CVV for use in e-commerce transactions. To provide a higher level of security, in addition to limiting the number of times the payment credential can be used, it can also have a limited "validity period." For example, as... Figure 4 As shown, payment vouchers are valid for only 10 minutes from the time they are transmitted to the consumer's electronic device 122.

[0080] Figure 4 The SMS 440 shown also indicates the account type. In this case, consumer 120 does not have an actual payment card and does not have a PAN, card expiration date, or CVV for the transaction, so SMS is used to provide these payment credentials.

[0081] exist Figure 4 In the example shown, when the consumer does not have an actual payment card, the payment credential format associated with e-commerce is the Primary Account Number (PAN), card expiry date, and Card Verification Value (CVV). In this case, consumer 120 cannot provide a static PAN to the merchant and therefore receives a one-time PAN.

[0082] In some implementations, the account type may be an account associated with a corresponding physical payment card having a static PAN. In this case, consumer 120 may not need to receive the PAN. The payment credential format associated with an e-commerce transaction for an account having a physical payment card may be the card expiry date and CVV. In this case, for example, when requesting a payment credential for an e-commerce transaction, consumer 120 may only receive the card expiry date and CVV for use with the static PAN. Of course, the consumer may be able to utilize the physical payment card's expiry date and CVV, but it is conceivable that providing such a payment credential to the consumer for use with the static PAN via a remotely accessible server 110 could enhance transaction security.

[0083] In some implementations, when the account type is an account not associated with an actual payment card and therefore not with a static PAN, the payment credential format associated with ATM cash withdrawal can be both PAN and PIN. Furthermore, when the account type is an account associated with a corresponding actual payment card having a static PAN, the payment credential format associated with ATM cash withdrawal can be only a PIN. Figure 5 An example of this implementation is shown in flowchart 500.

[0084] In this scenario, Consumer 120 requests a payment credential for making a cash withdrawal or cash out transaction at an ATM, and Consumer 120 does not have an account that includes the actual payment card (also known as the “accompanying plastic card”).

[0085] In the first phase 510, consumer 120 uses electronic device 122 (a mobile phone in this embodiment) to access a bank menu set up for USSD-based services. Various bank options are presented to consumer 120, and in the next phase 512, consumer 120 selects to generate a one-time payment voucher.

[0086] In the next stage 520, consumer 120 needs to select the type of transaction for which a payment voucher must be generated. In this case, and as an example, consumer 120 wants a payment voucher for an ATM withdrawal transaction, and selects the appropriate menu option in the next stage 522.

[0087] In the next stage 530, a notification is presented to consumer 120 that the request has been received and authorization is in progress. In this case, remotely accessible server 110 uses details from consumer profile 114 to determine that consumer 120 has an actual payment card and therefore a PAN is not required to complete the transaction. Remotely accessible server 110 then uses this information, along with the transaction type received from electronic device 122, to determine the required specified payment credential format (in this example, only a PIN).

[0088] Consumer 120 receives the appropriate payment voucher using one or more SMS messages. For example... Figure 5 As shown, in the next stage 540, consumer 120 is provided with a single-use PIN that can be entered at the ATM keypad to complete the cash withdrawal transaction along with a static PAN already possessed by consumer 120. For a higher level of security, the credentials are only valid for 10 minutes from the time they are transmitted to consumer 120's electronic device 122.

[0089] In some implementations, the payment credential format associated with a withdrawal transaction at a mobile money agent is simply a PAN. In this case, if consumer 120 does not have a physical payment card, consumer 120 may only need to request a payment credential. If consumer 120 has a physical payment card, the static PAN on the physical payment card can be used to perform the withdrawal at the agent. Typically, consumer 120 may need to present some form of identification at the agent to verify their identity before completing the withdrawal. This verification can also be performed when completing many other transaction types.

[0090] Therefore, systems and methods are provided for providing payment credentials to consumers, wherein payment credentials are generated that depend directly on the type of transaction the consumer wishes to perform, and the payment credentials may be one-time credentials or credentials valid for multiple transactions.

[0091] The described method can reduce security risks. For example, if a payment credential is intercepted by criminals, it can only be used for a specified type of transaction. This limits the interceptor's ability to execute fraudulent transactions and makes it easier to predict and / or track the interceptor's subsequent transactions.

[0092] Furthermore, regarding the issuance of payment credentials to consumers, specifically in the case of one-time payment credentials, the systems and methods offered can provide increased flexibility. This allows the issuing institution of the payment credential to develop payment credentials suitable for the desired transaction type based on the available payment acceptance points and financial infrastructure. For example, if the consumer does not already have a static PAN, only the PAN can be provided to the consumer, while the CVV and validity period can be provided only when actually needed for the type of transaction to be conducted.

[0093] In other cases where only a PIN or identification code is typically required (e.g., at payment points in ATMs or retail settings), payment credentials can be developed to meet the precise needs of financial infrastructure.

[0094] The described technology can be used to restrict the information sent to consumers based on their specific requirements for the transaction.

[0095] It should be understood that the techniques described herein can be implemented, at least in part, as a computer program product for providing payment credentials to consumers. The computer program product may include a computer-readable medium having stored computer-readable program code for performing one or more of the following steps: receiving a request for a payment credential required for a transaction, the request originating from a consumer's electronic device; determining a transaction type associated with the transaction, said transaction type being one of a plurality of predefined transaction types, each transaction type being associated with a predefined payment credential format; obtaining a payment credential in the payment credential format associated with the determined transaction type; and transmitting the obtained payment credential to the consumer's electronic device for use in the transaction.

[0096] The computer-readable medium may be a non-volatile computer-readable medium, and the computer-readable program code may be executed by processing circuitry.

[0097] Figure 6An example of a computing device 600 that can implement various aspects of the present invention is shown. The computing device 600 can be adapted to store and execute computer program code. The various participants and elements in the foregoing system diagram can utilize any suitable number of subsystems or components of the computing device 600 to help achieve the functions described herein.

[0098] The computing device 600 may include subsystems or components interconnected via a communication architecture 605 (e.g., a communication bus, a cross-overbar device, or a network). The computing device 600 may include at least one central processing unit 610 and at least one memory component in the form of a computer-readable medium.

[0099] The memory components may include system memory 615, which may include read-only memory (ROM) and random access memory (RAM). The basic input / output system (BIOS) may be stored in the ROM. System software may be stored in system memory 615, including operating system software.

[0100] The memory component may also include secondary memory 620. Secondary memory 620 may include a fixed disk 621, such as a hard disk drive, and optionally include one or more removable storage interfaces 622 for removable storage component 623.

[0101] The removable storage interface 622 may be in the form of a removable storage drive (e.g., a tape drive, an optical disc drive, a floppy disk drive, etc.) for a corresponding removable storage component (e.g., a magnetic tape, an optical disc drive, a floppy disk drive, etc.), which can be written to and read from by the removable storage drive.

[0102] The removable storage interface 622 may also be in the form of a port or socket for engaging with other forms of the removable storage component 623, such as a flash drive, an external hard disk drive, or a removable storage chip.

[0103] The computing device 600 may include an external communication interface 630 for enabling data transmission between multiple computing devices 600 in a network environment. Data transmitted via the external communication interface 630 may be in the form of signals, which may be electronic, electromagnetic, optical, radio, or other types of signals.

[0104] The external communication interface 630 enables data communication between the computing device 600 and other computing devices, including servers and external storage devices. Network services can be accessed by the computing device 600 via the communication interface 630.

[0105] The external communication interface 630 may also allow other forms of communication to or from the computing device 600, including voice communication, near field communication, Bluetooth, etc.

[0106] Computer-readable media, existing in the form of various memory components, can provide storage for computer-executable instructions, data structures, program modules, and other data. Computer program products can be provided by computer-readable media that have stored computer-readable program code executable by the central processing unit 610.

[0107] The computer program product may be provided by a non-volatile computer-readable medium, or by means of signals or other volatile components received via the communication interface 630.

[0108] The interconnection of the communication architecture 605 enables the central processing unit 610 to communicate with each subsystem or component and control the execution of instructions from memory components, as well as the exchange of information between subsystems or components.

[0109] Peripheral devices (e.g., printers, scanners, cameras, etc.) and input / output (I / O) devices (e.g., mice, touchpads, keyboards, microphones, joysticks, etc.) can be connected to the computing device 600 directly or via the I / O controller 635. These components can be connected to the computing device 600 in many ways known to those skilled in the art (e.g., serial ports).

[0110] One or more monitors 645 can be connected to the computing device 600 via a display or video adapter 640.

[0111] Figure 7 A block diagram of a communication device 700 that can be used in embodiments of the present invention is shown. The communication device 700 can be a cellular phone, a feature phone, a smartphone, a satellite phone, or a computing device with telephone capabilities.

[0112] The communication device 700 may include a processor 705 (e.g., a microprocessor) and a display 720, wherein the processor 705 processes the functions of the communication device 700, and the display 720 allows a user to view telephone numbers, messages, and / or other information. The communication device 700 may further include an input element 725, a speaker 730, and a microphone 735, wherein the input element 725 allows a user to input information into the device (e.g., input buttons, a touchscreen, etc.); the speaker 730 allows a user to hear voice communications, music, etc.; and the microphone 735 allows a user to transmit their voice via the communication device 700.

[0113] The processor 705 of the communication device 700 can be connected to the memory 715. The memory 715 can be in the form of a computer-readable medium that stores data and optionally computer-executable instructions.

[0114] The communication device 700 may also include a communication element 740 for connecting to a communication channel (e.g., a cellular telephone network, a data transmission network, a Wi-Fi network, a satellite telephone network, the Internet, satellite Internet, etc.). The communication element 740 may include associated wireless transmission elements, such as an antenna.

[0115] The communication element 740 may include a Subscriber Identity Module (SIM), which is in the form of an integrated circuit storing an International Mobile Subscriber Identity (IMSI) and related keys for identifying and authenticating users of the communication device 700. One or more SIMs may be removed from or embedded in the communication device 700.

[0116] The communication device 700 may further include a contactless element 750, which is typically implemented as a semiconductor chip (or other data storage element) with associated wireless transmission elements (e.g., an antenna). The contactless element 750 may be associated with the communication device 700 (e.g., embedded in the communication device 700), and data or control commands transmitted via a cellular network can be applied to the contactless element 750 through a contactless element interface (not shown). The contactless element interface can be used to allow the exchange of data and / or control commands between the mobile device circuitry (and therefore the cellular network) and the contactless element 750.

[0117] The contactless component 750 typically utilizes Near Field Communication (NFC) functionality (or a near field communication medium) to transmit and receive data according to standardized protocols or data transmission mechanisms (e.g., ISO 14443 / NFC). Near field communication is a short-range communication capability, such as radio frequency identification (RFID), Bluetooth, infrared, or other data transmission capabilities that can be used to exchange data between the communication device 700 and the interrogation device. Therefore, the communication device 700 can communicate and transmit data and / or control commands via both cellular networks and near field communication capabilities.

[0118] The data stored in memory 715 may include: work data related to the operation of communication device 700, personal data (e.g., name, date of birth, ID number, etc.), financial data (e.g., bank account information, bank identification number (BIN), credit card or debit card number information, account balance information, expiration date, loyalty provider account number, etc.), transportation information (e.g., taking the subway or train), access information (e.g., access token card), etc. Users can transmit this data from communication device 700 to selected recipients.

[0119] In other respects, the communication device 700 can be a notification device capable of receiving alarm messages and access reports, a portable merchant device capable of transmitting control data identifying discounts to be applied, and a portable consumer device capable of making payments.

[0120] The foregoing description of embodiments of the present invention has been presented for illustrative purposes; it is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Those skilled in the art will understand that various modifications and variations can be made in light of the foregoing disclosure.

[0121] Certain portions of this specification describe embodiments of the invention with respect to algorithms and symbolic representations of operations relating to information. These descriptions and representations of algorithms are commonly used by those skilled in the art of data processing to effectively communicate the essence of their work to others skilled in the art. Functionally, these operations are understood computationally or logically to be performed by computer programs or equivalent circuits, microcode, etc. The described operations can be implemented using software, firmware, hardware, or any combination thereof.

[0122] The software components or functions described in this application can be implemented as software code executed by one or more processors using any suitable computer language (e.g., Java, C++, or Perl) employing, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a non-volatile computer-readable medium (e.g., random access memory (RAM), read-only memory (ROM)), magnetic medium (e.g., hard disk drive or floppy disk), or optical medium (e.g., CD-ROM). Any such computer-readable medium can also be disposed on or within a single computing device, and can be located on or within different computing devices within a system or network.

[0123] Any step, operation, or process described herein may be performed or implemented individually using one or more hardware or software modules, or may be performed or implemented in combination with other devices. In one embodiment, the software module implements a computer program product including a non-volatile computer-readable medium (which includes computer program code), which may be executed by a computer processor for performing any or all of the described steps, operations, or processes.

[0124] Finally, the language used in this specification has been chosen primarily for readability and guidance purposes, and is not intended to describe or limit the subject matter of the invention. Therefore, the scope of the invention is not intended to be limited by this specific description, but rather by any of the claims of the application based thereon. Thus, the disclosure of embodiments of the invention is intended to be illustrative, and not to limit the scope of the invention as set forth in the appended claims.

Claims

1. A method for providing payment credentials to an account holder, the method being performed at a remotely accessible server, the remotely accessible server including a processor and a memory component for storing computer-executable instructions, and the method comprising the steps of: Receive a first request for payment credentials required for a first transaction using the account holder's payment account, the first request originating from a mobile wallet provided on the account holder's mobile phone, the first request including an identifier of the account holder's mobile phone and an account identifier associated with the payment account; The transaction type associated with the first transaction is determined, which is one of a plurality of predefined transaction types, including agent withdrawal transactions or e-commerce transactions, wherein each transaction type is associated with one or more predefined payment voucher components; Determine the account type associated with the payment account, wherein the account type is one of the following: (i) an account associated with a corresponding actual payment card; or (ii) an account not associated with a corresponding actual payment card; A first set of payment credential components is determined for a given transaction type and a given account type, wherein an account associated with the corresponding physical payment card requires a first set of predefined payment credential components, while an account not associated with the corresponding physical payment card requires a predefined second set of payment credential components, wherein the first set of payment credential components differs from the second set of payment credential components that identify the payment account, wherein the second set of payment credential components is associated with a different transaction type, and wherein, when the determined account type is an account associated with the corresponding physical payment card having a static primary account number (PAN) and the determined transaction type is an e-commerce transaction, the first set of payment credential components associated with the e-commerce transaction includes the card expiry date and the card verification value (CVV). Obtain the components of the first set of payment vouchers; and The first set of payment credential components is sent to the mobile phone using one or more SMS messages to enable a first transaction to be successfully completed using the payment account, wherein the first transaction fails if a second set of payment credential components is used. Receive a second request for payment credentials required for a second transaction using the account holder's payment account, the second request originating from the account holder's mobile phone, the second request including an identifier of the account holder's mobile phone and an account identifier associated with the payment account; It was determined that the second transaction was a cash withdrawal from an ATM without a card; Identify the components of the payment credential required for cash withdrawal at a cardless ATM, including the main account PAN and personal identification number PIN; and The payment voucher components required for cash withdrawal from a cardless ATM are sent to the mobile phone for use in successfully completing a second transaction using a payment account, wherein presenting the payment voucher components to the ATM enables cardless cash withdrawal at the ATM, wherein the second transaction fails if the first set of payment voucher components is used.

2. The method according to claim 1, wherein, The first or second request for a payment voucher includes an account holder transaction selection, and the transaction type is determined at least in part based on the account holder transaction selection included in the first or second request.

3. The method according to claim 1, wherein, The payment account is a mobile wallet account.

4. The method according to claim 1, wherein, The remotely accessible server is operated by a mobile banking system, and the first transaction is a mobile banking transaction.

5. The method according to claim 1, wherein, The first or second request for a payment voucher is a request for a payment voucher used only once.

6. The method according to claim 1, wherein, The steps for obtaining the components of the first set of payment vouchers include: requesting the components of the first set of payment vouchers from the external voucher generation module.

7. The method according to claim 1, wherein, The steps for obtaining the components of the first set of payment credentials include: generating the components of the first set of payment credentials at the remotely accessible server.

8. The method according to claim 1, wherein, The first set of payment credentials also includes one or a combination of the following: bank account number, primary account PAN, pseudo PAN, password, access code, personal identification number PIN, token, barcode, and quick-response QR code.

9. The method according to claim 1, wherein, When the determined account type is an account not associated with the corresponding actual payment card and the determined transaction type is an e-commerce transaction, the first set of payment credentials associated with the e-commerce transaction consists of the primary account number PAN, the card expiry date, and the card verification value CVV.

10. The method according to claim 1, wherein, The identified transaction type is an agent withdrawal transaction, and the first set of payment vouchers associated with the agent withdrawal transaction is the primary account PAN.

11. A system for providing payment credentials to an account holder, the system comprising a processor for communicating with a mobile phone of the account holder and a memory component for storing computer-executable instructions, which, when executed by the processor, cause the processor to: Receive a first request for payment credentials required for a first transaction using the account holder's payment account, the first request originating from a mobile wallet provided on the account holder's mobile phone, the first request including an identifier of the account holder's mobile phone and an account identifier associated with the payment account; The transaction type associated with the first transaction is determined. This transaction type is one of a plurality of predefined transaction types, including agent withdrawal transactions and e-commerce transactions. Each transaction type is associated with one or more predefined components of a payment voucher; Determine the account type associated with the payment account, wherein the account type is one of the following: (i) an account associated with a corresponding actual payment card; or (ii) an account not associated with a corresponding actual payment card; A first set of payment credential components is determined for a given transaction type and a given account type, wherein an account associated with the corresponding physical payment card requires a first set of predefined payment credential components, while an account not associated with the corresponding physical payment card requires a predefined second set of payment credential components, wherein the first set of payment credential components differs from the second set of payment credential components that identify the payment account, wherein the second set of payment credential components is associated with a different transaction type, and wherein, when the determined account type is an account associated with the corresponding physical payment card having a static primary account number (PAN) and the determined transaction type is an e-commerce transaction, the first set of payment credential components associated with the e-commerce transaction includes the card expiry date and the card verification value (CVV). Obtain the components of the first set of payment vouchers; and The first set of payment credential components is sent to the mobile phone using one or more SMS messages to enable a successful first transaction using the payment account, wherein the first transaction fails if a second set of payment credential components is used. Receive a second request for payment credentials required for a second transaction using the account holder's payment account, the second request originating from the account holder's mobile phone, the second request including an identifier of the account holder's mobile phone and an account identifier associated with the payment account; The second transaction was determined to be a cash withdrawal from a cardless ATM. Identify the components of the payment credential required for cash withdrawal at a cardless ATM, including the main account PAN and personal identification number PIN; and The payment voucher components required for cash withdrawal from a cardless ATM are sent to a mobile phone for use in successfully completing a second transaction using a payment account. Presenting the payment voucher components to the ATM enables cardless cash withdrawal at the ATM. If the first set of payment voucher components is used, the second transaction fails.

12. The system for providing payment credentials to account holders according to claim 11, wherein, When executed by the processor, the instruction causes the processor to further request components of the first set of payment vouchers from the external voucher generation module.

13. The system for providing payment credentials to account holders according to claim 12, wherein, The external credential generation module is operated by either the account holder's card issuer or the payment processor.

14. The system for providing payment credentials to account holders according to claim 11, wherein, When executed by the processor, the instructions cause the processor to further generate the components of the first set of payment vouchers.

15. A computer program product for providing payment credentials to an account holder, the computer program product comprising a computer-readable medium storing computer-readable program code for performing the following steps: Receive a first request for payment credentials required for a first transaction using the account holder's payment account, the first request originating from a mobile wallet provided on the account holder's mobile phone, the first request including an identifier of the account holder's mobile phone and an account identifier associated with the payment account; The transaction type associated with the first transaction is determined. This transaction type is one of a plurality of predefined transaction types, including agent withdrawal transactions and e-commerce transactions. Each transaction type is associated with one or more predefined components of a payment voucher; Determine the account type associated with the payment account, wherein the account type is one of the following: (i) an account associated with a corresponding actual payment card; or (ii) an account not associated with a corresponding actual payment card; A first set of payment credential components is determined for a given transaction type and a given account type, wherein an account associated with the corresponding physical payment card requires a first set of predefined payment credential components, while an account not associated with the corresponding physical payment card requires a predefined second set of payment credential components, wherein the first set of payment credential components differs from the second set of payment credential components that identify the payment account, wherein the second set of payment credential components is associated with a different transaction type, and wherein, when the determined account type is an account associated with the corresponding physical payment card having a static primary account number (PAN) and the determined transaction type is an e-commerce transaction, the first set of payment credential components associated with the e-commerce transaction includes the card expiry date and the card verification value (CVV). Obtain the components of the first set of payment vouchers; and The first set of payment credential components is sent to the mobile phone using one or more SMS messages to enable a successful first transaction using the payment account, wherein the first transaction fails if a second set of payment credential components is used. Receive a second request for payment credentials required for a second transaction using the account holder's payment account, the second request originating from the account holder's mobile phone, the second request including an identifier of the account holder's mobile phone and an account identifier associated with the payment account; The second transaction was determined to be a cash withdrawal from a cardless ATM. Identify the components of the payment document required for cash withdrawal from an ATM, including the main account PAN and personal identification number PIN; and The payment voucher components required for cash withdrawal from an ATM are sent to a mobile phone to enable a second transaction to be successfully completed using a payment account. Presenting the payment voucher components to the ATM enables cash withdrawal at the ATM. If the first set of payment voucher components is used, the second transaction fails.

Images