Systems, methods, and computer program products for automatically updating credentials

Abstract

A system, method, and computer program product for automatically updating credentials are provided. The system includes at least one processor programmed or configured to: receive a migration request from a first issuer system, the migration request identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier; analyzing the credential request history to identify at least one pre-provisioned credential associated with the original account identifier, the at least one pre-provisioned credential including at least one of a card archive merchant credential and a device token; and in response to identifying the at least one provisioning credential, automatically generating an 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 provisioning credential based on the new account identifier.

Description

[0001] Cross-referencing related applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 447,717, filed on February 23, 2023, the disclosure of which is hereby incorporated in its entirety. Technical Field

[0003] This disclosure generally relates to credentials, and in some non-limiting embodiments or aspects, to systems, methods, and computer program products for automatically updating credentials. Background Technology

[0004] When payment card issuers migrate from one scheme (e.g., a payment network) to another, the process involves reissuing all their cards under the portfolio being migrated. This results in cardholders receiving new cards from one scheme, replacing their old cards from the other. With the increasing use of device-based credentials and card archiving credentials, these scheme migrations become more difficult and complex because they require cardholders to manually delete and re-provision tokens on their devices and contact each card archiving merchant to change their card details. Failure to do so will result in transaction rejection. Furthermore, existing processes for changing credentials utilize numerous communications, messages, and repetitive requests and / or queries, leading to wasted computational / processing resources and additional opportunities for security vulnerabilities. Summary of the Invention

[0005] According to a non-limiting embodiment or aspect, a system is provided that includes at least one processor of a transaction processing system, the at least one processor being programmed or configured to: receive a migration request from a first issuing system, the 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 pre-configured credential associated with the original account identifier, the at least one pre-configured credential including at least one of a card archive merchant credential and a device token; and automatically generate an update request in response to identifying the at least one pre-configured credential, the update request being configured to update the at least one pre-configured credential based on at least one of the following: a merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof.

[0006] In a non-limiting embodiment or aspect, at least one provisioned credential associated with the original account identifier includes at least one of a card archive merchant credential and a device token. In a non-limiting embodiment or aspect, the card archive merchant credential includes the original account identifier. In a non-limiting embodiment or aspect, a migration request is received via a central migration system communicating with a first issuing system, a transaction processing system, and a second transaction processing system, and wherein at least a credential request history is received by the central migration system from the first issuing system. In a non-limiting embodiment or aspect, the credential request history includes at least one of the following: a token reference identifier, token requester 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 at least one device token includes a new token. In a non-limiting embodiment or aspect, the account data associated with at least one provisioned credential includes at least one of the following: a numerical subset 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, at least one pre-configured credential associated with the original account identifier includes at least one of a card archive merchant credential and a device token, and automatically generating an update request in response to identifying at least one pre-configured credential includes: automatically generating a merchant update request in response to identifying the card archive merchant credential, the merchant update request being configured to cause the card archive merchant's merchant system and / or the card archive merchant's payment gateway to update the account data associated with the pre-configured credential and stored by the card archive merchant's merchant system or payment gateway; and automatically generating a device update request in response to identifying the device token, the device update request being configured to cause the user device to update the account data associated with the device token and stored by the user device.

[0007] According to a non-limiting embodiment or aspect, a computer-implemented method is provided, comprising: receiving a migration request from a first issuing system using at least one processor of a transaction processing system, the 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; analyzing the credential request history using the at least one processor to identify at least one pre-configured credential associated with the original account identifier, the at least one pre-configured credential including at least one of a card archive merchant credential and a device token; and automatically generating an update request in response to identifying the at least one pre-configured credential, the update request being configured to update the at least one pre-configured credential based on at least one of: a merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof.

[0008] In a non-limiting embodiment or aspect, at least one provisioned credential associated with the original account identifier includes at least one of a card archive merchant credential and a device token. In a non-limiting embodiment or aspect, the card archive merchant credential includes the original account identifier. In a non-limiting embodiment or aspect, a migration request is received via a central migration system communicating with a first issuing system, a transaction processing system, and a second transaction processing system, and wherein at least a credential request history is received by the central migration system from the first issuing system. In a non-limiting embodiment or aspect, the credential request history includes at least one of the following: a token reference identifier, token requester 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 at least one device token includes a new token. In a non-limiting embodiment or aspect, the account data associated with at least one provisioned credential includes at least one of the following: a numerical subset 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, at least one pre-configured credential associated with the original account identifier includes at least one of a card archive merchant credential and a device token, and automatically generating an update request in response to identifying at least one pre-configured credential includes: automatically generating a merchant update request in response to identifying the card archive merchant credential, the merchant update request being configured to cause the merchant system or payment gateway associated with the card archive merchant to update the account data associated with the pre-configured credential and stored by the card archive merchant's merchant system or payment gateway; and automatically generating a device update request in response to identifying the device token, the device update request being configured to cause the user device to update the account data associated with the device token and stored by the user device.

[0009] According to a non-limiting embodiment or aspect, a computer-implemented method is provided, comprising: receiving a migration request from a first issuing system using at least one processor of a transaction processing system, the 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; analyzing the credential request history using the at least one processor to identify at least one pre-provisioned credential associated with the original account identifier for a card archive merchant and at least one device token; automatically generating a merchant update request in response to identifying a pre-provisioned credential for at least one card archive merchant, the merchant update request being configured to cause the card archive merchant to update account data associated with the pre-provisioned credential and stored by the card archive merchant's merchant system; and automatically generating a device update request in response to identifying at least one device token, the device update request being configured to cause a user device to update account data associated with at least one device token and stored by the user device.

[0010] According to a non-limiting embodiment or aspect, a computer program product is provided, the computer program product comprising at least one non-transitory computer-readable medium, the non-transitory computer-readable medium comprising program instructions, which, when executed by at least one processor of a transaction processing system, cause the at least one processor to: receive a migration request from a first issuing system, the 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 pre-configured credential associated with the original account identifier, the at least one pre-configured credential including at least one of a card archive merchant credential and a device token; and automatically generate an update request in response to identifying the at least one pre-configured credential, the update request being configured to cause at least one of the following to update the at least one pre-configured credential based on the new account identifier: a merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof.

[0011] Other non-limiting embodiments or aspects will be set forth in the following numbered clauses:

[0012] Clause 1: A system comprising at least one processor of a transaction processing system, the at least one processor being programmed or configured to: receive a migration request from a first issuing system, the 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 pre-configured credential associated with the original account identifier, the at least one pre-configured credential including at least one of a card archive merchant credential and a device token; and automatically generate an update request in response to identifying the at least one pre-configured credential, the update request being configured to update the at least one pre-configured credential based on at least one of: a merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof.

[0013] Clause 2: The system according to Clause 1, wherein the at least one pre-configured credential associated with the original account identifier includes at least one of a card archive merchant credential and the device token.

[0014] Clause 3: In a system pursuant to Clause 1 or 2, the card archive merchant credentials include the original account identifier.

[0015] Clause 4: A system pursuant to any one of Clauses 1 to 3, wherein the migration request is received via a central migration system that communicates with the first issuing system, the transaction processing system, and the second transaction processing system, and wherein at least the credential request history is received by the central migration system from the first issuing system.

[0016] Clause 5: In a system pursuant to any one of Clauses 1 to 4, the credential request history includes at least one of the following: a token reference identifier, token requester data, a merchant identifier associated with the original account identifier, or any combination thereof.

[0017] Clause 6: A system pursuant to any one of Clauses 1 to 5, wherein the account data associated with the at least one device token includes a new token.

[0018] Clause 7: A system pursuant to any one of Clauses 1 to 6, wherein the account data associated with the at least one pre-provisioned credential includes at least one of the following: a digital subset of the new account identifier, a token corresponding to the new account identifier, the new account identifier, or any combination thereof.

[0019] Clause 8: A system according to any one of Clauses 1 to 7, wherein the at least one pre-configured credential associated with the original account identifier includes at least one of a card archive merchant credential and the device token, and wherein automatically generating the update request in response to identifying the at least one pre-configured credential includes: automatically generating a merchant update request in response to identifying the card archive merchant credential, the merchant update request being configured to cause the merchant system of the card archive merchant and / or the payment gateway of the card archive merchant to update the account data associated with the pre-configured credential and stored by the merchant system or the payment gateway of the card archive merchant; and automatically generating a device update request in response to identifying the device token, the device update request being configured to cause the user device to update the account data associated with the device token and stored by the user device.

[0020] Clause 9: A computer-implemented method comprising: receiving a migration request from a first issuing system using at least one processor of a transaction processing system, the 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; analyzing the credential request history using the at least one processor to identify at least one pre-configured credential associated with the original account identifier, the at least one pre-configured credential including at least one of a card archive merchant credential and a device token; and automatically generating an update request in response to identifying the at least one pre-configured credential, the update request being configured to update the at least one pre-configured credential based on at least one of: a merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof.

[0021] Clause 10: The computer-implemented method according to Clause 9, wherein the at least one pre-provisioned credential associated with the original account identifier includes at least one of a card archive merchant credential and the device token.

[0022] Clause 11: A computer-implemented method according to Clause 9 or 10, wherein the card archive merchant credentials include the original account identifier.

[0023] Clause 12: A computer-implemented method according to any one of Clauses 9 to 11, wherein the migration request is received via a central migration system communicating with the first issuing system, the transaction processing system, and the second transaction processing system, and wherein at least the credential request history is received by the central migration system from the first issuing system.

[0024] Clause 13: A computer-implemented method according to any one of Clauses 9 to 12, wherein the credential request history includes at least one of the following: a token reference identifier, token requester data, a merchant identifier associated with the original account identifier, or any combination thereof.

[0025] Clause 14: A computer-implemented method according to any one of Clauses 9 to 13, wherein the account data associated with the at least one device token includes a new token.

[0026] Clause 15: A computer-implemented method according to any one of Clauses 9 to 14, wherein the account data associated with the at least one pre-provisioned credential includes at least one of the following: a digital subset of the new account identifier, a token corresponding to the new account identifier, the new account identifier, or any combination thereof.

[0027] Clause 16: A computer-implemented method according to any one of Clauses 9 to 15, wherein the at least one pre-provisioned credential associated with the original account identifier includes at least one of a card archive merchant credential and the device token, and wherein automatically generating the update request in response to identifying the at least one pre-provisioned credential includes: automatically generating a merchant update request in response to identifying the card archive merchant credential, the merchant update request being configured to cause the merchant system or payment gateway associated with the card archive merchant to update account data associated with the pre-provisioned credential and stored by the merchant system or payment gateway of the card archive merchant; and automatically generating a device update request in response to identifying the device token, the device update request being configured to cause a user device to update account data associated with the device token and stored by the user device.

[0028] Clause 17: A computer-implemented method comprising: receiving a migration request from a first issuing system using at least one processor of a transaction processing system, the 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; analyzing the credential request history using the at least one processor to identify at least one pre-provisioned credential associated with the original account identifier for a card archive merchant and at least one device token; automatically generating a merchant update request in response to identifying the pre-provisioned credential for the at least one card archive merchant, the merchant update request being configured to cause the card archive merchant to update account data associated with the pre-provisioned credential and stored by the card archive merchant's merchant system; and automatically generating a device update request in response to identifying the at least one device token, the device update request being configured to cause a user device to update account data associated with the at least one device token and stored by the user device.

[0029] Clause 18: A computer program product comprising at least one non-transitory computer-readable medium including program instructions that, when executed by at least one processor of a transaction processing system, cause the at least one processor to: receive a migration request from a first issuing system, the 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 pre-configured credential associated with the original account identifier, the at least one pre-configured credential including at least one of a card archive merchant credential and a device token; and, in response to identifying the at least one pre-configured credential, automatically generate an update request configured to update the at least one pre-configured credential based on the new account identifier by: a merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof.

[0030] The operational methods and manufacturing economics of these and other features and characteristics of this disclosure, as well as the combinations of related structural elements and parts, will become more apparent when considered with reference to the accompanying drawings, all of which form part of this specification, wherein similar reference numerals denote corresponding parts in the drawings. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to be a definition of limitation on the disclosed subject matter. Attached Figure Description

[0031] Additional advantages and details are explained in more detail below with reference to the non-limiting exemplary embodiments shown in the illustrative accompanying drawings, in which:

[0032] Figure 1 This is a schematic diagram of a system for automatically updating credentials according to some non-limiting embodiments or aspects;

[0033] Figure 2 This is a flowchart of a method for automatically updating credentials according to some non-limiting embodiments or aspects;

[0034] Figure 3 This is another schematic diagram of a system for automatically updating credentials according to some non-limiting embodiments or aspects;

[0035] Figure 4 This is another schematic diagram of a system for automatically updating credentials according to some non-limiting embodiments or aspects;

[0036] Figure 5 This is a schematic diagram of an electronic payment processing network according to some non-limiting embodiments or aspects; and

[0037] Figure 6 This is a schematic diagram of example components of one or more devices according to some non-limiting embodiments or aspects. Detailed Implementation

[0038] For the purposes of the following description, the terms “end,” “upper,” “lower,” “right,” “left,” “vertical,” “horizontal,” “top,” “bottom,” “lateral,” “longitudinal,” and their derivatives should be associated with the orientation of the embodiments in the accompanying drawings. However, it should be understood that embodiments may take various alternative variations and sequences of steps, except where explicitly specified as the opposite. It should also be understood that the specific apparatus and processes shown in the drawings and appendices and described in the following specification are merely exemplary embodiments or aspects of the disclosed subject matter. Therefore, specific dimensions and other physical characteristics relating to the embodiments or aspects disclosed herein should not be considered limiting.

[0039] The terms aspect, component, element, structure, action, step, function, instruction, etc., used herein should not be construed as critical or necessary unless explicitly stated otherwise. Furthermore, as used herein, the article “a” is intended to include one or more items and is interchangeable with “one or more” and “at least one.” Additionally, as used herein, the term “set” is intended to include one or more items (e.g., related items, unrelated items, a combination of related and unrelated items, etc.) and is interchangeable with “one or more” or “at least one.” Where only one item is desired, the term “a” or similar language is used. Moreover, as used herein, the terms “has,” “have,” “having,” etc., are intended to be open-ended terms. Furthermore, unless explicitly stated otherwise, the phrase “based on” is intended to mean “at least partially based on.”

[0040] As used herein, the term "acquiring institution" can refer to an entity licensed and / or approved by a transaction service provider to initiate transactions (e.g., payment transactions) using payment devices associated with the transaction service provider. Transactions that an acquiring institution can initiate may include payment transactions (e.g., purchases, original letter of credit transactions (OCT), account treasury transactions (AFT), etc.). In some non-limiting embodiments or aspects, the acquiring institution may be a financial institution, such as a bank. As used herein, the term "acquiring system" can refer to one or more computing devices operated by or on behalf of an acquiring institution, such as a server computer executing one or more software applications.

[0041] As used herein, the term "account identifier" can include one or more master account (PAN), tokens, or other identifiers associated with a customer account. The term "token" can refer to an identifier used as a substitute or replacement identifier for an original account identifier such as a PAN. An account identifier can be any combination of alphanumeric or characters and / or symbols. A token can be associated with a PAN or other original account identifier in one or more data structures (e.g., one or more databases, etc.) such that the token can be used to conduct transactions without directly using the original account identifier. In some examples, an original account identifier such as a PAN can be associated with multiple tokens for different individuals or purposes.

[0042] An “Application Programming Interface” (API) refers to computer code or other data ordered on a computer-readable medium that can be executed by a processor to facilitate interaction between software components, such as interaction between 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) that a user can interact with directly or indirectly (e.g., via a keyboard, mouse, etc.).

[0043] As used herein, the term "communication" can refer to the receiving, accepting, sending, transmitting, and providing of data (e.g., information, signals, messages, instructions, commands, etc.). For one unit (e.g., an apparatus, system, component of an apparatus or system, a combination thereof, and / or the like) to communicate with another unit means that the first unit is able to receive information directly or indirectly from and / or send information to the other unit. This can refer to a direct or indirect connection that is inherently wired and / or wireless (e.g., a direct communication connection, an indirect communication connection, and / or the like thereof). Furthermore, although the transmitted information may be modified, processed, relayed, and / or routed between the first and second units, the two units can also communicate with each other. For example, the first unit can communicate with the second unit even if it passively receives information and does not actively send information to the second unit. As another example, the first unit can communicate with the second unit if at least one intermediate unit processes information received from the first unit and transmits the processed information to the second unit.

[0044] As used herein, the term "computing device" can refer to one or more electronic devices configured to process data. In some examples, a computing device may include the necessary components for receiving, processing, and outputting data, such as a processor, display, memory, input device, network interface, and / or the like. A computing device can be a mobile device. As examples, a mobile device may include a cellular phone (e.g., a smartphone or standard cellular phone), a portable computer, a wearable device (e.g., a watch, glasses, lenses, clothing, etc.), a personal digital assistant (PDA), and / or other similar devices. A computing device can also be a desktop computer or other form of non-mobile computer.

[0045] As used herein, the terms "e-wallet" and "e-wallet application" refer to one or more electronic devices and / or software applications configured to initiate and / or conduct payment transactions. For example, an e-wallet may include a mobile device executing an e-wallet application, and may also include server-side software and / or a database for maintaining transaction data and providing that data to the mobile device. An "e-wallet provider" may include an entity that provides and / or maintains e-wallets for customers, such as… And / or other similar electronic payment systems. In some non-restrictive examples, the issuing bank may be an e-wallet provider.

[0046] As used herein, the term "issuer institution" can refer to one or more entities, such as a bank, that provide customers with accounts for conducting transactions (e.g., payment transactions), such as initiating credit and / or debit payments. For example, an issuer institution may provide customers with an account identifier, such as a PAN, that uniquely identifies one or more accounts associated with said customer. The account identifier may be embodied in 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" refers to one or more computer devices operated by or on behalf of an issuer institution, such as a server computer executing one or more software applications. For example, an issuer system may include one or more authorization servers for authorizing transactions.

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

[0048] As used herein, "point-of-sale (POS) device" can refer to one or more devices that a merchant can use to conduct transactions (e.g., payment transactions) and / or process transactions. For example, a POS device may include one or more client devices. Alternatively or additionally, a POS device may include peripheral devices, card readers, scanning devices (e.g., barcode scanners), Communication receivers, near-field communication (NFC) receivers, radio frequency identification (RFID) receivers and / or other contactless transceivers or receivers, contact-based receivers, payment terminals, etc. As used herein, a "point-of-sale (POS) system" can refer to one or more client devices and / or peripheral devices 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 can 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 or configured to process online payment transactions via web pages, mobile applications, etc.

[0049] As used herein, the terms "client" and "client device" can refer to one or more client-side devices or systems (e.g., remote from the transaction service provider) used to initiate or facilitate a transaction (e.g., a payment transaction). As examples, "client device" can refer to one or more POS devices used by a merchant, one or more acquiring host computers used by an acquiring party, one or more mobile devices used by a user, etc. In some non-limiting embodiments or aspects, a client device can be an electronic device configured to communicate with one or more networks and initiate or facilitate transactions. For example, a client device can include one or more computers, laptops, tablets, mobile devices, cellular phones, wearable devices (e.g., watches, glasses, lenses, clothing, etc.), PDAs, etc. Furthermore, "client" can also refer to an entity (e.g., a merchant, acquiring party, etc.) that owns, utilizes, and / or operates a client device to initiate a transaction (e.g., initiate a transaction with a transaction service provider).

[0050] As used herein, the term "payment device" can refer to a payment card (e.g., a credit or debit card), gift card, smart card, smart medium, payroll card, healthcare card, wristband, machine-readable medium containing account information, keychain device or hook, RFID transponder, retailer discount or membership card, cellular phone, e-wallet mobile application, personal digital assistant (PDA), pager, security card, computing device, access card, wireless terminal, transponder, etc. In some non-limiting embodiments or aspects, a payment device may include volatile or non-volatile memory for storing information (e.g., account identifier, account holder name, etc.).

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

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

[0053] As used herein, the term "system" may refer to one or more computing devices or a combination of computing devices (e.g., processor, server, client device, software application, components of such computing devices, etc.). As used herein, references to "device," "server," "processor," etc., may refer to a previously described device, server, or processor, different devices, servers, or processors, and / or combinations of devices, servers, and / or processors, described as performing a preceding step or function. For example, as used in the specification and claims, a first device, first server, or first processor described as performing a first step or a first function may refer to the same or different devices, servers, or processors described as performing a second step or a second function.

[0054] Non-limiting embodiments or aspects of the disclosed subject matter relate to systems, methods, and computer program products for automatically updating credentials, which improve upon existing credential updating methods. In non-limiting embodiments, users do not need to participate in additional steps to update credentials (e.g., payment credentials, including account identifiers and tokens) of payment applications or providers (e.g., merchants, e-wallets, etc.).

[0055] refer to Figure 1This illustration shows a system 1000 for automatically updating credentials 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 executing one or more software applications as a service. The token management system 104 may include software and / or hardware, such as a server computer executing one or more applications as a service, an application executed by the transaction processing system, etc. The token management system 104 can manage (e.g., issue, store, maintain, etc.) tokens to merchants (e.g., merchant tokens) and / or devices (e.g., device tokens for user devices).

[0056] Transaction processing system 100 can communicate with and / or communicate with an issuer system 106, which includes and / or communicates with an issuer token store 108. The issuer token store 108 may include software and / or hardware, such as a network-accessible data storage device and / or associated software applications for storing and / or retrieving one or more tokens issued by an issuer corresponding to issuer system 106. Issuer system 106 can communicate directly with cardholder 112 and / or via application 110 (e.g., a mobile application, website, etc.). In the depicted example, issuer system 106 can switch from a first transaction processing system 101 (e.g., the original transaction processing system) to a second transaction processing system 100 (e.g., the target transaction processing system). In this example, issuer system 106 can generate a new PAN and issue a new payment device based on the new PAN.

[0057] Continue to refer to Figure 1 The issuing system 106 can transmit a migration request to the transaction processing system 100. The migration request 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 can be generated based on a query of the issuing token store 108 and can include a list of all merchants, applications, and / or other entities or systems that already possess provisioned credentials (e.g., PANs and / or PAN-based tokens). The credential request history can 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., a portion of a token and / or a unique identifier corresponding to the token), and / or a list of one or more applications (e.g., e-wallets, merchant applications, etc.) associated with 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 issuing system 106 for the credential request history.

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

[0059] Still referencing Figure 1 The transaction processing system 100 can generate update requests that are transmitted to merchants, applications, devices, and / or systems 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 can provide a new merchant token to the card archive merchant system 116. The token management system 104 can provide a new device token to a user device (e.g., a mobile device with an e-wallet). The token management system 104 can also provide a merchant token to the card archive merchant system 112, which previously stored the original PAN, but is moving to a token-based arrangement so that the merchant does not store the new PAN. In some non-limiting embodiments, the update request may include a reference to a previous credential (e.g., an old PAN or token) to allow merchant systems 112, 116, and / or device wallet 118 to locate the previous credential to delete it and / or replace it with a new credential. Device wallet 118 may be an e-wallet on a user computing device (e.g., a mobile device) with provisioned credentials (e.g., one or more tokens and / or PANs).

[0060] In some non-limiting embodiments, in instances where the merchant system may store pre-configured credentials on behalf of the merchant instead of storing credentials themselves, one or more payment gateways ( Figure 1 (Not shown in the image) can store pre-configured credentials. As used herein, "card archive merchant" can refer to a merchant that directly stores pre-configured credentials and / or uses a payment gateway to store pre-configured credentials for merchant use. In a non-limiting embodiment, the token management system 104 can provide update requests to the payment gateway corresponding to the merchant.

[0061] 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)). For example, the update request may include the last four digits of the new PAN, allowing the merchant and / or device to update the pre-provisioned credentials associated with the last four digits (e.g., new token, old token, new PAN, etc.), enabling the user to select a payment device (e.g., the user selects to transact with a payment device ending in the number "1234"). For instance, a merchant or wallet provider may have already shown the user the last four digits of the old PAN, and upon receiving an update request, may display the last four digits of the new PAN on the wallet or merchant payment checkout page to indicate to the user that the new credentials are in use. In such instances, the user will no longer see any reference to the old PAN or token.

[0062] Update requests may include any other data used by merchant systems 112, 114, 116, and / or device wallet 118. In a non-limiting embodiment, a new PAN (e.g., instead of a token or anything other than a token) may be provided to card archiving merchant 114 for storage via digital credential update service 102. Such merchants may be offered the option to switch to a token-based arrangement (e.g., merchant 112) instead of storing the PAN on a file, in which case token management system 104 may generate and transmit a new merchant token.

[0063] In non-limiting embodiments, transaction processing system 100 can batch process multiple update requests from multiple merchants and / or devices. Update requests can be automatically generated and transmitted (e.g., without requiring additional user action) to the merchants and / or devices (e.g., or applications running thereon). In some non-limiting embodiments, merchants and / or devices can be configured to receive such update requests from transaction processing system 100. In some non-limiting embodiments, transaction processing system 100 can generate update requests based on the protocol and / or format of the updated merchant and / or device, and can transmit update requests via application programming interfaces (APIs) exposed by the merchant and / or device. In some non-limiting embodiments, transaction processing system 100 can expose credentials for the merchant and / or device to request updates via the API. An "application programming interface" (API) refers to computer code or other data ordered on a computer-readable medium that can be executed by a processor to facilitate interaction between software components, such as interaction between a client-side front-end and / or a server-side back-end for receiving data from a client.

[0064] In a non-limiting embodiment, an update request sent to merchants 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 other indicator that, upon receipt, determines that new credentials are available. The update request may include new credentials. In some non-limiting embodiments where the update request does not include new credentials, an entity may generate a credential request (e.g., a request for a new token, a new PAN, new credential data, etc.) in response to this notification and transmit the credential request 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, etc.) to the entity that requested the requested data.

[0065] refer to Figure 4 The system 1004 is for automatically updating credentials according to some non-limiting embodiments or aspects. In some non-limiting embodiments, the central migration system 140 may facilitate automatic credential updates. For example, the central migration 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 issuing systems 106, 142. In such instances, the central migration system 140 may expose one or more APIs to facilitate communication between the transaction processing systems 100, 101 and / or the issuing systems 106, 142. For example, the central migration system 140 may allow transaction processing system 100 to request credential data (e.g., credential request history) from another transaction processing system 101. It should be understood that other arrangements are possible.

[0066] In some non-limiting embodiments, each transaction processing system 100, 101 (e.g., each payment network) may provide one or more interfaces (e.g., APIs and / or graphical user interfaces (GUIs) with input options) through which the issuer provides information related to the previous payment scheme from which it is migrating. In response to such a migration request, the transaction processing system may automatically contact all systems with old credentials (e.g., previous PANs and / or tokens linked to previous PANs) to update those systems with the new credentials. In non-limiting embodiments, the migration may be seamless for account holders and merchants, allowing transactions to continue to be processed successfully during the period in which the migration occurs.

[0067] In some non-limiting embodiments, the issuing system may transmit a single command to the transaction processing system 100 to enable credential updates across multiple merchants and / or devices. In some instances, the transaction processing system may communicate directly to request, verify, and / or cross-validate the credential data required for migration, thereby reducing the amount of data sent and / or requested by the issuing system.

[0068] Non-limiting embodiments can be used to update a card archive PAN to a token, update a card archive PAN to a new PAN, update a card archive token to a new token, and / or update a device token with a new token. In a non-limiting embodiment of system 1000 for updating a card archive PAN to a new PAN, a merchant (e.g., merchant 114) can request and / or obtain a list of PANs corresponding to the updated PAN from digital credential update service 102, and can be notified of the new credential from digital credential update service 102. In a non-limiting embodiment of system 1000 for updating a card archive token to a new token, the notification can be transmitted from token management system 104 to merchant systems (e.g., merchant system 112 and / or merchant system 116). In a non-limiting embodiment of system 1000 for updating a card archive PAN to a token and discontinuing the use of the PAN, the acquiring system associated with the merchant system (e.g., merchant system 112) ( Figure 1 (Not shown) may have a token reference identifier, which can transmit the token reference identifier to the merchant system 112, and cause the merchant system 112 to replace the archive PAN by transmitting the token reference identifier to the transaction processing system 100 (and / or the token management system 104), and receive a token in response to the token reference identifier to replace the card archive PAN for storage.

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

[0070] Now for reference Figure 2 The diagram illustrates a flowchart of a method for automatically updating credentials according to some non-limiting embodiments. Figure 2The steps shown are for illustrative purposes only. It should be understood that different, additional, fewer, and / or different orders of steps may be used in various embodiments. At step 300, the issuing system issues a new PAN to the account holder. The new PAN may be associated with a new transaction processing system (e.g., a new payment network) through which the account holder previously held an account (and associated payment device) via a different transaction processing system. Once the new PAN has been issued, the issuing system can wait for the user to activate the new PAN via the issuing application, issuing website, etc. At step 302, in response to determining that the user has activated the new PAN, the method may proceed to step 304.

[0071] exist Figure 2 At step 304, the issuing system may retrieve credential data from one or more databases, such as existing tokens, token request history, PAN request history, and credential-holding entities (e.g., merchants, applications, devices, etc.). In some instances, the issuing system may communicate with a token vault it maintains and / or accesses. In some examples, entities other than the issuing system may retrieve and / or compile credential data. For example, a transaction processing system may retrieve credential data after being granted access to any database and / or system storing the credential data. In some non-limiting embodiments, in addition to or instead of the issuing system retrieving credential data from one of its own databases, the issuing system may query the original transaction processing system (a payment scheme being migrated away, which may include the original transaction processing system and / or the original transaction processing system's token service) to obtain credential data, including previous token requests, merchant lists, etc. In some instances, the issuing system may use one or more APIs exposed by the original transaction processing system.

[0072] At step 306, a migration request is generated, which includes credential data, the old PAN, and the new PAN generated at step 300. The migration request can be one or more messages generated by the issuing system and transmitted to the transaction processing system. However, it should be understood that one or more other entities can generate and / or transmit migration requests. At step 308, the migration request is transmitted to the transaction processing system.

[0073] At step 310, in response to receiving a migration request at step 308, the transaction processing system can 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 can parse the data structure to identify each entity that can hold a credential, such as a merchant, application, and / or device. At step 312, a batch of update requests can be automatically generated for each entity identified in step 310. The update requests can 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, device, etc.), etc. At step 314, the update requests are delivered to the entities. In some non-limiting embodiments, steps 310-312 can be performed automatically in response to receiving a migration request and without user intervention. In some examples, steps 304-312 can be performed in response to a user activating a new PAN, such that the automatically updated credential is part of the activation process.

[0074] Figure 5 An electronic payment processing network 1100 according to a non-limiting embodiment or aspect is illustrated. This payment processing network can be used in conjunction with the systems and methods described herein. It should be understood that the specific arrangement of the illustrated electronic payment processing network 1100 is for illustrative purposes only, and various arrangements are possible. A transaction processing system 1101 (e.g., a transaction processor) is shown communicating with one or more issuing systems (e.g., issuing system 1106) and one or more acquiring systems (e.g., acquiring system 1108). Although only a single issuing system 1106 and a single acquiring system 1108 are shown, it should be understood that the transaction processing system 1101 can communicate with multiple issuing systems and / or acquiring systems. In some embodiments, the transaction processing system 1101 may also operate as an issuing system, such that both the transaction processing system 1101 and the issuing system 1106 are single systems and / or controlled by a single entity.

[0075] In some non-limiting embodiments or aspects, transaction processing system 1101 may communicate directly with merchant system 1104 via a public or private network connection. Alternatively, transaction processing system 1101 may communicate with merchant system 1104 via payment gateway 1102 and / or acquiring system 1108. In some non-limiting embodiments or aspects, acquiring system 1108 associated with merchant system 1104 may operate as payment gateway 1102 to facilitate the transmission of transaction requests from merchant system 1104 to transaction processing system 1101. Merchant system 1104 may communicate with payment gateway 1102 via a public or private network connection. For example, merchant system 1104 including a physical POS device may communicate with payment gateway 1102 via a public or private network for card transactions. As another example, merchant system 1104 including a server (e.g., a web server) may communicate with payment gateway 1102 via a public or private network, such as a public internet connection, for cardless transactions.

[0076] In some non-limiting embodiments or aspects, after receiving a transaction request from merchant system 1104 that identifies an account identifier associated with the payer (e.g., an account holder) of the issuing payment device 1110, transaction processing system 1101 may generate an authorization request message to be transmitted to the issuing system 1106 that issued the payment device 1110 and / or the account identifier. Issuing system 1106 may then approve or reject the authorization request and, based on the approval or rejection, generate an authorization response message transmitted to transaction processing system 1101. Transaction processing system 1101 may transmit the approval or rejection to merchant system 1104. When issuing system 1106 approves the authorization request message, it may then clear and settle the payment transaction between issuing system 1106 and acquiring system 1108.

[0077] Now for reference Figure 6 The diagram illustrates example components of device 400 according to a non-limiting embodiment or aspect. Device 400 may correspond to... Figure 1 At least one of the computing devices (e.g., transaction processing system 100, issuer system 106, etc.). 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. Provided Figure 6 The number and arrangement of components shown are for illustrative purposes only. In some non-limiting embodiments or aspects, device 400 may include components with... Figure 6 The components shown are those that are additional, fewer, different, or arranged differently compared to other components. Alternatively, a set of components of device 400 (e.g., one or more components) may perform one or more functions described as being performed by another set of components of device 400.

[0078] like Figure 6 As shown, device 400 may include bus 402, processor 404, memory 406, storage component 408, input component 410, output component 412, and communication interface 414. Bus 402 may include components that allow communication between 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., central processing unit (CPU), graphics processing unit (GPU), accelerated processing unit (APU), etc.), microprocessor, digital signal processor (DSP), and / or any processing component that can be programmed to perform functions (e.g., field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), etc.). 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 processor 404.

[0079] Continue to refer to Figure 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., magnetic disk, optical disk, magneto-optical disk, solid-state disk, etc.) and / or another type of computer-readable medium. Input component 410 may include components that allow device 400 to receive information, for example, through user input (e.g., touch screen display, keyboard, keypad, mouse, buttons, switches, microphone, etc.). Alternatively, input component 410 may include sensors for sensing information (e.g., Global Positioning System (GPS) components, accelerometers, gyroscopes, actuators, etc.). Output component 412 may include components that provide output information from device 400 (e.g., display, speaker, one or more light-emitting diodes (LEDs), etc.). Communication interface 414 may include transceiver-like components (e.g., transceivers, separate receivers and transmitters, etc.) that enable device 400 to communicate with other devices, for example, via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 414 may allow device 400 to receive information from another device and / or provide information to another device. For example, communication interface 414 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, etc. Interfaces, cellular network interfaces, etc.

[0080] Apparatus 400 can perform one or more processes described herein. Apparatus 400 can perform these processes based on processor 404 executing software instructions stored in a computer-readable medium such as memory 406 and / or storage component 408. The computer-readable medium can include any non-transient memory device. Memory devices include memory space located within a single physical storage device or memory space distributed across multiple physical storage devices. Software instructions can be read into memory 406 and / or storage component 408 via communication interface 414 from another computer-readable medium or from another device. When executed, the software instructions stored in memory 406 and / or storage component 408 can cause processor 404 to perform one or more processes described herein. Alternatively or additionally, hardwired circuitry can be used in place of or in conjunction with the software instructions to perform one or more processes described herein. Therefore, the embodiments described herein are not limited to any particular combination of hardware circuitry and software. As used herein, the term “configured to” can refer to an arrangement of software, apparatus, and / or hardware for performing and / or realizing one or more functions (e.g., actions, processes, steps of processes, etc.). For example, "a processor configured to..." can refer to a processor that executes software instructions (e.g., program code) that cause the processor to perform one or more functions.

[0081] Although embodiments have been described in detail for illustrative purposes, it should be understood that such details are for the purposes described only, and this disclosure is not limited to the disclosed embodiments or aspects, but rather is intended to cover modifications and equivalent arrangements that fall within the spirit and scope of the appended claims. For example, it should be understood that this disclosure contemplates, as far as possible, that one or more features of any embodiment or aspect may be combined with one or more features of any other embodiment or aspect.

Claims

1. A system comprising at least one processor of a transaction processing system, said at least one processor being programmed or configured to: A migration request is received from the first issuing system, the migration request identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier, which is associated with the second transaction processing system; Analyze the credential request history to identify at least one pre-provisioned credential associated with the original account identifier, the at least one pre-provisioned credential including at least one of a card archive merchant credential and a device token; as well as In response to identifying the at least one pre-configured credential, an update request is automatically generated, the update request being configured to update the at least one pre-configured credential based on the new account identifier: a merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof.

2. The system of claim 1, wherein the at least one pre-configured credential associated with the original account identifier includes at least one of a card archive merchant credential and the device token.

3. The system of claim 1, wherein at least one of the card archive merchant credentials includes the original account identifier.

4. The system of claim 1, wherein the migration request is received via a central migration system communicating with the first issuing system, the transaction processing system and the second transaction processing system, and wherein at least the credential request history is received by the central migration system from the first issuing system.

5. The system of claim 1, wherein the credential request history includes at least one of the following: a token reference identifier, token requester 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. The system of claim 1, wherein the account data associated with the at least one pre-configured credential includes at least one of the following: a digital subset of the new account identifier, a token corresponding to the new account identifier, the new account identifier, or any combination thereof.

8. The system of claim 1, wherein the at least one pre-provisioned credential associated with the original account identifier includes at least one of a card archive merchant credential and the device token, and wherein automatically generating the update request in response to identifying the at least one pre-provisioned credential includes: In response to at least one of the merchant credentials in the card archive, a merchant update request is automatically generated, the merchant update request being configured to cause the merchant system and / or the payment gateway of the card archive merchant to update the account data associated with the pre-configured credentials and stored by the merchant system or the payment gateway of the card archive merchant; as well as In response to the identification of the device token, a device update request is automatically generated, which is configured to cause the user device to update the account data associated with the device token and stored by the user device.

9. A computer-implemented method, comprising: The transaction processing system receives a migration request from a first issuer system using at least one processor. The migration request identifies an original account identifier, a new account identifier, and a credential request history associated with the original account identifier, which is associated with a second transaction processing system. The at least one processor is used to analyze the credential request history to identify at least one pre-provisioned credential associated with the original account identifier, the at least one pre-provisioned credential including at least one of a card archive merchant credential and a device token; as well as In response to identifying the at least one pre-configured credential, an update request is automatically generated, the update request being configured to update the at least one pre-configured credential based on the new account identifier: a merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof.

10. The computer-implemented method of claim 9, wherein the at least one pre-configured credential associated with the original account identifier includes at least one of a card archive merchant credential and the device token.

11. The computer-implemented method of claim 9, wherein the at least one of the card archive merchant credentials includes the original account identifier.

12. The computer-implemented method of claim 9, wherein the migration request is received via a central migration system communicating with the first issuing system, the transaction processing system, and the second transaction processing system, and wherein at least the credential request history is received by the central migration system from the first issuing system.

13. The computer-implemented method of claim 9, wherein the credential request history comprises at least one of the following: a token reference identifier, token requester 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. The computer-implemented method of claim 9, wherein the account data associated with the at least one pre-configured credential includes at least one of the following: a digital subset of the new account identifier, a token corresponding to the new account identifier, the new account identifier, or any combination thereof.

16. The computer-implemented method of claim 9, wherein the at least one pre-provisioned credential associated with the original account identifier includes at least one of a card archive merchant credential and the device token, and wherein automatically generating the update request in response to identifying the at least one pre-provisioned credential includes: In response to at least one of the merchant credentials in the card archive, a merchant update request is automatically generated, the merchant update request being configured to cause the merchant system or payment gateway associated with the card archive merchant to update the account data associated with the pre-configured credentials and stored by the merchant system or payment gateway of the card archive merchant; as well as In response to the identification of the device token, a device update request is automatically generated, which is configured to cause the user device to update the account data associated with the device token and stored by the user device.

17. A computer-implemented method, comprising: The transaction processing system receives a migration request from a first issuer system using at least one processor. The migration request identifies an original account identifier, a new account identifier, and a credential request history associated with the original account identifier, which is associated with a second transaction processing system. The at least one processor is used to analyze the credential request history to identify at least one pre-provisioned credential associated with the original account identifier for the card archive merchant and at least one device token; In response to identifying the pre-provisioned credentials of at least one card archive merchant, a merchant update request is automatically generated, the merchant update request being configured to update the card archive merchant with account data associated with the pre-provisioned credentials and stored by the card archive merchant's merchant system; as well as In response to the identification of the at least one device token, a device update request is automatically generated, the device update request being configured to cause the user device to update the account data associated with the at least one device token and stored by the user device.

18. A computer program product comprising at least one non-transitory computer-readable medium, said at least one non-transitory computer-readable medium comprising program instructions that, when executed by at least one processor of a transaction processing system, cause said at least one processor to: A migration request is received from the first issuing system, the migration request identifying an original account identifier, a new account identifier, and a credential request history associated with the original account identifier, which is associated with the second transaction processing system; Analyze the credential request history to identify at least one pre-provisioned credential associated with the original account identifier, the at least one pre-provisioned credential including at least one of a card archive merchant credential and a device token; as well as In response to identifying the at least one pre-configured credential, an update request is automatically generated, the update request being configured to update the at least one pre-configured credential based on the new account identifier: a merchant system, a payment gateway associated with the merchant system, a user device, or any combination thereof.

Images