Patent Application
20230010140
This disclosure relates generally to electronic payments, and more specifically to a software-based service that accepts credit and debit card payments in social networks by allowing the cardholder to make the payments through a simple voice command in cardholder's own voice, which is biometrically authenticated to provide a secure payment process.
Electronic payments have dramatically evolved over the years. For example, the credit/debit card payment acceptance machines at point-of-sale (POS) locations (such as a cash register at a supermarket) and the e-commerce website based payment systems allowing a credit/debit cardholder to enter the card number and the Card Verification Value (CVV) code on the back of the card on the website to make the electronic payments are still generally widely-used. However, other POS payment acceptance systems, such as, for example, the Europay Mastercard and Visa (EMV) terminals, Near-Field Communication (NFC) units allowing payment through a simple touch of the corresponding chip-enabled credit/debit card, and mobile card readers are also becoming increasingly popular. Additionally, apps have been designed to allow cardholders to use their mobile devices to effectuate payments through a simple scan of a Quick Response (QR) code (or other one-dimensional or two-dimensional (2D) barcodes) or their face using face recognition technologies.
Telephone based payments are also routinely used to pay bill collectors, utility companies, travel agencies, medical service providers, remote merchants, and so on. One of the top challenges for travel agencies, insurance companies, subscription services, merchants offering telemarketing sales promotions, Mail Order (MO) or Telephone Order (TO) companies, and the like, is their dependence on payment collections by telephone, which is a non-face-to-face means of collecting payments. However, such payments do not come without attendant risks. For example, today, millions of collection calls are made by call centers around the world. Some of these calls may be fraudulent, putting the security of cardholders at risk. When responding to such calls, the cardholders must disclose their confidential credit/debit card information—such as the card number, its expiration date, and card's CVV or security code—to the telephone operator to make the required payments. A malicious operator at the call center can use such critical cardholder information to make fraudulent purchases, thereby creating serious problems for the cardholder and the same merchants the call center is engaged to serve. The fraudulent transactions may translate into chargebacks (from the card issuers), with increased transactional risks and, consequently, a higher financial cost to the business.
PayLinks provide a partial solution to this problem. A PayLink may be an emailed link that the customer can click on to pay their bill online. Under the PayLink option, a radio button with “Pay My Invoice” text (or similar notation) may be displayed on the customer's device (smartphone, tablet, laptop computer, and the like). When the customer clicks that button, they may be presented with a screen where they can pay their invoice online with a debit or credit card. However, because such links may arise from a fraudulent source, they can result in potentially unsecured activities, which generate distrust and offer an unfriendly user experience.
With the advent and popularity of social media networks like Facebook®, Twitter®, and so on, the merchants are offering more and more options to social media users to make payments to the merchants online using a social media platform. However, currently, payments to merchants via social media forces the client to re-enter credit/debit card information each time they pay. This leaves the clients vulnerable each time they enter their personal and payment information online, especially in the event that the payment link or a QR code (for payment initiation) is not transmitted from a secure source.
This Summary provides a simplified form of concepts that are further described below in the Detailed Description. This Summary is not intended to identify key or essential features and should therefore not be used for determining or limiting the scope of the claimed subject matter.
As mentioned before, telephone calls from bill collectors or other merchants for payments may not provide the financial safety necessary for a customer's peace of mind. Furthermore, a customer may find multiple such calls harassing and privacy-invading. In case of online payments, although systems and apps have been devised to ensure customer's financial safety, the payment transactions conducted via social media platforms still remain exposed to fraud and unsecured activities.
It is therefore desirable to devise a method of online payment that allows a customer to use a social media platform to make a payment in a simple, secure, user-friendly, and trustworthy manner. It is further desirable to effectuate the payment through social media messaging instead of disturbing telephone calls, without jeopardizing the customer's financial safety.
As a solution, particular embodiments of the present disclosure relate to a system and method for accepting credit and debit card payments in social networks via a social media application such as, for example, the WhatsApp® messaging application and the Facebook® Messenger application. The solution may operate as an intermediary between a customer and a merchant. This intermediary system may support payment acceptance and execution and may offer a social POS in social networks to allow merchants affiliated with Payment Service Providers (PSPs), aggregators, or card issuer banks to receive payments with a credit or debit card (for example, VISA®, MasterCard®, American Express®, and the like). The system allows businesses to send payment requests to their clients by means of messages through social networks and to receive payments safely through a simple voice command spoken by the client using a smartphone, a tablet, or a personal computer.
Initially, at the time of the first payment, the cardholder may capture/scan and store their credit/debit card information in a secure way. The system may tokenize and encrypt this information, and also register the individual cardholder's biometric voice fingerprint. By doing so, the cardholder is able to make future payments to any affiliated merchant with a simple voice command, as simple as sending a voice message through the social media application. The voice message may be a configurable phrase such as, for example, “I approve the payment with code 3 4 6 7.” In one embodiment, the code may be a variable number that is randomly-generated by either the intermediary system or the card issuer bank.
In certain embodiments, to avoid fraud, the intermediary system of social media-based payments fulfills payments through a telephone number from the merchant or card-issuer bank itself, which has already been verified by the WhatsApp® or Facebook® platform and which has a seal or mark that identifies it and authenticates it. This ensures the customer that the payment request is genuine and their payment will be sent to the actual merchant, and not to an impostor.
In one embodiment, the present disclosure is directed to a computer program product comprising a non-transitory computer-usable medium having computer-readable program code embodied therein, wherein the computer-readable program code, when executed by a computing system, causes the computing system to implement a method. The method comprises: (i) sending a payment notification from a merchant to a customer of the merchant via a text message having a format required by a social media messaging application, wherein the social media application is one of the following: a WhatsApp® messaging application, and a Facebook® Messenger application; (ii) offering the customer a choice to pay the merchant via the social media application using customer's voice along with a customer-selected means of payment; and (iii) processing a voice signature of the customer and the customer-selected means of payment to effectuate the payment to the merchant.
In another embodiment, the present disclosure is directed to a method, which comprises: (i) receiving, by a computing system, a payment notification from a merchant requesting a payment from a customer, wherein the payment notification identifies the customer and a phone number registered for the customer with a social media messaging application; (ii) sending, by the computing system, the payment notification to the phone number of the customer as a first text message having a format required by the social media application, wherein the first text message offers the customer an option to pay the merchant electronically via the social media application; (iii) determining, by the computing system, that the customer is registered for voice payment and has selected the option to pay the merchant; (iv) sending, by the computing system, a second text message to the customer in the format required by the social media application, wherein the second text message contains a pre-defined sentence; (v) instructing, by the computing system, the customer to speak and record the pre-defined sentence using the social media application; (vi) receiving, by the computing system, the following from the customer via the social media application: (a) an identification of a means of payment selected by the customer to electronically pay the merchant, and (b) an audio message containing a recording of the pre-defined sentence spoken by the customer; (vii) authenticating, by the computing system, a voice signature of the customer based on an electronic analysis of the audio message; and (viii) executing, by the computing system, a transaction with an entity that has issued the customer-selected means of payment to effectuate the payment to the merchant. In one embodiment, the pre-defined sentence may be generated by appending a variable number to a pre-designated command phrase. For example, in the earlier-mentioned sentence “I approve the payment with code 3 4 6 7”, the pre-designated command phrase is “I approve the payment” and the variable number is “3 4 6 7” (which may be randomly-generated).
In a further embodiment, the present disclosure is directed to a method, which comprises: (i) receiving, by a computing system, a payment notification from a merchant requesting a payment from a customer, wherein the payment notification identifies the customer and a phone number registered for the customer with a social media messaging application; (ii) sending, by the computing system, the payment notification to the phone number of the customer as a first text message having a format required by the social media application, wherein the first text message offers the customer an option to pay the merchant electronically via the social media application; (iii) determining, by the computing system, that the customer has selected the option to pay the merchant; (iv) sending, by the computing system, a second text message to the customer in the format required by the social media application, wherein the second text message contains a secure link to enable the customer to electronically make the payment to the merchant via the social media application, wherein the secure link allows the customer to provide details of a customer-selected means of payment for verification with an entity that has issued the customer-selected means of payment; (v) receiving, by the computing system, the details of the customer-selected means of payment via the social media application; (vi) transmitting, by the computing system, the details of the customer-selected means of payment and an amount of the payment to the entity for processing; (vii) receiving, by the computing system, an indication from the entity that the payment is successfully processed using the customer-selected means of payment; (viii) sending, by the computing system, a third text message to the customer in the format required by the social media application, wherein the third text message invites the customer to register the means of payment and a voice signature of the customer for future transactions; (ix) receiving, by the computing system, an affirmative response to the third text message from the customer via the social media application; (x) securely storing, by the computing system, the details of the customer-selected means of payment for future use by the customer; and (xi) registering, by the computing system, the customer for voice payment upon successful storage of the voice signature of the customer based on a pre-determined number of recordings of a pre-defined sentence received from the customer via the social media application, wherein the pre-defined sentence is formed of a pre-designated command phrase and a variable number.
Thus, the payment mechanism using social media and with a voice command simplifies the processing of payments for the merchants, and avoids the use of POS hardware to process the payments. Once the first payment has been made via the social media application, all payments for subsequent purchases or other transactions can be made with a simple voice command, secured through biometric authentication. The customer does not need to share sensitive credit/debit card information every time he/she makes a payment. This increases trust and enhances a customer's purchasing experience. Furthermore, because a service provider or merchant is allowed to send payment notifications via social media messages, the cardholder/customer is saved from receiving multiple, annoying phone calls for payments. The customer may attend to the messages whenever he/she wishes, and without disturbing or jeopardizing the customer's financial safety.
A more complete understanding of the present disclosure may be obtained by reference to the following Detailed Description when taken in conjunction with the accompanying Drawings. For ease of discussion, the same reference numbers in different figures indicate similar or identical items.
In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the disclosure. However, it will be understood by those skilled in the art that the present disclosure may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the teachings of the present disclosure. Furthermore, this disclosure provides various example implementations or embodiments, as described and as illustrated in the drawings. However, this disclosure is not limited to the implementations described and illustrated herein, but can extend to other implementations, as would be known or as would become known to those skilled in the art.
Reference throughout this specification to “one embodiment,” “particular embodiments,” “this implementation,” “some embodiments,” or other terms of similar import, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment or implementation of the present disclosure. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same implementation/embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. Also, depending on the context of discussion herein, a singular term may include its plural forms and a plural term may include its singular form. Similarly, a hyphenated term (e.g., “social media-based,” “pre-defined”, “customer-selected,” etc.) may be occasionally interchangeably used with its non-hyphenated version (e.g., “social media based,” “predefined”, “customer selected,” etc.), and a capitalized entry (e.g., “Customer System,” “Merchant Module,” “Voice Payment Processor,” etc.) may be interchangeably used with its non-capitalized version (e.g., “customer system,” “merchant module,” “voice payment processor,” etc.). Such occasional interchangeable uses shall not be considered inconsistent with each other.
It is noted at the outset that the terms “coupled,” “operatively coupled,” “connected”, “connecting,” “electrically connected,” etc., are used interchangeably herein to generally refer to the condition of being electrically/electronically connected in an operative manner. Similarly, a first entity is considered to be in “communication” with a second entity (or entities) when the first entity electrically sends and/or receives (whether through wireline and/or wireless means) information signals (whether containing address, data, or control information) to/from the second entity regardless of the type (analog or digital) of those signals. It is further noted that various figures shown and discussed herein are for illustrative purpose only, and are not drawn to scale.
The terms “first,” “second,” etc., as used herein, are used as labels for nouns that they precede, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless explicitly defined as such. Furthermore, items or features appearing in different figures may be identified using the same reference numeral for ease of discussion. However, such identification does not imply that the commonly-referenced items/features are identical across all embodiments.
It is noted here that, for ease of discussion, a computer software, program code or module may be referred to as “performing,” “accomplishing,” or “carrying out” a function or process. However, it is evident to one skilled in the art that such performance may be technically accomplished by a processor when the software or program code is executed by the processor.
The program execution would cause the processor to perform the tasks or steps instructed by the software to accomplish the desired functionality or result. However, for the sake of convenience, in the discussion below, a processor or software component may be referred to interchangeably as an “actor” performing the task or action described, without technically dissecting the underlying software execution mechanism.
In the discussion herein, the terms “social media payment host,” “third party system”, “third party payment platform,” and “host system” may be used interchangeably merely for ease of description. Similarly, the terms “customer”, “client,” and “user” also may be used interchangeably, and so are the terms “bank system” and “payment service provider system”. Furthermore, it is noted that, in the discussion below, the WhatsApp® and the Facebook® Messenger applications are merely used as examples of social media applications suitable for voice payment as per teachings of the present disclosure. Thus, although the discussion is primarily focused on these social media applications for ease of description and for the sake of brevity, the teachings of the present disclosure remain equally applicable to other social media applications, networks, or platforms.
Generally, an operator of the social media payment host or any other computing system discussed herein, a merchant, or a payment service provider (PSP) each may be a human operator or a non-human entity (such as a for-profit corporation, a non-profit enterprise, a government agency, or any other commercial or non-commercial entity). A customer, on the other hand, is a human person whose own voice is used to make a payment as per teachings of the present disclosure. In particular embodiments, the social media payment host may be an independent entity not connected/related with the customer, the merchant, or the (card-issuer) bank/PSP, except for its provision of the voice payment services through social media networks as per the teachings of the present disclosure.
In the embodiment of
The host system 102 may be associated with a third party that merely provides an online platform (through the host system 102) to provide an independent, third party-based acceptance and execution of voice payments in social media networks, as discussed in more detail later below. In other words, as noted before, in particular embodiments, the payment host (managing the third party system 102) may be an independent entity that is neither affiliated nor associated with either the customer or the merchant or the bank/PSP, except to the extent of providing its online, social media-based voice payment service as per the teachings of the present disclosure. In particular embodiments, the third party host may charge a fee to the merchant or the bank/PSP for its voice payment services. In some embodiments, the third party host may license the voice payment software to the bank/PSP, in which case the functionality of the host system 102 may be incorporated into the bank system 108. Other arrangements to implement the voice payment features may be devised as suited in the marketplace.
The third party system 102 may include a voice payment processor (VPP) application 117 (or, simply, a “payment application”), which may be a software module that implements the social media-based voice payment as per teachings of the present disclosure. Various software modules contained in the VPP application 117 are illustrated in the exemplary embodiment of
As noted above, the payment application 117 may be a software application comprising program code, which, upon execution by a processor (not shown) in the host system 102, enables the host system 102 to perform different operations to facilitate social media-based voice payments. An exemplary set of such operations is illustrated in
The program code constituting the payment application 117 may be stored in a storage unit or memory (not shown) in the host system 102. Such memory, processor, and other exemplary architectural details of the host system 102 are shown in
As shown in the embodiment of
In some embodiments, each of the systems 102, 104, 106, and 108 may be a computing system. A computing system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users or operators of the system to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, computing systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in computing systems allow for computing systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, computing systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computers, data storage systems, and networking systems.
Modern computing systems include many different types of consumer and commercial electronic devices such as, for example, personal computers (e.g., desktops or laptops), tablet computers, mobile devices (e.g., personal digital assistants (PDAs), User Equipments (UEs), or smart phones), corporate (or small business) server and data processing systems (e.g., blade server or rack server), a network storage device, and the like. These devices may vary in size, shape, performance, functionality, and price. In any event, almost all of these modern devices are equipped with relevant hardware and software to allow their users/operators to access a number of different websites over the Internet and perform online transactions.
For purpose of this disclosure, a computing system may include any instrumentality or aggregate of instrumentalities operable to compute, calculate, determine, classify, process, transmit, receive, retrieve, originate, switch, store, display, communicate, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for personal, business, scientific, control, or other purposes. The computing system may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, read-only memory (ROM), and/or other types of nonvolatile memory. Additional components of the computing system may include one or more disk drives, one or more network ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, touch-screen and/or video display. The computing system may also include one or more buses operable to transmit communications between its various hardware components.
In particular embodiments, the VPP application 117 may be considered Software as a Service (SaaS) that works as a social POS in social networks. This service may be offered for free to customers, but the merchants and/or the banks/PSPs may be charged a fee for the use of the service. In one embodiment, the customer-specific functionality of the VPP application 117 may be offered as a downloadable mobile app and, upon execution, this mobile app may be seamlessly “integrated” or “incorporated” into the customer's social media application 120 through an API. The customer-specific functionality may allow a customer to send details of the customer's credit/debit card, recordings of customer's voice signature, and voice payment commands to the VPP application 117 as discussed later below. In some embodiments, a program shortcut may allow the customer to download the customer-specific software portion of the VPP application 117 into the customer system 104 for execution as an interface through the social media application 120 when making payments through the social media application 120. Similarly, the merchant-specific functionality of the VPP application 117 may be made available to the merchant system 106 via another API. The merchant-specific functionality may allow a merchant to send payment notifications to a customer via a social media channel and accept voice payments from the customer, as discussed in detail later below. It is noted here that the relevant program code of the VPP application 117 and/or an API may be stored in a memory (not shown) of the respective system 104, 106, and may be executed by a processor (not shown) in the respective system 104, 106 under operative control of a respective Operating System (OS). Similarly, the program code for the payment application 117 may be stored in a memory (not shown) in the host system 102 and executed by a processor (not shown) in the host system 102 under operative control of a corresponding OS (not shown) of the host system 102. In particular embodiments, the payment application 117 may configure the host system 102 to act as an intermediary between a customer and a merchant to facilitate social media-based voice payments from the customer to the merchant. In particular embodiments, the OS of each of the systems 102, 104, 106, and 108 may be a Microsoft® Windows® based operating system (such as, for example, Windows XP, Windows 7, 8, or 10, and Windows NT operating systems). In other embodiments, each system 102, 104, 106, and 108 may have a different operating system, which may not be a Microsoft® Windows® based operating system.
In the flowcharts 200, 210, each block represents one or more tasks that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions that, when executed by one or more processors, cause the processors to perform the recited tasks. Generally, computer-executable instructions include routines, programs, objects, modules, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the blocks are described is not intended to be construed as a limitation, and any number of the described tasks can be combined in any order and/or in parallel to implement the processes shown in the flowcharts 200, 210. For discussion purpose, the processes in the flowcharts 200, 210 are described with reference to
Referring now to
The flowchart 210 in
At block 214, the computing system 102 may determine that the customer is registered for voice payment and has selected the (first text message's) option to pay the merchant. The registration process for voice payment is discussed later with reference to
At block 217, the computing system 102 may receive the following two items from the customer via the social media application: (i) an identification of the means of payment selected by the customer to electronically pay the merchant, and (ii) an audio message containing a recording of the pre-defined sentence spoken by the customer. For example, if the customer has a means of payment—for example, one or more credit and/or debit cards—already stored with the host system 102, the customer may identify and select the payment means to be used to pay the merchant, and provide a corresponding intimation to the host system 102 via a social media message from the customer system 104. In other embodiments, when only one method of payment is stored in the host system 102 on behalf of the customer, the reception of the audio message from the customer may automatically indicate to the host system 102 to select the pre-stored payment method for the customer. In this situation, a separate payment selection notification or message may not be received from the customer. The audio message may be received as a social media message such as, for example, a WhatsApp® audio message. In some embodiments, the audio message may be received as a Voice over IP (VoIP) communication over the network 110.
At block 218, the computing system 102 may authenticate the voice signature of the customer based on an electronic analysis of the audio message (received at block 217). Details of the storage of a customer's voice signature and registration of the customer for voice payment are discussed later with reference to
It is noted that although a credit or debit card payment in a traditional currency (for example, US dollars, or other national currency) is primarily discussed herein, in certain embodiments, the customer may be allowed to make a payment in any one of the following forms or in a combination of two or more of the following forms: as a traditional currency, as a non-traditional monetary instrument (for example, fungible tokens like stablecoins), as a digital currency (for example, an Electronic Fund Transfer (EFT) payment, or a payment through an e-commerce payment processor like PayPal® or Zelle®), as a cryptocurrency (for example, Bitcoins or Ethers), and/or a non-fungible token (NFT).
It is noted that WhatsApp® messaging is used merely as an example in the below discussion of
In
The payment module 304 may allow connectivity with the bank system 108 or any other payment processor system (not shown). For example, the payment module 304 may offer payment processor APIs to enable the host system 102 to communicate with payment processors, aggregators, card-issuer banks, and/or payment gateways (or switches). In particular embodiments, the payment module 304 may send a customer's payment information to a switch (or payment gateway), receive a payment authorization number from the switch, generate a payment receipt based on the payment authorization, and send the payment receipt to the social media message module 302 for sending the receipt to the customer as a WhatsApp® text message. The biometric verification module 305 may perform biometric voice enrollment, update, and verification. For example, the biometric module 305 may analyze the audio files of voice samples of a customer to extract the customer's voice signature therefrom, securely store the voice signature (for example, in the database 118 with the help of the storage module 303), and verify the voice signature every time the customer initiate a voice payment transaction.
The speech-to-text (STT) conversion module 306 may perform speech to text conversion for verification of at least the security code received in a WhatsApp® audio message from the customer. As mentioned before, at the time of voice payment, the customer may speak and record a pre-defined sentence and send the recording to the host system 102 as a WhatsApp® audio message. As per the earlier example, the pre-defined sentence may be: “I approve the payment with code 3 4 6 7”, which is formed of a pre-designated command phrase (“I approve the payment”) followed by a randomly-generated variable number or security code (“3 4 6 7”). In certain embodiments, the STT conversion module 306 may perform the speech-to-text conversion on the recording of the pre-defined sentence contained in the audio message to generate texts of the pre-designated command phrase and the variable number spoken by the customer. Thereafter, the STT conversion module 306 may verify that the customer-spoken text of the variable number (or security code) is correct. In some embodiments, the STT conversion module 306 also may verify that the customer-spoken text of the pre-designated command phrase is correct as well to maintain a record that the customer indeed approved the payment transaction and not any other type of transaction. This record-keeping may assist the merchant or other entity in the event a dispute arises as to whether the payment was authorized or not.
In the context of
Referring now to
Once the VPP application 117 receives the payment request, it may send a message to the customer system 104 at block 404 via WhatsApp® (or Facebook® Messenger). The message may be sent to the phone number of the customer registered with the social media application and may offer the customer an option to pay the merchant electronically via the relevant social media application (here, WhatsApp®). In one embodiment, the message may be sent encrypted and authenticated as coming from a trusted source. In another embodiment, the message may contain the phone number of the merchant registered with the social media application and also may contain the above-mentioned social media-specific mark, verified icon, or seal associated with the merchant, providing an assurance to the customer that the payment request is from an authentic source. As an example, the host system 102 may send the following WhatsApp® message on behalf of a telephone company collecting a bill from a customer: “Dear John Smith, the balance of your telephone bill for $250.64 on the account ending in 6321 is due now. Would you like to make your payment through Bank X's voice-pay service?” In this message, the Bank X may be the bank with which the telephone company is affiliated and that accepts payments on behalf of its affiliated merchant—here, the telephone company. The WhatsApp® message to the customer also may include the payment options “Yes” or “No” for the customer to choose.
At the decision block 405, the payment application 117 may determine if the customer is registered for voice payments and if the customer has a credit or debit card registered with the payment application 117. If this is the customer's first social media-based payment transaction (for the present merchant or any other merchant) using the payment application 117 or if the customer has declined to register for voice payments in the past (for the present merchant or any other merchant), the customer may not have been registered for voice payment yet. In that case, the payment application 117 may proceed to transition block 406 (identified by the circled letter “A” in
The transition block 406 leads to the voice payment registration process illustrated through blocks 407-419 in
At block 409, the VPP application 117 may receive the details of the means of payment—credit or debit card—selected by the customer at block 408 via a corresponding WhatsApp® message, and may transmit the details of the customer-selected means of payment and the amount of payment to the card-issuer bank for processing. In particular embodiments, the VPP application 117 may send the transaction details to an intermediate payment processor switch or gateway (which may include a PSP), via APIs, for eventual approval by the issuer bank. In particular embodiments, the transaction details may be sent to the switch/PSP or issuer bank by a secure ISO 8583 communication channel. As noted at block 410, the payment processor switch and/or other intermediate processor—such as a PSP—may request the issuing bank for authorization of the payment and an approval code for the transaction. If the payment is not authorized by the issuer bank for whatever reason (for example, wrong card number, stolen card, expired card, insufficient funds, and the like), the VPP application 117 may send the rejection or error code—received from the issuer bank—to the customer via, for example, a new WhatsApp message and request the customer to re-initiate the payment process starting with the tasks at block 408, as indicated by the “No” outcome at decision block 411.
If the payment is authorized by the issuer bank—as indicated by the “Yes” outcome at decision block 411, the switch may return the authorization number received from the bank to the VPP application 117, as noted at blocks 412-413. The authorization or approval of the transaction by the issuer bank may not be in the format of the relevant social media application. In particular embodiments, the VPP application 117 may incorporate the contents of the payment receipt from the issuer bank into a WhatsApp® message and send the message to the customer, as noted at block 414. As an example, once the payment has been made, the host system 102 may report its approval and corresponding approval code number as the following WhatsApp® message: “Thank you. Your transaction dated Jun. 20, 2021 has been approved under code number 099600. Bank X Payment Services thanks you for your trust.” A similar text also may be sent by the VPP application 117 to the customer's WhatsApp® phone number as a Short Message Service (SMS) text message. In certain embodiments, the customer also may receive from the VPP application 117, via another WhatsApp® message, a foliated digital receipt in the PDF format as proof of the successful payment.
Once the payment process is completed, the VPP application 117 may send a WhatsApp® message to the customer system 104 inviting the customer to register the customer's credit/debit card for future payments and also to register the customer's voice signature for future payments (block 415). As an example, the WhatsApp® invitation message at block 415 may read: “Do you want to register your card and voice to make future payments?” The message also may contain clickable options labeled “Yes” and “No.” If the customer declines the invitation to register for voice payment, the process may terminate (blocks 416-417). However, if the customer agrees to register for voice payment at block 416, the VPP application 117 may enroll the customer for voice payment using customer's voice (block 418). The customer may be registered for voice payment upon successful storage of the customer's voice signature based on a pre-determined number of recording of a pre-defined sentence received from the customer via the social media application (here, WhatsApp®). In one embodiment, as a security request from the acquiring bank (card-issuer bank) or PSP, the voice enrollment process (discussed below) may be executed into the personal banking app of the bank or PSP, allowing the cardholder to pay by its voice (as discussed herein) to any collecting message sent by any affiliated merchant of the bank/PSP via social media. Once the cardholder voice is enrolled into the bank's app or the first payment is made via the social media application, all future payments can be made with a simple voice command as per the teachings of the present disclosure.
In one embodiment, as part of the enrollment at block 418, the VPP application 117 may send three (3) recording-related WhatsApp® text messages to the customer and receive and analyze the customer's response to each message as discussed herein. Each message may invite the customer to speak an identical voice command and send its recording to the host system 102 via the social media application. For example, the first of the three recording-related messages may read: “The voice registration process requires you to send three equal messages with the voice command given below. The voice command will be used to make your payments in future. Please, with your voice and pressing the WhatsApp® microphone icon, repeat the voice command: ‘I approve the payment with the code 3,4,6,7.’” The customer may record the voice command—“I approve the payment with the code 3,4,6,7”—and send a WhatsApp® voice message containing this recording to the host system 102. The VPP application 117 may biometrically analyze the received recording to extract the voiceprint or voice signature of the customer therefrom. The VPP application 117 also may securely store the extracted voice signature in, for example, the database 118 (
Additionally, as noted at block 419, before concluding the voice registration process (at block 417), the VPP application 117 also may perform tokenization of the customer's credit/debit card of record to securely store the details of the customer-selected means of payment for future use by the customer. The card information may have been received from the customer at block 408. In some embodiments, the customer may choose to register one or more additional cards even though the customer may have already provided card information for at least one card in the past. In one embodiment, the database 118 may be used for secure storage of customer-specific card details. In particular embodiments, the stored card information may comply with the data protection and security requirements of the Payment Card Industry—Data Security Standard (PCI-DSS) regulations developed by the PCI Security Standards Council (PCI SSC). Furthermore, proper encryption methods may be implemented to maintain security, integrity, and confidentiality of the customer's credit/debit card details transmitted over open public networks—such as the Internet. For example, the information transmitted in WhatsApp® or Facebook® Messenger messages may be end-to-end encrypted by the social media application itself. However, in some embodiments, the VPP application 117 itself may use tokenization and encryption to provide a secure payment facility to payment processors, banks, PSPs, switches, and the like, when they accept payments with the VPP application 117 (for example, via appropriate APIs as noted before) and when customers pay with their voice via their smartphones, tablets, and personal computers. The VPP application 117 may facilitate transactions that achieve the EMV Corporation (EMVCo) grade security, with cryptograms generated from variable credentials (tokens). The EMV specification information may be obtained from https://www.emvco.com.
Once the customer goes through the voice and card registration process of blocks 407-419—for example, during a social media-based payment to another merchant in the past—the payment application 117 may determine in the affirmative at decision block 405. Furthermore, if the customer selects the “Yes” option in the WhatsApp® message at block 404, the payment application 117 also may determine at decision block 420 that the customer has accepted making the payment to the current merchant (associated with the payment request at block 403) using the social media-based voice payment process. As a result, the payment application 117 may initiate the voice payment process at block 422 and send a WhatsApp® text message to the customer containing a pre-defied sentence. The message may provide an instruction for the customer to speak and record the pre-defined sentence using the relevant social media application (here, WhatsApp®). As an example, such a message may read: “To approve the transaction, repeat the following phrase with your voice and pressing the WhatsApp microphone icon: ‘I approve the payment with code 3 4 6 7.’ Each number must be pronounced separately, one by one.” As mentioned before, in the pre-defined sentence “I approve the payment with code 3 4 6 7”, the pre-designated command phrase is “I approve the payment” and the variable number is “3 4 6 7” (which may be randomly-generated). It is observed from the earlier discussion that the same pre-designated command phrase was used during the customer's voice registration at block 418 to enable the VPP application 117 to easily ascertain the authenticity of the customer's voice signature as discussed below.
It is noted that, in some embodiments, the variable number mentioned above may act as a Personal Identification Number (PIN) of the customer for the transaction at issue. In particular embodiments, the VPP application 117 may receive the variable number from the card-issuer bank, a PSP, or other entity involved in the processing of the payment transaction. In other embodiments, the VPP application 117 itself may randomly generate the variable number. The VPP application 117 may then generate the pre-defined sentence by appending the variable number to the pre-designated command phrase, and then send the sentence to the customer at block 422. If the customer has multiple cards already enrolled for payments, the customer may select one of those cards for the current payment (block 422). On the other hand, if the customer has only one card registered for payments, the customer may simply choose this card as the “default” payment method. As part of the tasks at block 422, the customer system 104 may generate a WhatsApp® audio message containing the recording of the above-mentioned pre-defined sentence spoken by the customer. Consequently, as noted at block 422, the customer may use WhatsApp® messaging to send to the host system 102 an identification of the card selected by the customer for payment, and the audio message for authenticating the customer's voice signature and the variable number (or random number/issuer PIN).
The payment application 117 may receive the WhatsApp® message(s) sent by the customer at block 422 and perform voice pay authentication of the customer (at block 423) through biometric voice match and STT conversion. The biometric voice match may involve an electronic analysis of the audio message received at block 422. For example, in one embodiment, the VPP application 117 may biometrically analyze the audio message to extract the customer's voice signature therefrom and electronically compare it with the customer's pre-stored voice signature (at block 418) during voice registration process. The voice match may be considered a success if this comparison indicates that both of the signatures are substantially identical. In one embodiment, the technology of voice biometrics from ValidSoft® (https://www.validsoft.com) may be used by the VPP application 117 for such biometric analyses.
It is noted here that each person's throat, paddle and vocal cords are uniquely different, and it is these elements that mainly affect the air that is expelled from a person's lungs and mouth when the person speaks. Starting with the raw audio and the waveform generated when the customer speaks, the VPP application 117 may process the audio waveform to extract key characteristics that are unique to the speaker (here, the customer). From this, a statistical model and voice signature may be built for each individual person enrolled in the voice pay system. When comparing the voice audio later—for example, when authenticating a person against their previously registered voice signature—the same process may be applied a measure of similarity of the key characteristics may be obtained. The value of this measure may indicate whether the voice match is a pass or a fail. Voice biometrics “knows” who the speaker is, but not what the speaker is saying. Therefore, voice biometrics may be used to authenticate the identity of an individual speaker. On the other hand, voice recognition or speech recognition may be used to identify the content of a person's speech—that is, what the person is saying. In some embodiments, both of these technologies may be used together to facilitate voice payments.
In particular embodiments, as part of the authentication at block 423, the payment application 117 also may perform a speech-to-text (STT) conversion on the recording of the pre-defined sentence contained in the audio message (at block 422) to generate texts of the pre-designated command phrase and the variable number spoken by the customer. Thereafter, the payment application 117 may verify that the customer-spoken texts of the pre-designated command phrase and the variable number are correct—that is, the STT converted versions match the corresponding texts in the pre-defined sentence sent by the payment application 117 to the customer as part of the earlier-mentioned WhatsApp® text message at block 422. As mentioned before, the STT conversion may allow the payment application 117 to maintain a record that the customer indeed approved the payment transaction and not any other type of transaction, and used the correct PIN. This record-keeping may assist the merchant or other entity in the event a dispute arises as to whether the payment was authorized or not. In one embodiment, the voice transcription technology from SpeechMatics® (https://www.speechmatics.com) may be used by the VPP application 117 for such STT conversion.
If the voice pay authentication is successful at block 423, the VPP application 117 may proceed with the payment at block 424 in a manner similar to that discussed before with reference to blocks 409-413 in
However, if the voice pay authentication is unsuccessful at block 423—for example, if the customer's voice in the audio message at block 422 is not recognized by the biometric verification module 305 (
In particular embodiments, as noted before, in addition to the biometric analysis of customer's voice, the VPP application 117 also may verify the customer-spoken variable number (PIN) based on the STT conversion of the audio message received at block 422. Even if the voice signature of the customer is verified at block 423 based on a successful biometric analysis of the pre-designated command phrase spoken by the customer, there may be an error in the random verification number sent by the customer with his/her voice message at block 422. In that case, the VPP application 117 also may send a notice to the customer via a WhatsApp® message offering the customer to send his/her voice message again with a new random number (PIN). As before, if the new PIN-based voice authentication attempt fails for the third time (block 426), the VPP application 117 may send a WhatsApp® message to the customer requesting the customer to re-register their card or select another payment method and then make their payment (block 427). As an example, such a message at block 427 may read: “Your authentication has failed. Would you like to enroll again and to register another payment card?” If the customer declines to re-register at block 427, the payment process may terminate at block 425. However, if the customer wishes to use the same or another card for payment and re-register for voice pay at block 427, the payment application 117 may proceed to transition block 428 (identified by the circled letter “B” in
The foregoing discussion of
In one embodiment, the input devices 506 may provide operator inputs—such as, for example, messages or commands related to the administration of the host system 102, customer service related inputs (for example, rectifying a credit card number incorrectly entered by the customer), responses to merchant queries, and the like—to the processor 500 and the payment application 117 for further processing. The input devices 506 may include, for example, a touchpad, a camera, a computer keyboard, a touch-screen, a joystick, a physical or virtual “clickable button,” a computer mouse/pointing device, and the like. A display screen is an example of the output device 508. Other examples of an output device include a graphics/display device, a computer screen or monitor, an alarm system, or any other type of data output device. In some embodiments, the input device(s) 506 and the output device(s) 508 may be coupled to the processor 500 via an I/O or peripheral interface(s). In some embodiments, the computer system 102 may include more than one instance of the devices shown. In various embodiments, all of the components shown in
The processor 500 is a hardware device that may include a single processing unit or a number of processing units, all of which may include single or multiple computing units or multiple cores. When the computing device 102 is a multiprocessor system, there may be more than one instance of the processor 500 or there may be multiple other processors coupled to the processor 500 via their respective interfaces (not shown). The processor 500 may include an integrated Graphics Processing Unit (GPU) or the GPU may be a separate processor device in the system 202. The processor 500 may be implemented as one or more microprocessors, microcomputers, microcontrollers, Digital Signal Processors (DSPs), Central Processing Units (CPUs), Graphics Processing Units (GPUs), state machines, logic circuitries, virtual machines, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 500 may be configured to fetch and execute computer-readable instructions stored in the memory 502, the peripheral storage 510, or other computer-readable media. In some embodiments, the processor 500 may be a System on Chip (SoC).
The memory 502 and the peripheral storage unit 510 are examples of non-transitory computer media (e.g., memory storage devices) for storing instructions that can be executed by the processor 500 to perform the various functions described herein. In some embodiments, the memory 502 and the peripheral storage unit 510 may include tangible, computer-readable data storage media. For example, the memory unit 502 may include both volatile memory and non-volatile memory (e.g., RAM, ROM, or the like) devices. Further, in particular embodiments, the peripheral storage unit 510 may include one or more mass storage devices such as, for example, hard disk drives, solid-state drives, removable media, including external and removable drives, memory cards, flash memory, floppy disks, optical disks (e.g., CD, DVD), a storage array, a network attached storage, a storage area network, or the like. Both memory 502 and mass storage devices constituting the peripheral storage 510 may be collectively referred to as “memory” or “computer storage media” herein, and may be a media capable of storing computer-readable, processor-executable program instructions as computer program code that can be executed by the processor 500 as a particular machine (or special purpose machine) configured for carrying out the operations and functions described in the implementations herein. In some embodiments, the database 118 (
The computing device 102 may also include one or more communication interfaces as part of its interface unit 504 for exchanging data via a network (such as the communication network 110 in
The computer storage media, such as the memory 502 and the mass storage devices in the peripheral storage 510, may be used to store software and data. For example, the computer storage media may be used to store the operating system (OS) for the computing device 102, various device drivers for the device 102, various inputs provided by the operator of the device 102 or received from the customer system 104 (for example, audio samples of customer's voice, credit/debit card information, and so on), the merchant system 106 (for example, payment notifications), and the bank system 108 (for example, transaction confirmations or failure notifications, payment receipts, and the like) at run-time during the implementation of the social media-based voice payment methodology discussed before with reference to
In one embodiment, a non-transitory, computer-readable data storage medium, such as, for example, the system memory 502 or the peripheral data storage unit 510 may store program code or software for the payment application 117 as per particular embodiments of the present disclosure. In the embodiment of
In particular embodiments, the computing device 102 may include an on-board power supply unit 512 to provide electrical power to various system components illustrated in
The example systems and computing devices described herein are merely examples suitable for some implementations and are not intended to suggest any limitation as to the scope of use or functionality of the environments, architectures and frameworks that can implement the processes, components and features described herein. Thus, implementations herein are operational with numerous environments or architectures, and may be implemented in general purpose and special-purpose computing systems, or other devices having processing capability, and, hence, are considered machine-implemented. Generally, any of the functions described with reference to the figures can be implemented using software, hardware (e.g., fixed logic circuitry) or a combination of these implementations. The terms “module,” “mechanism” or “component” as used herein generally represents software, hardware, or a combination of software and hardware that can be configured to implement prescribed functions. For instance, in the case of a software implementation, the term “module,” “mechanism” or “component” can represent program code (and/or declarative-type instructions), such as the program code for the payment application 117 (including the software modules shown in
Although the present disclosure has been described in connection with several embodiments, the disclosure is not intended to be limited to the specific forms set forth herein. On the contrary, it is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the scope of the disclosure as defined by the appended claims.
This application claims the priority benefit under 35 U.S.C. § 119(e) of U.S. Provisional Application No. 63/220,877 filed on Jul. 12, 2021, the disclosure of which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63220877 | Jul 2021 | US |
