Systems, methods, and computer program products for automatically updating authentication information

The system automates credential updates for payment card migrations by analyzing credential history and generating update requests, addressing the complexity and security issues of manual re-provisioning, ensuring efficient and secure transitions between payment schemes.

JP2026506200APending Publication Date: 2026-02-20VISA INTERNATIONAL SERVICE ASSOCIATION
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2025549585
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-02-23
Filing Date
2024-02-23
Publication Date
2026-02-20

AI Technical Summary

Technical Problem

The migration of payment card issuers from one scheme to another necessitates manual deletion and re-provisioning of device-based and card-on-file credentials, leading to transaction denials and inefficient use of computing resources, with existing processes being complex and prone to security breaches.

Method used

A system and method for automatically generating update requests to merchant systems and user devices to update credentials based on new account identifiers, utilizing a transaction processing system that analyzes credential history and generates requests to update card-on-file merchant credentials and device tokens.

Benefits of technology

Facilitates seamless credential updates across multiple systems, reducing manual intervention, minimizing transaction denials, and enhancing security by automating the process, thus optimizing resource utilization and reducing security risks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2026506200000001_ABST
    Figure 2026506200000001_ABST
Patent Text Reader

Abstract

Systems, methods, and computer program products for automatically updating credentials include at least one processor programmed or configured to: receive from a first issuer system a migration request identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier; analyze the credential request history to identify at least one provisioned credential associated with the original account identifier, the at least one provisioned credential including at least one of a card-on-file merchant credential and a device token; and, in response to identifying the at least one provisioned credential, automatically generate an update request based on the new account identifier, the update request configured to cause at least one of the merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof, to update the at least one provisioned credential.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 447,717, filed February 23, 2023, the entire disclosure of which is incorporated herein by reference.

[0002] The present disclosure relates generally to credentials and, in some non-limiting embodiments or aspects, to systems, methods, and computer program products for automatically updating credentials. [Background technology]

[0003] (Technical consideration) When a payment card issuer migrates from one scheme (e.g., a payment network) to another, the process involves reissuing all cards under the migrated portfolio, resulting in the cardholder receiving a new card from one scheme to replace the old card from another scheme. As the use of device-based and card-on-file credentials increases, migrations between these schemes become more difficult and complex, requiring cardholders to manually delete and re-provision tokens on their devices and contact each card-on-file merchant to change their card details; failure to do so results in transaction denials. Furthermore, existing processes used to change credentials use numerous communications, messages, and duplicate requests and / or queries, resulting in wasted computing / processing resources and additional opportunities for security breaches. Summary of the Invention

[0004] According to a non-limiting embodiment or aspect, a system comprising at least one processor of a transaction processing system, the at least one processor programmed or configured to: receive, from a first issuer system, a migration request identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier, where the original account identifier is associated with a second transaction processing system; analyze the credential request history to identify at least one provisioned credential associated with the original account identifier, where the at least one provisioned credential includes at least one of a card-on-file merchant credential and a device token; and, in response to identifying the at least one provisioned credential, automatically generate an update request configured to cause at least one of the merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof, to update the at least one provisioned credential based on the new account identifier.

[0005] In a non-limiting embodiment or aspect, the at least one provisioned credential associated with the original account identifier includes at least one of a card-on-file merchant credential and a device token. In a non-limiting embodiment or aspect, the card-on-file merchant credential includes the original account identifier. In a non-limiting embodiment or aspect, the migration request is received via a central migration system in communication with the first issuer system, the transaction processing system, and the second transaction processing system, and at least the credential request history is received by the central migration system from the first issuer system. In a non-limiting embodiment or aspect, the credential request history includes at least one of a token reference identifier, token requestor data, a merchant identifier associated with the original account identifier, or any combination thereof. In a non-limiting embodiment or aspect, the account data associated with the at least one device token includes a new token. In a non-limiting embodiment or aspect, the account data associated with the at least one provisioned credential includes at least one of a subset of digits of the new account identifier, a token corresponding to the new account identifier, the new account identifier, or any combination thereof.In a non-limiting embodiment or aspect, the at least one provisioned credential associated with the original account identifier includes at least one of a card-on-file merchant credential and a device token, and automatically generating an update request in response to identifying the at least one provisioned credential includes: in response to identifying the card-on-file merchant credential, automatically generating a merchant update request configured to cause a card-on-file merchant's merchant system and / or the card-on-file merchant's payment gateway to update account data associated with the provisioned credential and stored by the merchant system or the card-on-file merchant's payment gateway; and in response to identifying the device token, automatically generating a device update request configured to cause a user device to update account data associated with the device token and stored by the user device.

[0006] According to a non-limiting embodiment or aspect, a computer-implemented method is provided that includes: receiving, at at least one processor of a transaction processing system from a first issuer system, a migration request identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier, where the original account identifier is associated with a second transaction processing system; analyzing, at the at least one processor, the credential request history to identify at least one provisioned credential associated with the original account identifier, where the at least one provisioned credential includes at least one of a card-on-file merchant credential and a device token; and in response to identifying the at least one provisioned credential, automatically generating an update request based on the new account identifier, the update request configured to cause at least one of the merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof, to update the at least one provisioned credential.

[0007] In a non-limiting embodiment or aspect, the at least one provisioned credential associated with the original account identifier includes at least one of a card-on-file merchant credential and a device token. In a non-limiting embodiment or aspect, the card-on-file merchant credential includes the original account identifier. In a non-limiting embodiment or aspect, the migration request is received via a central migration system in communication with the first issuer system, the transaction processing system, and the second transaction processing system, and at least the credential request history is received by the central migration system from the first issuer system. In a non-limiting embodiment or aspect, the credential request history includes at least one of a token reference identifier, token requestor data, a merchant identifier associated with the original account identifier, or any combination thereof. In a non-limiting embodiment or aspect, the account data associated with the at least one device token includes a new token. In a non-limiting embodiment or aspect, the account data associated with the at least one provisioned credential includes at least one of a subset of digits of the new account identifier, a token corresponding to the new account identifier, the new account identifier, or any combination thereof.In a non-limiting embodiment or aspect, the at least one provisioned credential associated with the original account identifier includes at least one of a card-on-file merchant credential and a device token, and automatically generating an update request in response to identifying the at least one provisioned credential includes: in response to identifying the card-on-file merchant credential, automatically generating a merchant update request configured to cause a merchant system or a payment gateway associated with the card-on-file merchant to update account data associated with the provisioned credential and stored by the card-on-file merchant's merchant system or payment gateway; and in response to identifying the device token, automatically generating a device update request configured to cause the user device to update account data associated with the device token and stored by the user device.

[0008] According to a non-limiting embodiment or aspect, a computer-implemented method is provided that includes: receiving, at at least one processor in a transaction processing system, from a first issuer system, a migration request identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier, where the original account identifier is associated with a second transaction processing system; analyzing, at the at least one processor, the credential request history to identify at least one provisioned credential for a card-on-file merchant and at least one device token associated with the original identifier; in response to identifying the at least one provisioned credential for the card-on-file merchant, automatically generating a merchant update request configured to cause the card-on-file merchant to update account data associated with the provisioned credential and stored in the card-on-file merchant's merchant system; and in response to identifying the at least one device token, automatically generating a device update request to a user device configured to cause the user device to update account data associated with the at least one device token and stored by the user device.

[0009] According to a non-limiting embodiment or aspect, a computer program product is provided that includes at least one non-transitory computer-readable medium including program instructions that, when executed by at least one processor in a transaction processing system, cause the at least one processor to: receive, from a first issuer system, a migration request identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier, where the original account identifier is associated with a second transaction processing system; analyze the credential request history to identify at least one provisioned credential associated with the original account identifier, where the at least one provisioned credential includes at least one of a card-on-file merchant credential and a device token; and in response to identifying the at least one provisioned credential, automatically generate an update request based on the new account identifier, the update request configured to cause at least one of the merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof to update the at least one provisioned credential.

[0010] Further non-limiting embodiments or aspects are described in the following numbered clauses:

[0011] Clause 1: A system comprising at least one processor in a transaction processing system, the at least one processor being programmed or configured to: receive, from a first issuer system, a migration request identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier; the original account identifier being associated with a second transaction processing system; analyze the credential request history to identify at least one provisioned credential associated with the original account identifier, the at least one provisioned credential comprising at least one of a card-on-file merchant credential and a device token; and in response to identifying the at least one provisioned credential, automatically generate an update request configured to cause at least one of the merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof, to update the at least one provisioned credential based on the new account identifier.

[0012] Clause 2: The system of clause 1, wherein the at least one provisioned credential associated with the original account identifier includes at least one of a card-on-file merchant credential and a device token.

[0013] Clause 3: The system described in clause 1 or clause 2, wherein the card-on-file merchant authentication information includes an originating account identifier.

[0014] Clause 4: A system described in any of clauses 1 to 3, wherein the migration request is received via a central migration system that communicates with the first issuer system, the transaction processing system, and the second transaction processing system, and at least the authentication information request history is received by the central migration system from the first issuer system.

[0015] Clause 5: The system described in any of clauses 1 to 4, wherein the authentication information request history includes at least one of a token reference identifier, token requestor data, a merchant identifier associated with the original account identifier, or any combination thereof.

[0016] Clause 6: The system of any of clauses 1 to 5, wherein the account data associated with at least one device token includes a new token.

[0017] Clause 7: The system of any of clauses 1-6, wherein the account data associated with at least one provisioned credential includes at least one of a digit subset of a new account identifier, a token corresponding to the new account identifier, the new account identifier, or any combination thereof.

[0018] Clause 8: The system of any of clauses 1-7, wherein the at least one provisioned credential associated with the original account identifier includes at least one of a card-on-file merchant credential and a device token, and wherein automatically generating an update request in response to identifying the at least one provisioned credential comprises: in response to identifying the card-on-file merchant credential, automatically generating a merchant update request configured to cause the card-on-file merchant's merchant system and / or the card-on-file merchant's payment gateway to update account data associated with the provisioned credential and stored by the merchant system or the card-on-file merchant's payment gateway; and in response to identifying the device token, automatically generating a device update request configured to cause the user device to update account data associated with the device token and stored by the user device.

[0019] Clause 9: A computer-implemented method, comprising: receiving, at at least one processor of a transaction processing system from a first issuer system, a migration request identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier, wherein the original account identifier is associated with a second transaction processing system; analyzing, at the at least one processor, the credential request history to identify at least one provisioned credential associated with the original account identifier, wherein the at least one provisioned credential comprises at least one of a card-on-file merchant credential and a device token; and in response to identifying the at least one provisioned credential, automatically generating an update request configured to cause at least one of the merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof, to update the at least one provisioned credential based on the new account identifier.

[0020] Clause 10: The computer-implemented method of clause 9, wherein the at least one provisioned credential associated with the original account identifier includes at least one of a card-on-file merchant credential and a device token.

[0021] Clause 11: The computer-implemented method of clause 9 or 10, wherein the card-on-file merchant authentication information includes an originating account identifier.

[0022] Clause 12: The computer-implemented method of any of clauses 9-11, wherein the migration request is received via a central migration system in communication with the first issuer system, the transaction processing system, and the second transaction processing system, and at least the authentication information request history is received by the central migration system from the first issuer system.

[0023] Clause 13: The computer-implemented method of any of clauses 9-12, wherein the authentication information request history includes at least one of a token reference identifier, token requestor data, a merchant identifier associated with the original account identifier, or any combination thereof.

[0024] Clause 14: The computer-implemented method of any of clauses 9-13, wherein the account data associated with at least one device token includes a new token.

[0025] Clause 15: The computer-implemented method of any of clauses 9-14, wherein the account data associated with at least one provisioned credential includes at least one of a digit subset of a new account identifier, a token corresponding to the new account identifier, the new account identifier, or any combination thereof.

[0026] Clause 16: The computer-implemented method of any of clauses 9-15, wherein the at least one provisioned credential associated with the original account identifier includes at least one of a card-on-file merchant credential and a device token, and wherein automatically generating an update request in response to identifying the at least one provisioned credential comprises: in response to identifying the card-on-file merchant credential, automatically generating a merchant update request configured to cause a merchant system or a payment gateway associated with the card-on-file merchant to update account data associated with the provisioned credential and stored by the card-on-file merchant's merchant system or payment gateway; and in response to identifying the device token, automatically generating a device update request configured to cause the user device to update account data associated with the device token and stored by the user device.

[0027] Clause 17: A computer-implemented method comprising: receiving, at at least one processor in a transaction processing system, from a first issuer system, a migration request identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier, wherein the original account identifier is associated with a second transaction processing system; analyzing, at the at least one processor, the credential request history to identify at least one provisioned credential for a card-on-file merchant and at least one device token associated with the original identifier; in response to identifying the at least one provisioned credential for the card-on-file merchant, automatically generating a merchant update request configured to cause the card-on-file merchant to update account data associated with the provisioned credential and stored in the card-on-file merchant's merchant system; and in response to identifying the at least one device token, automatically generating a device update request to a user device configured to cause the user device to update account data associated with the at least one device token and stored by the user device.

[0028] Clause 18: A computer program product comprising at least one non-transitory computer-readable medium comprising program instructions that, when executed by at least one processor in a transaction processing system, cause the at least one processor to: receive, from a first issuer system, a migration request identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier, where the original account identifier is associated with a second transaction processing system; analyze the credential request history to identify at least one provisioned credential associated with the original account identifier, where the at least one provisioned credential includes at least one of a card-on-file merchant credential and a device token; and in response to identifying the at least one provisioned credential, automatically generate an update request configured to cause at least one of the merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof to update the at least one provisioned credential based on the new account identifier.

[0029] These and other characteristics and features of the present disclosure, as well as the method of operation and function of associated elements of construction and combination of parts and economies of manufacture, will become more apparent from a consideration of the following description and appended claims with reference to the accompanying drawings, all of which form a part of this specification, and in which like reference numerals indicate corresponding parts in the various views, it being expressly understood, however, that the drawings are for purposes of illustration and description and are not intended as a limiting definition of the disclosed subject matter. [Brief explanation of the drawings]

[0030] Further advantages and details are explained in more detail below with reference to non-limiting exemplary embodiments shown in the accompanying schematic drawings.

[0031] [Figure 1] FIG. 1 is a schematic diagram of a system for automatically updating authentication information, according to some non-limiting embodiments or aspects. [Figure 2] FIG. 2 is a flow diagram of a method for automatically updating authentication information according to some non-limiting embodiments or aspects. [Figure 3] FIG. 3 is a further schematic diagram of a system for automatically updating authentication information, according to some non-limiting embodiments or aspects. [Figure 4] FIG. 4 is a further schematic diagram of a system for automatically updating authentication information, according to some non-limiting embodiments or aspects. [Figure 5] FIG. 5 is a schematic diagram of an electronic payment processing network, according to some non-limiting embodiments or aspects. [Figure 6] FIG. 6 is a schematic diagram of exemplary components of one or more devices, according to some non-limiting embodiments or aspects. DETAILED DESCRIPTION OF THE INVENTION

[0032] Hereinafter, for purposes of description, the terms "end," "top," "bottom," "right," "left," "vertical," "horizontal," "top," "bottom," "lateral," "longitudinal," and their derivatives refer to the present embodiment as oriented in the drawings. However, it is to be understood that the present embodiment may assume various alternative variations and step sequences unless expressly specified to the contrary. It will also be understood that the specific devices and processes illustrated in the accompanying drawings and described in the following specification are merely exemplary embodiments or aspects of the disclosed subject matter. Hence, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein are not to be considered limiting.

[0033] No aspect, component, element, structure, act, step, function, instruction, and / or the like used herein should be construed as critical or essential unless expressly stated as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more" and "at least one." Furthermore, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, and / or the like) and may be used interchangeably with "one or more" or "at least one." Where only one item is intended, the term "one" or similar language is used. Also, as used herein, the terms "has," "have," "having," or similar terms are intended to be open-ended. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise.

[0034] As used herein, the term "acquirer institution" may refer to an entity licensed and / or authorized by a transaction service provider to initiate transactions (e.g., payment transactions) using payment devices associated with the transaction service provider. Transactions that an acquirer institution may initiate may include payment transactions (e.g., purchases, original credit transactions (OCTs), account funds transactions (AFTs), and / or the like). In some non-limiting embodiments or aspects, an acquirer institution may be a financial institution such as a bank. As used herein, the term "acquirer system" may also refer to one or more computing devices operated by or on behalf of an acquirer institution, such as a server computer running one or more software applications.

[0035] As used herein, the term "account identifier" may include one or more primary account numbers, PANs, tokens, or other identifiers associated with a customer account. The term "token" may refer to an identifier used as a substitute or alternative identifier for an original account identifier, such as a PAN. An account identifier may be alphanumeric or any combination of letters and / or symbols. A token may be associated with a PAN or other original account identifier in one or more data structures (one or more databases, and / or the like) such that it can be used to conduct transactions without directly using the original account identifier. In some embodiments, an original account identifier, such as a PAN, may be associated with multiple tokens for different individuals or for different purposes.

[0036] An "application program interface" (API) refers to computer code or other data sorted on a computer-readable medium that can be executed by a processor to facilitate interaction between software components, such as a client-side front end and / or a server-side back end for receiving data from a client. An "interface" refers to a generated display, such as one or more graphical user interfaces (GUIs), with which a user can interact directly or indirectly (e.g., via a keyboard, mouse, etc.).

[0037] As used herein, the term "communication" may refer to the receipt, reception, transmission, transfer, provision, and / or the like of data (e.g., information, signals, messages, instructions, commands, and / or the like). When one unit (e.g., a device, system, or component of a device or system, combinations thereof, and / or the like) communicates with another unit, it means that the unit can directly or indirectly receive information from and / or transmit information to the other unit. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, and / or the like) that is wired and / or wireless in nature. Furthermore, when two units communicate with each other, the information transmitted may be modified, processed, relayed, and / or routed between the first and second units. For example, a first unit may be communicating with a second unit even if the first unit passively receives information and does not actively transmit information to the second unit. As another example, a first unit may communicate with a second unit if at least one intermediate unit processes information received from the first unit and communicates the processed information to the second unit.

[0038] As used herein, the term "computing device" may refer to one or more electronic devices configured to process data. A computing device, in some embodiments, may include components necessary to receive, process, and output data, such as a processor, a display, a memory, input devices, a network interface, and / or the like. A computing device may be a mobile device. By way of example, a mobile device may include a mobile phone (e.g., a smartphone or a standard mobile phone), a portable computer, a wearable device (e.g., a watch, eyeglasses, lenses, clothing, and / or the like), a personal digital assistant (PDA), and / or other similar devices. A computing device may also be a desktop computer or other form of non-mobile computer.

[0039] As used herein, the terms "electronic wallet" and "electronic wallet application" refer to one or more electronic devices and / or software applications configured to initiate and / or conduct payment transactions. For example, an electronic wallet may include a mobile device running an electronic wallet application and may further include server-side software and / or databases for maintaining and providing transaction data to the mobile device. An "electronic wallet provider" may include an entity that offers and / or maintains electronic wallets for customers, such as Google Pay®, Android Pay®, Apple Pay®, Samsung Pay®, and / or other similar electronic payment systems. In some non-limiting examples, an issuer bank may be an electronic wallet provider.

[0040] As used herein, the term "issuer institution" may refer to one or more entities, such as a bank, that provide a customer with an account for conducting transactions (e.g., payment transactions), such as initiating credit and / or debit payments. For example, an issuer institution may provide a customer with an account identifier, such as a PAN, that uniquely identifies one or more accounts associated with the customer. The account identifier may be displayed on a portable financial device, such as a physical financial instrument, e.g., a payment card, and / or may be electronic and used for electronic payments. The term "issuer system" may also refer to one or more computing devices operated by or on behalf of an issuer institution, such as a server computer running one or more software applications. For example, an issuer system may include one or more authentication servers for authorizing transactions.

[0041] As used herein, the term "merchant" may refer to an individual or entity that provides goods and / or services, or access to goods and / or services, to customers based on a transaction, such as a payment transaction. The terms "merchant" or "merchant system" may also refer to one or more computer systems operated by or on behalf of a merchant, such as a server computer running one or more software applications.

[0042] As used herein, a "point of sale (POS) device" may refer to one or more devices that may be used by a merchant to conduct and / or process transactions (e.g., payment transactions). For example, a POS device may include one or more client devices. Additionally or alternatively, a POS device may include peripheral devices, card readers, scanning devices (e.g., code scanners), Bluetooth® communication receivers, near field communication (NFC) receivers, RFID receivers, and / or other contactless transceivers or receivers, contact receivers, payment terminals, and / or the like. As used herein, a "point of sale (POS) system" may refer to one or more client devices and / or peripherals used by a merchant to conduct transactions. For example, a POS system may include one or more POS devices and / or other similar devices that may be used to conduct payment transactions. In some non-limiting embodiments or aspects, a POS system (e.g., a merchant POS system) may include one or more server computers programmed and / or configured to process online payment transactions through a web page, a mobile application, and / or the like.

[0043] As used herein, the terms “client” and “client device” may refer to one or more client-side devices or systems (e.g., remote from a transaction service provider) used to initiate or facilitate a transaction (e.g., a payment transaction). By way of example, a “client device” may refer to one or more point-of-sale devices used by a merchant, one or more acquirer host computers used by an acquirer, one or more mobile devices used by a user, and / or the like. In some non-limiting embodiments or aspects, a client device may be an electronic device configured to communicate with one or more networks and to initiate or facilitate a transaction. For example, a client device may include one or more computers, portable computers, laptop computers, tablet computers, mobile devices, mobile phones, wearable devices (e.g., watches, eyeglasses, lenses, clothing, and / or the like), PDAs, and / or the like. Furthermore, a “client” may also refer to an entity (e.g., a user, a merchant, an acquirer, and / or the like) that owns, uses, and / or operates a client device to initiate a transaction (e.g., to initiate a transaction with a transaction service provider).

[0044] As used herein, the term "payment device" may refer to a payment card (e.g., a credit or debit card), a gift card, a smart card, smart media, a payroll card, a healthcare card, a wristband, a machine-readable medium containing account information, a keychain device or fob, an RFID transponder, a merchant discount or loyalty card, a mobile phone, an electronic wallet mobile application, a personal digital assistant (PDA), a pager, a security card, a computing device, an access card, a wireless terminal, a transponder, and / or the like. In some non-limiting embodiments or aspects, a payment device may include volatile or non-volatile memory for storing information (e.g., an account identifier, the name of the account holder, and / or the like).

[0045] As used herein, the term "payment gateway" may refer to an entity and / or payment processing system operated by or on behalf of such an entity (e.g., merchant service provider, payment service provider, payment facilitator, payment facilitator contracted with acquirer, payment aggregator, and / or the like) that provides payment services (e.g., transaction service provider payment services, payment processing services, and / or the like) to one or more merchants. Payment services may be associated with the use of payment devices managed by the transaction service provider. As used herein, the term "payment gateway system" may refer to one or more computer systems, computer devices, servers, server groups, and / or the like operated by or for a payment gateway.

[0046] As used herein, the term "server" refers to or includes one or more computing devices operated by or facilitating communication and processing for multiple parties in a network environment, such as the Internet. However, it will be understood that communication may be facilitated through one or more public or private network environments, and various other arrangements are possible. Furthermore, multiple computing devices (e.g., servers, point-of-sale POS devices, mobile devices, etc.) communicating directly or indirectly within a network environment may constitute a "system."

[0047] As used herein, the term "system" may refer to one or more computing devices or a combination of computing devices (e.g., processors, servers, client devices, software applications, components of the same, and / or the like). References to a "device," "server," "processor," and / or the like, as used herein, can refer to a previously described server and / or processor, other servers and / or processors, and / or combinations of multiple servers and / or processors recited as performing a previous step or function. For example, as used in the specification and claims, a first server and / or first processor recited as performing a first step or function may refer to the same or different server and / or processor recited as performing a second step or function.

[0048] Non-limiting embodiments or aspects of the disclosed subject matter are directed to systems, methods, and computer program products for automatically updating credentials that improve upon existing credential update methods. In non-limiting embodiments, a user does not need to engage in additional steps to update authentication information (e.g., payment credentials, including account identifiers and tokens) for a payment application or provider (e.g., a merchant, an electronic wallet, and / or the like).

[0049] Referring to FIG. 1 , a system 1000 for automatically updating credentials is illustrated, according to some non-limiting embodiments or aspects. The transaction processing system 100 includes a digital credential update service 102 and a token management system 104. The digital credential update service 102 may include software and / or hardware, such as a server computer that runs one or more software applications as a service. The token management system 104 may include software and / or hardware, such as a server computer that runs one or more applications as a service, applications executed by the transaction processing system, and / or the like. The token management system 104 may manage (e.g., issue, store, maintain, etc.) tokens for merchants (e.g., merchant tokens) and / or devices (e.g., device tokens for user devices).

[0050] The transaction processing system 100 may be in communication with an issuer system 106, which may include and / or communicate with an issuer token vault 108. The issuer token vault 108 may include software and / or hardware, such as a network-accessible data storage device and / or associated software application(s), for storing and / or retrieving one or more tokens issued by an issuer corresponding to the issuer system 106. The issuer system 106 may communicate with the cardholder 112 directly and / or via an application 110 (e.g., a mobile application, a website, and / or the like). In the illustrated example, the issuer system 106 may be switched from a first transaction processing system 101 (e.g., an originating transaction processing system) to a second transaction processing system 100 (e.g., a target transaction processing system). In such an embodiment, the issuer system 106 may generate a new PAN and issue a new payment device based on the new PAN.

[0051] Continuing with reference to FIG. 1 , the issuer system 106 may send a migration request to the transaction processing system 100 that includes the original PAN (e.g., associated with the first transaction processing system), the new PAN, and a credential request history. The credential request history may be generated based on a query of the issuer token vault 108 and may include a list of all merchants, applications, and / or other entities or systems to which provisioned credentials (e.g., PANs and / or PAN-based tokens) have been provided. The credential request history may be generated based on records of tokens issued to one or more entities and / or systems. The credential request history may include a list of one or more merchants, a list of one or more devices, a list of token reference identifiers (e.g., portions of tokens and / or unique identifiers corresponding to tokens), and / or a list of one or more applications (e.g., electronic wallets, merchant applications, and / or the like) associated with the provisioned credentials (e.g., PANs and / or tokens). In some non-limiting embodiments, the migration request may include the credential request history. In other non-limiting embodiments, the migration request may cause the transaction processing system 100 to query the issuer system 106 for a credential request history.

[0052] In a non-limiting embodiment, in addition to or alternatively to the issuer system 106 querying the issuer token vault 108 for credential data, the issuer system 106 may query the first transaction processing system 101 (the original transaction processing system and / or the migrated payment scheme, which may include the original transaction processing system's token service) to obtain credential data, including previous token requests, lists of merchants, and / or the like. In some embodiments, the issuer system 106 may use one or more APIs exposed by the original transaction processing system 101.

[0053] With further reference to FIG. 1 , the transaction processing system 100 may generate an update request that is communicated to a merchant, application, device, and / or system to update at least one provisioned credential based on a new account identifier (e.g., a new PAN). For example, the token management system 104 may provide a new merchant token to the card-on-file merchant system 116. The token management system 104 may provide a new device token to a user device (e.g., a mobile device with an electronic wallet). The token management system 104 may also provide a merchant token to a card-on-file merchant system 112 that previously stored the original PAN but is transitioning to a token-based arrangement such that a new PAN is not stored by the merchant. In some non-limiting embodiments, the update request may include a reference to the previous credential (e.g., the previous PAN or token), which allows the merchant system 112, 116, and / or device wallet 118 to locate, delete, and / or replace the previous credential with a new credential. The device wallet 118 may be an electronic wallet on a user computing device (e.g., a mobile device, etc.) that has provisioned authentication information (e.g., one or more tokens and / or a PAN).

[0054] In some non-limiting embodiments, one or more payment gateways (not shown in FIG. 1 ) may hold the provisioned credentials in examples where the merchant system may not store the credentials because the payment gateway stores the provisioned credentials on behalf of the merchant. As used herein, a "card-on-file merchant" may refer to a merchant that stores the provisioned credentials directly and / or a merchant that uses a payment gateway to store the provisioned credentials for use by the merchant. In non-limiting embodiments, the token management system 104 may provide an update request to the payment gateway corresponding to the merchant.

[0055] In some non-limiting embodiments, the update request may include a portion of the new PAN (e.g., the last four digits, the first six digits, or the bank identification number (BIN), and / or the like). For example, the update request may include the last four digits of the new PAN so that the merchant and / or device can update and associate provisioned credentials (e.g., new token, old token, new PAN, and / or the like) with the last four digits, which may then be displayed to the user for selection of a payment device (e.g., a user selecting to transact with a payment device ending in the digits "1234"). For example, the merchant or wallet provider may display the last four digits of the old PAN to the user, and, based on the update request, may display the last four digits of the new PAN for display to the user on the wallet or merchant payment checkout page to identify that new credentials are being used. In such an example, the user no longer sees a reference to the old PAN or token.

[0056] The update request may include any other data used by the merchant systems 112, 114, 116, and / or the device wallet 118. In a non-limiting embodiment, a card-on-file merchant 114 may be provided with a new PAN (e.g., rather than, or in addition to, a token) by the digital credential update service 102 to be stored by the merchant 114. Such a merchant may be offered the option to switch to a token-based arrangement (e.g., with the merchant 112) rather than storing the PAN on file, in which case the token management system 104 may generate and communicate a new merchant token.

[0057] In non-limiting embodiments, transaction processing system 100 may process multiple update requests for multiple merchants and / or devices in a batch. The update requests may be generated and communicated automatically (e.g., without the need for a user to take additional action) to the merchant and / or device (e.g., or an application running thereon). In some non-limiting embodiments, the merchant and / or device may be configured to receive such update requests from transaction processing system 100. In some non-limiting embodiments, transaction processing system 100 may generate the update request based on the protocol and / or format of the merchant and / or device being updated and may communicate the update request via an application program interface (API) offered by the merchant and / or device. In some non-limiting embodiments, transaction processing system 100 may offer an API for the merchant and / or device to request updated authentication information. An "application program interface" (API) refers to computer code or other data sorted on a computer-readable medium that can be executed by a processor to facilitate interaction between software components, such as a client-side front end and / or a server-side back end for receiving data from a client.

[0058] In non-limiting embodiments, an update request sent to a merchant 112, 114, 116, and / or device wallet 118 may notify those entities that new credentials are available. For example, the update request may include a flag or some other indicator that, when received, is used to determine that new credentials are available. The update request may include the new credential(s). In some non-limiting embodiments in which the update request does not include new credentials, the entity may, in response to such notification, generate and communicate a credential request (e.g., a request for a new token, a new PAN, new credential data, and / or the like) to transaction processing system 100. Transaction processing system 100 may then provide the requested data (e.g., a new token, a new PAN, credential data, and / or the like) to the requested entity.

[0059] Referring to FIG. 4 , a system 1004 for automatically updating authentication information is shown, according to some non-limiting embodiments or aspects. In some non-limiting embodiments, a central translocation system 140 may facilitate automatically updating authentication information. For example, the central translocation system 140 may include one or more computing devices (e.g., server computers) that communicate with multiple transaction processing systems 100, 101 (e.g., multiple payment networks) and multiple issuer systems 106, 142. In such examples, the central translocation system 140 may expose one or more APIs to facilitate communication between the transaction processing systems 100, 101 and / or the issuer systems 106, 142. For example, the central translocation system 140 may enable a transaction processing system 100 to request authentication information data (e.g., authentication information request history, etc.) from another transaction processing system 101. It will be appreciated that various other arrangements are possible.

[0060] In some non-limiting embodiments, each transaction processing system 100, 101 (e.g., each payment network) may provide one or more interfaces (e.g., an API and / or a graphical user interface (GUI) with input options) through which issuers provide information about the previous payment scheme being migrated. In response to such a migration request, the transaction processing system may automatically contact all systems that have the old credentials (e.g., the previous PAN and / or tokens linked to the previous PAN) and have those systems update the old credentials with the new credentials. In non-limiting embodiments, the migration may be seamless to account holders and merchants, allowing transactions to continue to be processed normally during the period in which the migration occurs.

[0061] In some non-limiting embodiments, the issuer system may communicate a single command to the transaction processing system 100 to update authentication information across multiple merchants and / or devices. In some examples, the transaction processing system may communicate directly to request, verify, and / or cross-check authentication information data required for migration, thereby reducing the amount of data transmitted by and / or requested from the issuer system.

[0062] Non-limiting embodiments may be used to update a card-on-file PAN to a token, update a card-on-file PAN to a new PAN, update a card-on-file token to a new token, and / or update a device token to a new token. In non-limiting embodiments in which the system 1000 is used to update a card-on-file PAN to a new PAN, a merchant (e.g., merchant 114) may request and / or obtain a list of PANs corresponding to the updated PAN from the digital credential update service 102 and may receive notification of the new credential from the digital credential update service 102. In non-limiting embodiments in which the system 1000 is used to update a card-on-file token to a new token, notification may be communicated from the token management system 104 to a merchant system (e.g., merchant system 112 and / or merchant system 116). In a non-limiting embodiment in which the system 1000 is used to update a card-on-file PAN to a token, switching from using a PAN, an acquirer system (not shown in FIG. 1 ) associated with a merchant system (e.g., merchant system 112) may provide the token reference identifier to the merchant system 112, causing the merchant system 112 to communicate the token reference identifier to the transaction processing system 100 (and / or token management system 104) and, in response to the token reference identifier, to replace the on-file PAN by receiving a stored token in place of the card-on-file PAN.

[0063] Referring now to FIG. 3 , another system 1003 for automatically updating credentials is illustrated, according to some non-limiting embodiments or aspects. In this example, the issuer application 110 and / or issuer system 106 may initiate push-based provisioning of new credentials by communicating directly with the device wallet 118 (e.g., without communicating through the transaction processing system 100). For example, in an example where a token is remapped to a new PAN, notification from the issuer application 110 and / or issuer system 106 to the device wallet 118 may cause the device wallet 118 to display the last four (4) digits, or some other portion of the PAN and / or token, to allow a user to identify the credentials. As another example where a token is remapped to a new PAN, notification to a merchant system (e.g., the merchant system 116) may provide the last four (4) digits, or some other identifier.

[0064] Referring now to FIG. 2, a flow diagram of a method for automatically updating authentication information according to a non-limiting embodiment is shown. The steps shown in FIG. 2 are for illustrative purposes only. It will be understood that different, additional, fewer, and / or different orders of steps may be used in non-limiting embodiments or aspects. In step 300, a new PAN is issued to the account holder by the issuer system. The new PAN may be associated with a new transaction processing system (e.g., a new payment network), and the account holder previously held an account (and associated payment device) through a different transaction processing system. Once the new PAN is issued, the issuer system may wait for the user to activate the new PAN via an issuer application, issuer website, and / or the like. In response to determining in step 302 that the user has activated the new PAN, the method may proceed to step 304.

[0065] In step 304 of FIG. 2 , the issuer system may extract credential data, such as existing tokens, token request history, PAN request history, credential holding entities (e.g., merchants, applications, devices, and / or the like), from one or more databases. In some embodiments, the issuer system may communicate with a Token Vault that it maintains and / or has access to. In some embodiments, an entity other than the issuer system may extract and / or compile the credential data. For example, a transaction processing system may extract the credential data after being provided access to any databases and / or systems that store it. In some non-limiting embodiments, in addition to or instead of the issuer system extracting the credential data from one of its own databases, the issuer system may query the original transaction processing system (the payment scheme being migrated, which may include the original transaction processing system and / or the token service of the original transaction processing system) to obtain credential data, including previous token requests, lists of merchants, and / or the like. In some embodiments, the issuer system may use one or more APIs exposed by the original transaction processing system.

[0066] In step 306, a migration request is generated that includes the credential data generated in step 300, the old PAN, and the new PAN. The migration request may be one or more messages generated by the issuer system and communicated to the transaction processing system. However, it will be appreciated that one or more other entities may generate and / or communicate the migration request. In step 308, the migration request is communicated to the transaction processing system.

[0067] At step 310, in response to receiving the migration request at step 308, the transaction processing system may analyze the credential data to identify multiple credential-holding entities. For example, if the credential data is in a formatted data structure, the transaction processing system may parse the data structure to identify each entity, such as a merchant, an application, and / or a device, that may hold the credential. At step 312, a batch of update requests may be automatically generated for each entity identified at step 310. The update requests may be generated based on the type of entity, such as an entity holding a PAN, an entity holding a merchant token (e.g., a merchant), an entity holding a device token (e.g., an application, a device, and / or the like), and / or the like. At step 314, the update requests are communicated to the entities. In some non-limiting embodiments, steps 310-312 may be performed automatically and without user intervention in response to receiving the migration request. In some embodiments, steps 304-312 may be performed in response to a user activating a new PAN, such that automatically updated credentials are part of the activation flow.

[0068] FIG. 5 illustrates an electronic payment processing network 1100 according to a non-limiting embodiment or aspect. The payment processing network may be used in conjunction with the systems and methods described herein. It will be understood that the particular configuration of the electronic payment processing network 1100 shown is for illustrative purposes only, and that various configurations are possible. A transaction processing system 1101 (e.g., a transaction handler) is shown communicating with one or more issuer systems (e.g., issuer system 1106) and one or more acquirer systems (e.g., acquirer system 1108). While only a single issuer system 1106 and a single acquirer system 1108 are shown, it will be understood that the transaction processing system 1101 may communicate with multiple issuer systems and / or acquirer systems. In some embodiments, the transaction processing system 1101 may also operate as an issuer system, such that both the transaction processing system 1101 and the issuer system 1106 are a single system and / or controlled by a single entity.

[0069] In some non-limiting embodiments or aspects, the transaction processing system 1101 may communicate directly with the merchant system 1104 via a public or private network connection. Additionally or alternatively, the transaction processing system 1101 may communicate with the merchant system 1104 via a payment gateway 1102 and / or an acquirer system 1108. In some non-limiting embodiments or aspects, the acquirer system 1108 associated with the merchant system 1104 may act as the payment gateway 1102 to facilitate communication of transaction requests from the merchant system 1104 to the transaction processing system 1101. The merchant system 1104 may communicate with the payment gateway 1102 via a public or private network connection. For example, a merchant system 1104 including a physical point-of-sale device may communicate with the payment gateway 1102 via a public network or a private network to conduct card-present transactions. As another example, a merchant system 1104 including a server (e.g., a web server) may communicate with the payment gateway 1102 over a public or private network, such as a public internet connection, to conduct card-not-present transactions.

[0070] In some non-limiting embodiments or aspects, after the transaction processing system 1101 receives a transaction request from the merchant system 1104 that identifies the account identifier of a payer (e.g., an account holder) associated with the issued payment device 1110, the transaction processing system 1101 may generate an authorization request message that is communicated to the issuer system 1106 that issued the payment device 1110 and / or the account identifier. The issuer system 1106 may then approve or deny the authorization request and, based on the approval or denial, generate an authorization response message that is communicated to the transaction processing system 1101. The transaction processing system 1101 may communicate the approval or denial to the merchant system 1104. If the issuer system 1106 approves the authorization request message, it may then clear and settle the payment transaction between the issuer system 1106 and the acquirer system 1108.

[0071] Referring now to FIG. 6 , a diagram of exemplary components of device 400 is shown, according to a non-limiting embodiment or aspect. Device 400 may correspond to at least one of the computing devices (e.g., transaction processing system 100, issuer system 106, and / or the like) of FIG. 1 . In some non-limiting embodiments or aspects, such a system or device may include at least one device 400 and / or at least one component of device 400. The number and arrangement of components shown in FIG. 6 are provided as an example. In some non-limiting embodiments or aspects, device 400 may include additional components, fewer components, different components, or components in a different arrangement compared to those shown in FIG. 6 . Additionally or alternatively, a set of components (e.g., one or more components) of device 400 may perform one or more functions described as being performed by another set of components of device 400.

[0072] 6 , device 400 may include a bus 402, a processor 404, a memory 406, a storage component 408, an input component 410, an output component 412, and a communication interface 414. Bus 402 may include components that enable communication between the components of device 400. In some non-limiting embodiments or aspects, processor 404 may be implemented in hardware, firmware, or a combination of hardware and software. For example, processor 404 may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, a digital signal processor (DSP), and / or any processing component (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.) that may be programmed to perform functions. The memory 406 may include random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and / or instructions for use by the processor 404.

[0073] 6 , storage component 408 may store information and / or software related to the operation and use of device 400. For example, storage component 408 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, a solid-state disk, etc.) and / or another type of computer-readable medium. Input component 410 may include components that enable device 400 to receive information via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, etc.). Additionally or alternatively, input component 410 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.). Output component 412 may include components that provide output information from device 400 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.). The communication interface 414 may include transceiver-like components (e.g., a transceiver, a separate receiver and transmitter, etc.) that enable the device 400 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 414 may allow the device 400 to receive information from another device and / or provide information to another device. For example, the communication interface 414 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a wireless radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, and / or the like.

[0074] The device 400 may perform one or more processes described herein. The device 400 may perform these processes based on the processor 404 executing software instructions stored by a computer-readable medium, such as the memory 406 and / or the storage component 408. The computer-readable medium may include any non-transitory memory device. The memory device may include a memory space located within a single physical storage device or a memory space spread across multiple physical storage devices. The software instructions may be read into the memory 406 and / or the storage component 408 from another computer-readable medium or from another device via the communication interface 414. When executed, the software instructions stored in the memory 406 and / or the storage component 408 may cause the processor 404 to perform one or more processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement one or more processes described herein. Thus, the embodiments described herein are not limited to any specific combination of hardware circuitry and software. As used herein, the term "configured to" may refer to an arrangement of software, device(s), and / or hardware to perform and / or enable one or more functions (e.g., actions, processes, process steps, and / or the like). For example, a "processor configured to" may refer to a processor that executes software instructions (e.g., program code) that cause the processor to perform one or more functions.

[0075] While embodiments have been described in detail for purposes of illustration, it should be understood that such details are for that purpose only and that the disclosure is not limited to the disclosed embodiments or aspects, but on the contrary, is intended to cover modifications and equivalent arrangements within the spirit and scope of the appended claims. For example, it should be understood that the disclosure contemplates that, to the extent possible, one or more features of any embodiment or aspect can be combined with one or more features of any other embodiment or aspect.

Claims

1. 1. A system comprising at least one processor of a transaction processing system, the at least one processor comprising: receiving, from a first issuer system, a migration request identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier, wherein the original account identifier is associated with a second transaction processing system; analyzing the credential request history to identify at least one provisioned credential associated with the original account identifier, the at least one provisioned credential including at least one of a card-on-file merchant credential and a device token; and in response to identifying the at least one provisioned credential, automatically generating an update request based on the new account identifier, the update request configured to cause at least one of a merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof, to update the at least one provisioned credential.

2. 2. The system of claim 1, wherein the at least one provisioned credential associated with the original account identifier comprises at least one of a card-on-file merchant credential and the device token.

3. 10. The system of claim 1, wherein the at least one card-on-file merchant authentication information includes the original account identifier.

4. 2. The system of claim 1, wherein the migration request is received via a central migration system in communication with the first issuer system, the transaction processing system, and the second transaction processing system, and wherein at least the authentication information request history is received by the central migration system from the first issuer system.

5. 2. The system of claim 1, wherein the credential request history includes at least one of a token reference identifier, token requestor data, a merchant identifier associated with the original account identifier, or any combination thereof.

6. The system of claim 1 , wherein the account data associated with the device token includes a new token.

7. 2. The system of claim 1, wherein account data associated with the at least one provisioned credential includes at least one of a digit subset of the new account identifier, a token corresponding to the new account identifier, the new account identifier, or any combination thereof.

8. the at least one provisioned credential associated with the original account identifier includes at least one of a card-on-file merchant credential and the device token, and automatically generating the update request in response to identifying the at least one provisioned credential; automatically generating a merchant update request in response to identifying the at least one card-on-file merchant credential, the merchant system for the card-on-file merchant and / or the payment gateway for the card-on-file merchant configured to update account data associated with the provisioned credential and stored by the merchant system or the card-on-file merchant's payment gateway; and in response to identifying the device token, automatically generating a device update request configured to cause the user device to update account data associated with the device token and stored by the user device.

9. 1. A computer-implemented method comprising: receiving, at at least one processor of the transaction processing system, from a first issuer system, a migration request identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier, wherein the original account identifier is associated with a second transaction processing system; analyzing, with the at least one processor, a credential request history to identify at least one provisioned credential associated with the original account identifier, the at least one provisioned credential including at least one of a card-on-file merchant credential and a device token; and in response to identifying the at least one provisioned credential, automatically generating an update request based on the new account identifier, the update request configured to cause at least one of a merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof, to update the at least one provisioned credential.

10. 10. The computer-implemented method of claim 9, wherein the at least one provisioned credential associated with the original account identifier comprises at least one of a card-on-file merchant credential and the device token.

11. 10. The computer-implemented method of claim 9, wherein the at least one of the card-on-file merchant authentication information includes the original account identifier.

12. 10. The computer-implemented method of claim 9, wherein the migration request is received via a central migration system in communication with the first issuer system, the transaction processing system, and the second transaction processing system, and wherein at least the authentication information request history is received by the central migration system from the first issuer system.

13. 10. The computer-implemented method of claim 9, wherein the credential request history includes at least one of a token reference identifier, token requestor data, a merchant identifier associated with the original account identifier, or any combination thereof.

14. The computer-implemented method of claim 9 , wherein the account data associated with the device token includes a new token.

15. 10. The computer-implemented method of claim 9, wherein account data associated with the at least one provisioned credential comprises at least one of a subset of digits of the new account identifier, a token corresponding to the new account identifier, the new account identifier, or any combination thereof.

16. the at least one provisioned credential associated with the original account identifier includes at least one of a card-on-file merchant credential and the device token, and automatically generating the update request in response to identifying the at least one provisioned credential; automatically generating a merchant update request in response to identifying at least one of the card-on-file merchant credentials, the merchant system or payment gateway associated with the card-on-file merchant configured to update account data associated with the provisioned credentials and stored by the merchant system or payment gateway for the card-on-file merchant; 10. The computer-implemented method of claim 9, comprising: in response to identifying the device token, automatically generating a device update request configured to cause a user device to update account data associated with the device token and stored by the user device.

17. 1. A computer-implemented method comprising: receiving, at at least one processor of a transaction processing system, a migration request from a first issuer system identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier, wherein the original account identifier is associated with a second transaction processing system; analyzing, with the at least one processor, the credential request history to identify at least one provisioned credential for a card-on-file merchant and at least one device token associated with the original account identifier; automatically generating a merchant update request in response to identifying the provisioned credentials of at least one card-on-file merchant, the merchant update request configured to cause the card-on-file merchant to update account data associated with the provisioned credentials and stored by the card-on-file merchant's merchant system; and in response to identifying the at least one device token, automatically generating a device update request configured to cause a user device to update account data associated with the at least one device token and stored by the user device.

18. 1. A computer program product comprising: at least one non-transitory computer-readable medium containing program instructions that, when executed by at least one processor of a transaction processing system, cause the at least one processor to: receiving a migration request from a first issuer system identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier, wherein the original account identifier is associated with a second transaction processing system; analyzing the credential request history to identify at least one provisioned credential associated with the original account identifier, the at least one provisioned credential including at least one of a card-on-file merchant credential and a device token; and in response to identifying the at least one provisioned credential, automatically generating an update request based on the new account identifier, the update request configured to cause at least one of a merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof, to update the at least one provisioned credential.