US20200082384A1 - System and method for exchanging data with smart cards - Google Patents

Abstract

A system that includes an issuer system that receives, via a network, registration information from a mobile device, wherein the issuer system is associated with a financial institution that issues a smart card to a user and wherein the registration information includes an identifier of the mobile device, and a mobile device application associated with the issuer system, that when executed on a mobile device, communicates with the issuer system to validate the mobile device as a trusted device and enables the trusted device to communicate with the smart card and enable smart card management features mobile device application.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application is a continuation of, and claims priority under 35 U.S.C. § 120 to, U.S. patent application Ser. No. 14/338,423, filed Jul. 23, 2014, which claims priority to U.S. Provisional Patent Application No. 61/857,443, filed Jul. 23, 2013, the entire contents of which are fully incorporated herein by reference.
FIELD OF THE DISCLOSURE
• The present disclosure relates to systems and methods for exchanging data between mobile devices and smart cards.
BACKGROUND OF THE DISCLOSURE
• Currently, a user having a smart card is dependent on physical locations of smart card-accepting devices in order to read/write data onto the smart card. This can be frustrating for smart card cardholders, as they are limited as to where they can go to change the settings on their smart cards.
• These and other drawbacks exist.
SUMMARY OF THE DISCLOSURE
• Various example embodiment provide a system including an issuer system that receives, via a network, registration information from a mobile device, wherein the issuer system is associated with a financial institution that issues a smart card to a user and wherein the registration information includes an identifier of the mobile device and a mobile device application associated with the issuer system, that when executed on a mobile device, communicates with the issuer system to validate the mobile device as a trusted device and enables the trusted device to communicate with the smart card and enable smart card management features mobile device application.
• In various embodiments, the trusted device communicates with the smart card via near-field communications (NFC). Also, the smart card is an integrated circuit card and/or a Europay, MasterCard and Visa card. The management features include enabling offline updates to a personal identification number (PIN) of the smart card.
• Various embodiments also provide a system including an issuer system that receives via a network from a mobile device an inputted personal identification number (PIN) associated with a smart card issued by the issuer system and transmits via a communication interface a validation message including the inputted PIN to the mobile device based on a validation of the inputted PIN, and a mobile application executing on a mobile device that receives the validation message, prompts the user to provide the inputted PIN to the mobile device, compares, using a processor of the mobile device, the provided inputted PIN with the inputted PIN received in the validation message, and enables transmission of the inputted PIN to the smart card if the provided inputted PIN matches the inputted PIN received in the validation message.
• Various embodiments also provide a system including an issuer system that receives an authorization request for a transaction initiated by a user and transmits a verification request to a mobile application on a mobile device of the user, wherein the issuer system receives the authorization request from a merchant via an authorization network and wherein the issuer system transmits the verification request to the mobile application via a network, and a mobile application on a mobile device of the user that receives the verification request, prompts the user to input a personal identifier, receives an inputted personal identifier, and communicates with a smart card of the user to verify the inputted personal identifier. The personal identifier is a personal identification number (PIN) and the inputted personal identifier is an inputted PIN
• Also, the mobile device includes a biometric data reader that interfaces with the mobile application, and wherein the personal identifier includes biometric data and the inputted personal identifier includes inputted biometric data. To verify the inputted personal identifier, the mobile application receives the personal identifier from the smart card and compares the received personal identifier to the inputted personal identifier to determine whether the received and inputted personal identifiers match. When there is a match, the issuer system receives, via the network, a verification message and authorizes the transaction based on the received verification message.
• In various embodiments, the authorization network and the network are the same authorization network.
• Also, the issuer system transmits, via the authorization network, an authorization to a merchant associated with the transaction.
BRIEF DESCRIPTION OF THE DRAWINGS
• Various embodiments of the present disclosure, together with further objects and advantages, may best be understood by reference to the following description taken in conjunction with the accompanying drawings, in the several Figures of which like reference numerals identify like elements, and in which:
• FIG. 1 depicts a schematic diagram of a system for enabling read/write capability to a smart card by way of a mobile application on a mobile device, according to an exemplary embodiment of the disclosure;
• FIG. 2 depicts a schematic diagram of a method for providing a mobile device with a smart card management application, according to an exemplary embodiment of the disclosure;
• FIG. 3 depicts a schematic diagram of a method for updating the offline PIN on a smart card, according to an exemplary embodiment of the disclosure;
• FIG. 4 depicts a schematic diagram of a method for authenticating a cardholder during an online transaction using smart card data, according to an exemplary embodiment of the disclosure
• FIG. 5 depicts an example point of sale system according to an embodiment of the disclosure;
• FIG. 6 depicts an example authorization network according to an embodiment of the disclosure; and
• FIG. 7 depicts an example financial institution system according to an embodiment of the disclosure.
DETAILED DESCRIPTION OF THE EMBODIMENTS
• The following description is intended to convey a thorough understanding of the embodiments described by providing a number of specific exemplary embodiments and details involving systems and methods for providing read/write capabilities to a smart card by way of a secured application on a mobile device. It should be appreciated, however, that the present disclosure is not limited to these specific embodiments and details, which are exemplary only. It is further understood that one possessing ordinary skill in the art, in light of known systems and methods, would appreciate the use of the invention for its intended purposes and benefits in any number of alternative embodiments, depending on specific design and other needs. A financial institution and system supporting a financial institution are used as examples for the disclosure. The disclosure is not intended to be limited to financial institutions only.
• FIG. 1 depicts an exemplary embodiment of asystem100 for providing read/write interfaces between a smart card and a mobile device by way of a secured application on a mobile device, according to various embodiments of the disclosure. The system may include various network-enabled computer systems, including, as depicted inFIG. 1 for example, acard issuer104,cloud storage105, apayment network101, and amerchant107. It is also noted that thesystem100 illustrates only a single instance of each component. It will be appreciated that multiple instances of these components may be used. Moreover, thesystem100 may include other devices not depicted inFIG. 1.
• Other exemplary embodiments may disclosecard issuer104 and/orcloud storage105 as being integrated intopayment network101 ormerchant107. As referred to herein, a network-enabled computer system and/or device may include, but is not limited to: e.g., any computer device, or communications device including, e.g., a server, a network appliance, a personal computer (PC), a workstation, a mobile device, a phone, a handheld PC, a personal digital assistant (PDA), a thin client, a fat client, an Internet browser, or other device. The network-enabled computer systems may execute one or more software applications to, for example, receive data as input from an entity accessing the network-enabled computer system, process received data, transmit data over a network, and receive data over a network. The one or more network-enabled computer systems may also include one or more software applications to enable the creation and provisioning of account services tomobile device102 for use bycardholder106.
• The components depicted inFIG. 1 may store information in various electronic storage media. Electronic information, files, and documents may be stored in various ways, including, for example, a flat file, indexed file, hierarchical database, relational database, such as a database created and maintained with software from, for example, Oracle® Corporation, Microsoft® Excel file, Microsoft® Access file, or any other storage mechanism.
• The components depicted inFIG. 1 may be coupled via one or more networks, such as, for example,payment network101.Payment network101 may be used by one or more financial institutions and other entities to securely transmit data, such as data related to digital financial transactions.Payment network101 may be one or more of a wireless network, a wired network or any combination of wireless network and wired network. For example,network101 may include one or more of a fiber optics network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless LAN, a Global System for Mobile Communication (“GSM”), a Personal Communication Service (“PCS”), a Personal Area Network (“PAN”), D-AMPS, Wi-Fi, Fixed Wireless Data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g or any other wired or wireless network for transmitting and receiving a data signal. Network101 may comprise one or more secure communication channels for securely exchanging information betweenmobile device102,merchant107, and/orcard issuer104.
• In addition,network101 may include, without limitation, telephone lines, fiber optics, IEEE Ethernet 902.3, a wide area network (“WAN”), a local area network (“LAN”), or a global network such as the Internet. Alsonetwork101 may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. Network101 may further include one network, or any number of the exemplary types of networks mentioned above, operating as a stand-alone network or in cooperation with each other. Network101 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network101 may translate to or from other protocols to one or more protocols of network devices. Althoughnetwork101 is depicted as a single network, it should be appreciated that according to one or more embodiments,network101 may comprise a plurality of interconnected networks, such as, for example, the Internet, a service provider's network, a cable television network, corporate networks, and home networks.
• Cloud storage105 may be a virtualized data storage pool hosted by one or more third parties,card issuer104,payment network101, and/ormerchant107.Cloud storage105 may comprise one or more distributed servers and may be used to store data objects for access bymobile device102,card issuer104, and/orpayment network101.Cloud storage105 may be accessed through a web service application programming interface (API), a cloud storage gateway or through a web-based user interface.Cloud storage105 may communicate data withissuer104 andmobile device102 using one or more networks. The networks may be different frompayment network101. The networks may be secured. The networks may be wireless.
• Smart card103 may be any pocket-sized card with one or more embedded integrated circuits (IC). Smart cards may also be referred to as IC cards or chip cards.Smart card103 may be made of plastic and may provide identification, authentication, data storage and application processing.Smart card103 may exchange data, such as payment data, with merchant terminals or smart card-capable automatic teller machines (ATMs). Europay, Visa, and Mastercard (EMV) have developed standards that define the interaction at the physical, electrical, data and application levels between smart cards and smart card processing devices for financial transactions. There are standards based on ISO/IEC 7816 for contact cards, and standards based on ISO/IEC 14443 for contactless cards, which are both incorporated herein by reference.
• Smart card103 may be associated with one or more cardholders, such ascardholder106.Smart card103 may have been previously provided tocardholder106 byissuer104.Smart card103 may store one or more units of exchange to allowcardholder106 to purchase goods or services and have the value of the purchase deducted from a balance onsmart card103.Smart card103 may store one or more offline PINs associated withcardholder106. Before reading or writing data to the smart card at a smart card terminal, thecardholder106 must first enter the offline PIN on a keypad or touchscreen associated with the terminal.Smartcard103 may store biometric data associated withcardholder106, such as fingerprint data.Cardholder106 may usesmartcard103 to pay for goods and services.Smartcard103 may store account information forcardholder106.Smart card103 may be associated with one or more account numbers for accounts maintained byissuer104,merchant107, or by a third party entity.
• In various exemplary embodiments,cardholder106 may be any individual or entity that desires to conduct a financial transaction usingsmart card103. Also, a cardholder may be a computer system associated with or operated by such an individual or entity.
• Card issuer104 may be a financial institution. A financial institution may be, for example, a bank, other type of financial institution, including a credit card provider, for example, or any other entity that offers accounts to customers. An account may include any place, location, object, entity, or other mechanism for holding money or performing transactions in any form, including, without limitation, electronic form. An account may be, for example, a credit card account, a prepaid card account, stored value card account, debit card account, check card account, payroll card account, gift card account, prepaid credit card account, charge card account, checking account, rewards account, line of credit account, credit account, mobile device account, an account or service that links to an underlying payment account already described, or mobile commerce account. An account may or may not have an associated card, such as, for example, a credit card for a credit account or a debit card for a debit account. The account may enable payment using biometric authentication, or contactless based forms of authentication, such as QR codes or near-field communications. The account card may be associated or affiliated with one or more social networking sites, such as a co-branded credit card.
• Issuer104 may store data related tocardholder106 andsmartcard103.Issuer104 may store the offline PIN forsmart card103, the name, address, email address, phone number, a username, password, biometric information, and other data that uniquely identifiescardholder106.Card issuer104 may store an online PIN forsmart card103. The online PIN may be the same as the offline PIN. The online PIN may be different from the offline PIN in order to add an additional layer of security and fraud prevention.
• Cardholder106 may have one or more mobile devices, such asmobile device102.Mobile device102 may be, for example, a handheld PC, a phone, a smartphone, a PDA, a tablet computer, or other device.Mobile device102 may include Near Field Communication (NFC)capabilities102c, which may allow for communication with other devices by touching them together or bringing them into close proximity. Exemplary NFC standards include ISO/IEC 18092:2004, which defines communication modes for Near Field Communication Interface and Protocol (NFCIP-1). For example,mobile device102 may be configured using the Isis Mobile Wallet™ system, which is incorporated herein by reference. Other exemplary NFC standards include those created by the NFC Forum.
• Mobile device102 may include one or more software applications, such ascard application102a.Card application102amay be a software application that enablesmobile device102 to securely exchange data withsmart card103,payment network101,cloud storage105,merchant107, and/orcard issuer104.Card application102amay provide one or more graphical user interfaces forcardholder106 to pay for goods and services usingsmart card103, change the offline PIN forsmart card103, submit the offline or online PIN, biometric information, and/or other authorization information tosmart card103,payment network101,issuer104,merchant107, orcloud storage105. These processes will be described in greater detail in connection withFIGS. 2-4.
• Mobile device102 may be connected to one or more cardreaders102b.Cardreader102bmay be a hardware device that is configured to read data fromsmart card103 and write data tosmart card103.Cardholder106 may usecard application102ain conjunction withcardreader102bto read data fromsmart card103 and write data tosmart card103.Mobile device102 may also useNFC102cfor wireless or contactless data exchange withsmartcard103.
• Cardholder106 may usemobile device102 in conjunction withsmart card103 to purchase goods or services frommerchant107.Merchant107 may be a physical point of sale location.Merchant107 may be an online retailer of goods or services.Smart card103 may exchange payment information directly with one or more smart card terminals associated withmerchant107.Smart card103 may exchange payment information withmerchant107 throughcard application102aonmobile device102, and/or throughpayment network101. This process will be described in greater detail in connection withFIGS. 2-4.
• FIG. 5 depicts an example Point of Sale (PoS)device500.PoS device500 may provide the interface at what a customer or end user makes a payment to the merchant in exchange for goods or services.PoS device500 may include and/or cooperate with weighing scales, scanners, electronic and manual cash registers, electronic funds transfer at point of sale (EFTPOS) terminals, touch screens and any other wide variety of hardware and software available for use withPoS device500.PoS device500 may be a retail point of sale system and may include a cash register and/or cash register-like computer components to enable purchase transactions.PoS device500 also may be a hospitality point of sale system and include computerized systems incorporating registers, computers and peripheral equipment, usually on a computer network to be used in restaurant, hair salons, hotels or the like.PoS device500 may be a wireless point of sale device similar to a PoS device described herein or, for example a tablet computer that is configured to operate as a PoS device, including for example, software to cause the tablet computer to execute point of sale functionality and a card reader such as for example the Capital One® SparkPay card reader, the Square® reader, Intuit's® GoPayment reader, or the like.PoS device500 also may be a cloud-based point of sale system that can be deployed as software as a service, which can be accessed directly from the Internet using, for example, an Internet browser.
• Referring toFIG. 5, anexample PoS device500 is shown.PoS device500 may include acontroller502, areader interface504, adata interface506, asmartcard reader508, amagnetic stripe reader510, a near-field communications (NFC) reader512, apower manager514, akeypad516, anaudio interface518, a touchscreen/display controller520, and adisplay522. Also,PoS device500 may be coupled with, integrated into or otherwise connected with a cash register/retail enterprise system524.
• In various embodiments,Controller502 may be any controller or processor capable of controlling the operations ofPoS device500. For example,controller502 may be a Intel® 2nd Generation Core™ i3 or i5 or Pentium™ G850 processor or the like.Controller502 also may be a controller included in a personal computer, smartphone device, tablet PC or the like.
• Reader interface504 may provide an interface between the various reader devices associated withPoS device500 andPoS device500. For example,reader interface504 may provide an interface betweensmartcard reader508,magnetic stripe reader510, NFC reader512 andcontroller502. In various embodiments,reader interface504 may be a wired interface such as a USB, RS232 or RS485 interface and the like.Reader interface504 also may be a wireless interface and implement technologies such as Bluetooth, the 802.11(x) wireless specifications and the like.Reader interface504 may enable communication of information read by the various reader devices from the various reader devices toPoS device500 to enable transactions. For example,reader interface504 may enable communication of a credit or debit card number read by a reader device from that device toPoS device500. In various embodiments,reader interface504 may interface betweenPoS device500 and other devices that do not necessarily “read” information but instead receive information from other devices.
• Data interface506 may allowPoS device500 to pass communicate data throughout PoS device and with other devices including, for example, cash register/retail enterprise system524.Data interface506 may enablePoS device500 to integrate with various customer resource management (CRM) and/or enterprise resource management (ERP) systems.Data interface506 may include hardware, firmware and software that make aspects of data interface506 a wired interface.Data interface506 also may include hardware, firmware and software that make aspects of data interface506 a wireless interface. In various embodiments,data interface506 also enables communication between PoS device other devices.
• Smartcard reader508 may be any electronic data input device that reads data from a smart card.Smartcard reader508 may be capable of supplying an integrated circuit on the smart card with electricity and communicating with the smart card via protocols, thereby enabling read and write functions. In various embodiments,smartcard reader508 may enable reading from contact or contactless smart cards.Smartcard reader508 also may communicate using standard protocols including ISO/IEC 7816, ISO/IEC 14443 and/or the like or proprietary protocols.
• Magnetic stripe reader510 may be any electronic data input device that reads data from a magnetic stripe on a credit or debit card, for example. In various embodiments,magnetic stripe reader510 may include a magnetic reading head capable of reading information from a magnetic stripe.Magnetic stripe reader510 may be capable of reading, for example, cardholder information from tracks 1, 2, and 3 on magnetic cards. In various embodiments, track 1 may be written on a card with code known as DEC SIXBIT plus odd parity and the information on track 1 may be contained in several formats (e.g., ormat A, which may be reserved for proprietary use of the card issuer; format B; format C-M which may be reserved for us by ANSI subcommittee X3B10; and format N-Z, which may be available for use by individual card issuers). In various embodiments, track 2 may be written with a 5-bit scheme (4 data bits plus 1 parity). Track 3 may be unused on the magnetic stripe. In various embodiments, track 3 transmission channels may be used for transmitting dynamic data packet information to further enable enhanced token-based payments.
• NFC reader512 may be any electronic data input device that reads data from a NFC device. In an exemplary embodiment, NFC reader512 may enable Industry Standard NFC Payment Transmission. For example, the NFC reader512 may communicate with a NFC enabled device to enable two loop antennas to form an air-core transformer when placed near one another by using magnetic induction. NFC reader512 may operate at 13.56 MHz or any other acceptable frequency. Also, NFC reader512 may enable a passive communication mode, where an initiator device provides a carrier field, permitting answers by the target device via modulation of existing fields. Additionally, NFC reader512 also may enable an active communication mode by allowing alternate field generation by the initiator and target devices.
• In various embodiments, NFC reader512 may deactivate an RF field while awaiting data. NFC reader512 may receive communications containing Miller-type coding with varying modulations, including 100% modulation. NFC reader512 also may receive communications containing Manchester coding with varying modulations, including a modulation ratio of approximately 10%, for example. Additionally, NFC reader512 may be capable of receiving and transmitting data at the same time, as well as checking for potential collisions when the transmitted signal and received signal frequencies differ.
• NFC reader512 may be capable of utilizing standardized transmission protocols, for example but not by way of limitation, ISO/IEC 14443 A/B, ISO/IEC 18092, MiFare, FeliCa, tag/smartcard emulation, and the like. Also, NFC reader512 may be able to utilize transmission protocols and methods that are developed in the future using other frequencies or modes of transmission. NFC reader512 also may be backwards-compatible with existing payment techniques, such as, for example RFID. Also, NFC reader512 may support transmission requirements to meet new and evolving payment standards including internet based transmission triggered by NFC. In various embodiments, NFC reader512 may utilize MasterCard's® PayPass and/or Visa's® PayWave and/or American Express'® ExpressPay systems to enable transactions.
• Although not shown and described, other input devices and/or readers, such as for example, barcode readers and the like are contemplated.
• Power manager514 may be any microcontroller or integrated circuit that governs power functions ofPoS device500.Power manager514 may include, for example, firmware, software, memory, a CPU, a CPU, input/output functions, timers to measure intervals of time, as well as analog to digital converters to measure the voltages of the main battery or power source ofPoS device500. In various embodiments,Power manager514 remain active even whenPoS device500 is completely shut down, unused, and/or powered by the backup battery.Power manager514 may be responsible for coordinating many functions, including, for example, monitoring power connections and battery charges, charging batteries when necessary, controlling power to other integrated circuits withinPoS device500 and/or other peripherals and/or readers, shutting down unnecessary system components when they are left idle, controlling sleep and power functions (on and off), managing the interface for built-in keypad and trackpads, and/or regulating a real-time clock (RTC).
• Keypad516 may any input device that includes a set of buttons arranged, for example, in a block or pad and may bear digits, symbols and/or alphabetical letters.Keypad516 may be a hardware-based or mechanical-type keypad and/or implemented in software and displayed on, for example, a screen or touch screen to form a keypad.Keypad516 may receive input from a user that pushed or otherwise activates one or more buttons onkeypad516 to provide input.
• Audio interface518 may be any device capable of providing audio signals fromPoS device500. For example, audio interface may be a speaker or speakers that may produce audio signals. In various embodiments,audio interface518 may be integrated withinPoS device500.Audio interface518 also may include components that are external toPoS device500.
• Touchscreen/display control520 may be any device or controller that controls an electronic visual display. Touchscreen/display control520 may allow a user to interact withPoS device500 through simple or multi-touch gestures by touching a screen or display (e.g., display522). Touchscreen/display control520 may be configured to control any number of touchscreens, including, for example, resistive touchscreens, surface acoustic wave touchscreens, capacitive touchscreens, surface capacitance touchscreens, projected capacitance touchscreens, mutual capacitance touchscreens, self-capacitance touchscreens, infrared grid touchscreens, infrared acrylic projection touchscreens, optical touchscreens, touchscreens based on dispersive signal technology, acoustic pulse recognition touchscreens, and the like. In various embodiments, touchscreen/display control520 may receive inputs from the touchscreen and process the received inputs. Touchscreen/display control520 also may control the display onPoS device500, thereby providing the graphical user interface on a display to a user ofPoS device500.
• Display522 may be any display suitable for a PoS device. For example,display522 may be a TFT, LCD, LED or other display.Display522 also may be a touchscreen display that for example allows a user to interact withPoS device500 through simple or multi-touch gestures by touching a screen or display (e.g., display522).Display522 may include any number of touchscreens, including, for example, resistive touchscreens, surface acoustic wave touchscreens, capacitive touchscreens, surface capacitance touchscreens, projected capacitance touchscreens, mutual capacitance touchscreens, self-capacitance touchscreens, infrared grid touchscreens, infrared acrylic projection touchscreens, optical touchscreens, touchscreens based on dispersive signal technology, acoustic pulse recognition touchscreens, and the like. In various embodiments,522 may receive inputs from control gestures provided by a user.Display522 also may display images, thereby providing the graphical user interface to a user ofPoS device500.
• Cash register/retail enterprise system524 may me any device or devices that cooperate withPoS device500 to process transactions. Cash register/retail enterprise system524 may be coupled with other components ofPoS device500 via, for example, a data interface (e.g., data interface506) as illustrated inFIG. 5. Cash register/retail enterprise system524 also may be integrated intoPoS device500.
• In various embodiments, cash register/retail enterprise system524 may be a cash register. Example cash registers may include, for example, mechanical or electronic devices that calculate and record sales transactions. Cash registers also may include a cash drawer for storing cash and may be capable of printing receipts. Cash registers also may be connected to a network to enable payment transactions. Cash registers may include a numerical pad, QWERTY or custom keyboard, touch screen interface, or a combination of these input methods for a cashier to enter products and fees by hand and access information necessary to complete the sale.
• In various embodiments, cash register/retail enterprise system524 may comprise an retail enterprise system and/or a customer relationship management system.Retail enterprise system524 may enable retain enterprises to manage operations and performance across a retail operation.Retail enterprise system524 may be a stand-alone application in, for example, individual stores, or may be interconnected via a network.Retail enterprise system524 may include various point of sale capabilities, including the ability to, for example, customize and resize transaction screens, work with a “touch screen” graphical user interface, enter line items, automatically look up price (sales, quantity discount, promotional, price levels), automatically compute tax, VAT, look up quantity and item attribute, display item picture, extended description, and sub-descriptions, establish default shipping services, select shipping carrier and calculate shipping charges by weight/value, support multi-tender transactions, including cash, check, credit card, and debit card, accept food stamps, place transactions on hold and recall, perform voids and returns at POS, access online credit card authorizations and capture electronic signatures, integrate debit and credit card processing, ensure optional credit card discounts with address verification, support mix-and-match pricing structure, discount entire sale or selected items at time of sale, add customer account, track customer information, including total sales, number of visits, and last visit date. issue store credit, receive payment(s) for individual invoices, process deposits on orders, search by customer's ship-to address, create and process layaway, back orders, work orders, and sales quotes, credit items sold to selected sales reps, view daily sales graph at the PoS, view and print journals from any register, preview, search, and print journals by register, batch, and/or receipt number, print X, Z, and ZZ reports, print receipts, invoices, and pick tickets with logos/graphics, print kit components on receipt, reprint receipts, enter employee hours with an integrated time clock function, and/or sell when the network/server is down with an offline PoS mode.Retail enterprise system524 also may include inventory control and tracking capabilities, reporting tools, customer management capabilities, employee management tools, and may integrate with other accounting software.
• In various embodiments cash register/retail enterprise system524 may be a hospitality PoS. In such embodiments,retail enterprise system524 may include hospitality PoS software (e.g, Aloha PoS Restaurant software from NCR®, Micros® RES and Symphony software and the like), hospitality management software, and other hardware and software to facilitate hospitality operations.
• FIG. 6 illustrates anexample system600 and method for card authorization. As shown and described inFIG. 6, merchants, cardholders and financial institutions may be connected with a card association network to enable secure transactions and timely payments.System600 may include acardholder602,merchant604,Acquirer610, Association/Interchange616, andcard issuer618.
• Cardholder602 may be any card holder, including a credit card holder, debit card holder, stored value card holder and the like.Cardholder602 may possess a plastic card or carry a device (e.g., a mobile device) that securely stores card credentials and is capable of transmitting the card credentials to, for example, a PoS terminal (e.g., terminal606).Cardholder602 may interact with a merchant (e.g., merchant604) by presenting a card or card credentials to a terminal (e.g., terminal606).
• Merchant604 may be any merchant that accepts payment from a cardholder, for example.Merchant604 may be any retailer, service provider, business entity, or individual that accepts payments.Merchant604 may include software, firmware and hardware for accepting and/or processing payments. For example, as illustrated inFIG. 6,merchant604 may include a terminal606 and apayment gateway608.Terminal606 andpayment gateway608 may comprise the physical or virtual device(s) used bymerchant604 to communicate information to front-end processor612 ofacquirer610.Terminal606 may be similar to PoS system [Y00] as shown and described in Figure Y. In various embodiments,payment gateway608 may be an e-commerce application service provider service that authorizes payments for merchants. As such,payment gateway608 may be a virtual equivalent of a PoS terminal and interface with, for example, a billing system ofmerchant604 and pass data to front-end processor612 ofacquirer610.
• Acquirer610 may be, for example, a financial institution or bank, that holds the contract for providing payment processing services tomerchant604.Merchant604 may have a merchant account that may serve as a contract under whichAcquirer610 may extend a line of credit to a merchant who wishes to accept, for example, credit card transactions. As shown inFIG. 6,Acquirer610 may be associated with front-end processor612 and back-end processor614.
• In various examples, front-end processor612 may be a platform thatcard terminal606 and/orpayment gateway608 communicate with when approving a transaction. Front-end processor612 may include hardware, firmware, and software to process transactions. Front-end processor612 may be responsible for the authorization and capture portion of credit card transaction. Front-end processor612 also may include additional front-end platform interconnections to support, for example, ACH and debit transactions.
• Backend processor614 may be a platform that takes captured transactions from front-end processor612 and settles them through an Interchange system (e.g., association/interchange616). Back-end processor614 may generate, for example, daily ACH files for merchant settlement. Back-end processor614 also may handle chargeback handling, retrieval request and monthly statements.
• Association/interchange616 may be the consumer payment system whose members are the financial institutions that issue payment cards and/or sign merchant to accept payment cards. Example associations/interchanges616 may include, Visa®, MasterCard®, and AmericanExpress®. Association/interchange616 may include one or more computer systems and networks to process transactions.
• Issuer618 may be a financial institution that issues payment cards and maintains a contract with cardholders for repayment. In various embodiments,issuer618 may issue credit, debit, and/or stored value cards, for example. Example issuers may include, Capital One, Bank of America, Citibank, and the like.
• In various embodiments, processing a payment card transaction may involves two stages: (1) authorization and (2) clearing and settlement. Authorization may refer to an electronic request that is sent through various parties to either approve or decline the transaction. Clearing and Settlement may refer to settlement of the parties' settle accounts to enable the parties to get paid.
• During authorization,cardholder602 may present payment card as payment (601A) atmerchant604PoS terminal606, for example.Merchant604 may enter card into a physical PoS terminal606 or submit a credit card transaction to apayment gateway608 on behalf ofcardholder602 via secure connection from a Web site, retail location, or a wireless device.
• Payment gateway608 may receive the secure transaction information (603A) and may pass the secure transaction information (605A) via a secure connection to the merchant acquirer's610 front-end processor612.
• Front-end processor612 may submit the transaction (607A) to association/interchange616 (e.g., a network of financial entities that communicate to manage the processing, clearing and settlement of credit card transactions). Association/interchange616 may route the transaction (609A) to the customer'sIssuer618.Issuer618 may approve or decline the transaction and passes the transaction results back (611A) through association/interchange616. Association/interchange then may relay the transaction results (613A) to front-end processor612.
• Front-end processor612 may relay the transaction results (615A) back to thepayment gateway608 and/orterminal606.Payment gateway608 may store the transaction results and sends them tomerchant604.Merchant604 may receive the authorization response and complete the transaction accordingly.
• During settlement,merchant604 may deposit the transaction receipt (621S) withacquirer610 via, for example, a settlement batch. Captured authorizations may be passed (623S) from front-end processor612 to the back-end processor614 for settlement. Back-end processor may generates ACH files for merchant settlement. Acquirer may submit settlement files (625S,627S) toIssuer618 for reimbursement via association/interchange616.Issuer618 may post the transaction and pay merchant604 (629S,631S,633S).
• FIG. 7 depicts anexample system700 that may enable a financial institution, for example, to provide network services to its customers. As shown inFIG. 7,system700 may include aclient device702, anetwork704, a front-end controlleddomain706, a back-end controlleddomain712, and abackend718. Front-end controlleddomain706 may include one ormore load balancers708 and one ormore web servers710. Back-end controlleddomain712 may include one ormore load balancers714 and one ormore application servers716.
• Client device702 may be a network-enabled computer: As referred to herein, a network-enabled computer may include, but is not limited to: e.g., any computer device, or communications device including, e.g., a server, a network appliance, a personal computer (PC), a workstation, a mobile device, a phone, a handheld PC, a personal digital assistant (PDA), a thin client, a fat client, an Internet browser, or other device. The one or more network-enabled computers of theexample system700 may execute one or more software applications to enable, for example, network communications.
• Client device702 also may be a mobile device: For example, a mobile device may include an iPhone, iPod, iPad from Apple® or any other mobile device running Apple's iOS operating system, any device running Google's Android® operating system, including for example, Google's wearable device, Google Glass, any device running Microsoft's Windows® Mobile operating system, and/or any other smartphone or like wearable mobile device.
• Network704 may be one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network. For example,network704 may include one or more of a fiber optics network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless LAN, a Global System for Mobile Communication (GSM), a Personal Communication Service (PCS), a Personal Area Networks, (PAN), D-AMPS, Wi-Fi, Fixed Wireless Data, IEEE 802.11b, 802.15.1, 802.11n, and 802.11g or any other wired or wireless network for transmitting and receiving a data signal.
• In addition,network704 may include, without limitation, telephone lines, fiber optics, IEEE Ethernet 902.3, a wide area network (WAN), a local area network (LAN) or a global network such as the Internet. Also,network704 may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof.Network704 may further include one network, or any number of example types of networks mentioned above, operating as a stand-alone network or in cooperation with each other.Network704 may utilize one or more protocols of one or more network elements to which they are communicatively couples.Network704 may translate to or from other protocols to one or more protocols of network devices. Althoughnetwork704 is depicted as a single network, it should be appreciated that according to one or more embodiments,network704 may comprise a plurality of interconnected networks, such as, for example, the Internet, a service provider's network, a cable television network, corporate networks, and home networks.
• Front-end controlleddomain706 may be implemented to to provide security forbackend718. Load balancer(s)708 may distribute workloads across multiple computing resources, such as, for example computers, a computer cluster, network links, central processing units or disk drives. In various embodiments, load balancer(s)710 may distribute workloads across, for example, web server(S)716 and/orbackend718 systems. Load balancing aims to optimize resource use, maximize throughput, minimize response time, and avoid overload of any one of the resources. Using multiple components with load balancing instead of a single component may increase reliability through redundancy. Load balancing is usually provided by dedicated software or hardware, such as a multilayer switch or a Domain Name System (DNS) server process.
• Load balancer(s)708 may include software that monitoring the port where external clients, such as, for example,client device702, connect to access various services of a financial institution, for example. Load balancer(s)708 may forward requests to one of theapplication servers716 and/orbackend718 servers, which may then reply to loadbalancer708. This may allow load balancer(s)708 to reply toclient device702 withoutclient device702 ever knowing about the internal separation of functions. It also may prevent client devices from contacting backend servers directly, which may have security benefits by hiding the structure of the internal network and preventing attacks onbackend718 or unrelated services running on other ports, for example.
• A variety of scheduling algorithms may be used by load balancer(s)708 to determine which backend server to send a request to. Simple algorithms may include, for example, random choice or round robin.Load balancers708 also may account for additional factors, such as a server's reported load, recent response times, up/down status (determined by a monitoring poll of some kind), number of active connections, geographic location, capabilities, or how much traffic it has recently been assigned.
• Load balancers708 may be implemented in hardware and/or software. Load balancer(s)708 may implement numerous features, including, without limitation: asymmetric loading; Priority activation: SSL Offload and Acceleration; Distributed Denial of Service (DDoS) attack protection; HTTP compression; TCP offloading; TCP buffering; direct server return; health checking; HTTP caching; content filtering; HTTP security; priority queuing; rate shaping; content-aware switching; client authentication; programmatic traffic manipulation; firewall; intrusion prevention systems.
• Web server(s)710 may include hardware (e.g., one or more computers) and/or software (e.g., one or more applications) that deliver web content that can be accessed by, for example a client device (e.g., client device702) through a network (e.g., network704), such as the Internet. In various examples, web servers, may deliver web pages, relating to, for example, online banking applications and the like, to clients (e.g., client device702). Web server(s)710 may use, for example, a hypertext transfer protocol (HTTP or sHTTP) to communicate withclient device702. The web pages delivered to client device may include, for example, HTML documents, which may include images, style sheets and scripts in addition to text content.
• A user agent, such as, for example, a web browser, web crawler, or native mobile application, may initiate communication by making a request for a specific resource using HTTP andweb server710 may respond with the content of that resource or an error message if unable to do so. The resource may be, for example a file on stored onbackend718. Web server(s)710 also may enable or facilitate receiving content fromclient device702 so client device A02 may be able to, for example, submit web forms, including uploading of files.
• Web server(s) also may support server-side scripting using, for example, Active Server Pages (ASP), PHP, or other scripting languages. Accordingly, the behavior of web server(s)710 can be scripted in separate files, while the actual server software remains unchanged.
• Load balancers714 may be similar to loadbalancers708 as described above.
• Application server(s)716 may include hardware and/or software that is dedicated to the efficient execution of procedures (e.g., programs, routines, scripts) for supporting its applied applications. Application server(s)716 may comprise one or more application server frameworks, including, for example, Java application servers (e.g., Java platform, Enterprise Edition (Java EE), the .NET framework from Microsoft®, PHP application servers, and the like). The various application server frameworks may contain a comprehensive service layer model. Also, application server(s)716 may act as a set of components accessible to, for example, a financial institution or otherentity implementing system700, through an API defined by the platform itself. For Web applications, these components may be performed in, for example, the same running environment as web server(s)710, andapplication servers716 may support the construction of dynamic pages. Application server(s)716 also may implement services, such as, for example, clustering, fail-over, and load-balancing. In various embodiments, where application server(s)716 are Java application servers, the web server(s)716 may behaves like an extended virtual machine for running applications, transparently handling connections to databases associated withbackend718 on one side, and, connections to the Web client (e.g., client device702) on the other.
• Backend718 may include hardware and/or software that enables the backend services of, for example, a financial institution or other entity that maintains a distributes system similar tosystem700. For example,backend718 may include, a system of record, online banking applications, a rewards platform, a payments platform, a lending platform, including the various services associated with, for example, auto and home lending platforms, a statement processing platform, one or more platforms that provide mobile services, one or more platforms that provide online services, a card provisioning platform, a general ledger system, and the like.Backend718 may be associated with various databases, including account databases that maintain, for example, customer account information, product databases that maintain information about products and services available to customers, content databases that store content associated with, for example, a financial institution, and the like.Backend718 also may be associated with one or more servers that enable the various services provided bysystem700.
• Referring now toFIG. 2,FIG. 2 is a flow chart illustrating a method for providingcard application102atomobile device102. Themethod200 shown inFIG. 2 can be executed or otherwise performed by one or more combinations of various systems. Themethod200 as described below may be carried out by the system for providing read/write interfaces between a smart card and a mobile device by way of a secured application on the mobile device, as shown inFIGS. 1 and 5-7, by way of example, and various elements of that system are referenced in explaining the method ofFIG. 2. Each block shown inFIG. 2 represents one or more processes, methods, or subroutines in theexemplary method200. Referring toFIG. 2, theexemplary method200 may begin atblock201.
• Inblock201,method200 may include receiving registration information. The registration information may be received byissuer104 frommobile device102. The registration information may include a device identifier associated with the mobile device, such as a mobile phone number and/or a MAC address of the mobile device and/or the like. The registration information may include a username, password, social security number, email address, biometric information, or other information that uniquely identifiescardholder106.Issuer104 may store the registration information in one or more databases and associate it withcardholder106 andmobile device102.Cardholder106 may provide the registration information toissuer104 viapayment network101 and/ornetwork704. In response to receiving the registration information,issuer104 may send one or more notifications, such as an email or text message, tomobile device102, requesting verification information. The verification information may be an email containing a hyperlink to a verification page hosted byissuer104. Thecardholder106 may click on the link and be directed to the verification page, which may complete the registration process, allowingmobile device102 to downloadcard application102a. Verification via text messaging also may be used.Method200 may proceed to block202.
• Atblock202,method200 may transmit a smart card management application tomobile device102. The application may be transmitted byissuer104, a financial institution, and/or the like. The application may becard application102a. For example, the application may be a native mobile banking application, a mobile optimized web interface and/or the like.Cardholder106 may download and installcard application102aonmobile device102.Card application102amay provide one or more graphical userinterfaces allowing cardholder106 to usermobile device102 to exchange data withissuer104 and/orsmart card103.Card application102amay promptcardholder106 to enter an online PIN forsmart card103. The online PIN may have been previously created byissuer104 and associated withsmart card103 andcardholder106 in one or more databases.Issuer104 may have provided the PIN over a secure channel, such aspayment network101, tomobile device102. The online PIN may have been provided in an email or text message. Cardholder may use a keypad or touchscreen onmobile device102 to enter the received online PIN or other unique password.Issuer104 and/or financial institution may receive the entered online PIN and compare it to the online PIN associated withsmart card103 andcardholder106. If the PINs match,issuer104 may verify thatmobile device102 is a trusted device, and thatcard application102ais enabled to perform management operations withsmart card103, for example, as will be described in connection withFIGS. 3 and 4.Method200 may proceed to block203.
• Inblock203,method200 may transmit updated scripts tomobile device102.Issuer104 may transmit updated scripts tomobile device102 usingpayment network101.Issuer104 may transmit updated scripts tomobile device102 using, for example,cloud storage105.Cardholder106 may usemobile device102 to checkcloud storage105 for updates. Also,cloud storage105 may automatically “push” updated scripts tomobile device102 as they are received fromissuer104. The scripts may be software modules that can be downloaded tomobile device102 and later invoked bycard application102ato perform one or more functions involvingsmart card103. Scripts may include an Update PIN script, which enables thecard application102ato update the offline PIN ofsmart card103 and/or a provision card script, which may provision an account number to the card. Scripts may include loyalty programs, reward programs, deals, or other offers fromissuer104,merchant107, or one or more third parties.
• For example, a Rewards script may enablecard application102 to store rewards points onsmart card103.Smart card103 may maintain a rewards points balance that cardholder106 can use to buy goods or services.
• FIG. 3 is a flow chart illustrating a method updating the offline PIN on a smart card, for example, using a mobile application on a mobile device. Themethod300 shown inFIG. 3 can be executed or otherwise performed by one or more combinations of various systems. Themethod300 as described below may be carried out by the system for providing read/write interfaces between a smart card and a mobile device by way of a secured application on the mobile device, as shown inFIGS. 1 and 5-7, by way of example, and various elements of that system are referenced in explaining the method ofFIG. 3. Each block shown inFIG. 3 represents one or more processes, methods, or subroutines in theexemplary method300. Referring toFIG. 3, theexemplary method300 may begin atblock301.
• Atblock301,cardholder106 may login to cardapplication102aonmobile device102.Cardholder106 may provide a username and/or password and/or other similar login credentials to securely accesscard application102a, using a touchscreen and/or keypad onmobile device102.Cardholder106 may provide biometric identification tomobile device102. Cardholder may select one or more scripts oncard application102a, such as the Update PIN script.Method300 may proceed to block302.
• At block302,cardholder106 may enter a new offline PIN forsmart card103 in response to a prompt frommobile device102. The new PIN may be a series of letters or numbers chosen bycardholder106.Cardholder106 may enter the new offline PIN using a touchscreen or keypad associated withmobile device102.Method300 may proceed to block303.
• Atblock303,card application102amay “package” the new offline PIN and transmit the new offline PIN toissuer104 orcloud storage105.Cloud storage105 may transmit the offline PIN toissuer104 viapayment network101.Cloud storage105 may transmit the new offline PIN toissuer104 via a different network thanpayment network101.Method300 may proceed to block304.
• Atblock304,Issuer104 may update the previously stored offline PIN based on the new offline PIN. The previously stored offline PIN may be associated withcardholder106 andsmart card103 in one or more databases associated withissuer104.Issuer104 may delete the previously stored offline PIN and replace it with the new offline PIN.Issuer104 may sync the new offline PIN with the stored online PIN.Method300 may proceed to block305.
• Atblock305,Issuer104 may transmit a validation request tomobile device102. The validation request may be first transmitted tocloud storage105, then pushed tomobile device102. The validation request may be transmitted tomobile device102 viapayment network101 via for example, an email message, text message, and or the like. Validation request may prompt thecardholder106 to provide validation information.Method300 may proceed to block306.
• Atblock306,card application102amay receive validation information from thecardholder106.Card application102amay prompt thecardholder106 to validate the new offline PIN.Card application102amay display the new offline PIN on the screen ofmobile device102 and request input from the cardholder106 (such as a button, check box, or other interactive display that receives input from cardholder106).Cardholder106 may confirm the accuracy of the new offline PIN.Cardholder106 may cancel the process or refuse to validate the new offline PIN. Ifcardholder106 does not validate the new offline PIN,method300 may end. In other embodiments,card application102amay request confirmation fromcardholder106 that he wishes to keep his old offline PIN.Method300 may proceed to block307.
• Atblock307, if the offline PIN is validated,card application102amay write the updated offline PIN tosmart card103.Card application102amay promptcardholder106 to “tap”mobile device102 tosmart card103. This may involve bringingsmart card103 in close physical proximity tomobile device102 or physically touchingsmart card103 withmobile device102. Doing this may allowcard application102ato transmit the new offline PIN tosmart card103 usingNFC102c. The updated offline PIN also may be transmitted by havingcardholder106 dipsmart card103 towardscard reader device102b.Card application102amay transmit one or more scripts that includes commands forsmart card103 to delete its current offline PIN and replace it with the new offline PIN insmart card103's memory.Smartcard103 may store the new offline PIN in response to receiving the one or more scripts or commands fromcard application102a. In this way, a cardholder can use his mobile device to update the PIN on his smart card without having to find a smart card capable terminal or ATM.
• FIG. 4 is a flow chart illustrating a method for authenticating a cardholder to a merchant using data read from a smart card using a mobile device. Themethod400 shown inFIG. 4 can be executed or otherwise performed by one or more combinations of various systems. Themethod400 as described below may be carried out by the system for providing read/write interfaces between a smart card and a mobile device by way of a secured application on the mobile device, as shown inFIG. 1, by way of example, and various elements of that system are referenced in explaining the method ofFIG. 4. Each block shown inFIG. 4 represents one or more processes, methods, or subroutines in theexemplary method400. Referring toFIG. 4, theexemplary method400 may begin atblock401.
• Atblock401,cardholder106 may attempt to purchase one or more goods or services frommerchant107.Merchant107 may be an online merchant.Cardholder106 may access the merchant's website (such as a clothing website), select several dress shirts to purchase, place them in an online shopping cart, and proceed to checkout. At checkout,merchant107 may promptcardholder106 for payment information.Cardholder106 may provide one or more account numbers or card numbers associated withSmart card103 in an attempt to purchase the shirts usingsmart card103.Merchant107 may receive this information and package it as authorization information.Method400 may proceed to block402.
• Atblock402,merchant107 may route authorization information toissuer104. The authorization information may include the account number associated withsmart card103 and/orcardholder106.Merchant107 may route the authorization information viapayment network101. In various embodiments, a merchant may route the authorization information in a manner as shown and described in, for example,FIG. 6. Referring back toFIG. 4,method400 may proceed to block403.
• Atblock403,issuer104 may promptcardholder106 for verification.Issuer104 may send one or more signals tomobile device102. These signals may causemobile device102 to invokecard application102a.Card application102amay promptcardholder106 for the offline PIN forsmart card103.Card application102amay cause one or more GUIs to be displayed on the screen ofmobile device102, and request that cardholder106 enter his offline PIN using a keypad or touchscreen formobile device102.Method400 may proceed to block404.
• Atblock404,card application102amay receive the cardholder's offline PIN and authenticate it withsmart card103.Cardholder106 may enter his offline PIN onmobile device102 in response to the prompt fromcard application102a.Card application102amay invoke one or more scripts, such as an Authenticate Cardholder script, to request the offline PIN stored onsmart card103. As with the Update PIN function described in connection withFIG. 3, invoking the Authenticate Cardholder script may causecard application102ato promptcardholder106 to tap or touchsmart card103 tomobile device102 in order thatcard application102amay read and/or receive the offline PIN fromsmart card103. The offline PIN onsmart card103 may be read usingNFC102c. In other embodiments,card application102amay promptcardholder106 to dipsmart card103 towardscardreader device102band read the offline PIN onsmart card103.
• Card application102amay read the offline PIN stored onsmart card103 and compare it to the PIN entered bycardholder106. In other embodiments,card application102amay receive biometric data stored onsmart card103 and compare it to biometric data input by cardholder106 (such as a fingerprint).Method400 may proceed to block405.
• Atblock405,mobile device102 may transmit the results of the comparison toissuer104. If the results indicate a match (for example, if the PIN entered by the cardholder onmobile device102 matches the offline PIN stored on smart card103),issuer104 may send an authorization signal tomerchant107, authorizing the transaction to move forward. If the comparison indicates no match, or insufficient match,issuer104 may send a signal tomerchant107, indicating the error, and promptingmerchant107 to request thatcardholder106 attempt to enter his PIN again. In other embodiments,merchant107 may end the transaction. Ifissuer104 authorizes the transaction,merchant107 may proceed to checkout and allow the cardholder to pay for the purchased shirts. In this way,card application102amay provide a way for a cardholder to use a smart card as a method of authentication when making online (non face-to-face or card not present) purchases. In various embodiments, blocks403-405 may occur during in conjunction with the authorization methods described inFIGS. 4 and 6.
• It is further noted that the software described herein maybe tangibly embodied in one of more physical media, such as, but not limited to, a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a hard drive, read only memory (ROM), random access memory (RAM), as well as other physical media capable of storing software, or combinations thereof. Moreover, the figures illustrate various components (e.g., servers, computers, processors, etc.) separately. The functions described as being performed at various components may be performed at other components, and the various components bay be combined or separated. Other modifications also may be made.
• In the preceding specification, various preferred embodiments have been described with references to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded as an illustrative rather than restrictive sense.

Claims (18)

What is claimed is:

1. A non-transitory, computer-readable medium storing instructions that, when executed by a processor of a mobile device, cause the processor to perform a method of transaction authentication comprising:

receiving a verification request from an issuer system, the verification request corresponding to a requested transaction associated with a financial account of a customer, the financial account associated with a smart card;

receiving an authentication factor inputted by the customer to the mobile device;

communicating with the smart card to compare the authentication factor with a stored authentication factor stored on the smart card;

based on a comparison of the received authentication factor and the stored authentication factor, creating instructions indicating whether the requested transaction is verified by the customer; and

outputting for transmission the instructions to the issuer system.

2. The non-transitory, computer-readable medium ofclaim 1, wherein the received authentication factor comprises secret information.

3. The non-transitory, computer-readable medium ofclaim 2, where the secret information is a personal identification number (PIN).

4. The non-transitory, computer-readable medium ofclaim 1, wherein the received authentication factor and the stored authentication factor each comprise biometric information associated with the customer.

5. The non-transitory, computer-readable medium ofclaim 1, wherein the instructions, when executed by the processor of the mobile device, cause the processor to perform a method further comprising:

receiving the stored authentication factor from the smart card; and

comparing the received authentication factor to the stored authentication factor.

6. The non-transitory, computer-readable medium ofclaim 5, wherein receiving the stored authentication factor comprises reading the stored authentication factor from the smart card.

7. The non-transitory, computer-readable medium ofclaim 1, wherein the instructions, when executed by the processor of the mobile device, cause the processor to perform a method further comprising:

displaying, via a screen of the mobile device, a prompt requesting that the customer initiate communication between the mobile device and the smart card.

8. The non-transitory, computer-readable medium ofclaim 7, wherein initiating communication between the mobile device and the smart card comprises touching the smart card to the mobile device.

9. The non-transitory, computer-readable medium ofclaim 7, wherein initiating communication between the mobile device and the smart card comprises moving the smart card toward the mobile device.

10. The non-transitory, computer-readable medium ofclaim 1, wherein the requested transaction is a card-not-present transaction request.

11. The non-transitory, computer-readable medium ofclaim 10, wherein the requested transaction is an online transaction.

12. A method for authorizing a payment, the method comprising:

receiving a payment authorization request from a merchant, the payment authorization request corresponding to a requested transaction and comprising an account identifier associated with a financial account of a customer, the financial account having a smart card associated therewith;

transmitting a verification request to a mobile device associated with the customer, the verification request comprising:

a prompt for a card application installed on the mobile device to communicate with the smart card to receive an authentication factor associated with the smart card;

receiving verification of the requested transaction from the mobile device based on the received authentication factor; and

approving or denying the transaction based on the received verification by transmitting an authorization signal to the merchant.

13. The method ofclaim 12, wherein the authentication factor comprises secret information.

14. The method ofclaim 13, wherein the secret information is a personal identification number (PIN).

15. The method ofclaim 12, wherein the authentication factor and the stored authentication factor each comprise biometric information associated with the customer.

16. The method ofclaim 12, wherein the requested transaction is a card-not-present transaction request.

17. The method ofclaim 16, wherein the requested transaction is an online transaction.

18. The method ofclaim 12, wherein the authentication factor is stored on the smart card.

Images