SYSTEM AND METHOD TO PUSH PAYMENT TO BENEFICIARY ACCOUNT USING AN ALIAS

Abstract

A method includes receiving a funds transfer request. The request includes an alias character string. The request is for requesting a funds transfer. The alias character string is translated to payment routing information. The payment routing information specifies a recipient's financial institution deposit account. The funds request is routed via a payment network for the purpose of being credited to the specified deposit account.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application Nos. 62/350,322 (filed on Jun. 15, 2016); 62/350,335 (filed Jun. 15, 2016); 62/350,407 (filed Jun. 15, 2016); 62/351,155 (filed Jun. 16, 2016); 62/350,821 (filed Jun. 16, 2016); 62/351,016 (filed Jun. 16, 2016); 62/351,227 (filed Jun. 16, 2016); 62/350,831 (filed Jun. 16, 2016); 62/350,416 (filed Jun. 15, 2016); and 62/351,164 (filed Jun. 16, 2016); the contents of which provisional applications are hereby incorporated by reference for all purposes.

BACKGROUND

Funds to be transferred from one account to another between financial institutions typically require destination account details such as account number, routing number and bank code. This information is potentially vulnerable to being compromised as it is communicated, for example, to the originator's bank. When a successful attack occurs, there may be an unauthorized withdrawal of funds from the account specified in the destination account details.

The present inventors have now recognized that there are opportunities to reduce the possibility of successful attacks on requested funds transfers in EFT (electronic funds transfer) systems.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of some embodiments of the present disclosure, and the manner in which the same are accomplished, will become more readily apparent upon consideration of the following detailed description of the invention taken in conjunction with the accompanying drawings, which illustrate preferred and example embodiments and which are not necessarily drawn to scale, wherein:

FIG. 1 is a block diagram of a payment card account system.

FIG. 2 is block diagram of a payment system such as an EFT (electronic funds transfer) system.

FIG. 3 is a block diagram of a payment transaction system provided in accordance with aspects of the present disclosure.

FIGS. 4 and 5 are block diagrams of example computer systems that may perform functions in the system of FIG. 3.

FIGS. 6, 7 and 8 are flow charts that illustrate processes that may be performed in the system of FIG. 3 in accordance with aspects of the present disclosure.

FIG. 9 is a block diagram that shows aspects of the payment transaction system of FIG. 3 as provided in accordance with other embodiments.

FIG. 10 is a flow chart that illustrates a process that may be performed in the system as depicted in FIG. 9.

DESCRIPTION

In general, and for the purpose of introducing concepts of embodiments of the present disclosure, an alias (e.g., a telephone number, an email address, or another type of character string) may be selected to replace account information in EFT system funds transfer requests. When a funds transfer request is received that includes such an alias as a beneficiary account designation, an alias directory is accessed to translate the alias into the relevant destination account details. The account details thus obtained are used to route the funds transfer in the EFT system.

By using an alias instead of the actual account details during potentially vulnerable communications between the funds transfer requester and his/her financial institution, the risk of compromise of the account details may be reduced.

FIG. 1 is a block diagram that illustrates a payment card account system 100.

The system 100 includes a customer device 102 such as a magnetic stripe card, a payment IC (integrated circuit) card (contactless and/or contact), or a payment-enabled mobile device. Block 104 in FIG. 1 represents a merchant device such as a POS (point of sale) terminal/card reader. The merchant device 104 may also be considered part of the payment card account system 100. The customer device 102 may be presented to the merchant device 104, to consummate a purchase transaction and to permit the merchant device 104 to read payment card account data (including, e.g., a payment account number) from the customer device 102. In other situations, the merchant device 104 may be an e-commerce server computer, and the customer device 102 may be a personal computer, a mobile device running a mobile browser, etc.; in such situations, the customer device 102 may engage in an online shopping session with an e-commerce website hosted by the merchant device 104.

A computer 106 operated by an acquirer (acquiring financial institution) is also shown as part of the system 100 in FIG. 1. The acquirer computer 106 may receive a payment account system authorization request message for the transaction from the merchant device 104. The acquirer computer 106 may route the authorization request message via a card network 108 to a server computer 110 operated by the issuer of a payment account that is associated with the account number obtained by the merchant device 104 (e.g., from the customer device 102) and included in the authorization request message. The authorization response message generated by the payment issuer server computer 110 may be routed back to the merchant device 104 via the card network 108 and the acquirer computer 106.

One well known example of a card network is referred to as the “Banknet” system, and is operated by MasterCard International Incorporated, which is the assignee hereof.

The payment account issuer server computer 110 may be operated by or on behalf of a financial institution (“FI”) that issues payment accounts to individual users such as the customer who presented or operated the customer device 102 referred to above. For example, the payment card issuer server computer 110 may perform such functions as (a) receiving and responding to requests for authorization of payment account transactions to be charged to payment accounts issued by the FI; and (b) tracking and storing transactions and maintaining account records.

The payment card account system communications among the merchants, acquirers, card network and/or issuers may conform to a known standard such as ISO 8583.

The components of the system 100 as depicted in FIG. 1 are only those that are needed for processing a single transaction. A typical payment system may process many purchase transactions (including simultaneous transactions) and may include a considerable number of payment account issuers and their computers, a considerable number of acquirers and their computers, and numerous merchants and their devices, as well as a very large number of customer devices.

FIG. 2 is a block diagram that illustrates a payment network system 200, of which one example is the ACH (automated clearing house) system operated in the United States.

The system 200 includes an originator device 202, which may be a computer operated by an originator of a transaction. Common kinds of transactions are credit transactions and debit transactions. The originator is the party that initiates the transaction. The originator may be, for example, an individual or a corporation or other organization.

The system 200 further includes an originator PSP (payment services provider) computer 204. The originator PSP computer 204 receives payment instructions from the originator and forwards data entries that reflect the instructions to a payment system switch/network 206, which is also part of the system 200. The originator PSP computer 204 may be operated by an originator PSP of which the originator is a customer. The switch/network 206 may be operated by a governmental or private entity that serves as a clearing facility for the system 200.

Also included in the system 200 is a beneficiary PSP computer 208. The beneficiary PSP computer 208 receives entries from the payment system switch/network 206 and posts entries to accounts of depositors.

Still further, the system 200 includes a beneficiary 210 that is one of the depositors of the beneficiary PSP. In the case of a credit transaction, the account at the beneficiary PSP of the beneficiary may be credited with the amount instructed to be paid by the originator device 202. The beneficiary may be, for example, an individual or a corporation or other organization. Both PSPs may typically be banks or other financial institutions (FIs).

The communications among the parties in the system 200 may typically be conducted using XML (eXtensible Markup Language) and may comply with a standard according to ISO 20022.

The components of the system 200 as depicted in FIG. 2 are only those that are needed for processing a single transaction. A typical payment network system may process many transactions (including simultaneous transactions) and may include a considerable number of PSPs and their computers, one or more clearing operators, and numerous originators and beneficiaries

FIG. 3 is a block diagram of a payment transaction system 300 provided in accordance with aspects of the present disclosure.

The payment transaction system 300 may include an originator or funds transaction requestor 302. The description of the originator 202 in regard to FIG. 2 may also be applicable to the originator 302 shown in FIG. 3. The system 300 may also include an originator PSP 304 in communication with the originator 302. The description of the originator PSP 204 in regard to FIG. 2 may also be applicable to the originator PSP 304 shown in FIG. 3. The originator PSP 304 may also be in communication with a gateway computer 306. The gateway computer 306, in turn, is shown operatively connected between a payment card network 310 and a payment switch/network 308. Although the gateway computer 306 is shown separately from the payment card network 310, it may, in some embodiments, be a component or components associated with or provided by and/or operated by the operator of the payment card network 310. The payment card network 310 may generally resemble and provide functionality like that of the card network 108 shown in and discussed in connection with FIG. 1. The payment switch/network 308 may generally resemble and provide functionality like that of the payment switch network 206 shown in and discussed in connection with FIG. 2.

In some embodiments, the gateway computer 306 is configured to bridge the payment switch/network 308 and the payment card network 310. This may occur at the application layer level and/or the presentation layer level. The gateway computer 306 may serve as a central switching platform that is the seat of the interrelated operations of the networks 308 and 310 and may work independently of the chosen protocol of the network participants.

The payment card network 310 is shown in FIG. 3 as providing routing services for routing of payment card account system transactions to account issuers/FIs (financial institutions) 312. The issuer FIs 312 may operate substantially as described above with respect to the issuer 110 shown in and discussed in connection with FIG. 1.

The gateway computer 306 is also shown connected to an alias directory 314. The purpose and functioning of the alias directory 314 will be described further below. The alias directory may translate a beneficiary/recipient's alias into destination account information and may supply the destination account information to the gateway computer 306.

The alias directory 314 may map non-sensitive aliases to critical and sensitive account details. The alias directory 314 may be managed by a central trusted party (such as the clearing party/payment switch/network or the payment card network). The directory service can then be used by any trusted/secure service provider, e.g., by financial institutions such as, e.g., the originator PSP 304, where the service provider allows for initiation of funds transfers. With use of aliases in the instructions to initiate a funds transfer, the service provider may provide a portal to allow the instructions to be received, including the aliases. The aliases may be, for example, phone numbers or email addresses or other unique but non-sensitive identifiers. The sender of the funds transfer will only need the recipient's unique alias to send funds. In many cases the alias may be the recipient's phone number or email address, which may already be known to the sender, or which the recipient may not be reluctant to provide to the sender.

The payment switch/network 308 is in communication with the beneficiary PSP 316. The description of the beneficiary PSP 208 in regard to FIG. 2 may be applicable to the beneficiary PSP 316 shown in FIG. 3. The beneficiary/recipient 318 is also shown in FIG. 3 in association with the beneficiary PSP 316. The description of the beneficiary 210 in regard to FIG. 2 may also be applicable to the beneficiary 318 shown in FIG. 3.

Also shown in phantom is a provider 320 of goods and/or services (hereinafter “service provider 320”). The service provider 320 may be in communication with the gateway computer 306 to allow the service provider 320 to benefit from alias translation services in a manner to be described below with respect to FIG. 8.

Although aspects of a payment card network and related FIs are illustrated in FIG. 3, in some embodiments the same may be absent, with transfers in the system 300 in such cases entirely consisting of ACH/EFT transfers or the like. Moreover, functionality ascribed herein to the gateway computer 306 may instead be incorporated at least partially in the payment switch/network 308, such that no gateway computer 306 need necessarily be present, and alias translation may be sought and obtained by the payment switch/network 308. In such embodiments, the payment switch/network 308 may be in communication with the alias directory 314 and/or may be accessible for alias translation services by the service provider 320. In other embodiments, alias translation may be sought and obtained by the originator PSP 304.

Any one or more of the blocks shown in FIG. 3, in addition to representing the indicated entity, may also be considered to represent one or more computer systems or other computing devices (e.g. smartphones or other mobile devices) operated by such entity.

FIG. 4 is a block diagram of an example computer system 402 that may perform functions in the system of FIG. 3. The computer system 402 will nominally be referred to as a “beneficiary PSP computer system”, although some or all of the functions ascribed to it may be performed by other components of the system 300.

Referring now to FIG. 4, the beneficiary PSP computer system 402 may, in its hardware aspects, resemble a typical server computer and/or mainframe computer, but may be controlled by software to cause it to function as described herein.

The beneficiary PSP computer system 402 may include a computer processor 400 operatively coupled to a communication device 401, a storage device 404, an input device 406 and an output device 408. The communications device 401, the storage device 404, the input device 406 and the output device 408 may all be in communication with the processor 400.

The computer processor 400 may be constituted by one or more processors. Processor 400 operates to execute processor-executable steps, contained in program instructions described below, so as to control the beneficiary PSP computer system 402 to provide desired functionality.

Communication device 401 may be used to facilitate communication with, for example, other devices (such as other components of the payment system 300, as well as mobile devices and/or computing devices operated by account holders). Communication device 401 may comprise numerous communication ports (not separately shown), to allow the beneficiary PSP computer system 402 to communicate simultaneously with a number of other computers and other devices, including communications as required to simultaneously handle numerous interactions with other devices and/or numerous transactions such as funds transfers.

Input device 406 may comprise one or more of any type of peripheral device typically used to input data into a computer. For example, the input device 406 may include a keyboard and a mouse. Output device 408 may comprise, for example, a display and/or a printer.

Storage device 404 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., hard disk drives), optical storage devices such as CDs and/or DVDs, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as so-called flash memory. Any one or more of such information storage devices may be considered to be a computer-readable storage medium or a computer usable medium or a memory.

Storage device 404 stores one or more programs for controlling processor 400. The programs comprise program instructions (which may be referred to as computer readable program code means) that contain processor-executable process steps of the beneficiary PSP computer system 402, executed by the processor 400 (and/or executed by other processors) to cause the beneficiary PSP computer system 402 (and/or other computer systems) to function as described herein.

The programs may include one or more conventional operating systems (not shown) that control the processor 400 so as to manage and coordinate activities and sharing of resources in the beneficiary PSP computer system 402, and to serve as a host for application programs (described below) that run on the beneficiary PSP computer system 402.

The programs stored in the storage device 404 may include, for example, a transaction handling application program 410. The transaction handling application program 410 may operate to handle transactions such as funds transfers in a manner or manners to be described below.

Another program that may be stored in the storage device 404 is an application program 412 for handling set-up requests received from deposit account holders. The purpose of the set-up requests may be to select aliases to represent deposit accounts held by the requesting individuals. Details of handling of set-up requests will also be described below.

The storage device 404 may also store web hosting software 414. The web hosting software 414 may control the processor 400 to enable the beneficiary PSP computer system 402 to maintain a website by which account holders may access and interact with the beneficiary PSP computer system 402.

The storage device 404 may further store one or more software modules (block 416) that serve as software interfaces between the beneficiary PSP computer system 402 and one or more other components of the system 300.

The storage device 404 may also store, and the beneficiary PSP computer system 402 may also execute, other programs, which are not shown. For example, such programs may include communications software and a reporting application. The latter program may respond to requests from system administrators for reports on the activities performed by the beneficiary PSP computer system 402. The other programs may also include, e.g., device drivers, database management software, etc.

The storage device 404 may also store one or more databases 418 needed for operation of the beneficiary PSP computer system 402.

FIG. 5 is a block diagram that illustrates an example embodiment of the gateway computer 306. The gateway computer 306 may be similar in its hardware aspects to the beneficiary PSP computer system 402 that was just described. Accordingly, the gateway computer 306 may include a processor 500 in communication with a communication device 501, a storage device 504, an input device 506 and an output device 508.

Storage device 504 stores one or more programs for controlling processor 500. The programs comprise program instructions (which may be referred to as computer readable program code means) that contain processor-executable process steps of the gateway computer 306, executed by the processor 500 (and/or executed by other processors) to cause the gateway computer 306 (and/or other computer systems) to function as described herein.

The programs may include one or more conventional operating systems (not shown) that control the processor 500 so as to manage and coordinate activities and sharing of resources in the gateway computer 306, and to serve as a host for application programs (described below) that run on the gateway computer 306.

The programs stored in the storage device 504 may include, for example, a transaction handling application program 510. The transaction handling application program 510 may control the processor 500 to enable the gateway computer 306 to handle transactions in a manner or manners to be described below.

Another program that may be stored in the storage device 504 is an application program 512 for handling translation of alias strings received by the gateway computer 306 in connection with transaction requests. Details of alias translation will be provided below.

The storage device 504 may further store one or more software modules (block 514) that serve as software interfaces between the gateway computer 306 and one or more other components of the system 300, including the alias directory 314 (FIG. 3).

Continuing to refer to FIG. 5, the storage device 504 may also store, and the gateway computer 306 may also execute, other programs, which are not shown. For example, such programs may include communications software and a reporting application. The latter program may respond to requests from system administrators for reports on the activities performed by the gateway computer 306. The other programs may also include, e.g., device drivers, database management software, etc.

The storage device 504 may also store one or more databases 516 needed for operation of the gateway computer 306.

Other computerized components of the system 300 may be constituted by computer hardware having the same type of components and hardware architecture as described herein with reference to FIG. 4.

FIG. 6 is a flow chart that illustrates a process that may be performed in the system of FIG. 3 in accordance with aspects of the present disclosure. In particular, the process of FIG. 6 relates to handling a request to select an alias to represent a deposit account.

At 602 in FIG. 6 a user request is received for selecting an alias to represent the user's deposit account. The user request may be received via any one of a number of channels, including but not limited to mobile phone apps, web based portals, merchant card on file systems, digital wallets, mobile browsers or web-browsing PCs, or over the counter.

At 604, user authentication takes place. This may be done in any manner that the beneficiary PSP deems to be prudent. For example, submission and verification of a PIN may be employed, or the user may submit and the beneficiary PSP may verify a biometric measure. More generally, if deemed appropriate or necessary, ID&V (identification and verification) procedures like those used in connection with payment card account provisioning may be employed to obtain reasonable assurance of user authentication.

At 606, the requestor/user may select an alias to represent the user's account details. The alias may be, for example, a phone number, an email address, a unique set of characters or a phrase or social media handle. The alias may then be mapped by the alias directory 314 to the user's account details. In some embodiments or use cases, the alias can be mapped to multiple accounts, though it may be advisable for a default account to be selected by the user. The default account may be the account that the alias directory 314 returns when a translation is requested.

As shown in phantom at 608, in some embodiments or use cases, the user may cause several aliases to be created to match a given account.

FIG. 7 is a flow chart that illustrates a process that may be performed in the system of FIG. 3 in accordance with aspects of the present disclosure. In particular, the process of FIG. 7 relates to handling a request for a funds transfer that may involve an alias selected and mapped per the process of FIG. 6.

At 702, a funds transfer request is received at the gateway computer 306.

A decision block 704 may follow block 702 in the process of FIG. 7. At decision block 704, the gateway computer 306 may determine whether transaction routing information in the funds transfer request (received at 702) includes a bank account number that identifies a deposit bank account that is the target/recipient account for the requested funds transfer.

In some embodiments, the determination at decision block 704 may include parsing a destination account number data field of the request to determine whether data in that field is in the format of a bank account number. If not, then the gateway computer may conclude that the data field contains an alias string that is standing in for the bank account number for the recipient account.

In other embodiments, a flag or the like in the request may indicate that the request contains an alias string rather than a recipient bank account number.

If a negative determination is made at decision block 704 (i.e., if the gateway computer 306 determines that the funds transfer request does not contain the recipient bank account number), then block 706 may follow decision block 704 in the process of FIG. 7.

At block 706, the alias is translated (e.g., at the alias directory 314, FIG. 3; e.g., at the request of the gateway computer 306) to the corresponding deposit account details. It will be assumed that the gateway computer 306 (or other computer performing like functions) is a trusted service provider with all relevant security and screening in place, and with secure communication channels with the alias directory 314. The translation of the alias at the alias directory 314 provides the required sensitive details (account details) needed by the system 300 to initiate and route a funds transfer. With this approach, all sensitive details needed in performing the funds transfer are maintained within trusted entities following stringent standards with respect to sensitive information. It will be appreciated that the alias is never used or usable to initiate a transfer of funds from the account represented by the alias.

Block 708 may follow block 706 in the process of FIG. 7. Block 708 represents initiation, routing and completion of the funds transfer utilizing the deposit account details obtained by translating the alias at 706. In some embodiments, the gateway computer 306 may communicate with the payment switch/network 308 or the originator PSP 304 to permit the requested funds transfer to proceed using the recipient bank account number obtained at 706 by translating the alias.

Referring again to decision block 704, if a positive determination is made at that decision block (i.e., if the gateway computer 306 determines that the recipient bank account number is present in the funds transfer request as received at 702), then the process of FIG. 7 may branch (as indicated at 710) from decision block 704 directly to block 708. In this circumstance, initiation, routing and completion of the funds transfer occurs (per block 708) without alias translation.

In the process of FIG. 7, the alias translation and funds transfer process may occur behind the scenes in the EFT network and in a manner that is transparent to the sender and the recipient.

With arrangements as described herein, funds may be credited to a deposit account via a funds transfer without any need to reveal account details. From the sender's perspective, all that is required to transfer funds is the alias that represents the account, with no need for the sender to deal with the inconvenient or burdensome details typically required for EFT transfers.

The process of FIG. 7 may include and/or be part of, or suitably alter, one or more of the transaction flows described below.

According to one alternative network flow, a virtual or physical merchant card acceptance terminal initiates a transaction that is transmitted via a merchant system. Prior to transmitting the request, the merchant system may evaluate the payment credentials, and if the same are tokenized, may call a detokenization service provided by a Token Service Provider. Also prior to transmitting the request, the merchant system may determine the originator PSP (O-PSP), and build the transaction request message. The transaction request message is then submitted by the merchant system to the O-PSP. The O-PSP evaluates the transaction request message and authenticates the consumer credentials and debits the originator/consumer account. The flow then proceeds to the payment network (EFT network), which determines the routing path and routes to the beneficiary PSP (B-PSP). The B-PSP evaluates the messages, checks the validity of the beneficiary account, authorizes the transaction request message and posts the transaction (immediately or at a later point in time) against the beneficiary account. The B-PSP returns a response message to the O-PSP via the payment network (EFT network). The O-PSP returns the response to the merchant system/merchant card acceptance terminal.

According to another alternative network flow, a virtual or physical merchant card acceptance terminal initiates a transaction that is transmitted via a merchant system. The merchant system builds and submits the transaction request message to the merchant acquirer. The merchant acquirer may evaluate the payment credentials in the message, and if the same are tokenized, may call a detokenization service provided by a Token Service Provider. The merchant acquirer may determine the O-PSP and transmit the message to the O-PSP. The O-PSP evaluates the transaction request message and authenticates the consumer credentials and debits the originator/consumer account. The O-PSP also routes the message to the payment network (EFT network). The payment network determines the routing path and routes the message to the B-PSP. The B-PSP evaluates the message, checks the validity of the beneficiary account, authorizes the transaction request message and posts the transaction (immediately or at a later point in time) against the beneficiary account. The B-PSP returns a response message to the O-PSP via the payment network (EFT network). The O-PSP returns the response to the merchant system/merchant card acceptance terminal.

According to still another alternative network flow, a virtual or physical merchant card acceptance terminal initiates a transaction that is transmitted via a merchant system. The merchant system builds and submits the transaction request message to the merchant acquirer. The merchant acquirer may evaluate the payment credentials in the message, and may determine the payment network (EFT network). The payment network may evaluate the message and evaluate the payment credentials in the message, and if the same are tokenized, may call a detokenization service provided by a Token Service Provider. Further, the payment network may determine the O-PSP and transmit the message to the O-PSP. The O-PSP may evaluate the message and authenticate the consumer credentials and debit the originator/consumer account. Also, the O-PSP may return the response to the payment network, which determines the routing path and routes the message to the B-PSP. The B-PSP evaluates the message, checks the validity of the beneficiary account, authorizes the transaction request message and posts the transaction (immediately or at a later point in time) against the beneficiary account. The B-PSP returns a response message to the O-PSP via the payment network (EFT network). The O-PSP returns the response to the merchant system/merchant card acceptance terminal.

When the user engages in checkout from such an interface using a deposit account as the underlying source of funds, any one of the above alternative transaction flows may occur in various use cases. As another alternative, the following further alternative flow may take place.

Via the merchant device a digital wallet acceptance interface may be invoked, with user/customer authentication or with the customer pre-authenticated. The digital wallet provider may evaluate the payment credentials, and if the same are tokenized, may call a detokenization service provided by a Token Service Provider. The digital wallet provider determines the O-PSP and builds and submits a transaction request message to the O-PSP. The O-PSP evaluates the message and authenticates the consumer credentials and then forwards the message to the payment network (EFT network). The payment network determines the routing path and routes the message to the B-PSP. The B-PSP evaluates the message, checks the validity of the beneficiary account, authorizes the transaction request message and posts the transaction (immediately or at a later point in time) against the beneficiary account. The B-PSP returns a response message to the O-PSP via the payment network (EFT network). The O-PSP returns the response message to the merchant via the payment network and via the digital wallet provider. The merchant may also receive other information such as billing address, shipping address, and loyalty account information in addition to a payment confirmation message.

There may be intermediate steps in the above flow, where the digital wallet provider may act as B-PSP for the funding leg of the transaction, with the consumer originator account being debited and a B-PSP account (which can be a pooled account) of the digital wallet provider posted and credited. In the payment leg of the transaction, the digital wallet provider may act as O-PSP of the transaction where the digital wallet provider account is debited and the B-PSP account of the beneficiary will be posted and credited.

In some embodiments, the payment credentials may be a bank account number and bank routing information (IBAN, IFSC code, SWIFT code, etc.) and/or card number (credit, debit, prepaid, commercial, or a push card instrument tied to a deposit account). Mapping of tokens and payment credentials may allow for the merchant only to see the token and not the real payment credentials. In some embodiments, the merchant/merchant bank account may be indicated by an alias, until the same is translated as part of the transaction flow.

In previous discussion herein a use case was described in which a request for a funds transfer included an alias that was translated into account details. According to another use case, an alias can be applied in a scenario in which a user wishes to authenticate or qualify himself/herself to a merchant. For example, in some situations, the merchant may be a telephone company (e.g., a mobile network operator) and the user may be seeking to open a post-paid telecommunications services account. In such a situation, the user may provide his/her alias to the telco/merchant (again the alias may for example be an email address or a phone number). The telco/merchant may send the alias to the user's financial institution/beneficiary PSP using the payment network's API to get a positive or negative response from the FI/beneficiary PSP. The payment network operator may in the background facilitate translation of the alias to the account details and may send the request to the FI/beneficiary PSP with the relevant details seeking an authentication. In another use case, the beneficiary PSP may receive a request to perform a user authentication/ID&V process relative to the user, with the user and account details being represented by an alias included in the request for user authentication.

FIG. 8 is a flow chart that illustrates another process that may be performed in the system 300 of FIG. 3 according to other aspects of the present disclosure. The process of FIG. 8 is concerned with allowing the service provider 320 to obtain credit reference or the like with respect to a prospective customer by using an alias for a bank account owned by the prospective customer. The process of FIG. 8 proceeds on the assumption that the prospective customer has provided the alias to the service provider 320. According to one example, the service provider may be a mobile telephone network operator, and the prospective customer may be seeking to show that he/she is sufficiently creditworthy to obtain a post-paid mobile telephone service arrangement.

At 802 in FIG. 8, the gateway computer 306 may receive a message from the service provider 320. The message may request an indication of financial responsibility as to the prospective customer. The prospective customer and his/her bank account may be identified in the message only by an alias string, such as mobile phone number or email address.

At 804, the gateway computer 306 may use the alias to route a request to the FI that issued the prospective customer's bank account. That is, the gateway computer 306 may obtain the bank account number by having the alias (received at 802) translated by the alias directory 314. From the bank account number, the gateway computer may identify the issuing FI and may route the request to the issuing FI, including the bank account number in the request. The routing of the request may not be via the same communication channels utilized for funds transfer requests.

At 806, the gateway computer 306 may receive a response from the issuing FI. The response may, for example, contain the prospective customer's name as listed on the bank account, and may also include an indication as to whether the prospective customer is deemed financially responsible, as determined by the issuing FI based on its experience with the bank account in question. It will be appreciated that the indication may be a positive or negative indication as to the prospective customer's creditworthiness.

At 808, the gateway computer 306 may transmit information to the service provider 320 based on the response received by the gateway computer 306 at 806. The information provided at 808 may include the prospective customer's name (as provided by the issuing FI) and the indication as to whether the prospective customer is deemed financially responsible. Based on the information, the service provider 320 may be able to confirm the prospective customer's identity (as provided by the prospective customer to the service provider 320) and may also make a prudent decision as to whether to extend credit to the prospective customer. This may occur without the prospective customer revealing sensitive information such as his/her bank account number to the service provider 320.

FIG. 9 is a block diagram that shows aspects of the payment transaction system 300 of FIG. 3 as provided in accordance with other embodiments. In FIG. 9, the payment transaction system is generally indicated by reference numeral 300a. Some or all components of the system 300 of FIG. 3 may be present in the system 300a, although not explicitly depicted in FIG. 9.

The payment transaction system 300a may include a merchant device 902 which is provided in accordance with teachings of the present transaction. The merchant device 902 may in many ways resemble a typical POS terminal, but it is assumed that the merchant device 902 has been programmed to generate an optical code to support transaction processing as described herein. The merchant device may print out the optical code (reference numeral 904) on a piece of paper via its printer component (not separately shown) and/or may display the optical code on its display component (not separately shown). Suitable types of optical codes may include a QR (quick response) code or other type of barcode, but other types of optical codes may be used, including, for example, a suitable string/block of alphanumeric characters.

The customer (not shown) at the point of sale is assumed to be in possession of a suitable customer device 906. The customer device 906 may be a smartphone programmed with a mobile app that facilitates the payment process as described herein. The customer device 906 may alternatively be another type of suitably programmed mobile device other than a smartphone. The customer device 906 is assumed to have a camera component (not separately shown)—as most smartphones do—with which the customer device 906, under control of the relevant mobile app, captures (reference numeral 908) an image of the optical code 904 as printed out or displayed by the merchant device 902.

The system 300 further includes components of an EFT/ACH system similar to those described above in connection with FIG. 2. In particular, the system 300a includes a payment switch/network 910. The payment switch/network 910 may resemble the payment switch/network 206 of FIG. 2, but with additional capabilities for receiving and translating optical code images sent to the payment switch/network 910 from customer devices that are located at a point of sale. Also shown in FIG. 9 are an originator PSP 912 and a beneficiary PSP 914, which may correspond, respectively, to the items 204 and 208 described above in connection with FIG. 2.

Any one or more of the blocks shown in FIG. 3, in addition to representing the indicated entity, may also be considered to represent one or more computer systems operated by such entity.

One or more computers that are components of the system 300a may have the same type of hardware aspects as were described in connection with FIG. 4. Thus, for example, one or more components of the system 300a may include a processor in communication with a communication device, a storage device, an input device and an output device. One or more of the components (e.g., the payment switch/network 910 and/or the originator PSP 912) may run program instructions to provide functionality as described below in conjunction with FIG. 10.

FIG. 10 is a flow chart that illustrates a process that may be performed in the system 300a as depicted in FIG. 9. In particular, the process of FIG. 10 relates to a payment process that allows a merchant to accept EFT payment by producing an optical code.

The process of FIG. 10 assumes that the merchant has previously enrolled in an optical-code-EFT acceptance program. Such registration may, for example, occur by the merchant interacting online with a website hosted, e.g., by a computer operated by the EFT network operator/clearing facility. During the online interaction, the merchant may enter its identification details (name and address of merchant) and bank account details and may agree to terms and conditions of participating in the program. The merchant may then print out and display decals to inform customers of the merchant's participation in the optical-code-EFT acceptance program.

The process of FIG. 10 further assumes that the customer has registered for the program. This may involve downloading the mobile app for the program to the customer's smartphone (customer device 906, FIG. 9). Also, the customer may register himself/herself through the app by providing a delegation of user authentication to the app in order to initiate push transactions to credit business or other individual accounts.

At 1002 in FIG. 10, a purchase transaction is commenced at the point of sale. This may take place after the customer has entered the merchant's store, selected merchandise, and approached the checkout counter. The customer may also have opened the relevant app on his/her smartphone and authenticated himself/herself in a secure manner to the app (i.e., in a manner that is satisfactory to the banking partners participating in the program).

At 1004, the merchant device generates and prints/displays the above mentioned optical code (item 904 in FIG. 9).

At 1006, the customer's smartphone, via the app for the optical code acceptance program, captures an image of the optical code 904.

At 1008, the customer's smartphone (via the app) prompts the customer to confirm that the customer is approving the transaction and the indicated payment to the merchant's account. Assuming the customer indicates confirmation/approval, then block 1010 follows block 1008.

At 1010, the optical acceptance app in the smartphone/customer device 906 communicates with the payment switch/network 910 (or the originator PSP 912) to transmit the image of the optical code to the payment switch/network 910 (or to the originator PSP, as the case may be). It may be assumed that the same communication identifies the customer via registration details to the payment switch/network 910.

At 1012, the payment switch/network 910 translates the optical code image into transaction details, including the merchant's bank account details and the transaction amount.

At 1014, the payment switch network 1010 executes a funds transfer in which the funds are debited from the customer's bank account and credited almost immediately to the merchant's bank account. The result may be a very rapid EFT credit to the merchant virtually in real time as the purchase transaction is being consummated.

In some embodiments, the optical code may be translated/interpreted at the originator PSP 912 and/or at the customer device 906.

As used herein and in the appended claims, the term “computer” should be understood to encompass a single computer or two or more computers in communication with each other.

As used herein and in the appended claims, the term “processor” should be understood to encompass a single processor or two or more processors in communication with each other.

As used herein and in the appended claims, the term “memory” should be understood to encompass a single memory or storage device or two or more memories or storage devices.

As used herein and in the appended claims, a “server” includes a computer device or system that responds to numerous requests for service from other devices.

The above descriptions and illustrations of processes herein should not be considered to imply a fixed order for performing the process steps. Rather, the process steps may be performed in any order that is practicable, including simultaneous performance of at least some steps.

As used herein and in the appended claims, the term “payment card system account” includes a credit card account, a deposit account that the account holder may access using a debit card, a prepaid card account, or any other type of account from which payment transactions may be consummated. The terms “payment card system account” and “payment card account” and “payment account” are used interchangeably herein. The term “payment card account number” includes a number that identifies a payment card system account or a number carried by a payment card, or a number that is used to route a transaction in a payment system that handles payment card transactions. The term “payment card” includes a credit card, debit card, prepaid card, or other type of payment instrument, whether an actual physical card, electronic, or virtual.

As used herein and in the appended claims, the term “payment card system” or “payment account system” refers to a system for handling purchase transactions and related transactions. An example of such a system is the one operated by MasterCard International Incorporated, the assignee of the present disclosure. In some embodiments, the term “payment card system” may be limited to systems in which member financial institutions issue payment card accounts to individuals, businesses and/or other organizations.

Although the present invention has been described in connection with specific example embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the invention as set forth in the appended claims.

Claims

1. A method comprising:

receiving a funds transfer request, the request including an alias character string; the request for requesting a funds transfer;

translating the alias character string to payment routing information that specifies a recipient's financial institution deposit account; and

routing the requested funds transfer via a payment network for crediting to the specified deposit account.

2. The method of claim 1, wherein the alias character string is a telephone number.

3. The method of claim 1, wherein the alias character string is an email address.

4. The method of claim 1, wherein the payment routing information is in an IBAN (International Bank Account Number) format.

5. The method of claim 1, wherein the payment network is an EFT (electronic funds transfer) network.

6. The method of claim 5, wherein the EFT network is an ACH (automated clearing house) network.

7. A method comprising:

receiving an alias character string in a message from a service provider;

using the alias character string to route a request to an issuer of a user bank account, the request for obtaining credit information about a user who owns said user bank account;

receiving a response to the request from the issuer of the user bank account, said response providing a positive or negative indication regarding the user; and

transmitting said positive or negative indication to the service provider.

8. The method of claim 7, wherein the message from the service provider is not a payment card account transaction authorization message and is not a request for a funds transfer.

9. The method of claim 8, wherein the alias character string is a telephone number.

10. The method of claim 8, wherein the alias character string is an email address.

11. The method of claim 8, wherein said receiving and transmitting steps are performed by a computer operated by an operator of a payment card account network.

12. The method of claim 11, wherein said message is not received via a transaction acquirer or payment processor.

13. The method of claim 8, further comprising:

receiving a translation of the alias character string into a bank account number that identifies said user bank account.

14. The method of claim 13, wherein said bank account number identifies said issuer of said user bank account.

15. The method of claim 8, wherein the service provider is a telecommunications service provider.

16. The method of claim 15, wherein the service provider is a mobile network operator.

17. A method comprising:

receiving a funds transfer request, the funds transfer request including target account information, the target account information for identifying a bank account to which funds are to be transferred pursuant to the request;

determining that the target account information does not include a bank account number; and

in response to determining that the target account information does not include a bank account number, initiating a process to translate an alias character string contained in the target account information to a bank account number.

18. The method of claim 17, wherein the alias character string is a telephone number.

19. The method of claim 17, wherein the alias character string is an email address.

20. The method of claim 17, wherein the process to translate the alias character string includes accessing an alias directory.