US20220292503A1

Movatterモバイル変換

Info

Publication number: US20220292503A1
Application number: US17/831,279
Authority: US
Inventors: Zachary Brock
Original assignee: Block Inc
Current assignee: Block Inc
Priority date: 2014-08-06
Filing date: 2022-06-02
Publication date: 2022-09-15
Also published as: US11354673B1

Abstract

Payment card information of a consumer is protected during online payment card based transactions by equipping a user device of the consumer with a control that, when activated by the consumer during an online shopping session, causes the user device automatically to request and receive, from a third-party payment processing service (PPS), temporary proxy payment card information, and to populate that information into an online transaction web interface of the merchant. The temporary proxy payment card information is associated in the third-party PPS with a real payment card account of the consumer. When the PPS receives a transaction authorization request from a merchant via a payment card network, the PPS uses the consumer's real payment card information to authorize the transaction. The consumer's real payment card information is never exposed to the merchant.

Description

RELATED APPLICATIONS

This application claims priority to and is a continuation of U.S. patent application Ser. No. 14/453,551, filed on Aug. 6, 2014, the entire contents of which are incorporated herein by reference.

FIELD OF THE INVENTION

At least one embodiment of the present invention pertains to electronic commerce, and more particularly, to a technique for enhancing security of sensitive data during online transactions involving payment card accounts.

BACKGROUND

When purchasing goods or services online (e.g., via the Internet), a consumer may be given the option to pay by credit card or other type of payment card (e.g., debit card or gift card). To do so, after adding one or more items to his or her electronic shopping cart and requesting checkout, the consumer typically enters his or her payment card information into a web page generated by a shopping cart application of the merchant. Once the payment card information is entered, the consumer provides a confirmation input that indicates his or her commitment to the transaction and that causes his or her user device to submit payment information to the website of the merchant. The merchant's computer system then requests authorization of the card transaction through a financial system.

One problem with this payment paradigm is that it exposes sensitive information of the consumer, namely, the consumer's payment card information, to various third parties, where it may be vulnerable to misappropriation. For example, the payment card information may be inadvertently provided by the consumer to a wrongdoer posing as a legitimate online merchant. Additionally, merchants sometimes store the consumer's card information. Different merchants implement vastly differing degrees of data security, such that the consumer's card information may be vulnerable to unauthorized acquisition by hackers once it is in the possession of a merchant.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more embodiments of the present invention are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements.

FIG. 1 illustrates an example of an environment in which the data security technique can be implemented.

FIG. 2 illustrates relevant elements of the user device and the payment processing service (PPS) system.

FIG. 3 illustrates an example of the message flow between various elements associated with the data security technique.

FIGS. 4A and 4B illustrate unpopulated and populated states, respectively, of a merchant's payment information webpage.

FIG. 5 illustrates an example of the process performed by the consumer's user device in the data security technique.

FIGS. 6A and 6B illustrate examples of processes performed by the PPS system in the data security technique.

FIG. 7 illustrates an example of the hardware architecture of a processing system that can be used to implement any of the computing devices referred to herein.

DETAILED DESCRIPTION

In the technique introduced here, credit card or other payment card information of a consumer (also called the “cardholder” or “user” herein) is protected during online payment card based transactions, by enabling a user device of the consumer to request and receive, during an online shopping session, temporary proxy payment card information from a third-party payment processing service (PPS), and by enabling the user device to populate that temporary proxy payment card information into an online transaction web interface of the merchant automatically. In some embodiments, this is accomplished by equipping a browser in the user device with a control that, when activated by the consumer, accesses the PPS to obtain the proxy card information populates that information into the online transaction web interface of the merchant automatically. The temporary proxy payment card information is associated in the third-party PPS with a real payment card account of the consumer. When the merchant requests authorization for the transaction with the proxy payment card information, the authorization request gets routed to the PPS via the payment card network, by virtue of the proxy card number, according to the normal authorization request routing process. The PPS then uses the consumer's real payment card information to authorize and fund the transaction.

Hence, the consumer's real payment card information is never exposed to the merchant or to any unauthorized third parties who penetrate the merchant's information systems. Additionally, this technique is completely transparent to the merchant and therefore requires no modifications to the merchant's e-commerce system.

Consider the following example scenario in which the technique can be applied. The PPS is a secure business enterprise and computer system that is highly trusted by the consumer. A consumer initially enrolls with the PPS by setting up an account with the PPS, which includes providing his or her real credit card information to the PPS. Enrollment with the PPS may be done via a website of the PPS, by telephone, electronic mail, standard mail, or any other convenient communication channel. The consumer further installs a software extension or plug-in associated with the PPS into a conventional web browser (e.g., Microsoft Internet Explorer, Mozilla Firefox or Google Chrome) in a user device used by the consumer. The user device may be, for example, a conventional personal computer (PC), such as a desktop computer or laptop computer, or it may be a smartphone, tablet computer, or any other known or convenient processing device.

The consumer later visits an electronic commerce (e-commerce) website of a merchant, which may be a merchant with whom the consumer is not familiar and in whom the consumer does not have a high level of trust. The consumer adds one or more items to his or her electronic shopping cart and requests checkout. The consumer then clicks a button to activate the PPS browser extension, by which the consumer can pay securely through the PPS. When activated, the extension accesses the PPS (which is implemented at least partially on one or more remote server computers) via a network such as the Internet, to obtain a dynamically generated credit card number, along with corresponding card type information, cardholder name, expiration date and card verification value (CVV); this information collectively is the temporary proxy payment card information (or simply proxy card information). The proxy card information can include a valid Visa or Mastercard number, for example, and may be issued by the PPS. Once received from the PPS, the PPS browser extension automatically populates the proxy card information into the merchant's website's checkout page (e.g., a web form). The PPS is subsequently contacted as the card issuer during the credit card payment authorization process.

Note that while the example of a credit card is used herein to facilitate description, the proxy card information can be associated in the PPS with any other type of real payment card, such as a debit card or a gift card, for example.

The PPS can maintain validity rules that limit the validity of the proxy card information, such as by time, merchant, transaction amount, number of transactions, or any other criteria. These rules may be specified or selected by the consumer (prior to the transaction), or they may be default rules provided by the PPS. The validity rules include at least one validity criterion, which can be or include, for example, a maximum individual or collective transaction amount and/or a maximum number of transactions for which the proxy card information can be used, particular merchant or category of merchant in which the proxy card information can be used, etc. The validity criterion further can be or include an expiration date and/or time for the proxy card information, which can be different from the expiration date of the consumer's real payment card. Furthermore, the expiration date/time of the proxy card information can also be different from the proxy expiration date provided to the merchant website, i.e., it can be earlier than or later than the proxy expiration date. In other words, the proxy card expiration date provided to the merchant may be a dummy expiration date that does not reflect the actual expiration date/time of the proxy card information or the expiration date of the consumer's real payment card information.

For example, the validity rules might specify that the proxy card information can be used only once, or only once per day, or only once per day per merchant, or only for specific merchants or categories of merchants, or only for up to $2,500 per month, or combination of such restrictions. From the merchant's perspective, the consumer is using a normal payment card number (and associated information). From the consumer's perspective, they just enter minimal PPS authentication information (e.g., username and password) once, or at most once per user session. From the PPS's perspective, they receive an authorization request through the proxy card information and then use the consumer's real card information on file to authorize and fund the transaction.

If the merchant is the target of a hacking attack directed to its stored card information, all they have of the consumer is a name and card information that has no value, because the information is single-use or very limited use, and the PPS can deactivate all proxy card numbers used at that merchant without having to the deactivate the backing payment cards.

FIG. 1 illustrates an example of an environment in which the data security technique can be implemented. The environment includes at least oneuser device1A or1B (collectively user device1) of a consumer, which can be, for example, amobile device1A such as a smartphone or tablet, or a PC1B. The environment further includes ane-commerce website2 of a merchant, acomputer system3 of the PPS (hereinafter the PPS system3), and afinancial system4 for processing payment card transactions. ThePPS system3 includes adatabase5 storing information such as identification information of users enrolled with the PPS, real payment card account information of such users, and an association of that account information with proxy card information for at least some users.

Though not shown inFIG. 1, thefinancial system4 can include the merchant's acquiring bank and at least one payment card payment network, such as Visa or MasterCard, and computer systems associated with such entities. Each of the aforementioned computer systems can include one or more distinct physical computers and/or other processing devices which, in the case of multiple devices, can be connected to each other through one or more wired and/or wireless networks. All of the aforementioned devices are coupled to each other through an internetwork6, which can be or include the Internet and one or more wireless networks (e.g., a WiFi network and/or a cellular telecommunications network).

Referring now toFIG. 2, theuser device1 and thePPS system3 are shown in greater detail, according to at least one embodiment. As illustrated, theuser device1 includes abrowser21, which in the illustrated embodiment includes a user-installable extension (plug-in)22 associated with the PPS. In the case of a mobile user device, the PPS client-side functionality may be implemented, for example, by a bookmarklet (i.e., a browser bookmark containing executable script such as JavaScript).

ThePPS system3 includes, for each consumer enrolled with the PPS,information23 identifying the consumer and/or the consumer's user device (hereinafter “user/device information”), real paymentcard account information24 of the consumer, and proxypayment card information25 associated with the consumer. Additionally, thePPS system3 includes a cardinformation proxying unit26 and apayment authorization unit27. The cardinformation proxying unit26 is responsible for maintaining the association between the consumer's user/device information23, realcard account information24 and proxycard account information25, and for looking up and providing proxycard account information25 to theuser device1 when required. Thepayment authorization unit27 is responsible for determining whether to authorize requested payment card transactions, including applying storedvalidity rules28 associated with theproxy card information25.

In some embodiments, thePPS system3 may associate a particular consumer with two or more different sets of proxy payment card accounts, all of which may be associated in thePPS system3 with the same real payment card of the consumer or with two or more different real payment cards of the consumer. In such an embodiment, the particular proxy payment card information to be used for a given transaction can be selected using any of various techniques, such as by user selection on a per-transaction basis, based on selection rules or policies previously specified by the user, or based on default rules or policies. The real payment card or cards associated with a particular consumer in the PPS system3 (and hence, with a particular set of proxy payment card information) can include one or more credit cards, debit cards, gift cards, or a combination thereof.

In operation, when the consumer activates a known browser control associated with the PPS plug-in22, the PPS plug-in22 sends information of the consumer to the PPS. In certain embodiments, the PPS plug-in first prompts the consumer to enter his or her identifying information to be used by the PPS to authenticate the consumer, such as a username and password. This information can be input one time and then stored locally in the user device for future use, or it may be input by the consumer for each online transaction or each user session. The user/device information may be sent to thePPS system3 via any known or convenient network or internetwork, such as the Internet. When the user/device information is received by thePPS system3, the cardinformation proxying unit26 uses the user/device information to look up the proxycard account information25, which it then returns to the PPS plug-in22. The PPS plug-in22 then populates the received proxy card account information into the payment information user interface provided by the merchant'swebsite2, which may be a web form. The receipt of proxy card information and population of that information into the merchant's user interface normally happens within a few seconds (at most), of the consumer activating the PPS browser control. In an alternative embodiment, the proxy card information may simply be displayed to the user, who then manually copies that information into the merchant's payment information user interface.

When the user commits to the transaction by providing an appropriate confirmation input, themerchant e-commerce website2 sends a transaction authorization request to its acquiring bank, which routes the request to the applicable card network (e.g., Visa or MasterCard) based on the proxy payment card number, which then routes the request to thePPS system3. Thepayment authorization unit27 in thePPS system3 then uses the proxy payment card number in the request to look up the applicable validity rules orrules28 associated with the proxy payment card information and determine whether the transaction request complies with them. If the request does not comply with any applicable validity rule(s)28, the authorization request is denied. If the request does comply, then thepayment authorization unit27 looks up the realpayment card information24 of the consumer and uses that information to authorize the transaction, assuming the consumer's real payment card has not expired and has sufficient credit or funds remaining to cover the transaction amount.

In some embodiments, instead of implementing this technique with a browser extension on the client side, the PPS client-side functionality may be provided by a separate software application or dedicated PPS hardware device that operates in the consumer'suser device1. In that scenario, the PPS can publish an application programming interface (API) for other software vendors, to allow browsers and/or e-commerce software to invoke the PPS functionality. In that case, the user can easily switch back and forth between a browser or e-commerce application and the PPS client-side application/functionality, to request and receive proxy payment card information.

FIG. 3 illustrates an example of the message flow between various elements associated with this technique, according to some embodiments. When the consumer is requested by a merchant's e-commerce website to enter payment information for a transaction, the consumer enters anappropriate user input31 associated with PPS functionality, to theuser device1.FIG. 4A shows an example of a merchant's initially empty payment information webpage44 (e.g., an HTML form or the like). The above-mentioneduser input31 can be in the form of the consumer clicking on a “PPS”button45 or other similar control, displayed (e.g., by the PPS plug-in) on thewebpage44.

In response touser input31, theuser device1 sends a proxycard information request32 to thePPS system3. The request may be sent using any known or convenient protocol(s), including, for example, Hypertext Transport Protocol Secure (HTTPS).

Note that in this description, any references to sending or transmitting a message, signal, etc. to another device (recipient device) means that the message is sent with the intention that it its information content ultimately be delivered to the recipient device; however, such references do not mean that the message must be sent directly to the recipient device. That is, unless stated otherwise, there can be one or more intermediary entities that receive and forward the message, signal, etc., either as is or in modified form, prior to its delivery to the recipient device. This clarification also applies to any references herein to receiving a message, signal, etc. from another device; i.e., direct point-to-point communication is not required unless so stated.

In response to the proxycard information request32, thePPS system3 generates or looks up the proxy payment card information for that user, and returns it to the user device in a proxycard information response33. The PPS functionality in theuser device1 then automatically populates this information into the payment card information fields46 (e.g., card type, card number, security code (CVV), expiration date and name on card) in the merchant'spayment information webpage44. Alternatively, the consumer can manually copy that information into the merchant'spayment information webpage44. An example of the result of this operation is shown inFIG. 4B, which shows thewebpage44 ofFIG. 4A after the card information fields46 have been populated.

In certain embodiments, to provide additional fraud protection, thePPS system3 can use a different proxy payment card number for each merchant or category of merchants. Additionally, or as an alternative, thePPS system3 can generate different combinations of proxy CWs and/or proxy expirations dates with the same proxy payment card number, and can use a different combination of such information for each merchant or category of merchant. The use of such combinations provides a greater number of unique permutations of proxy payment card information, thereby reducing the overall exposure to wrongdoers.

When the consumer is ready to commit to the transaction, he or she enters anappropriate user input34 to theuser device1, for example, by clicking on a “Pay Now”button47. This causes theuser device1 to send a conventional transaction confirmation message35 (e.g., using HTTPS or other similar protocol) containing the proxy card information to the merchant'se-commerce website2. The merchant'se-commerce website2 then sends atransaction authorization request36 to thefinancial system4. Thefinancial system4 routes the request in the form ofmessage37 to thePPS system3. ThePPS system3 determines whether to authorize the transaction in the manner described above, and sends an authorization response38 (e.g. authorized or declined) to thefinancial system4, which forwards the response in the form ofmessage39 to the merchant'se-commerce website2. The merchant'se-commerce website2 then sends anappropriate message40 confirming or denying the transaction to theuser device1, which displays41 the message to the consumer.

FIG. 5 illustrates an example of a process performed by the consumer'suser device1, according to some embodiments. Initially, in response to a user input, a browser in the user device accesses the website of an online merchant atstep501. Atstep502 the browser displays a window including a shopping cart page of the merchant, where the window includes a control for the PPS (e.g., “PPS” button45). When the consumer activates the PPS control at step503 (after having added one or more items to his or her shopping cart and requested checkout), the PPS functionality in theuser device1 then atstep504 prompts the consumer for and receives PPS authentication information (e.g., username and password), if such information was not previously input by the consumer and stored locally in the user device. Next, atstep505 theuser device1 sends a message including the consumer's authentication information to thePPS system3. Assuming the user is properly authenticated by thePPS system3, theuser device1 receives a message containing the proxy card information from thePPS system3 atstep506. Theuser device1 then atstep507 appropriately populates the payment card information fields of the merchant's payment information page with the proxy card information.

FIGS. 6A and 6B illustrate examples of processes performed by thePPS system3, in association with the example ofFIG. 5, according to some embodiments. More specifically,FIG. 6A shows an example of the process for providing proxy card information to theuser device1. Initially, atstep601 thePPS system3 receives a message including the consumer's authentication information from theuser device1. ThePPS system3 responds by looking up the consumers account information based on the authentication information atstep602. Based on the account information, thePPS system3 atstep603 retrieves the proxy card information associated with consumer's account if that information was previously generated and stored in thePPS system3, or generates the proxy card information if it was not previously generated and stored. ThePPS system3 then sends a message containing the proxy card information to the user device atstep604.

FIG. 6B shows an example of the process by which thePPS system3 processes a subsequent transaction authorization request. Atstep611 thePPS system3 receives a transaction authorization request containing proxy card information, from thefinancial system4, based on a corresponding authorization request originated by the merchant'se-commerce website2. Atstep612 thePPS system3 responds to the authorization request by determining whether the request complies with the validity rule or rules, stored in thePPS system3, associated with the proxy card information in the request. As described above, the rules include one or more of validity criteria for the proxy card information, such as a time limit, merchant identity or category restriction, transaction amount limit, etc., or a combination thereof. If the request does not comply with all applicable validity rules (step613), then thePPS system3 atstep618 sends a message for delivery to the merchant'se-commerce website2, indicating that the transaction is denied. If, on the other hand, the request complies with all applicable validity rules (step613), thePPS system3 atstep614 looks up the real payment card account associated with the proxy card information, and then determines atstep615 whether the transaction can be authorized based on the real payment card account information (e.g., whether the real payment card is not expired and has sufficient credit or funds available to cover the transaction amount). If thePPS system3 determines that the transaction can be authorized based on the real payment card account information (step616), thePPS system3 sends a message atstep617 for delivery to the merchant's e-commerce website, indicating that the transaction is authorized; otherwise, the process branches to step618, where thePPS system3 sends a message for delivery to the merchant'se-commerce website2, indicating that the transaction is denied.

FIG. 7 illustrates at a high-level an example of the hardware architecture of a processing system that can be used to implement any of the computing devices referred to above, such as theuser device1, themerchant website2, thePPS system3, or thefinancial system4. Note that any of these devices each can include multiple instances of an architecture such as shown inFIG. 7 (i.e., multiple computers), particularly the server-based systems such as themerchant website2,PPS system3, andfinancial system4, and such multiple instances can be coupled to each other via a network or multiple networks.

In the illustrated embodiment, thearchitecture700 includes one ormore processors710,memory711, one or more communication device(s)712, one or more input/output (I/O)devices713, and one or moremass storage devices714, all coupled to each other through aninterconnect715. Theinterconnect715 may be or include one or more conductive traces, buses, point-to-point connections, controllers, adapters and/or other conventional connection devices. The processor(s)710 may be or include, for example, one or more general-purpose programmable microprocessors, digital signal processors (DSPs), microcontrollers, application specific integrated circuits (ASICs), programmable gate arrays, or the like, or a combination of such devices. The processor(s)710 control the overall operation of theprocessing device700.

Memory

711 may be or include one or more physical storage devices, which may be in the form of random access memory (RAM), read-only memory (ROM) (which may be erasable and programmable), flash memory, miniature hard disk drive, or other suitable type of storage device, or a combination of such devices. The mass storage device (s)714 may be or include one or more hard drives, digital versatile disks (DVDs), flash memories, or the like.Memory711 and/ormass storage714 may store (individually or collectively) data and instructions that configure the processor(s)710 to execute operations in accordance with the techniques described above. Thecommunication devices712 may be or include, for example, an Ethernet adapter, cable modem, Wi-Fi adapter, cellular transceiver, Bluetooth or Bluetooth Low Energy (BLE) transceiver, or the like, or a combination thereof. Depending on the specific nature and purpose of theprocessing device700, the I/O devices713 can include devices such as a display (which may be a touch screen display), audio speaker, keyboard, mouse or other pointing device, microphone, camera, etc. Note that these I/O devices may be unnecessary, however, if theprocessing device700 is embodied solely as a server computer.

In the case of theuser device1, thecommunication devices712 can be or include, for example, a cellular telecommunications transceiver (e.g., 3G or 4G/LTE), Wi-Fi transceiver, Bluetooth or BLE transceiver, or the like, or a combination thereof. In the case of thevalidation system22, thecommunication devices712 can be or include, for example, any of the aforementioned types of communication devices, a wired Ethernet adapter, cable modem, DSL modem, or the like, or a combination of such devices.

Unless contrary to physical possibility, it is envisioned that (i) the methods/steps described herein may be performed in any sequence and/or in any combination, and that (ii) the components of respective embodiments may be combined in any manner.

The machine-implemented operations described above can be implemented by programmable circuitry programmed/configured by software and/or firmware, or entirely by special-purpose circuitry, or by a combination of such forms. Such special-purpose circuitry (if any) can be in the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), etc.

Software used to implement the techniques introduced here may be stored on a machine-readable storage medium and may be executed by one or more general-purpose or special-purpose programmable microprocessors. A “machine-readable medium”, as the term is used herein, includes any mechanism that can store information in a form accessible by a machine (a machine may be, for example, a computer, network device, cellular phone, personal digital assistant (PDA), manufacturing tool, any device with one or more processors, etc.). For example, a machine-accessible medium includes recordable/non-recordable media (e.g., read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; etc.), etc.

Note that any and all of the embodiments described above can be combined with each other, except to the extent that it may be stated otherwise above or to the extent that any such embodiments might be mutually exclusive in function and/or structure.

Although the present invention has been described with reference to specific exemplary embodiments, it will be recognized that the invention is not limited to the embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense.

Claims

What is claimed is:

1. A method comprising:

receiving, at a service provider remote from a merchant, and from an application associated with a user device of a user, a request to perform a transaction with the merchant via a user account of the user, the service provider configured to facilitate transactions involving user accounts of users of the service provider;

generating, based at least in part on the request and in near real-time, temporary payment card information, wherein the temporary payment card information:

represents a temporary payment card;

is associated with the user account of the user;

includes information to permit processing of the transaction between the user and the merchant; and

is configured to be utilized by the merchant as an approval of the transaction;

generating instructions for presenting the temporary payment card information on a user interface associated with the application; and

sending the temporary payment card information and the instructions to the user device.

2. The method ofclaim 1, wherein generating the temporary payment card information is based at least in part on receiving previous user input requesting use of the temporary payment card information.

3. The method ofclaim 1, wherein generating the temporary payment card information is based at least in part on determining that a payment instrument is unassociated with the user account when the request is received.

4. The method ofclaim 1, wherein generating the temporary payment card information is based at least in part on determining that a payment instrument of the service provider is absent from the user account when the request is received.

5. The method ofclaim 1, wherein the instructions are configured to cause, when received at the user device and without user input, the user device to populate the temporary card information into one or more payment fields of the user interface.

6. The method ofclaim 1, further comprising:

receiving, from a merchant device of the merchant, an indication that the temporary card information has been utilized to satisfy a cost of the transaction;

determining the user account associated with the temporary card information; and

withdrawing funds equal to the cost from the user account.

7. The method ofclaim 1, further comprising:

associating a validity rule with the temporary card information, the validity rule indicating that the temporary card information is valid for exactly one transaction;

determining that the temporary card information has yet to be used; and

wherein sending the temporary card information is based at least in part on the temporary card information not yet being used.

8. The method ofclaim 1, wherein generating the temporary card information is based at least in part on an indication that the merchant corresponds to a predetermined merchant and the transaction is set to occur at a predetermined time.

9. A system comprising:

one or more processors; and

non-transitory computer-readable media storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising:

receiving, at a service provider and from a merchant interface associated with a merchant, a request to perform a transaction with the merchant via a user account of a user, the service provider configured to facilitate transactions involving user accounts of users of the service provider;

is associated with the user account of the user; and

includes information to permit processing of the transaction; and

is configured to be utilized by the merchant as an approval of the transaction;

generating data configured to cause presentation of the temporary payment card information on the merchant interface; and

sending the temporary payment card information and the data to the merchant interface.

10. The system ofclaim 9, wherein:

the merchant interface is presented in association with a payment application on a user device; and

sending the temporary card information and the data comprises sending the temporary card information and the data to the user device.

11. The system ofclaim 9, wherein:

the merchant interface is associated with a merchant ecommerce website; and

sending the temporary card information and the data comprises sending the temporary card information and the data to the merchant ecommerce website.

12. The system ofclaim 9, wherein the payment service is separate and remote from a device where the merchant interface is being displayed.

13. The system ofclaim 9, the operations further comprising:

causing display, on the merchant interface, of a selectable element corresponding to a plug-in for the payment service;

receiving user input data indicating selection of the selectable element; and

wherein generating the temporary card information is based at least in part on receiving the user input data.

14. The system ofclaim 9, the operations further comprising:

in response to receiving the request, requesting authentication input from the user;

receiving the authentication input; and

wherein sending the temporary card information and the data is based at least in part on receiving the authentication input.

15. A method comprising:

is associated with the user account of the user; and

includes information to permit processing of the transaction; and

is configured to be utilized by the merchant as an approval of the transaction;

16. The method ofclaim 15, wherein:

the merchant interface is associated with a merchant ecommerce website; and

17. The method ofclaim 15, further comprising:

determining that the temporary card information has yet to be used; and

18. The method of clam15, wherein generating the temporary card information is based at least in part on an indication that the merchant corresponds to a predetermined merchant and the transaction is set to occur at a predetermined time.

19. The method ofclaim 15, wherein generating the temporary payment card information is based at least in part on determining that a payment instrument of the service provider is absent from the user account when the request is received.

20. The method ofclaim 15, wherein the data are configured to cause, when received at the merchant interface and without user input, the merchant interface to populate the temporary card information into one or more payment fields of the merchant interface.