Method for securely updating payment means tokens by means of a virtual platform

Abstract

The present invention discloses a method for securely updating payment means tokens by means of a virtual platform, which communicates with a payment means brand (50), a payment means issuer (63) and a merchant (40). The method comprises: receiving a holder (70), a replaced payment means (71), a replacement payment means (72) and merchants (40) with registered brand tokens (73) of the holder from the payment means issuer; requesting an intermediate brand token (74) for the replacement payment means from the payment means brand; receiving the intermediate brand token; and sending an update request to the merchant. The update request comprises: the data of the replaced payment means, the intermediate brand token and a request for a new brand token (75) to the payment means brand of the replacement payment means.

Description

[0001] SECURE METHOD FOR UPDATING PAYMENT TOKENS THROUGH A VIRTUAL PLATFORM

[0002] DESCRIPTION

[0003] OBJECT OF THE INVENTION

[0004] The present invention relates to a method for securely updating payment tokens using a virtual platform. Specifically, the present invention aims to update a user's payment tokens across all participating parties (users, payment issuers, merchants), maintaining the security of the payment method and without modifying anything at the merchant where the user has registered tokens associated with the payment methods they wish to update.

[0005] The invention finds special application in the field of telecommunication techniques, virtual security, authentication and protection of privacy and anonymity.

[0006] BACKGROUND OF THE INVENTION AND TECHNICAL PROBLEM TO BE SOLVED

[0007] In the current state of the art, the token (defined in the following paragraph) has become the fundamental element for accessing an account and, therefore, for payments that a merchant must make to an account holder. It is therefore essential for the merchant to have this information correctly; if they do not have it, they will be unable to make payments to their customer, which will reduce their business and could also lead to penalties. It is also important for the customer because if this information is not up-to-date, they may find themselves without the goods or services they wanted from the merchant. Since their inception as a technology, tokens have been generated and maintained as proprietary elements of the merchant or the acquirer, providing them with a barrier to merchant abandonment of their service while maintaining little transparency regarding the feasibility of importing and exporting proprietary tokens.Recently, card brands, led by Visa, have taken a step forward and begun managing brand tokens from both the issuer and acquirer ends. The relevant aspect of this invention is that merchants now have the opportunity to offer new payment options to their customers while maintaining security. The essential element of this service for merchants is ensuring the automated lifecycle of the brand token, as this will allow them to optimize their operations and offer their customers the best possible experience. This invention therefore focuses on maintaining this automated lifecycle, even in cases of customer account replacement.

[0008] In the current state of the art, a "token" is known as the digital representation of real-world data that allows it to be masked using various mechanisms, ultimately preventing the real data from being compromised. Therefore, "tokenizing" information can reduce the risk of fraud because, unlike real data, a token is a perishable element that can be replaced either periodically or at the first sign of a security breach. Although tokens minimize risk, an attacker can potentially capture a token and attempt to reuse it fraudulently.

[0009] In the current state of the art, a "brand token" is defined as the digital representation generated by a payment card issuer ("brand") (Visa, MasterCard, etc.) based on the PAN ("Personal Account Number") of the actual payment card on the physical card. The generation and management of the "brand token" is the sole responsibility of the payment card brand itself.

[0010] In the current state of the art, and for the present sector of technology, the "Mainjd" is understood as the token of a static piece of information belonging to a natural or legal person that does not change over time. In this sense, the following can act as a "Mainjd": a personal identification number (DNI), passport number, driver's license number, Social Security number, the PAR as a non-financial reference assigned to each PAN, etc.

[0011] “Tokens” as elements of digital information can be used and are used massively to protect sensitive personal information related to means of payment as well as any other type of personal information that in the digital world can be replaced with tokens.

[0012] Currently, each user / customer has a set of personal data such as name, national identity document number, passport number, tax identification number, etc., or address, phone number, email, etc. This data, along with their preferred payment method information, is tokenized at each merchant. This token generates a "proprietary token" or "brand token" that allows for simple and automatic processing of future purchases and payments, as well as recurring payments initiated without the user's presence, all in a secure manner. This data set includes both fixed and variable or replaceable information. The standard practice for tokenizing payment method data (bank cards) by service providers to merchants (not brand tokens) is typically limited to the card details themselves, excluding other data belonging to the cardholder.

[0013] Due to the tokenization of payment methods to maintain their security, in the current state of the art, the process of updating payment methods is solely controlled by the issuer of the payment method as the only entity capable of generating and managing the brand token.

[0014] The problem arises when a user updates their payment method, which is registered with various merchants. Specifically, if the token in question is the payment method token the user has registered with the merchant, we are dealing with the brand token for that user and that particular merchant. When the payment method update occurs, the problem for all the merchants that have stored the user's brand token information for each of their relationships is the loss of connection with that customer and, ultimately, the potential loss of business, usability, and availability for the user. This is because the brand token is encrypted information that represents the user's payment method, the user, and the merchant.

[0015] In the current state of the art, registering the payment method that the user wishes to use involves a series of steps that are exchanged in an interconnected environment comprising the user, a merchant, a cloud system, and a payment method issuer (“brand”), such that:

[0016] • The merchant captures data from the payment method (bank card) that the customer wants to associate with the merchant for their payments;

[0017] • The merchant uses its own interface with the cloud system to request a card brand token. This request includes only information about the payment method (bank card); • The system requests a token for the card from the brand and forwards it to the merchant.

[0018] And when you want to perform an update:

[0019] • The payment issuer informs the cloud system of changes to the expiration date or the deletion of a token;

[0020] • The cloud system notifies the merchant of a change in the expiration date or the deletion of a token.

[0021] In other words, due to the encryption (tokenization) required for payment methods, the update of payment methods can only be carried out when the "new" payment method belongs to the same provider as the "old" payment method that is intended to be updated and only for a single merchant, since for each Brand token generated it only includes one merchant per user.

[0022] In the prior art, PCT / ES2023 / 070202 discloses a method for updating an encrypted payment method (brand token) across all participants in the environment when one of them wishes to update the payment method, without compromising the security of the encrypted payment method. However, this method of updating brand tokens requires implementing the invention in each (usually online) merchant where the user has registered brand tokens. This entails technical difficulties related to the convergence of programming languages, as well as other challenges such as obtaining permission to access third-party information, managing updates, etc.

[0023] Therefore, it would be desirable for users to be able to update their registered trademark tokens at merchants in a way that is completely transparent to the merchant. In other words, it would be desirable to update registered trademark tokens at merchants without implementing or modifying anything at the merchant's site.

[0024] DESCRIPTION OF THE INVENTION

[0025] The present invention falls within an environment with the following participants:

[0026] • Customer of the merchant and holder of a payment account, whether in the form of a card or in any other form;

[0027] • Commerce, the central focus of the benefit of the present invention, and to which an automated form of maintenance of brand tokens is provided in order to optimize its operation;

[0028] • Account / card issuers, such as payment account providers to customers so that they can manage their payments at merchants;

[0029] • Brand, as the provider of the brand token to the merchant holder;

[0030] • The present invention, as an intermediary between merchants and brands, but to which both account / card issuers and customers themselves can also be connected directly or indirectly to maintain the automated management of the life cycle of their brand token in their merchants, thereby avoiding any type of interruption in the supply of the good or service provided by the merchant.

[0031] This descriptive report focuses on the "brand token," in which one of the invariable data points (Name, ID, Passport, PAR, etc.) encrypted within the "brand token" is the user's "MainID" across the various websites where they register variable personal information. The brand token is designed so that events that would require replacement in the world of tokens created by payment processors for merchants—such as expiration, theft, loss, or damage to the card—do not require replacement (card data changes, but not the underlying account), since brand tokens can represent both the old and new cards precisely to avoid the need for replacement.This MainID is typically shared by all websites (businesses) associated with the system, serving as the central point for the additional data that each website (business) may collect according to its specific business or activity. This means that a single client can have "n" pieces of information, typically represented as tokens, across the "n" businesses with which they regularly interact, and that the information stored in these tokens accurately reflects the situation at the time the information was recorded.

[0032] Consequently, the present invention allows the updating of a “brand token”, and its transparent substitution and replacement on the “n” websites (commerce sites) associated with the system.

[0033] Therefore, in a first aspect of the present invention, a method for securely updating payment tokens using a virtual platform is disclosed. The virtual platform communicates with at least one payment brand, at least one payment issuer, and at least one merchant. The method comprises the following steps:

[0034] • receive from the payment method issuer: details of a payment method holder, details of a replaced payment method, details of a replacement payment method and a list of merchants where the payment method holder has registered trademark tokens for the replaced payment method;

[0035] • request, from the payment brand, an intermediate brand token for the replacement payment method through a unique cryptographic TR-TSP interface provided by the payment brand (specifically) for the virtual platform;

[0036] • receive the intermediate brand token from the payment method brand;

[0037] • Send an update request to a merchant in the merchant list, where the update request comprises: o the details of the replaced payment method; o the intermediate brand token; o a request for a new brand token from the payment method brand of the replacing payment method.

[0038] Optionally, the method may include a step of receiving confirmation from the merchant that the new brand token has been stored and replaces the registered brand token.

[0039] Regarding the intermediate brand token, the intermediate brand token is generated by the payment method brand after communication between the payment method brand and the payment method issuer that had previously generated the replacement payment method, where the payment method issuer authorizes the tokenization to the payment method brand.

[0040] Regarding the virtual platform, the method additionally includes registering the virtual platform as a business with the payment methods brand.

[0041] In one implementation, the replaced payment method data consists of a Mainjd and a payment method mask.

[0042] Regarding the upgrade request, the request for a new brand token from the payment brand of the replacing payment method is carried out through a unique cryptographic TR-TSP interface provided by the payment brand for the merchant. The new brand token is generated by the payment brand following communication between the payment brand and the payment issuer that previously generated the replacing payment method. The payment issuer authorizes the tokenization to the payment brand.

[0043] Optionally, the method may additionally involve storing the intermediate brand token in a database in communication with the virtual platform.

[0044] Optionally, the method may additionally involve storing the new brand token in a database that communicates with the merchant.

[0045] In a second aspect of the invention, a secure payment token update system is disclosed using a virtual platform. The system comprises at least one virtual platform and a unique cryptographic TR-TSP interface, which connects the virtual platform to the payment brand. The virtual platform communicates with a payment issuer and at least one merchant. Optionally, the system may include a database that stores at least payment token holder data, data on a replaced payment token, data on a replacement payment token, a list of merchants where the payment token holder has registered brand tokens, and the intermediate brand token.

[0046] In one embodiment of the invention, the unique cryptographic TR-TSP interface communicates the virtual platform with the payment means brand using encryption protocols. Optionally, the encryption protocol is selected between TLS1.2 and TLS1.3.

[0047] In a third aspect of the invention, a computer program is disclosed comprising instructions that, when executed on a computer, cause the computer to carry out the method of the first aspect of the invention.

[0048] In a fourth aspect of the invention, a computer-readable medium is disclosed comprising instructions that, when executed on a computer, cause the computer to carry out the method of the first aspect of the invention. BRIEF DESCRIPTION OF THE FIGURES

[0049] To complete the description of the invention and to aid in a better understanding of its characteristics, according to a preferred embodiment thereof, a set of drawings is included in which, for illustrative and non-limiting purposes, the following figures have been represented:

[0050] • FIG. 1 represents a diagram showing all the participants, both those that make up the system and those that are not part of the system, as well as the interactions between the elements that are part of the method of the present invention

[0051] • FIG. 2 represents the first tokenization that the user carries out for the first time with their means of payment to be replaced in the store.

[0052] • FIG. 3 represents the generation of the intermediate token when the user wants to update their payment method to a new replacement payment method at the store.

[0053] • FIG. 4 represents the replacement flow of the trademark token that the merchant has stored in its database.

[0054] The following is a list of the references used in the figures:

[0055] Steps 1 to 31 of the secure payment token update method using a virtual platform;

[0056] 40. Trade;

[0057] 41. Trade databases;

[0058] 42. Unique TR-TSP crypto trading interface;

[0059] 43. issuer of means of payment of the replaced / to be replaced means of payment 71 ;

[0060] 50. payment method brand;

[0061] 60. virtual platform;

[0062] 61. Virtual platform database;

[0063] 62. unique TR-TSP cryptographic interface of the virtual platform;

[0064] 63. issuer of means of payment of the replacement means of payment 72;

[0065] 64. system; 70. user / holder of payment methods 71 ​​and 72;

[0066] 71. means of payment replaced / to be replaced;

[0067] 72. Replacement means of payment.

[0068] DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION

[0069] In the figures detailed below, merchant 40 can be any of the merchants in a list of merchants where user 70 has tokenized their payment methods. Also, only one payment method brand 50 is represented, but it should be understood that the present invention can be applied to different payment method brands that connect with the merchant.

[0070] Figure 1 represents a diagram showing all the participants, both those that comprise system 64 and those that are not part of system 64, as well as the interactions between the elements that form part of the method of the present invention. System 64 can be a distributed cloud system connected via a global communications network (internet), which, to carry out the method of the present invention as shown in Figure 1, comprises the virtual platform 60, the database 61, and the unique cryptographic TR-TSP interface 62, which connects the virtual platform 60 with the payment method brand 50. The virtual platform 60 is in communication with the payment method issuer 63 of the replacement payment method 72, and is also in communication with at least one merchant 40 that has registered the replacement payment method 71, i.e., the registered token 73, in its database 41.The registered token 73 of the payment method to be replaced 71 was previously generated by the payment method issuer 43, which is different from the payment method issuer 63 of the replacement payment method 72. The payment method to be replaced 71 was generated by the payment method brand 50 in communication with the payment method issuer 43 of the payment method to be replaced 71, such that once the tokenization is approved by the payment method issuer 43, the payment method brand 50 sends the registered token 73 to the merchant 40 through the unique cryptographic TR-TSP interface 42 associated with the merchant 40. The registered token 73 was generated by the direct request of the user / holder 70 of the payment method to be replaced 71 to the merchant 40.

[0071] Figure 2 represents the first tokenization that user 70 performs for the first time with their payment method 71 at merchant 40, typically an e-commerce site. This first tokenization performed by the user would be prior (step zero) to the present invention, since the present invention updates the tokenization when payment method 71 is replaced by the new payment method 72. The steps that user 70 performs for the first tokenization are:

[0072] 1. Merchant 40 requests tokenization using the payment credentials that the holder

[0073] 70 of the payment method (card) 71 has provided;

[0074] 2. the unique cryptographic TR-TSP interface 42, enabled by the payment means brand 50 to provide the tokenization service, connects with the payment means brand 50 to request tokenization, to do so it uses the cryptographic resources (TR-TSP single interface) that have been defined during the integration between the merchant 40 and each of the payment means brands 50;

[0075] 3. The payment method brand 50 communicates with the payment method issuer 43 to determine if the payment method (card) 71 presented by the payment method (card) holder 70 can be tokenized;

[0076] 4. The payment medium issuer 43 communicates with the payment medium brand 50 to carry out tokenization;

[0077] 5. The payment brand 50 creates token 73 and sends it to both the cryptographic TR-TSP unique interface 42 and the payment issuer 43;

[0078] 6. The unique cryptographic TR-TSP interface 42 sends token 73 to merchant 40;

[0079] 7. The merchant 40 stores token 73 in its database 41 to perform recurring operations from token 73 of holder 70.

[0080] Figure 3 illustrates the generation of the intermediate token 74 when user 70 wants to update their payment method 71 to a new replacement payment method 72 at merchant 40. To carry out these steps, the virtual platform 60 must be registered with the payment method brand 50 before any tokenization can take place. The steps for generating the intermediate token 74 are:

[0081] 8. The user / holder 70 of the replacement payment method 72 (card) communicates with the payment method issuer 63 that generated the replacement payment method 72. Typically, user 70 accesses the online banking platform of the payment method issuer 63 and requests tokenization using their payment credentials. The intermediary platform 60 requests from user 70, via the payment method issuer 63, the list of merchants where the cardholder has registered tokens. This is done using the MAIN_ID and the mask of the card to be renewed.

[0082] 9. The virtual platform 60 connects to the unique cryptographic TR-TSP interface 62 to request a tokenization for the virtual platform 60;

[0083] 10. The unique cryptographic TR-TSP interface 62 connects with the payment means brand 50 to request tokenization. For this purpose, it uses cryptographic resources included in the unique cryptographic TR-TSP interface 62 and that have been defined during the integration between the virtual platform 60 and the payment means brand 50;

[0084] 11. The payment method brand 50 communicates with the payment method issuer 63 to check if the payment method presented by the holder 70 of the payment method 72 can be tokenized;

[0085] 12. The payment media issuer 63 communicates with the payment media brand 50 to authorize tokenization;

[0086] 13. The payment brand 50 creates the intermediate token 74 and sends it to both the cryptographic TR-TSP single interface 62 and the payment issuer 63;

[0087] 14. The cryptographic TR-TSP single interface 62 sends the intermediate token 74 to the virtual platform 60;

[0088] 15. The virtual platform 60 stores the intermediate token 74 in its database 61. The intermediate token 74 will be used to perform the replacement of the existing token 73 with a new token 75 as described below.

[0089] FIG. 4 represents the effective replacement flow of the trademark token 73 that the merchant 40 has stored in its database 41 and which is described below.

[0090] 16. Once the user / holder 70 of the payment method (card) has created the intermediate token 74 for the replacement payment method 72 (the new CARD #2), the virtual platform 60 sends an update request to the merchant 40 which includes the data of the replaced payment method 71 (old card), the intermediate brand token 74 and a request (of type “push” or similar) for the merchant 40 to update the brand token 73 that it has stored for a new token 75;

[0091] 17. The merchant 40, after receiving the update request from the virtual platform 60, requests the creation of a new brand token 75 to the payment method brand 50 of the replacement payment method 72;

[0092] 18. The unique cryptographic TR-TSP interface 42, provided by payment means brand 50 to merchant 40 and providing cryptographic services to merchant 40, connects to payment means brand 50 to request tokenization. To do this, the cryptographic TR-TSP single interface 42 uses cryptographic resources that have been defined during the integration between the cryptographic TR-TSP single interface 42 and the payment means brand 50;

[0093] 19. The payment brand 50 communicates with the payment issuer 63 so that the payment issuer 63 authorizes the new brand token 75;

[0094] 20. The payment medium issuer 63 authorizes the payment medium brand 50 to carry out tokenization;

[0095] 21. The payment brand 50 creates the new brand token 75 and notifies both the cryptographic TR-TSP single interface 42 and the payment issuer 63;

[0096] 22. The unique cryptographic TR-TSP interface 42 sends the new brand token 75 to merchant 40; 23. Merchant 40 stores the new brand token 75 (Token #3) in its database

[0097] 41 to perform recurring operations. Trading 40 removes the old token 73 (previously registered trademark token);

[0098] 24. The merchant 40 optionally notifies the intermediary platform 60 that the new brand token 75 has successfully replaced the registered brand token 73.

[0099] It should be noted that steps 18 to 23 above are performed automatically by the merchant 40 once it receives the virtual platform update request 60. Therefore, the virtual platform update request to the merchant is a “push” type update request.

Claims

CLAIMS 1. A method for securely updating payment tokens using a virtual platform, where the virtual platform (60) is in communication with at least one payment brand (50), with a payment issuer (63) and with at least one merchant (40), characterized in that the method comprises the following steps: • receive (8) from the issuer of means of payment (63): data of a holder of a means of payment (70), data of a replaced means of payment (71), data of a replacement means of payment (72) and a list of merchants (40) where the holder of the means of payment (70) has registered trademark tokens; • request (9, 10), from the payment brand (50), an intermediate brand token (74) for the replacement payment medium (72) by means of a unique cryptographic TR-TSP interface (62) provided by the payment brand (50) for the virtual platform (60); • receive (13,14) from the payment media brand (50) the intermediate brand token (74); • send (16) an update request to a merchant (40) from the merchant list, wherein the update request comprises: or the details of the replaced payment method (71); or the intermediate brand token (74); or a request (17) for a new brand token (75) to the payment method brand (50) of the replacing payment method (72).

2. The method of claim 1, wherein the method further comprises receiving (24) from the merchant (40) a confirmation that the new trademark token (75) has been stored (23) and replaces the registered trademark token (73). 3.- The method of claim 1, wherein the intermediate brand token (74) is generated by the payment means brand (50) following a communication (11) between the payment means brand (50) and the payment means issuer (63) that had previously generated the replacement payment means (72) wherein the payment means issuer (63) authorizes (12) the tokenization to the payment means brand (50).

4. The method of claim 1, wherein the method further comprises registering the virtual platform (60) as a business in relation to the payment methods brand (50). 5.- The method of claim 1, wherein the data of the replaced means of payment (71) are a Mainjd and a mask.

6. The method of claim 1, wherein the request for a new brand token (75) to the payment brand (50) of the replacement payment means (72) is carried out by means of a unique cryptographic TR-TSP interface (42) provided by the payment brand (50) for the merchant (40), wherein the new brand token (75) is generated by the payment brand (50) following a communication (19) between the payment brand (50) and the payment issuer (63) that had previously generated the replacement payment means (72), wherein the payment issuer (63) authorizes (20) the tokenization to the payment brand (50). 7.- The method of claim 1, wherein the method further comprises storing (15) the intermediate brand token in a database in communication with the virtual platform.

8. The method of claim 1, wherein the method further comprises storing (23) the new brand token in a database in communication with the merchant. 9.- A secure payment token update system using a virtual platform, characterized in that the system (64) comprises at least one virtual platform (60) and a unique cryptographic TR-TSP interface (62), which communicates the virtual platform (60) with the payment brand (50), wherein the virtual platform (60) is in communication with a payment issuer (63) and with at least one merchant (40).

10. The system of claim 9, wherein the system (64) further comprises a database (61) that stores at least data of a holder of a means of payment (70), data of a replaced means of payment (71), data of a replacement means of payment (72), a list of merchants (40) where the holder of the means of payment (70) has registered trademark tokens (73) and the intermediate trademark token (74).

11. The system of claim 9, wherein the unique cryptographic TR-TSP interface (62) communicates the virtual platform (60) with the payment media brand (50) using encryption protocols.

12. The system of claim 11, wherein the encryption protocol is selected from TLS1.2 and TLS1.

3.

13. A computer program comprising instructions which, when executed on a computer, cause the computer to carry out the method of claim 1.

14. A computer-readable medium comprising instructions which, when executed on a computer, cause the computer to carry out the method of claim 1.

Images