The present disclosure relates in general to the field of electronic payment systems, and more specifically, to emulating card-based payments.
The card payment industry has introduced support for some cardholders to pay at a merchant's point-of-sale (POS) terminal device using a near field communications (NFC)-enabled mobile phone. For instance, the Europay, MasterCard, and Visa (EMV) consortium has defined standards that individual card brands have used as a basis for their own derived specifications. Such mobile phones can store the card data and associated algorithms in a hardware chip called a “Secure Element” that is located in the phone. The card data and algorithms are the same as those stored in an EMV-style “chip card”, which is a plastic card with an embedded chip that can be used complete transactions using NFC. In the mobile phone version, even though there is no plastic card, the industry still uses the word “card”. In keeping with this terminology, “card” can also refer to a payment credential and accompanying logic residing in an NFC-enabled device, such as a smartphone, that enables the device to function as a traditional chip card or other payment device. During a transaction, an NFC-enabled device is held an inch or so from the POS terminal, and the terminal and the payment device communicate over NFC to complete the transaction.
According to one aspect of the present disclosure, data can be received that corresponds to an image presented at a location of a transaction involving a user device and a terminal device. It can be determined that the user device and the terminal device are engaged in the transaction based at least in part on the data and local interactions of a payment device with the terminal device can be virtualized based on authenticating the transaction. Virtualizing the interactions can include exchanging messages with the terminal device over a network according to a protocol corresponding to the payment device and the terminal device.
Like reference numbers and designations in the various drawings indicate like elements.
As will be appreciated by one skilled in the art, aspects of the present disclosure may be illustrated and described herein in any of a number of patentable classes or context including any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof. Accordingly, aspects of the present disclosure may be implemented entirely in hardware, entirely software (including firmware, resident software, micro-code, etc.) or combining software and hardware implementations that may all generally be referred to herein as a “circuit,” “module,” “component,” or “system.” Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable media having computer readable program code embodied thereon.
Any combination of one or more computer readable media may be utilized. The computer readable media may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an appropriate optical fiber with a repeater, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable signal medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, CII, VB.NET, Python or the like, conventional procedural programming languages, such as the “C” programming language, Visual Basic, Fortran 2003, Peri, COBOL 2002, PHP, ABAP, dynamic programming languages such as Python, Ruby and Groovy, or other programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider) or in a cloud computing environment or offered as a service such as a Software as a Service (SaaS).
Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatuses (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable instruction execution apparatus, create a mechanism for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that when executed can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions when stored in the computer readable medium produce an article of manufacture including instructions which when executed, cause a computer to implement the function/act specified in the flowchart and/or block diagram block or blocks. The computer program instructions may also be loaded onto a computer, other programmable instruction execution apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatuses or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
Referring now to
In general, “servers,” “user devices,” “mainframes”, “computing devices,” “network elements,” “hosts,” “clients,” “communication devices,” “computers,” and “systems,” etc. (e.g., 105, 110, 115, 120, 125, 130, 135, etc.) in example computing environment 100, can include electronic computing devices operable to receive, transmit, process, store, or manage data and information associated with the computing environment 100. As used in this document, the term “computer,” “processor,” “processor device,” or “processing device” is intended to encompass any suitable processing device. For example, elements shown as single devices within the computing environment 100 may be implemented using a plurality of computing devices and processors, such as server pools including multiple server computers. Further, any, all, or some of the computing devices may be adapted to execute any operating system, including Linux, UNIX, Microsoft Windows, Apple OS, Apple iOS, Google Android, Windows Server, etc., as well as virtual machines adapted to virtualize execution of a particular operating system, including customized and proprietary operating systems.
Further, servers, clients, network elements, systems, and computing devices (e.g., 105, 110, 115, 120, 125, 130, 135, etc.) can each include one or more processors, computer-readable memory, and one or more interfaces, among other features and hardware. Servers can include any suitable software component or module, or computing device(s) capable of hosting and/or serving software applications and services, including distributed, enterprise, or cloud-based software applications, data, and services. For instance, in some implementations, virtual card payment system 105, or other system or subsystem of an example computing environment (e.g., 100) can be at least partially (or wholly) cloud-implemented, web-based, or distributed to remotely host, serve, or otherwise manage data, software services and applications interfacing, coordinating with, dependent on, or used by other services and devices in environment 100. In some instances, a server, system, subsystem, or computing device can be implemented as some combination of devices that can be hosted on a common computing system, server, server pool, or cloud computing environment and share computing resources, including shared memory, processors, and interfaces.
While
A payment device can be a device that hosts or otherwise possesses computer-implemented functionality of a card or other electronic payment instrument (sometimes referred to herein collectively as “payment instrument”). A payment instrument can be hosted in memory of one or more payment devices and embodied as electronic payment logic and credentials, account information, and other data used by the payment logic to process and generate messages exchanged with a terminal in a transaction. A payment device can potentially host multiple payment instruments (e.g., one for each account associated with a user/owner of the payment device). Similarly, in some cases, instances of a payment instrument for an account can be hosted on multiple different devices (e.g., each of a plurality of devices owned by the account holder). A payment device can be used at a merchant point-of-service device, kiosk, automated teller machine (ATM), or other terminal system and communicate data with the terminal to complete a transaction. While much of the discussion herein references examples involving terminal systems and transactions, it should be appreciated that the concepts discussed herein also pertain to other systems supporting the use of payment cards.
During a transaction in which a payment instrument (e.g., hosted by a payment device) is used by a user to withdraw money, purchase a good or service, etc. or otherwise engage in a transaction with another party, a terminal device, such as a point-of-sale (POS) terminal, and the payment device can exchange several messages and negotiate whether the transaction will be performed, and if so, how it will be performed. A variety of protocols can be utilized to define the exchange of messages and the negotiation between a terminal and the card. One such example is the Europay, MasterCard, Visa (EMV) standard, although a wide array of other standards can also be used, including variants of EMV and other standards.
It has been shown that sophisticated antennae and signal processing tools can be utilized to intercept transmissions over an NFC channel between a payment device (e.g., using a hosted payment instrument) and a terminal device. These intercepted transmissions can pose an unacceptable security risk to the holders of the card or other payment instrument, with malicious individuals capable of using the captured transmissions to collect and misuse sensitive personal and financial information, among other potential issues.
In traditional payment devices, sensitive card data is attempted to be secured on the device within a Secure Element (SE), which can include a tamper-resistant chip that has both a processor and storage and stores logic for performing the functionality of a chip card. Such implementations require both algorithms and data, and these are both stored within the SE. The SE's add to the cost of a device and are not universally included in hardware of all mobile devices. Moreover, various actors such as the device seller, the carrier, and the operating system provider, may control or block access to the SE, limiting its utility, among other potential issues in previous systems.
In one example, a virtual card system can be provided that addresses at least a portion of the issues introduce above, among others. For instance, a virtual card system can utilize a remotely-provided virtual card server hosting an instance of a “virtual card” payment instrument that can conduct various steps of protocols used in traditional card transactions over one or more secure network connections. Such a system can apply to a variety of protocols including variants of the EMV standard, magstripe style protocols, and other variants not yet codified. Further, a virtual card system can apply to a variety of transactions to including transactions at retail POS terminals, ATM transactions, unattended kiosk transactions, and others. In some implementations, a user device can interact with a terminal to trigger an exchange between the terminal and a remote “virtual card” associated with the user. The virtual card can emulate an exchange with the terminal as if it were a locally presented card using a protocol supported by the terminal. The emulated exchange can appear to the terminal device as the same as a local exchange except for the connection mechanism (and the fact that the virtual card is remotely hosted and not (necessarily) local to the terminal). This can provide enhanced security for digital transactions, for instance, because the terminal-to-server network channel can use secure socket layer (SSL) or other encryption, unlike the unencrypted NFC channels used in traditional terminal-to-payment device communications, among other example advantages. Further, a virtual card system can allow not only the bona fides of the user/card holder to be proven to a merchant, but the merchant's bona fides can also be proven, guarding the user against unscrupulous merchants, among other potential example advantages.
Turning now to the simplified block diagram of
Account manager 206, in some implementations, can additionally manager merchant data records 214 identifying merchants that have been involved in transactions with holders of virtual cards supported by virtual card payment system 105. In some cases, at least some merchants identified in merchant data 214 can be considered authorized or trusted merchants. In some cases, virtual card payment system 105 can also support transactions with merchants not (yet) included or recognized as trusted merchants and can assess and associate reputation scores for the merchants as well as collect information from the merchants that can be used to authenticate the merchants or indicate to users a level of trust associated with a given merchant. In this manner, card holders can receive feedback regarding the level of security involved in transacting with a particular merchant. Merchant data 214 can be used to compare information obtained by the virtual card payment system 105 from a terminal (e.g., 115) in a transaction to attempt to authenticate or at least identify the merchant involved in the transaction, among other uses and examples.
An example virtual card payment system 105 can further include an authentication manager 208 configured to authenticate a transaction before passing the handling of the transaction to session emulator 210. In one example, a user device (e.g., 125) can trigger a virtual card transaction by passing authentication data to a terminal device (e.g., 115). The authentication data can encode a key and/or identifier associated with a particular card holder account. Terminal device 115 can identify that the transaction is to involve a virtual card hosted by virtual card payment system (e.g., 105) and send the authentication data to the virtual card payment system 105 along with other transaction data identifying the merchant, the amount of the transaction, other transaction descriptor data, and other information. The authentication manager 208 can decode the authentication data to determine if the authentication data is authentic and corresponds to one of the accounts managed by the virtual card payment system 105. In other implementations, authentication manager 208 can be triggered to send authentication data to the terminal device 115 which the terminal device is to then pass to the user device 125 associated with a particular card holder's account. The user device 125 can relay the authentication data received from the terminal device 115 back to the virtual card payment system 105 for use by the authentication manager 208 in authenticating a transaction between a given card holder (using a supported card-holder-associated device (e.g., 125)) and merchant associated with a given terminal device (e.g., 115), among other potential examples.
Upon authenticating that a legitimate card holder is in the presence of and completing a transaction with a given terminal device, session emulator 210 can interact with terminal device over one or more networks 165 to emulate an exchange of messages associated with a particular electronic payment protocol, such as a protocol between a chip card or magstripe card and a local reader on the terminal device. In some implementations, session emulator 210 can emulate an EMV protocol exchange, such as illustrated in the example of
As shown in the simplified flowchart 300, a protocol exchange between a session emulator (e.g., 210) and terminal system (e.g., 115, or a backend system supporting terminal device 115) can be emulated. In some cases, multiple applications (such as multiple EMV applications) may be supported—for a given card and the protocol can include selection (at 305) of a particular one of the applications. The - card emulated by the session emulator (e.g., 210) (e.g., the virtual card) can negotiate and agree upon a common supported application and choose which to use for the transaction. In some cases, selection of the application to be used in the transaction can involve a user (e.g., of the communication device (e.g., 125)) being prompted for a selection that is to be communicated to the virtual card payment system 105 and, in turn, the terminal system (e.g., 115). The selected application can be initiated (at 310) and application data can be provided from the virtual card (e.g., over network 165 from the virtual card payment system 105) to the terminal system for use by the terminal system. Offline data authentication 315 can then be performed to validate the virtual card using, for instance public-key cryptography. One or more of multiple available cryptographic checks can be performed including: static data authentication (SDA) to ensure data read from the card has been signed by the card issuer; dynamic data authentication (DDA) to protect against modification of data and cloning; and combined DDA/generate application cryptogram (CDA) to assure card validity, among other potential example techniques.
Restrictions can be processed (at 320) to confirm that the virtual card is allowed to do the requested transaction. Application data can be checked in connection with restriction processing 320 including the application version number, application usage control (e.g., whether the card is geographically restricted, etc.), application effective or expiration date(s), etc. Cardholder verification (at 325) can also be performed to verify the cardholder. A mechanism supported by the terminal system for verifying the cardholder can be agreed upon between the virtual card emulated by the emulation engine and the terminal system, such as a user signature, online PIN entry, offline enciphered PIN, offline plaintext PIN, “no CVM”, among other examples. Terminal risk management (at 330) can be performed to conduct one or more checks to determine whether a transaction should be authorized online or offline. Such checks can include, for example, checking floor limit, among other examples. Based on results of offline data authentication, processing restrictions, cardholder verification, terminal risk management and rules in the terminal and from the chip, terminal action analysis can be performed (at 335) and the terminal can request a result of decline offline, approve offline, or go online, among other examples. Card action analysis can also be performed (at 340) based on virtual card issuer defined rules and limits and a response can be issued such as go online, offline decline, offline approval, etc. In the case of offline approval, for instance, the transaction can proceed to completion (at 345). In the case that the transactions goes online, online processing can be performed (at 350) before proceeding to transaction completion 345. Online processing 350 can include the terminal building an online request to the virtual card issuer host for authorization and online card authentication. In some cases, a response can include optional issuer authentication and the terminal system can send the data to the virtual card for verification. Further, it should be appreciated that other protocol steps including variants of the foregoing can be included or substituted for those examples discussed above.
Returning to the discussion of the example of
An example terminal device (e.g., 115) can include one or more data processing apparatus 218, one or more memory elements 220, as well as one or more computer executable logic embodied, in some instances, in one or more software and/or hardware-based components, including, for example, a transaction processing engine 222, among other examples. In one example, transaction processing engine 222 can include physical card processing engine 224 for processing transactions with physical cards presented locally at the terminal device 115, such as chip cards and magstripe cards as well as virtual card processing engine 225 to enable the transaction processing engine 222 to complete transactions with virtual cards remotely provided through one or more virtual card payment services (such as one hosted by virtual card payment system 105). A terminal device can detect the form of payment/withdrawal used for instance based on an input of a customer or detecting and/or communicating with the card or device used by the customer in the transaction. In other instances, a human operator of the terminal device 115 can input the type of card used in the transaction causing either physical card processing 224 or virtual card processing 225 logic to be invoked and used in the transaction.
In the case of a virtual card processing engine 225, multiple types and supported protocols of virtual cards can be supported by the virtual card processing engine 225. For instance, multiple different virtual card payment systems may exist (including 105) and the terminal device 115 may be equipped so as to flexibly handle transactions involving anyone of a priority of different virtual card payment systems, among other examples. Terminal system 115 can communicate with a virtual card payment system 105 over one or more networks (e.g., 165), as introduced above. The terminal system can communicate authentication data to the virtual card payment system 105, in some instances, or a personal communicate device, in other instances, in connection with authentication of a transaction using a particular virtual card hosted by the virtual card payment system 105. The terminal system can further exchange communications with the virtual card payment system 105 in connection with one or more protocols emulating protocols between the terminal device and local card payment mechanisms, such as EVM chip cards and other examples.
A terminal device 115 can include various components to assist the terminal device in gathering and using information in connection with both local card transactions and virtual card transactions. For instance, terminal device 115 can include or be connected to a magnetic strip reader 226 (e.g., for reading a magstripe card), a near-field communication module 230 (e.g., for communicating with a local chip card or communication device embodying a chip card), as well as include other functionality for use in transactions involving some implementations of virtual card payment systems (e.g., 105).
A user device 125 can also include one or more data processing apparatus 234, one or more memory elements 236, as well as one or more computer executable logic embodied, in some instances, in one or more software and/or hardware-based components, including, for example, a virtual card payment application 240, among other examples. The user device 125, in one example, can further include an operating system 238 and one or more other applications 242 and programs. Other features can be provided for use in connection with virtual card payment application 240 such as a display device 244, such as a touchscreen or other display, and image capturing device 246, such as an integrated digital camera, among other examples. In some implementations, user device 125 can possess functionality to allow the device 125 to be adapted for other electronic payment schemes such as use as a traditional NFC card through a secure element (not shown) and a NFC module 248, among other examples. User device 125 can also include functionality for connecting, via wired or wireless communication channels, to one or more networks 165.
In one example, virtual card payment application 240 can include subcomponents such as an image processing engine 254, communication engine 256, and data manager 258, among other examples or alternatives. In one implementation, image processing engine 254 can be provided in connection with the triggering of a virtual card transaction at a terminal (e.g., 115). The image processing engine 254 can generate image data for presentation to the terminal device. The image data can be generated such that at least a portion of the image data varies from transaction to transaction (e.g., randomly) and another portion is encoded to identify the user device, a particular virtual card account, cardholder, or other information that can be decoded by virtual card payment system 105. Information encoded in the image data can further include such examples as the identity of the merchant on the other side of the transaction, the amount of the transaction, among other examples. In some implementations, the version of the image data can be generated such that it is a version expected for a next transaction involving a particular virtual card account. For instance, a counter value can be consulted (e.g., in virtual card data 250) by image processing engine 240 to determine or generate particular image data for a given transaction. The image data can be used to authenticate that a particular terminal device is legitimately transacting with an authorized user device (e.g., including virtual card data 250 and a virtual card payment application 240 installation associated with a valid virtual card account). Virtual card data 250 can be stored in secured memory or data structures (e.g., 252) and, in some cases, may only be accessed by a corresponding virtual card payment application installation.
In some implementations, virtual card payment application 240 can trigger and generate authentication image data for a virtual card transaction even when the user device is offline, allowing for use of the virtual card payment mechanism even in environments when network connectivity is unavailable, limited, or disallowed. In other instances, virtual card payment application 240 can include a communication engine 256 for use in interfacing with and interoperating with virtual card server system 105 over one or more networks (e.g., 165) in connection with some virtual card transactions. In some instances, communication engine 256 can include or utilize certificates, keys, encryption, one-time-passwords, or other authentication schemes and mechanisms to participate in secured, mutually authenticated communications with virtual card server system 105. Data can be received from virtual card server system 105, in some implementations and a data manager 258 can manage virtual card data 250 in accordance with operation of the virtual card payment application 240 and communications received from virtual card server system 105, among other examples.
As introduced above, in some examples, image data can be shared between a terminal device and a user device 125 in connection with authentication of a virtual card transaction. In one implementation, a user device (e.g., 125) associated with a virtual cardholder account can present an image to the terminal device 115 and image capturing device 228 on the terminal device can capture, and in some cases, at least partially interpret the image data presented by the user device. A virtual card server system 105 associated with an attempted payment using a virtual card can be identified, for instance, automatically from the image data or manually by a user of the terminal device 115. The terminal device 115 can communicate with the corresponding virtual card server system 105 to indicate that a transaction using a particular virtual card has been triggered by a user device 125. The terminal device 115 can provide transaction information to the virtual card server system 105 describing aspects of the transaction, such as the identity of the merchant, the amount involved in the transaction, etc. and can further transmit the received image data as captured by the terminal device 115. The virtual card server system 105 can determine whether the image data is authentic and, if so, further identify a corresponding virtual card account associated with the image data. The virtual card server system 105 can then emulate the behavior of a chip card or other payment device (and its payment instrument) according to one or more protocols supported by the terminal device for electronic payment at the terminal device by other forms of local payment.
In another example, a user device 125 can trigger a virtual card payment by communicating with virtual card server system 105. Further, unique image data can be generated by virtual card server system 105 and sent to the terminal device 115 at the other side of the transaction. The image data can be displayed to the user device 125 (e.g., using display 226 of terminal device 115) and captured by the user device 125 (e.g. using image capturing device 246). The user device 125 can send the captured image data to the virtual card server system 105 for comparison with the image data sent to the terminal device 115 and authentication of the virtual card transaction if the image data sent to terminal device 115 matches the image data captured by the user device 125, among other potential examples. Again, authentication of the transaction can trigger communication between the virtual card emulated at the virtual card server system 105 and the terminal device 115 to complete the transaction according to a protocol supported by the terminal device 115, including legacy payment protocols and other example protocols.
Turning now to the examples of
In some instances, in the example of
Indeed, in one particular example, virtual card payment application can be installed on smartphone together with virtual card data. The virtual card data can include a specific card credential downloaded onto the phone (e.g., in secure storage, such as a secure element). The credential can serve as a “nominal card” containing information that identifies the card issuer, identification of the particular virtual card service and system hosting the virtual card, a primary account number (PAN) of the virtual card, a authentication information that enables a terminal to have a secure session with the virtual card server system, among other example information. In some cases, rather than including the PAN itself, the nominal card can include some other card identification data that can be mapped to or used to derive the actual PAN (e.g., using the virtual card payment application or at the virtual card server system) so as to keep sensitive card data from having to be stored on the communication device. The nominal card can further include one or more cryptographic secrets for use in generating image data corresponding to an account. For instance, the secret data can be packaged into a byte string (e.g., using any mechanism, such as XML, to pack structured data, among other examples). When access to the secret is authenticated, information included in the secret data can be unpacked and encoded in a QR code or other optical code, using standard encoding mechanisms for that type of code. The secret data can be stored, for instance, in a Secure Element of the device, or encrypted in application storage associated with the virtual card payment application or other memory (e.g., when a secure element is unavailable). In particular, if the secrets are stored in application storage they may be cryptographically camouflaged under a PIN or other authentication key (e.g., including biometric signatures, etc.). Indeed, access and use of such secret data can be preconditioned on a user authenticating access to the data using such authentication techniques as passwords, PINs, touchscreen swipe patterns, biometric data, and the like. Information included in the secret data to be encoded in the image data can include, for example, identification of the virtual card issuer and/or server, identification of a primary account number (PAN) or other identifier of the account, a session ticket, among other example information.
To initiate payment the user can enter a PIN into their mobile phone associated with the virtual card payment application installed on the phone. Entering the PIN can unlock the nominal card credentials that can be used to generate the image (e.g., 405). In some implementations, brute force attacks on the PIN can be mitigated through a maximum failed PIN attempts rule (e.g., a three strikes policy) or other mechanism to protect the payment application from hacks. The image generated from the credential (e.g., by the virtual card payment application) can be encoded to include one or more pieces of information from the credentials including, for example, the virtual card issuer identifier, virtual card server system identifier, the PAN or other virtual card account identifier, a session ticket (for a session between the terminal and the virtual card server system), among potentially other information.
In one example, upon reading the QR code or other image (e.g., 405) generated by the customer's communication device, the terminal can initiate a session with the virtual card server system over one or more networks using the session ticket. In some implementations, the session ticket can be a short-lived cryptographic credential, such as a Kerberos-style ticket, a SAML token, or other credential. The session ticket can have a predefined validity period and the period can be set to a relatively small interval, such as 60 seconds or less from the time of the ticket's generation or generation of the image data, to make it difficult for unscrupulous actors to steal or reuse the image data and masquerade as the terminal in an unauthorized transaction. Further security measures can be employed either through the session ticket characteristics or characteristics of the image data. For instance, in one example, image data can expire according to short intervals and regenerate (e.g., every 10 seconds) to generate batches of images and accommodate delay between the card member's launching the application and the readiness of the terminal in being able to read the image. In some implementations, gaps can be defined between regenerated images to avoid reading errors, among other examples.
The terminal can initiate an encrypted session with the virtual card server system using information (e.g., the session ticket) encoded in the image received from the customer's communication device. For instance, the terminal can present the ticket received in the image data to the virtual card server system and the virtual card server system can accept or reject the session based on the received session ticket. The virtual card server system can enforce single use of a given session ticket such that there are no parallel sessions utilizing the same ticket. Further, in instances where regeneration of image data is supported, the virtual card server system can check for attempted use of multiple tickets within a given batch of images. With the session established, the virtual card server system can emulate a transaction between the virtual card and the terminal similar to exchanges between the terminal and a local, physical card device at the terminal. For instance, rather than a terminal making calls to an NFC stack or other interface of a local card, the terminal can utilize an API or other interface to make similar call (e.g., according to EMV protocol) with the virtual card server system.
While at least some of the previous examples, including the example of
Turning to
In one implementation, in examples similar to that illustrated in
In the example of
Turning to
Turning to the example of
In some implementations, a terminal may present an image to the user device in connection with the initiation of a virtual card transaction. For instance, in the example of
Turning to the example of
The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various aspects of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The terminology used herein is for the purpose of describing particular aspects only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of any means or step plus function elements in the claims below are intended to include any disclosed structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the disclosure in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the disclosure. The aspects of the disclosure herein were chosen and described in order to best explain the principles of the disclosure and the practical application, and to enable others of ordinary skill in the art to understand the disclosure with various modifications as are suited to the particular use contemplated.