US20160012428A1

US20160012428A1 - Systems and methods for providing secure data transmission between networked computing systems

Info

Publication number: US20160012428A1
Application number: US14/796,512
Authority: US
Inventors: Perry Haldenby; John Jong Suk LEE; Paul Mon-Wah CHAN; Jenny Lin; Michael D. Cummins; Lauren Van Heerden; Prabaharan Sivashanmugam; Orin Del Vecchio; Gunalan Nadarajah
Original assignee: Toronto Dominion Bank
Current assignee: Toronto Dominion Bank
Priority date: 2014-07-11
Filing date: 2015-07-10
Publication date: 2016-01-14
Also published as: CA2896755C; CA2896755A1; US20160012419A1; CA2896763A1; US10671996B2; CA2896763C

Abstract

The disclosed embodiments include methods and systems that provide secure data transmission between networked computing systems by obfuscating sensitive customer account data with placeholder account data generated in real-time and without customer intervention. The disclosed embodiments may include a computerized device that monitors user input to detect an initiation of a purchase transaction at a merchant, and upon detection of the initiated purchase transaction, may obtain a placeholder account suitable for use in the purchase transaction and capable of masking a user's sensitive account information without user intervention. In some instances, a system of a financial institution may activate and fund the placeholder account in real time and in an amount consistent with a transaction amount of the purchase transaction. Devices consistent with the disclosed embodiments may request execution of the initiated purchase transaction in accordance with the activated and funded placeholder account.

Description

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional Patent Application No. 62/023,770, filed Jul. 11, 2014, which is expressly incorporated by reference to its entirety.

BACKGROUND

1. Technical Field
The present disclosure generally relates to computerized systems and methods that provide secure data transmission between networked computing systems, and more particularly to computerized systems and methods that mask sensitive user account data in transmitted data using placeholder account data generated in real-time and without user intervention.
2. Background
Retailers and financial institutions currently offer pre-paid account cards of various denominations (e.g., $10, $20, $50, or $100) for sale in an inactive state. For example, a buyer may select a $50 gift card, and provide a corresponding retailer with funds equivalent to the $50 denomination of the gift card. The retailer may then “activate” the purchased gift card, which may be loaded with $50 in equivalent spendable funds. The buyer or any other individual may use the activated card to purchase goods and services from participating retailers. Further, after purchasing such goods and services, the buyer may provide additional funds to the retailer, who may “re-load” the card with the additional funds to facilitate future purchases.
By way of example, the buyer may purchase multiple prepaid account cards to reserve until needed as last-minute gifts, to give as incentives, or for other purposes. In these instances, an initial investment of capital may be required to load the prepaid account cards at the time of purchase. Thus, customary methods of purchasing and/or re-loading such prepaid account cards require an initial investment of capital by the buyer (e.g., to provide an initial balance on the prepaid account cards), and the buyer's initial capital investment may be “tied up” capital until the buyer uses the account cards or provides the account cards as gifts. In addition, between the time of purchase and the time of use or gift, the buyer may be subject to undue risk of financial loss due to theft, or damage, or loss of the activated and fully funded prepaid cards. Further, fees associated with such prepaid account cards may reduce a balance available to the buyer, or alternatively, to a recipient of gift cards.
When a user initiates a purchase transaction using a credit card, debit card, or other payment instrument (e.g., online through a web page or at a point-of-sale (POS) device at a merchant), various networked computer systems and devices exchange sensitive account information (e.g., account numbers, expiration dates, etc.) to execute the initiated purchase transactions and to authorize payment. The exchanged sensitive date may, however, be intercepted by one or more malicious parties, who may replicate the intercepted information for use in authorized and/or fraudulent transactions. Existing techniques for reducing credit-card fraud (e.g., smart, chip, and or integrated circuit cards (e.g., EMV cards), NFC cards, etc.) are often incapable to preventing unauthorized access and replication by these malicious parties.
The disclosed embodiments provide methods and systems that address these and other concerns regarding unauthorized access and replication of data associated with conventional account instruments.

SUMMARY

The disclosed embodiments a device that includes a storage unit and at least one processor coupled to the storage unit. In one aspect, the storage unit may store instructions for controlling the at least one processor when executed by the at least one processor. The at least one processor may be operative with the instructions to monitor data input into the device by a user and to detect an initiation of a purchase transaction by the user. In some aspects, the purchase transaction may be associated with at least one merchant. The at least one processor may be operative with the instructions to obtain transaction information and payment information from the monitored data. The transaction information may, for example, identify the purchase transaction, and the payment information may identify a payment instrument involved in the purchase transaction. The at least one processor may be further operative with the instructions to receive, from a first system, data identifying a placeholder account associated with the user. In some aspects, the electronic multicard account may activated for use in the initiated purchase transaction. The at least one processor may also be operative with the instructions to modify at least a portion of the payment information to include portions of the received placeholder account data, and to perform operations that transmit, across a network to a second computer system associated with the merchant, a request to execute the initiated purchase transaction in accordance with the modified payment information.
The disclosed embodiments also provide a computer-implemented method that includes monitoring, by one or more processors, data input into the device by a user. The method may also detect, by one or more processors, an initiation of a purchase transaction by the user. The purchase transaction may, for example, be associated with at least one merchant. The method may also include obtaining, by one or more processors, transaction information and payment information from the monitored data. In some aspects, the transaction information may identify the purchase transaction, and the payment information identifying a payment instrument involved in the purchase transaction. Further, the method may include receiving, by one or more processors, and from a first system across a network, data identifying a placeholder account associated with the user. In one aspect, the electronic multicard account may be activated for use in the initiated purchase transaction. The method may also modify, by one or more processors, at least a portion of the payment information to include portions of the received placeholder account data, and perform, by one or more processors, operations that transmit, across the network to a second computer system associated with the merchant, a request to execute the initiated purchase transaction in accordance with the modified payment information.
In additional embodiments, a payment device includes an integrated circuit and storage unit coupled to the integrated circuit and configured to store payment information. In some aspects, the payment information may include at least one of an account number, expiration date, or card security code of a payment instrument associated with a user. The integrated circuit may be configured to detect an initiation of a purchase transaction involving the merchant. The initiated purchase transaction may be associated with a corresponding purchase amount. The integrated circuit may also receive, from a first system across a network, data identifying a placeholder account associated with the user. In one aspect, the purchase account being activated for use in the initiated purchase transaction. The integrated circuit may modify at least a portion of the stored payment information to include portions of the received placeholder account data, and provide, to the merchant device, at least a portion of the stored placeholder account data to execute the initiated purchase transaction.
The disclosed embodiments also include an apparatus that includes a storage device and at least one processor coupled to the storage device. The storage device may store instructions for controlling the at least one processor when executed by the at least one processor. The at least one processor may be operative with the instructions to receive a request to obtain data identifying a placeholder account associated with a user. In some aspects, the request may identify transaction information associated with an initiated purchase transaction, and the transaction information identifying a transaction amount and a merchant associated with the initiated purchase transaction. The at least one processor may also be operative with the instructions to identify an inactive placeholder account available to the user for use in the initiated purchase transaction, and perform operations that initiate a transfer of funds corresponding to the transaction amount from at least one financial services account of the user to the inactive placeholder account. The at least one processor may be operative with the instructions to generate placeholder account data corresponding to the funded placeholder account and store the placeholder account data in a data repository. In some aspects, the stored placeholder account data may include information identifying at least one of the merchant or the user, and information confirming an activation of the funded placeholder account for use in the initiated purchase transaction. The at least one processor may be further operative with the instructions to perform operations that transmit at least a portion of the stored placeholder account data to a device associated with the received request.
In certain example, exemplary objects and advantages of the disclosed embodiments may be set forth in part in the description that follows, and in part will be obvious from the description, or may be learned by practice of the disclosed embodiments. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments as claimed.
The accompanying drawings constitute a part of this specification. The drawings illustrate several embodiments of the present disclosure and, together with the description, serve to explain the principles of the disclosed embodiments as set forth in the accompanying claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an exemplary computing environment consistent with disclosed embodiments.

FIG. 2 depicts an exemplary computing system consistent with the disclosed embodiments.

FIG. 3 depicts a flowchart of an exemplary process for providing a pre-paid multicard consistent with disclosed embodiments.

FIG. 4 depicts another exemplary process for providing a pre-paid multicard consistent with disclosed embodiments.

FIGS. 5A and 5B illustrate an exemplary multicard consistent with disclosed embodiments.

FIG. 6 is a flowchart of an exemplary process for executing purchase transactions using electronic multicard account consistent with disclosed embodiments.

FIG. 7 is a flowchart of an exemplary process for funding and activating electronic multicard accounts consistent with disclosed embodiments.

DESCRIPTION OF THE EMBODIMENTS

Reference will now be made in detail to embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.
In this application, the use of the singular includes the plural unless specifically stated otherwise. In this application, the use of “or” means “and/or” unless stated otherwise. Furthermore, the use of the term “including,” as well as other forms such as “includes” and “included,” is not limiting. In addition, terms such as “element” or “component” encompass both elements and components comprising one unit, and elements and components that comprise more than one subunit, unless specifically stated otherwise.
FIG. 1 illustrates an exemplary computing environment 100 consistent with certain disclosed embodiments. In one aspect, computing environment 100 may include a client device 104, a system 140, a merchant system 150, and a communications network 120 connecting one or more of the components of environment 100. In disclosed embodiments, client device 104 may be configured to work in conjunction with system 140 and/or merchant system 150 to provide one or more configurable multicards 106.
In one embodiment, system 140 may be one or more computer systems configured to process and store information, and execute software instructions to perform one or more processes consistent with the disclosed embodiments. In certain exemplary embodiments, although not required, system 140 may be associated with a business entity 160. In certain embodiments, business entity 160 may be any type of business entity, such as a financial institution, a travel services business, a hotel or lodging business, or any other type of business entity. For example, system 140 may be a system associated with a commercial bank, an investment bank, a provider of a payment instrument or financial service accounts, etc. In some embodiments, a financial service account may be a check, savings, credit, debit, and/or a reward or loyalty account. In some aspects, a payment instrument may include, but is not limited to, a personal or corporate credit card, a debit card, a pre-paid credit or debit card, a pre-paid, general-purpose multicard, or check instruments. Business entity 160 may be an entity that provides accounts that may be used for purchasing goods and/or services, such as multicard accounts, which may, in certain embodiments, be used for purchases associated with one or more merchants (e.g., a merchant 170 associated with merchant system 150).
In certain embodiments, a multicard account may be an account that is associated with a multicard (e.g., a prepaid, general-purpose multicard). A multicard may be a general-purpose instrument that a user may carry and/or use to make purchases. For example, a multicard may be a plastic card (e.g., the form of a credit card instrument) that may include tangible computer-readable media (e.g., a magnetic strip configured to store information) consistent with known financial instruments (e.g., credit cards, debit cards, etc.) A multicard may also be a smart card that may include one or more memories and/or one or more processing devices (e.g., processor(s), electronic circuitry, logic, etc.). A multicard account may be configured as a financial account (e.g., a credit card account) that, for example, system 140 may be configured to create, store, and maintain, consistent with disclosed embodiments. While examples of a multicard are disclosed in connection with financial service accounts (e.g., accounts that may be used for purchases), the disclosed embodiments are not so limited. In certain aspects, a multicard may relate to other types of accounts, such as transportation credits (e.g., a subway fare card), service credit (e.g., landscaping services, personal grooming services, etc.), utility services credits (e.g., prepaid utility service amounts, hours of use, etc.), and other types of services. Thus, in certain aspects, a multicard (e.g., multicard 106) may be a credit-card sized plastic card, a paper card, an electronic multicard provided as part of an e-wallet system, an image of the electronic card printed by a purchaser of the electronic card, etc. It is contemplated that multicard 106 may take other physical or electronic forms, as understood by those skilled in the art.
In certain embodiments, system 140 may include one or more servers 142 and one or more data storages, such as data repository 144. Server 142 may be, for example, a computing system that processes, among other things, transactions, and thus for exemplary purposes only, may be configured to operate as a transaction server. A transaction may include financial transactions (e.g., purchase transactions, banking transactions, etc.), or other forms of transactions (e.g., access to a location, check out transactions of material, products, goods, etc., such as library transactions, etc.).
In one embodiment, server 142 may include a front end 142A, and a back end 142B in communication with front end 142A, although the configuration of server 142 is not limited to such configurations. In one example, front end 142A and back end 142B of server 142 may be incorporated into a single computer, a single server, or any additional or alternate computing device apparent to one or skill in the art. In other embodiments, front end 142A and backend 142B may be distributed computing devices. Further, in one embodiment, front end 142A may be one or more software programs, such as a software application (e.g., a web service) executed by one or more processors included in server 142. Similarly, backend 142B may be one or more software programs executed by one or more processors included in server 142. Server 142 is not limited to such configurations. In additional embodiments, front end 142A software can be executed by a server or computing system separate from a server or computing system that executes back end 142B.
Server 142 may be configured to execute software instructions to perform one or more processes consistent with the disclosed embodiments. In one embodiment, client device 104 may exchange information and parameters facilitating execution of one or more transactions associated with system 140. In one embodiment, where business entity 160 is a financial institution that provides financial service accounts and system 140 is configured to perform financial service account transaction processes, transactions may include, but are not limited to, a purchase or sale of goods or services, a transfer of funds between financial accounts (e.g., checking, savings, investment, etc.), a payment of a bill, a purchase or sale of a financial instrument or security, a deposit or withdrawal of funds, or an application for credit. In certain aspects, system 140 may provide one or more accounts associated with user 110 (or other user(s)) that may be used for purchases, or may have funds used to transfer to other accounts. In certain aspects, system 140 may provide one or more accounts that may fund a multicard account consistent with certain disclosed embodiments.
Server 142 may be implemented with one or more processors or computer-based systems, such as for example, a computer system 200 of FIG. 2).
Data repository 144 may be one or more data storages configured to store information consistent with the disclosed embodiments. In one aspect, data repository 144 may include customer data 144A, account data 144B, and transaction data 144C. In one aspect, customer data 144A may include one or more data records uniquely identifying one or more users 110 of business entity 160 associated with system 140. By way of example, a customer of a financial institution (e.g., business entity 160) may access a web page associated with system 140 (e.g., through a web server executed by front end 142A), and subsequently register for online banking services and provide data. The data may be linked to the customer and stored within customer data 144A.
In certain aspects, customer data 144A may include personal information associated with a user 110 (e.g., a name, home address, or date of birth), demographic information (e.g., educational level, income level), government-issued identifiers (e.g., driver's license numbers or Social Security numbers), employment information (e.g., employer name or address), and/or contact information (e.g., e-mail addresses, home numbers, work numbers, or mobile numbers). Customer data 144A may also include one or more authentication credentials associated with registered customers of the issuing bank. For example, the authentication credentials may include, but are not limited to, a user name, a user-specified password, a system-generated password, or an alphanumeric identification number (e.g., a PIN number) specified by the user or assigned by system 140. Other types of customer information may be stored and used by the disclosed embodiments.
Additionally or alternatively, customer data 144A may include information facilitating enhanced authentication techniques. For example, customer data 144A may store information identifying a security question associated with a customer (e.g., “What is your mother's maiden name?”) and the customer's registered answer to the security question. Customer data 144A may also include information identifying a particular security image or avatar selected by the user and displayed by the user during the authentication process.
Customer data 144A may include client device identification information identifying one or more client devices 104 registered to user 110. In one embodiment, the user may provide the client device identification information (e.g., a mobile telephone number provided by the user when registering for online banking services). Alternatively, server 142 may be configured to execute processes that automatically collect client device identification information (e.g., collecting an Internet Protocol (IP) address associated with the customer's smartphone).
In certain aspects, account data 144B may include account identification information identifying one or more accounts of customers of a financial institution (e.g., user 110 and business entity 160 associated with system 140). In one embodiment, account identification information may include financial service account information. For example, such service account information may include a checking account, a savings account, a revolving credit line, an account linked to a credit or debit card, a brokerage account, and any additional or alternate account provided or supported by the issuing bank. Information within account data 144B may also identify, for a single customer, one or more accounts associated with the customer and account data corresponding to the accounts (e.g., account, expiration date information, and/or card security codes, account balance information, and/or credit limit information).
Transaction data 144C may include information identifying one or more transactions involving one or more customers or accounts of business entity 160 associated with system 140. In one embodiment, such transactions may include, but are not limited to, purchase transactions (e.g., purchases of goods and/or services from electronic or physical retailers), financial service transactions (e.g., fund transfers), bill payment transactions (e.g., electronic bill payment transactions), financial instrument or security transactions (e.g., purchases of securities), deposits or withdrawals of funds, or applications for credit from the financial institution or other entity.
For example, system 140 may be configured to execute software instructions providing an online financial service portal enabling a user 110 (e.g., “customer”) to perform financial service type transactions. In one embodiment, the service portal may enable the customer to transfer funds between a first customer account to a second account, to fund one or more general-purpose multicards, to schedule automatic bill payment services (e.g., select an amount and periodic payment date for making payments to an identified payee from the customer's selected financial account), to purchase goods or services, and other known types of online financial service processes. Server 142 may, by way of example, generate a data record within transaction data 144C corresponding to the particular service the customer initiates, such as an initiated transfer of funds, and may populate the data record with information associated with the initiated transaction. As an example, transaction information for a funds transfer to fund a general-purpose multicard may include, but is not limited to, a unique identifier associated with the fund transfer transaction, a timestamp of the transaction, and transaction parameter information (e.g., a source account, a target account, a currency type, a transaction date, and an amount of transfer).
In certain embodiments, system 140 (or another system in communication with system 140) may provide an online portal to allow user 110 to configure one or more general-purpose multicards and associated multicard accounts in accordance with certain disclosed embodiments. For example, system 140 may provide a web site that user 110 may access via communication network 120 to configure and customize a general-purpose multicard for use by user 110 or another user, consistent with disclosed embodiments. In this regard, system 140 may include known computing components and infrastructures used to provide the web site and underlying web pages, interfaces, and communication technologies to allow user 110 to provide information via client device 104 (e.g., through a web browser, smart phone interfaces, etc.).
Merchant system 150 may be one or more computer systems associated with a business entity, e.g., a merchant 170, that provides products and/or services. In one example, merchant 170 may represent a retailer having one or more physical retail locations disposed within a geographic area (e.g., a “physical retailer”). Merchant 170 may also represent a retailer that provides electronic or e-commerce type retail services. In one example, merchant system 150 may be associated with an electronic or an e-commerce retailer 170 that interacts with consumers through corresponding web interfaces, digital wallets, or retailer-specific application programs (e.g., mobile “apps”). In one embodiment, one or more client devices 104 can exchange information with merchant system 150 to purchase one or more goods and/or services using various payment instruments, such as funded and activated multicards. Merchant system 150 may exchange information with payment network 130 and system 140 over communications network 120 to obtain authorization for such purchase instruments. For example, user 110 may perform a mobile payment using client device 104 and point-of-sale (POS) device using known mobile payment processes and components.
In other embodiments, merchant 170 may represent any additional or alternate type of business entity that may receive and use transaction accounts to perform some service or provide some product. For example, merchant 170 may represent a business, a place of work, a government agency, an academic institution, a library, a travel services business (e.g., passport or airport security identification services business), car rental agency, etc. In such embodiments, depending on the nature of the business provided, system 150 may use different devices, and/or require different authorization levels, to receive the transaction account from client device 104 (e.g., a reader device in place of POS 156).
In one embodiment, merchant system 150 may include a merchant server 152, a data repository 154, and point-of-sale (POS) module 156. Although not depicted in FIG. 1, merchant server 152 may include a front end and a back end disposed in communication with the front end as previously discussed. In certain aspects, the front and back ends may be incorporated into a hardware unit (e.g., a single computer, a single server, or any additional or alternate computing device apparent to one skilled in the art). In other embodiments, the front end may be a software application, such as a web service, executing on merchant server 152. Merchant server 152 is not limited to such configurations, however, and the front end may be executed on any computer or server separate from the back end.
In one embodiment, POS 156 may be one or more point-of-sale devices configured to perform known point-of-sale processes. POS module 156 may be disposed at a physical location in a merchant location associated with merchant system 150, such as a location where user 110 may provide payment for goods and/or services (e.g., at a cash register at the merchant) using, for example, client device 104. The disclosed embodiments are not limited to such physical POS modules, and in additional embodiments, POS module 156 may be a software module executed by merchant server 152, servers 142 or 160, or one or more of client devices 104. Further, POS 156 may represent a device communicatively coupled to one or more of client device 104 (e.g., a Square™) to provide mobile point-of-sale and payment services. POS 156 may also facilitate mobile payment systems through a mobile wallet technology such as, for example, Google Wallet™ or other known electronic or digital wallet technologies.
In some embodiments, one or more communications links may facilitate communications between POS 156, client device 104, system 140, and/or merchant server 152 or some other system that may be included in system environment 100. The communications link may include a separate communication link, such as, a wired cable connection, a wireless connection, a Bluetooth connection, and/or a near field communication (NFC) connection. Additionally or alternatively, POS 156 may communicate with client device 104, merchant server 152, and/or system 140 across communications network 120 using any of a number of communications protocols, such as hypertext transfer protocol (HTTP) and transmission control protocol/internet protocol (TCP/IP).
In one embodiment, merchant 170 may be associated with one or more point-of-sale devices configured to provide payment services and to perform known point of sale processes. Server 152 and/or POS 156 may be implemented with a processor or computer-based system (e.g., computer-system 200 of FIG. 2), may be configured to execute software instructions to transmit and receive data across network 120, or another communication link, using any of the communications protocols outlined herein. For example, POS 156 may directly communicate with network 120 through a corresponding interlace, and additionally or alternatively, may access communication network 120 via a server associated with the merchant (e.g., via communications link to merchant server 152 of FIG. 1).
Client device 104 may be one or more client devices. In certain embodiments, client device 104 may be associated with one or more users 110. In one example, user 110 may use client device 104 to provide input that may be used to perform one or more processes consistent with the disclosed embodiments. For example, user 110 may use client device 104 to perform a transaction involving an account associated with the user and provided, maintained, managed, and/or processed by system 140. In certain aspects, client device 104 can include, but is not limited to, a personal computer, a laptop computer, a tablet computer, a notebook computer, a hand-held computer, a personal digital assistant, a portable navigation device, a mobile phone, a wearable device, an embedded device, a smart phone, a set top box, third party portals, an optical disk player (e.g., a DVD player), a digital video recorder (DVR), and any additional or alternate computing device, and may be operable to transmit and receive data across network 120. Client device 104 may be implemented with one or more processors or computer-based systems, such as for example, computer-system 200 of FIG. 2. System 100 may include multiple client devices 104 that may be each associated with one or more users. For example, in addition to user 110 and client device 104, the disclosed embodiments may operate in connection with a second user that may operate a second client device that may communicate with one or more components of system 100.
Further, although computing environment 100 is illustrated in FIG. 1 with one client device 104, that the disclosed embodiments may include a plurality of client devices 104. Similarly, although computing environment 100 is illustrated in FIG. 1 with a single merchant system 150, system 140, and client device 104, the disclosed embodiments may include any number of additional components of system 100.
Communications network 120 may include one or more communication networks or medium of digital data communication. Examples of communication network 120 include a local area network (LAN), a wireless LAN, a RF network, a Near Field Communication (NFC) network, (e.g., a “WiFi” network), a wireless Metropolitan Area Network (MAN) connecting multiple wireless LANs, NFC communication link(s), and a wide area network (“WAN”), e.g., the Internet. Consistent with embodiments of the present disclosure, communications network 120 may include the Internet and any publicly accessible network or networks interconnected via one or more communication protocols, including, but not limited to, hypertext transfer protocol (HTTP) and transmission control protocol/internet protocol (TCP/1P). Communications protocols consistent with the disclosed embodiments also include protocols facilitating data transfer using radio frequency identification (RFID) communications and/or NFC. Moreover, communications network 120 may also include one or more mobile device networks, such as a GSM network or a PCS network, allowing client device 104 to send and receive data via applicable communications protocols, including those described herein.
In certain embodiments, one or more of server 142 and merchant server 152 may include a computer system (e.g., a personal computer, network computer, server, or mainframe computer) having one or more processors selectively activated or reconfigured by a computer program. In additional embodiments, one or more of server 142 and merchant server 152 may be incorporated as corresponding nodes in a distributed network, and additionally or alternatively, as corresponding networked servers in a cloud-computing environment. Furthermore, server 142 and/or merchant server 152 may communicate via network 120 with one or more additional servers (not shown), which facilitate the distribution of processes for parallel execution by the additional servers.
FIG. 2 illustrates an exemplary computer system 200 with which certain embodiments may be implemented. In certain embodiments, computer system 200 may reflect computer systems associated with system 140, server 142, system 150, server 152, and/or client device 104. In certain embodiments, computer system 200 may include one or more processors 202. Processor 202 may be connected to a communication infrastructure 206, such as a bus or communications network, e.g., a communications network 120 depicted in FIG. 1.
Computer system 200 may also include a main memory 208, for example, random access memory (RAM), and may include a secondary memory 210. Memory 208 may represent a tangible and non-transitory computer-readable medium having stored therein computer programs, sets of instructions, code, or data to be executed by processor 202. Secondary memory 210 may include, for example, a hard disk drive 212, and/or a removable storage drive 214, representing a magnetic tape drive, flash memory, an optical disk drive, CD/DVD drive, etc. The removable storage drive 214 may read from and/or write to a removable storage unit 218 in a well-known manner. Removable storage unit 218 may represent a magnetic tape, optical disk, or other storage medium that is read by and written to by removable storage drive 214. Removable storage unit 218 may represent a tangible and non-transitory computer-readable medium having stored therein computer programs, sets of instructions, code, or data to be executed by processor 202.
In alternate embodiments, secondary memory 210 may include other means for allowing computer programs or other program instructions to be loaded into computer system 200. Such means may include, for example, a removable storage unit 222 and an interface 220. An example of such means may include a removable memory chip (e.g., EPROM, RAM, ROM, DRAM, EEPROM, flash memory devices, or other volatile or non-volatile memory devices) and associated socket, or other removable storage units 222 and interfaces 220, which allow instructions and data to be transferred from the removable storage unit 222 to computer system 200.
Computer system 200 may also include one or more communications interfaces, such as communications interface 224. Communications interlace 224 allows software and data to be transferred between computer system 200 and external devices. Examples of communications interface 224 may include a modem, a network interface (e.g., an Ethernet card), a communications port, a PCMCIA slot and card, etc. Communications interface 224 may transfer software and data in the form of signals 226, which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface 224. These signals 226 may be provided to communications interface 224 via a communications path (i.e., channel 228). Channel 228 carries signals 226 and may be implemented using wire, cable, fiber optics, RF link, and/or other communications channels. In a disclosed embodiment, signals 226 comprise data packets sent to processor 202. Information representing processed packets can also be sent in the form of signals 226 from processor 202 through communications path 228.
In certain embodiments in connection with FIG. 2, the terms “storage device” and “storage medium” may refer to particular tangible storage devices including, but not limited to, main memory 208, secondary memory 210, a hard disk installed in hard disk drive 212, and removable storage units 218 and 222. Further, the term “computer-readable medium” may refer to devices including, but not limited to, a hard disk installed in hard disk drive 212, any combination of main memory 208 and secondary memory 210, and removable storage units 218 and 222, which may respectively provide computer programs and/or sets of instructions to processor 202 of computer system 200. Such computer programs and sets of instructions can be stored within one or more computer-readable media. Additionally or alternatively, computer programs and sets of instructions may also be received via communications interface 224 and stored on the one or more computer-readable media.
Such computer programs and instructions, when executed by processor 202, enable processor 202 to perform one or more processes consistent with the disclosed embodiments. Examples of program instructions include, for example, machine code, such as code produced by a compiler, and files containing a high-level code that can be executed by processor 202 using an interpreter.
Furthermore, the computer-implemented methods described herein can be implemented on a single processor of a computer system, such as processor 202 of system 200. In additional embodiments, however, these computer-implemented methods may be implemented using one or more processors within a single computer system, and additionally or alternatively, these computer-implemented methods may be implemented on one or more processors within separate computer systems linked via a network.
The disclosed embodiments include computer-implemented systems and methods for validating, funding, activating, and/or reloading one or more general-purpose multicards. As described herein, a multicard may represent a general-purpose physical or electronic payment instrument that an individual (e.g., user 110) may present to participating retailers (e.g., merchant 170) to purchase goods or services. Additionally or alternatively, user 110 may also present a multicard to a financial institution (e.g., business entity 140 of FIG. 1) to transfer funds from the multicard to an account held by user 110 at the financial institution. Further, in additional embodiments, user 110 may use a multicard to obtain cash from an automated teller machine (ATM) or a point-of-sale (POS) system associated with merchant 170 (e.g., POS 156). The disclosed embodiments are not limited to such exemplary applications, and in further embodiments, user 110 may use an activated and funded general purpose multicard as a cash substitute in any additional or alternate manner appropriate to conventional cash substitutes, such as credit cards, bank, cards, and debit cards.
In certain aspects, user 110 may purchase one or more multicards (e.g., general-purpose multicards) from a retailer in an unfunded, inactive state. For example, user 110 may purchase a single unfunded, inactive multicard from merchant 170 or from a financial institution (e.g., business entity 160 associated with system 140). Further, in some embodiments, user 110 may purchase a package of unfunded, inactive multicards (e.g., a package of ten multicards) from merchant 170 and/or business entity 160. In some aspects, user 110 may retain the purchased multicards for subsequent distribution as gifts, incentives, rewards, and/or reimbursements.
In an embodiment, an unfunded and inactive multicard may be associated with a multicard account having a zero account balance. Additionally or alternatively, a multicard may not be associated with or linked to a multicard account when in the unfunded, inactive state. By way of example, the unfunded and inactive multicard may not be usable for purchases of goods and services from retailers, merchants, and businesses (e.g., merchant 170 and/or business entity 160), and a “value” associated with the unfunded and inactive multicard may be limited to a manufacturing and packaging cost of the multicard. Merchant 170 and/or business entity 160 may thus offer the unfunded and inactive multicards for sale at relatively low prices (e.g., $1.00 per multicard card or $10.00 for a pack of three cards). Further, in certain aspects, should user 110 lose or have one or more of the purchased multicards stolen prior to activation and funding, the value lost by user 110 may be limited to the sale price of the lost or stolen multicards. User 110 may, for example, retain or store the multicards for significant time periods after purchase without concern for loss of funds.
In certain aspects, system 140, client device 104, and/or merchant system 150 may configured to validate, fund, and/or activate one or more of the purchased multicards. For example, as described above, user 110 may purchase a package of ten unfunded and inactive multicards for merchant 170, and may subsequently validate, fund, and activate the purchased multicards prior to distributing the multicards as gifts, incentives, rewards, and/or reimbursements. A particular type of unfunded and inactive multicard (e.g., credit, debit, etc.) may be determined upon purchase of the multicard from merchant 170. In certain aspects, the computer-implemented systems and methods described herein may enable user 110 to associate and fund the purchased multicards with corresponding multicard accounts and multicard account balance amounts (e.g., $100), and further, to specify currencies that denominate the multicard account balance amounts.
The funded multicards may, in some aspects, remain configured in an inactive state after initial funding. In such an inactive state, user 110 and/or any other user (e.g., a recipient of one of the funded multicards) may be unable to use the funded multicards for purchases of goods and services. In certain aspects, the inactive state of the funded multicards protects user 110's investment in the funded multicards against theft or loss.
In certain embodiments, the computer-implemented systems and methods described herein may enable user 110 and/or another user to request an activation of a previously funded multicard. For example, user 110 may purchase a package of inactive, unfunded multicards, may fund one or more of the multicards with a specified multicard account balance, and may activate the funded multicards prior to distribution to other users as gifts, rewards, incentives, and/or reimbursements. Alternatively, user 110 may fund one or more of the purchased multicards with a specified balance, and then distribute the funded multicards to the additional user in an inactive state. The additional user may, for example, leverage the computer-implemented systems and method described herein to activate the previously funded multicard or multicards received from user 110.
In some aspects, system 140 and/or client device 104 may be configured to perform one or more processes that enable the configuration, funding, and activation of multicard(s). For example, a user, regardless of whether they are a merchant by profession, may request to activate one or more multicards on their home personal computer, tablet, laptop, mobile phone, etc.
In certain embodiments, an activated and funded multicard may be used for purchases or services in a manner similar to a bankcard, check card, credit card, and/or debit card. By way of example, a user (e.g., user 110 or any additional user) may substitute the activated and funded multicard for cash payment when making a purchase of goods or services from a participating merchant (e.g., a merchant that accepts the activated multicard). In some aspects, the activated multicard may correspond to a payment instrument associated with a particular business entity that provides payment network services (e.g., Visa™, MasterCard™, etc.), and may include information identifying the payment network entity (e.g., a Visa™ symbol) on one or more faces of the multicard (e.g., multicard 106).
In other aspects, an activated and funded multicard may be associated with a particular merchant, and additionally or alternatively, a group of merchants disposed within a particular geographic region (e.g., a shopping mall) or associated with a particular retail industry (e.g., restaurants). For example, the activated and funded multicard may be used to purchase goods and services from the particular merchant and/or group of merchants. Further, in some embodiments, the particular merchant or groups of merchants may generate, store, and maintain multicard account information for activated and funded multicard. In other embodiments, system 140 may generate, store, and maintain such multicard account information.
FIG. 3 is a flowchart of an exemplary multicard configuration process 300, consistent with disclosed embodiments. In certain embodiments, client device 104 may perform one or more operations of exemplary process 300. In one example, client device 104 may be configured to authenticate a user, e.g., user 110, who may have obtained an inactivated multicard (e.g., in step 310). In some aspects, client device 104 may provide an interface that prompts the user to input authentication data (e.g., user identification data, passwords or other credentials). For example, the interface may be generated by an application program executed by client device 104 (e.g., a mobile application provided by system 140), or alternatively, the interface may be provided by a web page rendered for display by client device 104. Client device 104 may use the authentication data to authenticate user 110 with credential information such as account data 144B, customer data 144A, and/or other information that may be obtained from system 140 and stored in a local memory. In one aspect, client device 104 may have credential information stored locally, which may be updated periodically by one or more remote servers (e.g., server 142 or data repository 144). In some embodiments, authentication credentials are stored and maintained on one or more remote servers, for example, system 140. Accordingly, authenticating the user 110 may include executing software instructions that perform processes that transmit the authentication data to a receiving system (e.g., system 140), and receive an authentication response from the receiving system. For example, client device 104 may provide the user authentication data to system 140, which may be configured to perform authentication operations based on, for example, account data 144B, customer data 144A, and/or other information.
In certain embodiments, depending on the computing environment, the processor executing program instructions described herein may be located at client device 104, or on one or more processors remotely located in computing environment 100 (e.g., via system 140). Accordingly, it is understood that certain program instructions executed by any device in computing environment 100 (e.g., client device 104) may alternatively be executed via one or more processors located remotely in a distributed computing environment, and operating across communications network 120. For example, some or all aspects of process 300 may execute via one or more programs containing software instructions executed via one or more client device 104 processors. Client device 104 may be configured to execute software instructions stored locally in a computer memory, or may execute software instructions stored remotely, for example, at system 140 or data repository 144, yet execute the remotely stored instructions on a local processor.
In certain aspects, the disclosed embodiments may validate a previously purchased, received, and/or obtained multicard (e.g., in step 320). For example, client device 104 may be configured to execute software instructions that request information from user 110 that may be used to validate inactivated multicard 106. In one aspect, client device 104 may obtain multicard configuration information from user 110 that may be used to validate the multicard. In one aspect, client device 104 may perform processes to validate the multicard, or in other aspects, client device 104 may provide the obtained configuration information to system 140 (or another system) to perform the validation processes.
In one aspect, client device 104 may obtain unique multicard identification information associated with the multicard 106 (e.g., in step 320). The multicard identification information may be included on the multicard (e.g., printed on a surface of the multicard), may be provided with a receipt after purchase of the multicard, or provided electronically by the merchant, vendor, or financial institution who sold the card to user 112, system 140, or another system. In one embodiment, the validating system (e.g., system 140, client device 104, and/or another system) may perform a multicard validation process, which may include comparing the unique identification information obtained from user 110 to stored multicard data reflecting one or more validated multicards (e.g., multicards that were flagged as purchased, were distributed by the multicard provider, etc.). The validation process may generate a validation result, which may indicate that the multicard is valid for configuration and activation, or that the multicard is fraudulent or already activated/in use.
In certain embodiments, client device 104 may obtain the multicard identification information by user entry into an interface displayed by client device 104, by a card reader module operating in client device 104, or other input mechanisms. For example, client device 104 may be configured to prompt user 110 for multicard identification information, receive the input, and transmit the multicard information to one or more remote systems (e.g., system 140).
In some aspects, the unique multicard identification information may be displayed on a surface of multicard 106 in a human-readable form, such as a printed string of numbers, letters, symbols, etc. In some aspects, the unique identification information may be presented on a surface of multicard 106 in a machine-readable form, for example, as identification indicia printed on the multicard. Client device 104 may be configured to capture, via a digital image capturing device operatively connected to client device 104, an image of unique identification indicia printed on the inactivated multicard. The indicia may contain the unique identification information of the inactivated multicard in the form of machine-readable data, such as, for example, one-dimensional barcode data, or two-dimensional barcode data such as a micro PDF, PDF-417, data matrix, OR code, Aztec or Maxicode. The unique identification information may also be stored on the multicard via a magnetic strip storing numeric data. In other embodiments, for example, multicard 106 may be a smartcard containing an imbedded microprocessor, data storage, radio frequency identification (RFID) device and/or other data storage and processing components known in the art, and configured to display, send, or otherwise provide unique multicard identification information.
In certain embodiments, client device 104 may provide both unique identification information and user identification information as multicard configuration information to system 140. In other aspects, the user authentication information may also include unique identification information that uniquely identifies multicard 106. In still other aspects, user authentication information may be separate and distinct from unique multicard information, where one or more processors transmits unique multicard information to merchant system 150, for multicard validation, and one or more processors transmits user authentication information to system 140 for user account authentication. According to other embodiments, both the user authentication information and unique multicard information may be transmitted to the same receiving entity or system (e.g., client device 104 transmits both sets of data as configuration information to system 140, merchant system 150, or another system).
The disclosed embodiments may execute software that performs funding operations to fund multicard 106 (e.g., in step 330) In one embodiment, a multicard may be funded with a specified multicard account balance transferred or obtained from one or more financial services accounts associated with user 110. For example, client device 104 may perform processes that generate and provide an interface that requests input from user 110 to identify an amount of funds for the multicard account balance, the source account to draw the funds from, a currency denominating the multicard account balance (e.g., U.S. dollars, Euros, and/or Chinese yuan) and any other information that may be needed to perform electronic transfer operations. Client device 104 may receive the user input and provide the obtained fund information to system 140 (or another system) for funding the multicard in accordance with the configuration selections by user 110. For example, client device 104 may obtain input from user 110 that reflects the desire of user 110 to fund the multicard from a specified financial services account.
Client device 104 may receive a confirmation from system 140 (or other system) that the multicard 106 has been funded with the specified multicard account balance selected by user 110. In response, client device 104 may generate and provide a confirmation message that may be displayed in an interface provided by client device 104 (e.g., in step 340). In certain embodiments, client device 104 may provide the confirmation message to user 110 in other ways, such as email, or SMS text message, etc.
FIG. 4 is a flowchart of an exemplary multicard configuration process 400, consistent with disclosed embodiments. In one embodiment, one or more operations of process 400 may be performed by system 140. In one aspect, in response to a multicard validation and funding request initiated by user 110, a receiving system (e.g., system 140) may receive multicard configuration information, user authentication information, and/or validation data from client device 104, determine a validity and/or authenticity of user 110 and identified multicard, fund the multicard based on multicard configuration information, and generate and provide a confirmation back to the requesting device (e.g., client device 104 operated by user 110).
As an example, system 140 may receive, from client device 104, the user authentication information (e.g., in step 410). In other embodiments, system 140 may receive, from client device 104, the unique multicard information (e.g., in step 420), or both (e.g., in steps 410 and 420 combined). As described herein, and in certain embodiments, system 140 may be associated with business entity 160, and may control and maintain one or more financial services accounts associated with user 110 and multicard accounts associated with multicards. In other embodiments, system 140 may receive user authentication from client device 104 via communications network 120, validate a financial services account associated with user 110 for funding multicard 106, and transmit the funding information to another system (e.g., merchant system 150) for creating, funding, activating, etc. multicard(s) for user 110 or other users. In one embodiment, merchant system 150 may include one or more databases including a set of valid multicard identifications that may be used to validate a multicard, and including multicard account information of validated multicards. In other aspects, system 140 may maintain one or more databases including valid multicard identifications.
In additional embodiments, system 140 may receive funding data from client device 104 reflecting a multicard account balance amount specified by user 110 (e.g., in step 420). Further, in certain aspects, the funding data may specify a currency that denominates the multicard account balance amount. For example, the funding data may specify a currency of a nation in which user 110 purchased multicard 106, and additionally or alternatively, may indicate any of a number of currencies specified by user 110. For example, user 110 may purchase the multicard 106 in the United States, but may specify a multicard account balance amount denominated in Chinese yuan to facilitate planned travel to China. In some embodiments, the funding data may be provided as multicard configuration information from client device 104.
Based on the user authentication data and/or multicard configuration information (e.g., multicard validation information, funding data, etc.), system 140 may associate user 110 with the multicard 106 (e.g., in step 430). In general, associating user 110 with multicard 106 may include associating one or more financial services accounts held by user 110, with which the receiving entity may fund multicard 106.
In one aspect, system 140 may also generate and store a multicard account for multicard 106. In one embodiment, system 140 may generate the multicard account after validating multicard 106. In other aspects, the receiving system may generate the multicard account after receiving multicard configuration information, such as a multicard account balance. In other embodiments, the receiving system may generate and store the multicard account after determining a valid financial service account that is to be used to fund the multicard. In another aspect, the receiving system may generate a multicard account at another time, or in response to other conditions or information.
In another embodiment, system 140 may fund multicard 106 (e.g., in step 440). In one aspect, system 140 may fund multicard 106 by transferring funds from one or more determined financial service accounts to the generated multicard account. The funds may be an amount based on that identified in the multicard account balance specified by user 110 with the multicard configuration information provided by client device 104. In certain embodiments, system 140 may withdraw funds from one or more specified financial services accounts associated with user 110 and deposit the funds to a multicard account associated with multicard 106. In another embodiment, system 140 may fund multicard 106 by associating a financial services account held by user 110 with the generated multicard account, without transferring funds to the multicard account. For example, instead of maintaining an account balance for the multicard account, system 140 may be configured to perform processes that link the a financial service account of user 110 to the multicard 106 such that purchases used by the multicard 106, once activated, are funded from the financial service account up to a determined amount (e.g., the amount identified by user 110 when configuring the multicard). Further, in some aspects, the funds transferred to multicard 106 may be denominated in a currency of a nation in which user 110 purchased multicard 106, and additionally or alternatively, in a currency specified by user 110. Accordingly, a recipient of multicard 106 may use activated multicard 106 for purchases, where each purchase debits or withdraws the corresponding purchase amount from the associated financial service account until a predetermined limit has been reached.
In certain embodiments, system 140 may provide confirmation of the funded multicard 106 (e.g., in step 450). For example, system 140 may generate and provide information to client device 104 that confirms the establishment of an account associated with multicard 106 and having a balance as requested by user 110. The confirmation may include validation information, which includes, but is not limited to, information identifying user 110, information identifying an actual or intended recipient of multicard 106, financial services account information associated with the accounts used to fund the multicard account, a funding amount, a currency type, a type of multicard, date and time information, information identifying a valid multicard user, and any additional or alternate information appropriate to multicard 106, system 140, and client device 104.
The disclosed embodiments may also facilitate an activation of funded multicard 106 (e.g., as validated and funded using the exemplary processes described above). In one example, user 110, and additionally or alternatively, a different user (e.g., a recipient of the funded multicard from user 110), may request the activation of funded multicard 106. In one aspect, user 110 may request activation through a client device (e.g., client device 104). A client device 104 may generate an interface (e.g., a telephone call to an activation agent, a smart phone application, browser accessing a web page, etc.) that enables the user to request activation. The client device may provide the request to a receiving system (e.g., system 140, system 150, etc.) that maintains and manages the validation, funding, and/or activation of multicard 106. As described herein, the receiving system may, based on the request, perform processes that activate multicard 106 for use in purchases in accordance with one or more multicard parameters (e.g., multicard parameters established by user 110 or another activating user).
In the embodiments described above, system 140 may be configured to execute software instructions that perform the validation, funding, and activation steps of exemplary process 400. In additional embodiments, as described above, system 140 may receive user authentication from client device 104, may validate a financial services account associated with user 110 for funding multicard 106, and transmit the funding information to another system (e.g., merchant system 150) for fund and/or activate multicard 106. In other aspects, client device 104 may perform one or more of the steps of exemplary process 400, either alone or in conjunction with one or more of systems 140 and 150.
Further, in certain aspects, system 140 (or another system configured to validate and fund multicards) may receive information indicating a depletion of funds associated with activated multicard 106, and may subsequently execute software instructions to render multicard 106 inactive. For example, system 140 may configure multicard 106 in an inactive state when a multicard account balance of multicard 106 reaches zero, or alternatively, falls below a pre-determined threshold value (e.g., a value required to establish a “hold” on multicard 106 for a purchase, or a value specified by user 110 within the configuration information). System 140 may provide client device 104 a confirmation of the deactivation of multicard 106, and further, may provide client device 104 with various alerts of an impending deactivation, which client device 104 may render and present to user 110. Upon deactivation of multicard 106, user 110 will be unable to use multicard 106 for future purchases of goods and services until additional funds are added to inactivated multicard 106 through a “re-loading” process, as described below.
In certain aspects, user 110 may deplete a portion of the funds allocated to multicard 106 through purchases of goods and services at various physical and online retailers. For example, user 110, or alternatively, an individual acting on behalf of user 110 (e.g., a parent or an individual that purchased multicard 106) may access a corresponding graphical user interface (GUI) on client device 104 and request that multicard 106 be “re-loaded” with a specified amount of funds. For example, as described above, the GUI may be provided by a native application executed by client device 104 (e.g., a mobile application associated with and provided by system 140), and additionally or alternatively, through a web page provided by system 140 and rendered for display by client device 104. Alternatively, user 100 may leverage client device 104 to access a telephonic menu provided by system 140 (e.g., through a corresponding toll-free number displayed on a surface of multicard 106) and submit the request to reload multicard 106 with additional funds. Further, in other embodiments, user 110 may return multicard 100 to a financial institution or merchant from whom user 110 purchased multicard 106, and request that the financial institution or merchant re-load multicard 106 with the desired funds.
Upon receipt of a request to reload multicard 106 from client device 104, system 140 (and additionally or alternatively, client device 104 and system 150) may execute software instructions that implement the exemplary processes described above to authenticate user 110, re-validate multicard 106, reload multicard 106 with the provided funds, and re-activate multicard 106. By way of example, user 110 may reload multicard 106 for additional purchases at physical retailers and online retailers, and further, for deposit of funds into one or more accounts of user 110 (e.g., through a corresponding ATM).
As described above, computer-implemented systems and methods consistent with the disclosed embodiments may be configured to validate, fund, activate, and/or reload one or more general-purpose multicards previously purchased, obtained, and/or received by user 110. In some aspects, user 110 may purchase the general-purpose multicards in an unfunded state, and as such, user 110 need not make an initial capital investment to load the general-purpose multicards (and tie-up the initial capital investment) prior to use or distribution. Further, user 110's initial investment of capital may be limited to a nominal purchase price representative of manufacturing and packaging costs of the multicards. Thus, should user 110 lose or have one or more of the purchased multicards stolen prior to activation and funding, the value lost by user 110 may be limited to the sale price of the lost or stolen multicards, and a potential fraudulent use of the lost or stolen multicards may be reduced. Furthermore, and as outlined below, multicards consistent with the disclosed embodiments may include electronic multicards that user 110 may print “on-demand” for anticipated use or distribution, and additionally or alternatively, present to a merchant in electronic form via client device 104.
In some aspects, user 110 may purchase inactive multicards with an intention to validate, fund, activate, and subsequently present the multicards to as a gift or incentive to a recipient days, weeks, or months after purchase. For example, user 110 may purchase inactive multicards (e.g., a pack of three, five, or ten multicards) having a zero account balance from a merchant or a financial institution. By way of example, user 110 may access a corresponding graphical user interface (GUI) on client device 104, and may request that system 140 validate and fund the purchased multicards using one or more of the techniques described above in references to FIGS. 3 and 4 before providing the multicards to a recipient. Further, and as described herein, the recipient may, through a corresponding client device, request that system 140 activate the purchased multicards.
The recipient may use the activated and funded multicards to purchase goods and services from one or more physical retailers and online retailers, to deposit corresponding funds into an account held by the recipient, or to convert the loaded funds into cash at an ATM machine. Further, the recipient, and additionally or alternatively, user 110, may request, through a corresponding GUI on a client device (e.g., client device 104), that system 140 reload one or more of the multicards with additional funds using the processes described above. In some aspects, the disclosed embodiments may be configured to enable user 110 to purchase and hold multiple inactive multicards for future presentation without a substantial investment of capital at the time of purchase.
Further, in certain aspects, user 110 may be a parent, and user 110 may purchase inactive and unfunded multicards (e.g., a pack of ten multicards) from a retailer or a financial institution provide discrete allotments of funds to their children immediately or days, weeks or months later. For example, the parent may wish to provide funds to their children to purchase books and school supplies prior to the start of a current school term, and additionally or alternatively, funds to purchase lunches and snacks during the school day. In other aspects, the parent may provide a regular allowance to the children using funds loaded and subsequently reloaded to corresponding multicards.
For example, user 110 may, through client device 104, request that system 140 validate, load, and activate the purchased multicards using one or more of the techniques described above before providing the multicards to the children. The children may use the activated multicards to purchase goods and services, to deposit corresponding funds into one of their accounts, or to convert the loaded funds into cash at an ATM machine. Furthermore, the children and/or the parent may, through client device 104 (or other client device), request that system 140 reload one or more of the multicards with additional funds using the processes described above. The disclosed embodiments may, for example, be configured to enable the parent to provide funds to their children without obtaining and holding large amounts of cash, and further, enable the children to develop skills in managing funds and balancing purchase without the need to carry cash.
Further, in additional aspects, a parent may provide loaded multicards to children attending colleges, foreign study programs, or internships, and the children may activate the loaded multicards to access the funds using any of the techniques described above. For example, the disclosed embodiments may be configured to allow parents may provide children with discrete allotments of funds without obtaining and holding large amounts of cash, and further, in a manner that provides the children with freedom to access and spend the funds at will.
In other aspects, user 110 may purchase inactive and unfunded multicards (e.g., a pack of ten multicards) from a retailer or a financial institution in anticipation of domestic and/or international travel. In some embodiments, user 110 may access a graphical user interface (GUI) presented by client device 104 to request that system 140 validate, load, and activate one or more of the purchased multicards using the techniques described above prior to departing on a scheduled trip, or alternatively, upon arrival at a destination. For example, user 110 may, through client device 104, request that system 140 load the one or more inactive multicards with funds in a currency associated with the destination, and user 110 may then use the activated and loaded multicards to make purchases of goods and services while travelling at the destination. For example, user 110 may, through client device 104, request that system 140 validate, load, and/or activate the inactive multicards immediately after purchase, or at any time prior to or during travel (e.g., days, weeks, or months later). Further, one or more of user 110 or a recipient of the loaded and/or activated multicards may, through client device 104 (or a similar client device), request that system 140 reload the one or more of the multicards using any of the processes outlined above.
Further, in some aspects, as described above, user 110 (and additionally or alternatively, a recipient) may request that system 140 load and/or reload one or more of the multicards with funds denominated not only in their home currency, but also in the currency of the destination. For example, the disclosed embodiments may be configured to enable user 110 to purchase goods and services using the activated multicards without revealing any personal financial information (e.g., as would be required when user a personal credit card of user 110), and further, without the need to carry multiple currencies in what could be an unfamiliar environment.
In other aspects, user 110 may purchase one or more inactive multicards upon arrival at the destination. By way of example, system 140 (and additionally or alternatively, client device 104 and system 150) may validate and subsequently load the inactive multicards with a multicard account balance denominated in the currency of the destination, thus eliminating the need to time-consuming and costly currency conversion.
Further, for example, system 140 may receive a request from user 110 to load the inactive multicards with multicard account balances denominated in various currencies. For example, user 110 may plan visits to Japan, China, and South Korea in a single business trip. For example, and prior to travelling, user 110 may access a graphical user interface (GUI) at client device 104 to specify that a first subset of the inactive multicards be loaded with Japanese yen, a second subset of the inactive multicards be loaded with Chinese renminbi, and that a third subset of the inactive multicards be loaded with South Korean won. User 110 may, for example, travel between Japan, China, and South Korea without collecting and exchanging multiple national currencies.
Further, the disclosed embodiments may enable user 110 to load the inactive and unfunded multicards with foreign currencies at times prior to travel associated with favorable conversion rates. For example, system 140 may receive a request from user 110 may validate and load of the inactive and unfunded multicards with Japanese yen at a time prior to travel when the conversion rates between U.S. dollars and Japanese yen are especially favorable. User 110 may, for example, request that system 140 adaptively load one or more of the unfunded and inactive multicards at times that reduce losses of capital due to unfavorable currency conversion.
In some aspects, user 110 may use prepaid multicards to protect personal financial information during purchases of goods and services from online retailers. For example, and as described above, user 110 may purchase one or more inactive and unfunded multicards (e.g., a pack of ten multicards) from a merchant or a financial institution, and may request, through client device 103, that system 140 validate, load, and activate the purchased multicards using one or more of the techniques described above. In certain aspects, user 110 may use one or more of the activated multicards to make purchases of goods and services at electronic, web-based retailers without revealing personal financial information associated with a personal financial instrument, such as a personal credit or debit card. Further, for example, user 110 also maintains an ability to use the loaded and activated multicards to make purchases from one or more physical retailers, to deposit corresponding funds into an account held by user 110, or to convert the loaded funds into cash at an ATM machine. Additionally, user 110 may request, using client device 104, that system 140 reload one or more of the multicards with additional funds using the processes described above.
Further, in other aspects, a business entity (e.g., business entity 160) may rely on prepaid multicards to provide allowance, incentives, and gifts to employees, and additionally or alternatively, as a mechanism to cover or reimburse expenses incurred by the employees. For example, a representative of the business entity (e.g., a manager of a company, etc.) may purchase one or more inactive and unfunded multicards (e.g., a pack of ten multicards) from a merchant or a financial institution, and may, through client device 104, request that system 140 validate, load, and activate the purchased multicards using one or more of the techniques described above. For example, the manager may request that system 140 validate, load, and activate one or more of the purchased multicards immediately in response to a specific need, or may hold the purchased cards for days, weeks, or months to accommodate an expected future need.
In certain aspects, the manager may provide an employee with a loaded and activated multicard as an allowance, a gift, or to fund an anticipated expense. The employee may, for example, use the prepaid and activated multicards in a manner set forth by the business entity (e.g., to cover an anticipated expense), or alternatively, may use the prepaid and activated multicard to make purchases, deposit funds, or to obtain cash, as outlined above. Further, in some aspects, system 140 may reload the multicards with additional funds at the discretion or request of the purchasing business entity using any of the techniques described above.
In additional embodiments, a representative of a business entity may purchase one or more inactive and unfunded multicards (e.g., a pack of ten multicards) from a merchant or a financial institution, At the request of a customer of the business entity (e.g., user 110), the representative or other authorized individual may, through a client device, request that system 140 validate, load, and activate one or more of the purchased multicards using any of the techniques outlined above. The activated and funded multicards may, for example, include information identifying the business entity (e.g., a logo, etc.) or identifying a payment network associated with the prepaid multicard (e.g., Visa™). By way of example, the business entity may provide the activated and loaded multicard to user 110 for general use (e.g., for purchase of goods and services, to deposit corresponding funds into one of their accounts, or to convert the loaded funds into cash at an ATM machine). In certain aspects, representative of the business entity may, through the client device, request that system 140 reload one or more of the multicards using additional funds provided by user 110, and additionally or alternatively through a refund associated with returned goods. Further, in other aspects, the business entity may charge user 110 a fee for the convenience of reloading the one or more multicards, which the business entity may deduct from a multicard account balance associated with the reloaded multicard or multicards. In other aspects, user 110 may reload one or more of the multicards using any of the techniques outlined above.
In the embodiments described above, user 110 may purchase a package that includes multiple inactive multicards (e.g., ten cards). In certain aspects, user 110 may, through client device 104, request that system 140 validate, fund, and activate a single one of the multiple inactive cards, or alternatively, a subset of the packed inactive multicards, using the techniques described above. In some embodiments, the inactive and unfunded multicards within the purchased package may not be linked together, and as such, system 140 validate, fund, and activate the inactive and unfunded multicards individually or in any combination or grouping apparent to, appropriate to, and desired by user 110.
The disclosed embodiments may also be configured to allow inactivated or activated multicards to be customized visually. For example, in certain embodiments, a multicard may be formatted on one or more surfaces with text, graphics, images, etc. specified by user 110 or a user associated with an activated multicard (e.g., a recipient of the multicard from user 110). In one embodiment, one or more components of computing environment 100 may execute software instructions to provide for customization of multicard 106, e.g., through a corresponding interface presented to user 110 by client device 104. For example, client device 104, system 140, system 150, or another system may include a multicard customization module that may perform multicard customization operations consistent with disclosed embodiments. In some instances, the customization of a multicard may include printing indicia representing a payment network (e.g., Visa™), a logo of a retailer or merchant, and or one or more decorative elements on a surface of a multicard.
FIGS. 5A and 5B illustrate surfaces of an exemplary multicard 500, consistent with the disclosed embodiments. In FIGS. 5A and 5B, multicard 500 may corresponding to an unfunded inactive multicard, a funded inactive multicard, and additionally or alternatively, a fully funded and activated multicard, as described above. For example, multicard 500 may be a physical multicard resembling a network credit card (in size and shape) similar to the type issued by Visa™, Mastercard™, American Express™, Discover™ and/or the like. In some aspects, first surface 510 may include visual content 512 (e.g., a logo) corresponding to a payment network (e.g., Visa™, Mastercard™, American Express™, Discover™ and/or the like), a retailer or merchant, and or one or more decorative elements (e.g., a bow). Further, multicard 500 may be constructed of plastic, metal, paper, or some other material similar to that used to construct such network credit cards, and may be generally rectangular.
In additional embodiments, multicard 500 may correspond to an electronic multicard provided to client device 104 in electronic form (e.g., without a physical card purchased from a retailer). For example, system 140 may provide electronic multicard 500 to client device 104 as an encrypted file delivered to a recipient's electronic device via email, or via an internet link provided to the recipient. In one aspect, one account number or a group of account numbers may be purchased for a small nominal amount via online transaction. Similar to inactivated and unfunded physical multicards, the purchased account numbers remain unusable for any purpose until user 110 activates one or more of the accounts via the aforementioned methods and systems for multicard funding and activation. Accordingly, the activated electronic multicard may be presented by the recipient to a merchant for a purchase via a portable electronic device (e.g., client device 104). In some aspects, the merchant may scan a barcode displayed on the electronic multicard displayed on client device 104, or transfer the electronic multicard to a merchant device (e.g., POS 156) via RFID or by some other electronic method known in the art.
In other embodiments, user 110 may print an image of the electronic multicard (e.g., on a home printer communicating with client device 104 through a corresponding wired or wireless connection), and may present the printed image to a merchant to complete a purchase of a corresponding good or service. For example, the printed image of the electronic multicard may include an image of a machine-readable barcode and/or alphanumeric human-readable numbers that uniquely identify the electronic multicard and facilitate processing of a corresponding transaction.
Additionally, in some embodiments, system 140 may track the activation of electronic multicards associated with corresponding ones of the purchased group of account numbers. In certain aspects, when user 110 validates, loads, and activates greater than a threshold number of the purchased account numbers, system 140 may issue another set of account numbers to user 110 and charge user 110 the nominal amount via online transaction. In certain aspects, system 140 may issue the additional set of accounts numbers automatically and without intervention from user 110, or alternatively, may issue the additional set of account numbers upon receipt of confirmation from user 110 (e.g., through client device 104).
In certain aspects, system 140 ensures that user 110 maintains an adequate supply of account numbers, which user 110 may convert into corresponding electronic multicards, as described above. Further, in other embodiments, system 110 may issue an additional group of physical multicards to user 110 when user 110 validates, loads, and activates greater than a threshold number of the purchased account numbers (or a threshold number of previously purchased physical multicards). For example, system 110 may forward the additional group of physical multicards to a mailing address associated with a payment instrument provided by user 110 to purchase of the group of physical multicards.
FIG. 5B shows an exemplary second surface 520 of exemplary multicard 500. According to one embodiment, multicard surface 520 may include a machine-readable barcode 530. Additionally or alternatively, multicard surface 520 may contain alphanumeric human-readable numbers that uniquely identify the card. Multicard surface 520 may also include a magnetic strip 550 that may be readable by a magnetic card reader (not shown). According to some embodiments, multicard 500 may be configured for issuance to a specific recipient. In certain aspects, multicard surface 520 may, in addition to or alternatively, include an area 540 to allow the intended recipient to sign the face of the card. According to other embodiments, some or all of the described features of multicard 500 as shown in FIGS. 5A and 5B may be present, in any combination.
Using the disclosed embodiments, a system associated with a financial institution (e.g., system 140 of business entity 150) may generate and selectively fund one or more placeholder payment instruments (e.g., electronic multicard accounts) in an initiation of a payment process involving a payment instrument of a user (e.g., user 110). In certain aspects, a device associated with user 110 (e.g., client device 104), a point-of-sale (POS) device (e.g., POS device 156), a payment portal maintained by components of a merchant system (e.g., system 150), and/or a smart or integrated chip (IC) card may detect automatically an initiation of a payment transaction by user 110, and may further transmit a request to obtain a corresponding electronic multicard account from system 140 without intervention or direction from user 110. For example, one or more components of system 140 (e.g., server 142) may generate account information corresponding one or more of the placeholder payment instruments (e.g., electronic multicards) in anticipation of the received request, and additionally or alternatively, in real time upon receipt of the request. In further aspects, system 140 may perform operations, such as those described above, to load funds onto the established electronic multicards from one or more financial services accounts and/or payment instruments held and specified by user 110.
For example, server 142 may fund the electronic multicards by performing an electronic funds transfer from the specified financial services account and/or payment instrument of user 110 to an account associated with the established electronic multicards (e.g., data associated with which may be stored by system 140 within a portion of data repository 144). In certain aspects, system 140 may be configured to provide account information associated with the funded and activated electronic multicard accounts, may facilitate purchase transactions involving one or more retailers (e.g., as part of an electronic or digital wallet maintained for user 110 by client device 104, for transactions involving electronic or e-commerce retailers, etc.).
In certain aspects, and by initiating purchase transactions using one or more placeholder accounts (e.g., electronic multicard accounts), user 110 may reduce a likelihood that one or more malicious entities (e.g., hackers, etc.) fraudulently access information that uniquely identifies payment instruments and/or financial services accounts held by user 110. Further, in some instances, while the malicious entity could monitor network traffic to obtain information identifying the one or more electronic multicards, that malicious entity's unauthorized use of the one or more electric multicards would be limited to at most the funds loaded onto these multicards by user 110, thereby reducing user 110's exposure to the unauthorized use and/or fraudulent activity. Further, and as described below, the initiation and execution of purchase transactions using electronic multicard accounts and other placeholder accounts (which may be linked to a particular electronic or physical merchant) facilitate an efficient identification of a specific website or POS device representing a source of the fraudulent activity and thus reduce a post-activity tracking period.
The disclosed embodiments may enable system 140 to associate a plurality of electronic multicard accounts (and further, information facilitating the use of the electronic multicard accounts in one or more purchase transactions) with an existing financial services account of user 110, and further, to dynamically fund activate corresponding ones of the electronic multicard accounts in real time and in response to an initiation of a purchase transaction by user 110. For example, the disclosed embodiments may enable a device of user 110 (e.g., client device 104), a smart card or other physical payment instrument having an integrated circuit and held by user 110, and additionally or alternatively, a point-of-sale (POS) device disposed at a merchant location (e.g., POS device 156) to detect an initiation of a purchase transaction and to obtain information identifying the purchase transaction (e.g., a purchase amount, information identifying a merchant, a POS device, a web site, etc.) and a payment instrument (e.g., an account number, expiration date, CID number, etc. of user 110's credit or debit card), which may be provided to system 140 using any of the exemplary techniques described above.
In some aspects, system 140 may be configured to obtain the information identifying the purchase transaction and the payment instrument (e.g., from client device 104, the smart card, and/or POS device 156), and identify one of the electronic multicard accounts associated with user 110 and/or the payment instrument. System 140 may, for example, perform operations that load the identified multicard account with funds transferred from an account held by user 110 (e.g., and linked to the payment instrument) in an amount consistent with the purchase amount. System 140 may, in certain aspects, also generate one more data records in a portion of data repository 144 (e.g., in account data 144) that link together information identifying the funded electronic multicard account (e.g., account number, etc.), user 110, and/or the merchant (e.g., information identifying POS device 156, an IP address of a digital portal associated with the electronic retailer, etc.) to generate a data log of funded multicard accounts. In certain aspects, system 140 may access the data log to identify and account for funding returned to the electronic multicard accounts upon completion of corresponding purchase transactions. In other aspects, and in response to fraudulent activity involving the electronic multicard account, system 140 may access the data log to identify a specific website or POS device that represents a source of the fraudulent activity.
In the embodiments described below, system 40 may be configured to provide data identifying the activated and funded electronic multicard account to client device 104, the smart card, and/or POS device 156. For example, client device 104 may receive the information identifying the electronic multicard account, modify the payment instrument data by replacing portions of the payment instrument data with corresponding portions of the electronic multicard account data, and transmit the modified payment instrument data to a system associated with the electronic merchant (e.g., merchant system 150) in order to complete the purchase transaction.
The disclosed embodiments thus enable system 140 to generate, in real time, an electronic payment instrument (e.g., a funded electronic multicard and/or other placeholder account) capable of masking user 110's confidential account information during processing of a payment transaction. In some aspects, the establishment and funding of the placeholder account (e.g., the electronic multicard account), and the completion of the corresponding purchase transaction using the funded and activated placeholder account, may occur without the knowledge or direction of user 110.
In further aspects, the disclosed embodiments may also enable system 140 adaptively and selectively activate, fund, cancel, and re-activate placeholder accounts (e.g., electronic multicard accounts) to combat fraudulent activity by malicious parties and to manage an availability of unique multicard account numbers for assignment to individual purchase transactions. For example, and as described below, system 140 may activate and fund an electronic multicard account for use in a detected purchase transaction. In some aspects, however, the purchase transaction may not be executed by a corresponding merchant (e.g., hardware failures, declined transactions. lack of available products, etc.), and the activated and funded electronic multicard account may remain pendant in an unused state. System 140 may, in some embodiments, perform operations that detect the unused and funded electronic multicard account, cancel the unused and funded multicard, and generate for user 110 a gift card (e.g., a prepaid multicard) funded in an amount of the now-cancelled electronic multicard account using any of the exemplary techniques described above, The detection and cancellation of the unused and funded account may reduce a likelihood of fraudulent activity involving the unused and funded account, and may further mitigate potential shortages in multicard account numbers available for assignment to purchase transactions. In other embodiments, and to address an increase in purchase transactions requiring unique multicard accounts, system 1490 may modify a structure of the unique account numbers representative of the electronic accounts to increase a corresponding number set and/or to convert to a different positional numeral system, such as hexadecimal numbers.
FIG. 6 illustrates an exemplary process 600 for performing one or more purchase transactions using electronic multicard accounts, in accordance with the disclosed embodiments. In certain aspects, a device associated with a user (e.g., client device 104 of user 110) may perform one or more of the operations of exemplary process 600, as described below. For example, client device 104 may store one or more application programs (e.g., web browser applications or plug-ins, mobile applications provided by one or more business entities (e.g., a TD Bank™ mobile banking application), electronic wallet applications, etc.) that, upon execution by client device 104, cause client device 104 to perform the operations of exemplary process 600. In other aspects, however, a point-of-sale (POS) device associated with a merchant (e.g., POS device 156 of merchant 170) and additionally or alternatively, a smart card or other physical payment instrument including integrated circuit (IC) technologies may be perform all or a portion of the operations of exemplary process 600.
In one aspect, client device 104 may be configured to detect a purchase transaction initiated by user 110 (e.g., in step 602). By way of example, client device 104 may present, to user 110, a digital portal associated with one or more electronic retailers (e.g., a web page rendered for presentation by an executed browser, a graphical user interface (GUI) associated with an executed mobile application, etc.). In some instances, user 110 may access a web page associated with a particular merchant (e.g., as presented by client device 104), and may provide input to client device 104 that selects one or more goods and services for purchase. In response to user 110's selection, a server of other system associated with the merchant (e.g., server 152) may generate a purchase page that provides user 110 with an opportunity to identify a payment instrument to fund the purchase (e.g., a Visa™ debit card linked to a checking account held by user 110 at the financial institution, an American Express™ credit card held by user 110, etc.).
The purchase page may, in certain instances, be rendered for presentation to user 110 by client device 104, and user 110 may provide input to client device 104 that specifies an account number, expiration date, card security code, and/or billing information for the payment instrument. For example, user 110 may input a sixteen-digit account number, a four-digit expiration date, a three-digit card security code, and a billing address associated with user 110's Visa™ debit card to client device 104, and may click or touch a region of the presented purchase page (e.g., a presented icon, etc.) to confirm an intention to initiate the purchase using the input payment instrument data.
In certain aspects, client device 104 may dynamically monitor the provided input to detect an initiation of a purchase transaction by user 110. By way of example, client device 104 may monitor the input provided by user 110, and detect the initiation of the purchase transaction in step 602 after user 110 inputs a predetermined amount and/or type of data (e.g., an account number, expiration date, and card security code of user 110's Visa™ debit card). Additionally or alternatively, client device 104 may determine that user 110's confirmation of the input payment instrument data corresponds to the initiation of the purchase transaction. The disclosed embodiments are, however, not limited to these exemplary indicia of an initiated purchase transaction, and in further aspects, client device 104 may be configured to detect the initiated purchase transaction based on any additional or alternate indicia appropriate to the digital portal and client device 104 (e.g., gestural commands captured by an onboard digital camera, spoken commands, predetermined motions of client device 104, etc.).
In response to the detected purchase transaction (e.g., in step 602), client device 104 may perform operations that suspend the execution of the initiated purchase transaction and further, that obtain information characterizing the initiated purchase transaction and user 110's payment instrument (e.g., in step 604). For example, in step 604, one or more application programs executed by client device 104 (e.g., the mobile banking application, the electronic wallet application, the browser plug-in, etc.) may programmatically access input provided to the executed web browser by user 110 (e.g., through a corresponding API), and may extract data characterizing the purchase transaction and user 110's payment instrument. In some instances, transaction data consistent with the disclosed embodiments may identify a transaction amount and the merchant (e.g., a URL of the merchant web page, an IP address of server 152, a MAC address of server 152, etc.). In additional instances, payment data consistent with the disclosed embodiments may include an account number, expiration date, card security code, and/or billing information associated with the payment instrument. Further, client device 104 may, in step 604, establish a temporary data file (e.g., within a local data repository) structured to store the purchase transaction data and payment data, portions of which client device 104 may subsequent package and transmit to merchant server 152 as a request to execute the initiated (and suspended) purchase transaction.
In some aspects, client device 142 may transmit at least a portion of the obtained transaction data and payment data to system 140 as a request to obtain an electronic multicard account for use in the initiated purchase transaction (e.g., in step 606). For example, and as described below in reference to FIG. 7. system 140 may identify one of a plurality of previously generated multicards associated with the payment instrument specified by user 110 (e.g., user 110's Visa™ debit card). In response to the request, system 140 may perform operations that activate the identified electronic multicard account and transfer funds from an account associated with the Visa™ debit card (e.g., a checking account held by user 110) to the activated electronic multicard account.
FIG. 7 illustrates an exemplary process 700 for dynamically establishing and loading electronic multicards in response to initiated purchase transactions, in accordance with the disclosed embodiments. In certain aspects, a system associated with a financial institution (e.g., system 140 associated with business entity 150) may perform one or more of the operations of exemplary process 700, as described below.
In some aspects, system 140 may receive a request to dynamically fund and activate an electronic multicard account for use in a purchase transaction initiated by user 110 (e.g., in step 702). The received request may, in certain instances, include data that identifies the initiated purchase transaction (e.g., transaction data) and further, data that identifies a payment instrument selected by user 110 to fund the initiated purchase transaction (e.g., payment data). By way of example, transaction data consistent with the disclosed embodiments may include, but is not limited to, a transaction amount and a unique identifier of a merchant associated with the initiated purchase transaction (e.g., a URL of the merchant web page, an IP or MAC address associated with a merchant server (e.g., server 152 of FIG. 1), a device identifier of a point-of-sale (POS) system disposed at a merchant location, etc.). In further aspects, payment data consistent with the disclosed embodiments may include, but is not limited to, an account number, an expiration date, a card security code (e.g., a CCV2 or CID number), and/or a billing address associated with the payment instrument.
As described above, system 140 may be connected to a user device (e.g., client device 104) across a communications network (e.g., network 120). For example, and using any of the exemplary techniques outlined above, client device 104 may detect that user 110 initiated a purchase transaction from Amazon.com™ in an amount of $54.99 using a Visa™ debit card held by user 110. Based on the initiated payment transaction, and using any of the exemplary techniques described above, client device 104 may generate transaction data that identifies the transaction amount (i.e., $54.99) and the merchant (e.g., Amazon.com™), and further, payment data that identifies the account number, expiration date, card security code, and/or a billing address associated with user 110's Visa™ debit card. Client device 104 may, for instance, transmit the transaction data and payment data to system 140 as a request to obtain a dynamically funded and activated electronic multicard account for use in the initiated purchase transaction, which system 140 may receive in step 702 with or without explicit command or instructions from user 110. In some instances, system 140's determination to dynamically fund, activate, and/or use a multicard account may be based on one or more preferences, one or more fraud risk thresholds, and/or received user commands and/or instructions.
System 140 may, in some aspects, obtain purchase transaction data and/or payment instrument data corresponding to the initiated payment transaction from the received request (e.g., in step 704). For example, in step 704, system 140 may be configured to extract the transaction amount (e.g., $54,99) and/or the merchant information (e.g., Amazon.com™) from the received request as portions of the purchase transaction data. Additionally or alternatively, in step 704, system 140 may be further configured to extract the account number, expiration date, card security code, and/or a billing address associated with user 110's Visa™ debit card from the received request as portions of the payment instrument data. System 140 may also store the extracted purchase data and/or payment data within a corresponding portion of locally accessible data repository (e.g., data repository 144).
In one aspect, system 140 may obtain data associated with an electronic multicard account available for use in the initiated payment transaction (e.g., in step 706). By way example, and using any of the exemplary techniques described above, system 140 may perform operations that generate any number of unique electronic multicard accounts capable of association with at least one existing account held by user 110 at the financial institution. As described above, each of the unique electronic multicard accounts may be associated with a corresponding combination of account number, expiration date, and/or card security code. Further, in some instances, system 140 may be configured to store data identify the electronic multicard accounts (e.g., the corresponding combinations of account number, expiration date, and/or card security code) within a portion of data repository 144 (or another data repository or cold storage accessible to system 140 across network 120), along with data linking the electronic multicard accounts to user 110 and/or to existing accounts held by user 110.
System 140 may also be configured to perform operations that fund and activate the identified electronic multicard account for use in the initiated purchase transaction (e.g., in step 708). For example, and as described above, system 140 may identify a purchase amount associated with the purchase transaction (e.g., $54.99) and further, a payment instruments specified by user 110 for use in the initiated purchase transaction (e.g., user 110's Visa™ debit card). In one aspect, and based on stored account data accessible system 140 (e.g., within data repository 144), system 140 may determine that user 110's Visa™ debit card is linked to a checking account held by user 110 at the financial institution. In an embodiment, and using any of the exemplary techniques outlined above, system 140 may fund the identified electronic multicard account (e.g., in step 708) by performing operations that transfer funds equivalent to the identified transaction amount (e.g., $54.99) from user 110's checking account to the identified multicard amount. In some instances, upon funding and activation by system 140, the electronic multicard may be available for use in the initiated purchase transaction (e.g., as an alternative to user 110's Visa™ debit card that masks user 110's confidential information and reduces potential fraudulent activity due to sniffing, etc.). Further, in additional aspects, system 140 may impose temporal limits and/or usage limit that ensure the activated electronic multicard account is suitable for the single, initiated purchase transaction.
In step 710, system 140 may generate and store one or more data records (e.g., in data repository 144) that link the activated and funded electronic account to user 110 and additionally or alternatively, to a merchant associated with the initiated purchase transaction. For example, system 140 may generate a data record in data repository 144 having structured data fields that include the electronic multicard account number, expiration date, and card security code, the amount of funding (e.g., $54.00) and further, information identifying the corresponding merchant (e.g., Amazon.com™), user 110, and/or the payment instrument (e.g., user 110's Visa™ debit card). In certain aspects, by maintaining data records that link the funded and activated multicard to information identifying user 110 and the corresponding, system 140 may be capable of identifying and tracking sources of fraudulent activity involving the electronic multicard account.
In further aspects, data repository 144, and stored data identifying the funded and activated electronic multicard account, may be accessed by one or more back-end payment processing systems (not depicted in FIG. 1) that authorize payments using the electronic multicard account and other payment instruments. In other aspects, system 140 may be configured to store at least a portion of the data identifying the funded and activated electronic multicard account in one or more additional data repositories or cloud storages accessible to system 140 and the back-end payment processing systems (e.g., networked cloud-based storages, local data repositories of the back-end payment processing systems, etc.). As described below, the one or more back-end payment processing systems may access portions of the stored electronic multicard account data (e.g., within data repository 144 and/or within another network-accessible data repository or cloud storage), and may authorize one or more purchase transactions involving the electronic multicard account in accordance with guidelines and regulations established by the back-end payment processing systems and the financial institution.
In step 712, system 140 may transmit data identifying the activated and funded electronic multicard account across network 120 to one or more devices associated with the received request. In one aspect, the one or more devices associated with the received request may include a network-accessible device that detected the initiation of the purchase transaction by user 110 and generated and transmitted the request for the electronic multicard account to system 140 (e.g., client device 104 performing operations consistent with any of the exemplary techniques outlined above).
In other aspects, however, the devices associated with the received request may include a point-of-sale (POS) device (e.g., POS device 156 of FIG. 1) disposed at location of a merchant and capable of detecting receipt of payment instrument data from user 110 (e.g., in response to user 110 swiping a credit card through a magnetic reader, in response to user 110 disposing an EMV-compatible or smart card into proximity with POS device 156, in response to communications received from client device 112 during an digital wallet transaction, etc.). Further, and by way of example, the devices associated with the received request may include a connected smart card, EMV card, or other card having an integrated circuit capable of detecting an initiation of the purchase transaction and providing purchase transaction and payment instrument data to server 120. Additionally, one or more components of a merchant system (e.g., server 152 of system 150) may execute software instructions to generate and maintain a mobile- and/or web-based payment portal, which may receive requests for purchase transactions from various networked devices, and which may generate and transmit to system 140 requests for electronic multicard devices consistent with the disclsoed embodiments.
In other embodiments, in step 712, system 140 may be configured to transmit the electronic multicard account data not only to devices that generated and transmitted the initial request for electronic multicard, but also to devices and computer systems capable of executing the initiated purchase transaction and/or authorizing payment using the electronic multicard account. For example, system 140 may be configured to transmit, in step 712, portions of the electronic multicard account data to one or more components of merchant system 150 (e.g., server 152), which may process and submit the electronic multicard account data to the one or more back-end payment processing systems for payment authorization. Upon transmission of the electronic multicard account data to the one or more devices in step 712, exemplary process 700 is complete in step 714.
Referring back to FIG. 6, client device 104 may receive data associated with an electronic multicard account activated and funded by system 140 for use in the initiated purchase transaction (e.g., in step 608). For example, client device 104 may detect an initiated purchase transaction from Amazon.com™ in an amount of $54.99 and involving user 110's Visa™ debit card. In some aspects, client device 104 may receive data from system 140 in step 606 that identifies an electronic multicard account activated in real-time by system 140 and funded by an electronic funds transfer of $54.99 from user 110's checking account (e.g., which funds user 110's Visa™ debit card) to a corresponding electronic multicard account using any of the exemplary techniques outlined above.
In some aspects, system 140 may modify at least a portion of the obtained payment data to include corresponding potions of the electronic multicard account data (e.g., in step 610). For example, and as described above, the payment instrument information obtained by client device 104 may include, but is not limited to, an account number, an expiration date, a card security code, and/or a billing address associated with the payment instrument (e.g., the Visa™ debit card held by user 110). In certain aspects, user 110's account number, expiration date, and/or card security code may represent sensitive information particularly susceptible to unauthorized access by malicious parties during transmission between parties across network 120. In some instances, client device 104 may be configured (e.g., by an executed browser app or plug-in, mobile banking application, electronic wallet application, etc.) to replace portions of the sensitive payment instrument data with corresponding portions of the electronic multicard account data to obscure the sensitive information during transmission across network 120.
For instance, the electronic multicard account data may include, but is not limited to, a multicard account number, a multicard expiration date, and a multicard security code that facilitate use of the electronic multicard account in purchase transactions. In certain aspects, client device 104 may modify the payment data replace user 110's account number with the multicard account number, to replace the expiration data with the multicard expiration date, and further, to replace the card identification number with the multicard security code. By way of example, and as described above, client device 104 may store the payment instrument data and the transaction data (e.g., as input by user 110 and obtained by client device 104 in step 604, above) in a temporary data file in data repository 144, and client device may access the temporary data file and modify corresponding portions of the temporary data file to reflect the electronic multicard data.
In one aspect, and based on portions of the transaction data and the modified payment data, client device 104 generate a request to execute the initiated purchase transaction and transmit that generated request to a merchant system (e.g., system 150) for execution, approval, and subsequent processing (e.g., in step 612). For example, client device 104 may package the portions of purchase transaction data and the modified payment instrument data into a corresponding data structure, which may be transmitted to merchant system 156 using any of the exemplary techniques outlined above. In some instances, the included portions of the transaction data and the modified payment data may be specified by merchant system 150 and further, by one or more back-end payment processing systems associated with merchant system 150 (e.g., an issuer of user 110's Visa™ debit card). Further, in additional instances, the data structure associated with the generated request may conform to one or more requirements of merchant system 150, a mobile- or web-based portal associated with and maintained by merchant system 150 (e.g., through software instructions executed by one or more components of merchant system 150, such as server 152), and/or the purchase page, web site, and/or digital portal associated with merchant 150.
In some aspects, the mobile- or web-based portal associated with merchant system 150 may receive the request transmitted from client device 104, and may determine whether the received request conforms to the requirements established by merchant system 150 (e.g., security requirements, encryption requirements, content, etc.). If the received request conforms to the requirements established by merchant system 150, the mobile- or web-based portal may forward portions of the received request to merchant system 150 for payment processing. For example, merchant system 150 may be connected to one or more back-end payment processing systems (not depicted in FIG. 1), which may include, but are not limited to, system 140 associated with business entity 150 and/or systems associated with other issuers of credit cards and payment instruments. These back-end payment processing systems may, in some instances, be configured to receive the request from merchant system 150, process the request to extract the transaction data and the modified payment data, and based on stored data and various internal policies, determine whether to authorize payment using the electronic multicard account generated by system 140 for the initiated purchase transaction.
For example, as described above, system 140 may be configured to establish an electronic multicard account appropriate to user 110's Visa™ debit card, and to transfer funds from an account associated with user 110's Visa™ debit card to fund the established electronic multicard in the amount of the initiated purchase transaction (e.g., $54.99). Upon establishing and funding of the electronic multicard, system 140 may be configured to store data identifying the corresponding electronic multicard account (e.g., account number, expiration date, security code, etc.) and information confirming that the electronic multicard account is active and funded in the transaction amount within a data repository accessible to the back-end payment processing systems (e.g., in data repository 144 and/or other network access data repositories, such as cloud storage). In some aspects, the back-end payment processing systems may access the stored electronic multicard account data, and determine whether to determine whether to authorize payment using the electronic multicard account generated by system 140.
In certain instances, the back-end payment processing systems may be configured to authorize the requested payment in the amount of the initiated purchase transaction (e.g., the $54.99 purchase from Amazon.com™), and to perform additional back-end processing that clears the authorized payment and transfers funds from an account associated with the electronic multicard (e.g., as maintained by system 140) to that of the merchant (e.g., Amazon.com™). In additional aspects, the back-end payment processing systems may generate information confirming the successful authorization of the requested payment, which may be transmitted to merchant system 150 (and additionally or alternative, directly to client device 104) using any of the exemplar techniques described above.
In other instances, the back-end payment processing systems may decline to authorize the requested payment in the amount of the initiated purchase transaction (e.g., the $54.99 purchase from Amazon.com™). For example, the stored electronic multicard data may include information (e.g., generated by system 140 based on reported instances of fraudulent activity and/or various analytics) that flags the electronic multicard account for potential fraudulent activity. The back-end payment processing systems may, for example, generate information confirming the unsuccessful authorization of the requested payment, which may be transmitted to merchant system 150 (and additionally or alternative, directly to client device 104) using any of the exemplary techniques described above.
In some aspects, client device 104 may receive notification data (e.g., from merchant system 150 and/or from one or more of the back-end payment processing systems) indicative of a status of the requested purchase transaction and corresponding payment (e.g., in step 614), and client device 104 may be configured to process and render the received notification data for presentation to user 110 (e.g., in step 616). As described above, the presented notification data may indicate to user 110 that merchant system 150 successfully executed the requested purchase of the product from Amazon.com™ and the payment for that item using funds provided by user 110's Visa™ debit card. The presented notification data may further include information identifying the purchased product and information associated with the transaction, such as shipping and/or delivery information and a confirmation number. Alternatively, the presented notification data may indicate to user 110 that merchant system 150 was unable to successfully execute the requested purchase of the product from Amazon.com™, and may provide additional data surrounding the declined transaction (e.g., reasons for the declined transaction, etc.).
In one embodiment, client device 104 may render and present the received notification data within an application portal (e.g., a web page or GUI provided by a mobile application associated with merchant 170). For example, and as described above, user 110 may initiate the purchase of the product by entering payment instrument information into a purchase page provided by the merchant's web site, and client device 104 may be configured to present the received notification data within an additional page provided by the merchant's web site (e.g., a notification page) and additionally or alternatively, as a pop-up window within a window of the executed web browser. The disclosed embodiments are, however, not limited to these exemplary presented notifications, and in further aspects, notifications consistent with the disclosed embodiments may include, but are not limited to, an e-mail message, SMS text message, telephone message, pop notification, application notification (e.g., delivered to a mobile application running on the client device), or any other type of notice providing information to a client device. Upon rendering the notification data by client device 104 for presentation to user 110, exemplary process 600 is complete in step 618.
In certain aspects, the disclosed embodiments may enable user 110 to initiate a purchase transaction from an electronic or e-commerce merchant through a web page or other digital portal associated with the electronic or e-commerce merchant (e.g., presented to user 110 by client device 112). For example, and as described above, user 110 may provide, in response to a purchase page presented by client device 104, input to client device 104 identifying an account number, an expiration date, a card security code and/or billing information of a payment instrument. Client device 104 may, in some instances, execute application programs that detect user 110's input of the payment instrument information (and additionally or alternative, user 110's request to initiate a purchase transaction based on the input payment data), and based on the detected initiation of the payment transaction, transmit a request to system 140 for an electronic multicard account activated and funded in real time for use in the purchase transaction, as described above.
The disclosed embodiments are, however, not limited to processes that detect an initiation of a purchase transaction from an electronic or e-commerce merchant and through a corresponding web page or digital portal presented, e.g., by client device 104. In other embodiments, user 110 may hold one or more physical transaction cards, and user 110 may initiate a purchase transaction at a location of a merchant using the one or more physical transaction cards. For example, user 110 may swipe a Visa™ debit card a having a magnetic stripe through a corresponding reader at a point-of-sale (POS) terminal disposed at the merchant location (e.g., POS device 156 of FIG. 1). In other aspects, user 110 may hold a chip and/or integrated-circuit (IC) card compliant with the Europay MasterCard Visa (EMV) standard (e.g., an EMV transaction card), and user 110 may initiate the purchase transaction by physically inserting the EMV transaction card into POS device 156 and/or by bringing the EMV transaction card into proximity to POS device 156 (e.g., to transfer information using radio-frequency (RF) communication protocols, near-field communication (NFC) protocols, etc.). The disclosed embodiments are, however, not limited to these exemplary transaction cards and their interactions with POS device 156, and in other embodiments, user 110 may initiate a purchase transaction at the merchant's physical location using any additional or alternate payment instrument and interaction with POS device 156 (e.g., through data exchanged between client device 104 and POS device 156 that facilitates a purchase using a payment instrument within user 110's digital wallet).
In some embodiments, POS device 156 (or any other similar device associated with the merchant's physical location) may be configured to perform one or more of the exemplary processes described above to detect an initiation of a purchase transaction involving a payment instrument, request an activated and funded electronic multicard account associated with user 110 and/or the payment instrument from system 140, and that complete the initiated purchase transaction using the data identifying activated and funded electronic multicard account received from system 140. For example, POS device 156 may receive data identifying one or more products selected by user 110 purchase (e.g., based on a scanned bar and/or OR code, manual entry of an identifier, etc.), and further, may receive data identifying a payment instrument that user 110 intends to fund the purchase (e.g., from transaction card having a magnetic stripe, an EMV transaction card, etc.).
In some aspects, POS 156 may detect user 110's initiation of a transaction to purchase of the selected one or more products (e.g., in step 602), and may identify portions of the transaction data (e.g., a transaction amount, information identifying the merchant, etc.) and the payment data (e.g., an account number, expiration date, card security code, etc.) associated with a request to activate and fund an electronic multicard account for purchase transaction (e.g., in step 604). POS device 156 may, in some aspects, transmit the request to system 140 (e.g., in step 606), and system 140 may perform processes that fund and activate an electronic multicard account in the purchase amount using any of the exemplary techniques described above.
POS device 156 may receive data identifying the funded and activated electronic multicard account from system 140 (e.g., in step 608), and may modify portions of the payment data to reflect corresponding portions of the electronic multicard account data (e.g., in step 610). For example, and as described above, POS device 156 may temporarily store portions of the transaction data and the payment data in a local data repository, and may modify portions of the stored payment data to replace the account number, expiration date, and/or card-security code with a corresponding electronic multicard account number, expiration date, and/or card-security code. In some aspects, POS device 156 may transmit the modified payment data and additionally or alternatively, portions of the transaction data, to one or components of a merchant system (e.g., server 152) and/or back-end payment processing systems (e.g., in step 612). POS device 156 may also receive notifications of authorized and/or decline payments involving the electronic multicard account (e.g., in step 614), which may be presented to user 110 (e.g., in step 616). As described above, POS device 156 may perform the exemplary processes outlined above without knowledge or direct intervention of user 110.
Further, and as described above, physical transaction cards consistent with embodiments include chip cards and/or integrated-circuit (IC) cards compliant with the EMV standard (e.g., EMV transaction cards). In certain embodiments, one or more of user 110's EMV transaction cards may be configured to detect an initiation of a purchase transaction (e.g., in step 602, above), and to transmit data identifying the purchase transaction and data identifying the EMV transaction card (e.g., payment instrument data) to system 150 to request activation and funding of an electronic multicard account associated with user 110 and suitable for use in executing the initiated purchase transaction.
For example, the EMV transaction card may detect an initiated transaction upon insertion into POS device 156 and additionally or alternatively, upon disposition by user 110 at a location proximate to POS device 156 (e.g., to transfer information using radio-frequency (RF) communication protocols, near-field communication (NFC) protocols, etc.). In some instances, user 110's EMV transaction card may obtain and store data indicative of the detected purchase transaction (e.g., a purchase amount, an identifier of the merchant, etc.). Further, user 110's EMV transaction card may also store payment instrument data that links the EMV transaction card to one or more accounts held by user 110 (e.g., debit card account and/or credit card accounts held by user 110 and issued by the financial institution). In an embodiment, and upon detection of the initiated purchase transaction, user 110's EMV transaction card may establish communications with system 140 (e.g., through a wired or wireless link and/or tether to client device 104, or through other communications protocols, such as WiFi communication, etc.), and may transmit portions of the purchase transaction data and the payment instrument data to system 140 (e.g., in step 606). Using any of the exemplary techniques described above, system 140 may be configured to establish, in real time, an electronic multicard account funded from one of user 110's financial services accounts in an amount corresponding to the purchase amount, which system 140 may activate for use in the detected purchase transaction.
In certain aspects, user 110's EMV card may receive data associated with the activated and funded electronic multicard account (e.g., in step 608, above), which may be stored by user 110's EMV card and which may be provided to POS device 156 (e.g., using RF communication protocols, NFC protocols, etc.) to execute the initiated purchase transaction. In some aspects, POS device 156 may transmit the received electronic multicard account data and additionally or alternatively, portions of the purchase transaction data, to one or components of a merchant system (e.g., server 152) and/or back-end payment processing systems to execute the initiated purchase transaction using any of the exemplary techniques described above.
In further embodiments, and as described above, one or more components of a merchant system (e.g., server 152 of merchant system 150) may execute stored instructions to establish and maintain a mobile and/or web-based payment portal that receives requests for purchase transactions from various networked devices (e.g., client device 104, POS device 152, and/or user 110's EMV card), and processes and forwards the received requests to one or more components of merchant system 150 for execution and processing. For example, and using any of the exemplary techniques outlined above, client device 104 may provide, to the mobile payment portal of merchant system 150, a request to purchase one or more products from an electronic or e-commerce merchant (e.g., merchant 170) using a corresponding payment instrument (e.g., user 110's Visa™ debit card).
In some aspects, and consistent with the disclosed embodiments, the mobile and/or web-based payment portal may be configured to intercept the request, detect that user 110 initiated a purchase transaction involving merchant 170 and the corresponding payment instrument (e.g., in step 602), and may identify portions of the received request that correspond to purchase transaction data and payment instrument data (e.g., in step 604). The mobile and/or web-based payment portal may be configured to transmit the transaction data and payment data to system 140 (e.g., through one or more components of system 150 connected to network 120) as a request for an electronic multicard account (e.g., in step 606). Using any of the exemplary techniques described above, system 140 may be configured to establish, in real time, an electronic multicard account funded from one of user 110's financial services accounts in an amount corresponding to the purchase amount, which system 140 may activate for use in the detected purchase transaction. In certain aspects, system 140 may be configured to provide data identifying the activated and funded multicard account to the mobile and/or web-based payment portal, and one or more components of merchant system 150 (e.g., server 152) may perform operations that execute the initiated purchase transaction in accordance with the electronic multicard account data using any of the exemplary techniques described above.
The disclosed embodiments thus address one or more problems associated with conventional payment systems in a technical matter, by enable system 140 to generate, in real time, an electronic payment instrument (e.g., a funded electronic multicard) suitable for use in a single purchase transaction and capable of masking user 110's confidential account information during processing of that payment transaction. Further, in some aspects, the establishment and funding of the electronic multicard, and the completion of the corresponding purchase transaction using the funded electronic multicard, may occur without the knowledge or direction of user 110, which may assume a selected one or user 110's payment instruments facilitated completion of the purchase transaction. Further, in additional aspects, the real-time generation of single-use electronic multicard account may reduce fees charged to merchants by financial institutions (and thus passed on to customers), as the exemplary processes may convert a “card-not-present” payment transaction to a “card-present” transaction for the merchants.
Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosed embodiments being indicated by the following claims.

Claims

What is claimed is:

1. A device, comprising:

a storage device; and

at least one processor coupled to the storage device, the storage device storing instructions for controlling the at least one processor when executed by the at least one processor, the at least one processor being operative with the instructions to:

monitor data input into the device by a user;

detect an initiation of a purchase transaction by the user;

obtain transaction information and payment information from the monitored data, the transaction information identifying the purchase transaction, and the payment information identifying a payment instrument involved in the purchase transaction;

receive, from a first system, data identifying a placeholder account associated with the user, the placeholder account being activated for use in the initiated purchase transaction in accordance with the transaction information;

modify at least a portion of the payment information to include portions of the received placeholder account data; and

perform operations that transmit, across a network to a second computer system associated with the merchant, a request to execute the initiated purchase transaction in accordance with the modified payment information.

2. The device of claim 1, wherein:

the transaction information comprises a transaction amount and an identifier of a merchant; and

an amount of funding associated with the placeholder account is equivalent to the transaction amount, the placeholder account being funded from an account associated with the payment instrument and held by the user.

3. The device of claim 2, wherein the at least one processor is further operative with the instructions to:

generate a request to obtain the placeholder account data, the request comprising information identifying the user and at least a portion of the transaction information;

perform operations that transmit the generated request to the first computer system across the network; and

receive the placeholder account data from the first computer system in response to the request.

4. The device of claim 1, wherein:

the payment information comprises at least one of an account number of the payment instrument, an expiration date of the payment instrument, a card security code of the payment instrument, or billing information associated with the payment instrument; and

the placeholder account data comprises at least one of a placeholder account number, a placeholder expiration data, or a placeholder card security code.

5. The device of claim 4, wherein the at least one processor is further operative with the instructions to:

modify portions of the payment information to replace at least one of (i) the payment instrument account number with the placeholder account number, (ii) the payment instrument expiration date with the placeholder expiration date, or (iii) the payment instrument card security code with the placeholder card security code; and

generate the request to execute the initiated purchase transaction based on the modified portions of the payment information.

6. The device of claim 4, wherein the at least one processor is further operative with the instructions to:

perform operations that generate a temporary data file within a data repository and store the transaction information and the payment information in corresponding portions of the temporary data file;

modify at least a portion of the temporary data file storing the payment information to replace at least one of (i) the payment instrument account number with the placeholder account number, (ii) the payment instrument expiration date with the placeholder expiration date, or (iii) the payment instrument card security code with the placeholder card security code; and

generate the request to execute the initiated purchase transaction based on the modified portions of the temporary data file.

7. The device of claim 1, wherein the at least one processor is further operative with the instructions to:

receive, from the second computer system, notification data indicative of a status of the initiated purchase transaction; and

perform operations that render the notification data for presentation to the user.

8. The device of claim 1, wherein the at least one processor is further operative with the instructions to modify the payment information portion to include the portions of the received placeholder account data without user instruction.

9. The device of claim 1, wherein the at least one processor is further operative with the instructions to receive at least a portion of the monitored data as input to an interface presented by the device to the user.

10. The device of claim 1, wherein:

the payment instrument comprises a physical payment instrument;

the device further comprises a sensor configured to detect the physical payment instrument; and

the at least one processor is further operative with the instructions to receive at least a portion of the monitored data from the sensor.

11. The device of claim 1, wherein:

at least a portion of the payment information represents sensitive information; and

the modified payment information obscures the sensitive information during transmission across the network.

12. The device of claim 1, wherein the at least one processor is further operative with the instructions to detect the initiated purchase transaction based on at least one of the monitored data or at least one rule established by a business entity.

13. A computer-implemented method, comprising:

monitoring, by one or more processors, data input into the device by a user;

detecting, by one or more processors, an initiation of a purchase transaction by the user;

obtaining, by one or more processors, transaction information and payment information from the monitored data, the transaction information identifying the purchase transaction, and the payment information identifying a payment instrument involved in the purchase transaction;

receiving, by one or more processors, and from a first system across a network, data identifying a placeholder account associated with the user, the placeholder account being activated for use in the initiated purchase transaction in accordance with the transaction information;

modifying, by one or more processors, at least a portion of the payment information to include portions of the received placeholder account data; and

performing, by one or more processors, operations that transmit, across the network to a second computer system associated with the merchant, a request to execute the initiated purchase transaction in accordance with the modified payment information.

14. The method of claim 13, wherein:

15. The method of claim 14, further comprising:

generating, by the one or more processors, a request to obtain the placeholder account data, the request comprising information identifying the user and at least a portion of the transaction information;

performing, by the one or more processors, operations that transmit the generated request to the first computer system across the network; and

receiving, by the one or more processors, the placeholder account data from the first computer system in response to the request.

16. The method of claim 13, wherein:

the placeholder account data comprises at least one of a placeholder account number, a multicard expiration data, or a placeholder card security code.

17. The method of claim 16, further comprising:

modifying, by the one or more processors, portions of the payment information to replace at least one of (i) the payment instrument account number with the placeholder account number, (ii) the payment instrument expiration date with the placeholder expiration date, or (iii) the payment instrument card security code with the placeholder card security code; and

generating, by the one or more processors, the request to execute the initiated purchase transaction based on the modified portions of the payment information.

18. The method of claim 16, further comprising:

performing, by the one or more processors, operations that generate a temporary data file within a data repository and store the transaction information and the payment information in corresponding portions of the temporary data file;

modifying, by the one or more processors, at least a portion of the temporary data file storing the payment information to replace at least one of (i) the payment instrument account number with the placeholder account number, (ii) the payment instrument expiration date with the placeholder expiration date, or (iii) the payment instrument card security code with the placeholder card security code; and

generating, by the one or more processors, the request to execute the initiated purchase transaction based on the modified portions of the temporary data file.

19. The method of claim 13, further comprising:

receiving, by the one or more processors, and from the second computer system, notification data indicative of a status of the initiated purchase transaction; and

performing, by the one or more processors, operations that render the notification data for presentation to the user.

20. The method of claim 13, further comprising modifying, by the one or more processors, the portion of the payment information to include the portions of the received placeholder account data without user intervention.

21. The method of claim 13, further comprising receiving, by the one or more processors, at least a portion of the monitored data as input to an interface presented by the device to the user.

22. The method of claim 21, wherein the received portion of the monitored data comprises at least one of the account number of the payment instrument, the expiration date of the payment instrument, or the card security code of the payment instrument.

23. The method of claim 13, wherein:

the payment instrument comprises a physical payment instrument;

the method further comprises receiving, by the one or more processors, at least a portion of the monitored data from the sensor.

24. The method of claim 13, wherein:

25. A payment device, comprising:

an integrated circuit; and

a storage device coupled to the integrated circuit and configured to store payment information, the payment information comprising at least one of an account number, expiration date, or card security code of a payment instrument associated with a user,

the integrated circuit being configured to:

detect an initiation of a purchase transaction involving the merchant, the initiated purchase transaction being associated with a corresponding purchase amount;

receive, from a first system across a network, data identifying a placeholder account associated with the user, the placeholder account being activated for use in the initiated purchase transaction;

modify at least a portion of the stored payment information to include portions of the received placeholder account data; and

provide, to the merchant device, at least a portion of the stored placeholder account data to execute the initiated purchase transaction.

26. The payment device of claim 25, wherein the integrated circuit is further configured to:

detect a proximity of the payment device to a sensor of a device associated with a merchant;

based on the detected proximity, identify the initiation of the purchase transaction involving the merchant.

27. An apparatus, comprising:

a storage device; and

receive a request to obtain data identifying a placeholder account associated with a user, the request identifying transaction information associated with an initiated purchase transaction, and the transaction information identifying a transaction amount and a merchant associated with the initiated purchase transaction;

identify a placeholder account available to the user for use in the initiated purchase transaction;

perform operations that initiate a transfer of funds corresponding to the transaction amount from at least one financial services account of the user to the available placeholder account;

generate placeholder account data corresponding to the funded placeholder account and store the placeholder account data in a data repository, the stored placeholder account data comprising information identifying at least one of the merchant or the user, and information confirming an activation of the funded placeholder account for use in the initiated purchase transaction; and

perform operations that transmit at least a portion of the stored placeholder account data to a device associated with the received request.

28. The apparatus of claim 27, wherein:

the request further identifies payment information associated with the initiated purchase transaction, the payment information comprising an account number of a payment instrument associated with the user; and

the method further comprises identifying the at least one financial services account of the user based on the account number of the payment instrument.