Virtual card access providing

Abstract

The present disclosure relates to a method and a card management system for providing access to a virtual card (VC) addressed to a user by a card issuer. The card management system comprises an API management gateway and a virtual card VC processor. The VC processor is configured to receive a VC voucher request from the user through the API management gateway; acquiring a VC voucher; and providing the VC voucher to the card issuer application program through the API management gateway for pushing the VC voucher to the user to allow card-free transaction on the card issuer application program.

Description

Technical Field

[0001] The present invention relates generally to virtual cards and, more particularly, to exemplary embodiments of exemplary systems and methods for providing access to virtual cards. Background Art

[0002] Traditional payment systems are integrated with several card issuing entities, such as banks and / or credit card companies. The card issuer may issue a physical card to a customer. For example, when such a card-holding customer wishes to make an online purchase, the customer may provide the merchant with the account number and / or card number of a physical debit or credit card issued to him or her by the card issuing entity. However, signing up for a credit or debit card is typically a time-consuming process and is governed by regulatory requirements.

[0003] On the other hand, a digital card, virtual card or cloud card is a digital virtual representation of any physical card hosted online, or any type of authorization credential that can be used for e-commerce transactions. Compared to a physical card, a virtual card does not require any physical representation in the first place, because it is completely virtual and hosted online, thus reducing the time from the user's card request to the card availability for the first transaction. Such a virtual card can simulate any kind of plastic card, and can therefore support so-called card-not-present (CNP) transactions. A CNP transaction is a payment card transaction in which the cardholder does not or cannot physically present the card for visual inspection by the merchant when giving an order and making a payment. It is most commonly used for payments made over the phone or the Internet. Examples of such virtual card issuers can include ICICI Bank and AmazonPay.

[0004] However, such virtual cards are limited to a single card program, i.e., they are coupled to a specific host bank system and card issuer as part of the transaction lifecycle, storage and security of cardholder data.

[0005] Therefore, it is desirable to provide a more flexible solution for accessing virtual cards. Summary of the invention

[0006] The invention solves the above objects by the subject matter covered by the independent claims. Preferred embodiments of the invention are defined in the dependent claims.

[0007] According to a first aspect of the present invention, there is provided a method for providing access to a virtual card VC through a card management system, the VC being issued to a user by a card issuer, the card management system comprising a virtual card processor (VC processor) and an API management gateway. The method comprises the following steps: receiving a request for a VC credential at the VC processor, the request being sent by the user through the API management gateway; obtaining the VC credential by the VC processor; and providing the VC credential to a card issuer application through the API management gateway, for pushing the VC credential to the user to allow card-not-present transactions on the card issuer application.

[0008] According to a second aspect of the present invention, there is provided a card management system for providing access to a virtual card VC, which is issued to a user by a card issuer, the card management system comprising an API management gateway and a virtual card VC processor. The VC processor is configured to receive a request for a VC credential from a user via the API management gateway, obtain the VC credential, and provide the VC credential to a card issuer application via the API management gateway to push it to the user so as to allow a card-not-present transaction to be performed on the card issuer application.

[0009] The proposed method and system allow for the creation of a digital or virtual representation of a physical card. Specifically, once a card issuer is registered within a card management system, i.e., an account is created, the virtual card credentials provided to the user through the card issuer application allow for viewing the physical card details within the banking application in near real time, before the physical card is available. While the physical card is still on the way, the accurate digital representation is available within the user's mobile application for online transactions. Thus, a convenient, tangible and fast means is provided to the user for immediate execution of CNP transactions online and in-store.

[0010] In this specification, a card issuer is any bank and / or credit card company that issues a physical credit / payment card to a customer. In addition, a card issuer may provide a web / mobile banking application (also referred to as a card issuer application) to the user with a secure channel for logging in.

[0011] The card management system is preferably hosted at a card personalization agency, which is the entity that produces and provides physical credit cards to banks and / or credit card companies.

[0012] VC Request is the personalization / payment credential received at the card management system. The payment credential can be card information (physical or virtual factor), wearable, mobile credential. The payment credential is the payment credential in the scope of personalization and fulfillment related. VC Request can be received as part of a personalization order document, portal user interface, subscription to information system and / or API and other methods for requesting.

[0013] In some embodiments of the present invention, the VC request includes a request ID and authentication information. Preferably, the method further includes storing the request ID and authentication information in a private cloud of the card management system. The authentication information may indicate a form of authentication, such as, for example, token-based authentication that generates a cryptographically secure token unique to each virtual card.

[0014] This allows users to be linked to cards (via the card issuer application and the card management system), providing a more flexible solution over conventional single card programs.

[0015] In some embodiments of the present invention, the method further comprises obtaining the VC credential by retrieving the cardholder record corresponding to the request ID from the VC cloud storage. In a further step, the authentication between the card issuer and the VC processor may be performed using the authentication information stored with the request ID. Subsequently, upon successful authentication, the VC credential is provided to the card issuer application.

[0016] In this way, it is ensured that only users who are allowed to log into the card issuer application can access the virtual card. Therefore, the user can use the existing issuer login authentication to enter the issuer application to access the virtual card.

[0017] Preferably, the authentication information includes a session key between the VC issuer and the VC processor.

[0018] In some embodiments of the present invention, prior to receiving a request for a VC credential, the VC issuer registers with the card management system.

[0019] In some embodiments of the present invention, a request for card personalization is received at a card management system from a card issuer. The request includes data uniquely identifying each cardholder record of a plurality of cardholder records of a user who is requesting access to a virtual card issued by the card issuer. Card personalization is performed for each cardholder record.

[0020] In some embodiments of the invention, the method includes receiving a card verification value for each personalized cardholder record from a card issuer.

[0021] Preferably, the card verification value is a static card verification value CVV. Preferably, the card verification value is a dynamic card verification value CVV.

[0022] Support for dynamic CVV provides a more secure solution for issuer applications, reducing credit / payment card fraud.

[0023] In some embodiments of the invention, card personalization is performed by creating a subscription or cardholder record based at least on the received data (particularly, the request ID and authentication information) and the received card verification value, the subscription or cardholder record including the VC credentials for each cardholder record, wherein the subscription record is stored in a database. The database may be located in a private cloud of the VC processor.

[0024] Preferably, the VC data credential includes at least one of a primary account number (PAN), an expiration date, and a card verification value.

[0025] In some embodiments of the present invention, the card management system includes a digital content output manager DCOM. DCOM can be configured to create digital assets, particularly card images, for each cardholder record, and store the digital assets for each cardholder record, preferably together with the VC credentials in the corresponding cardholder record.

[0026] In some embodiments of the present invention, DCOM is configured to provide digital assets to the VC processor upon receiving a VC image provision request from a card issuer application.

[0027] In some embodiments of the present invention, the card management system is configured to be accessed through an API library integrated within the user's mobile banking application as a software development kit.

[0028] This provides cardholders with an efficient way to perform CNP transactions by referring to their virtual card.

[0029] In some embodiments of the invention, the card management system is configured to delete a cardholder record after a preset period of time has passed since the creation of the cardholder record.

[0030] This allows provision of a temporary virtual credit card with a limited day subscription. For example, a temporary VC may be available for 30-45 days, at which point the VC details will be purged from the VC processor. If the issuer wishes the VC to extend beyond a preset time limit, data lifecycle management, consent, and other considerations in data storage may be implemented to retain the data beyond the temporary period.

[0031] It must be noted that all devices, elements, units and means described in this application can be implemented in software or hardware elements or a combination thereof. All steps performed by various entities described in this application and the functions described are intended to indicate that the corresponding entities are suitable or configured to perform the corresponding steps and functions.

[0032] Other aspects, features and advantages of the present invention will become apparent to those of ordinary skill in the art after reading the following detailed description of the preferred embodiments and variations of the present invention in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Reference will now be made to the accompanying drawings, in which:

[0034] Figure 1 A schematic diagram illustrating the process flow of a customer / user applying for a physical card and receiving access to a virtual card according to an embodiment of the present invention is shown;

[0035] Figure 2 A structural diagram of a system according to an embodiment of the present invention is shown;

[0036] Figure 3 A schematic diagram of a card management system for providing VC services according to another embodiment of the present invention is shown;

[0037] Figure 4 A flow chart showing a method for registering a card issuer and for providing a user with access to a virtual card according to an embodiment of the present invention;

[0038] Figure 5 shows a schematic representation of the process from card personalization to virtual card output according to an embodiment of the present invention;

[0039] Figure 6 A schematic diagram showing a process flow of performing a card-not-present (CNP) transaction using a virtual card credential according to an embodiment of the present invention;

[0040] Figure 7 A signal diagram showing a CNP transaction according to an embodiment of the present invention; and

[0041] Figure 8 Shown is a schematic representation of a virtual card credential provided to a user according to an embodiment of the present invention. DETAILED DESCRIPTION

[0042] The detailed description of the present invention is given below with reference to the accompanying drawings showing specific embodiment examples of the present invention. These embodiments are described in sufficient detail to enable those skilled in the art to practice the present invention. It should be understood that the various embodiments of the present invention are different, but not necessarily mutually exclusive. For example, without departing from the scope of the present invention, the specific features, structures or characteristics described herein in conjunction with one embodiment can be implemented in other embodiments. In addition, it should be understood that the position or arrangement of each element in each disclosed embodiment can be modified without departing from the scope of the present invention. Therefore, the following detailed description should not be regarded as having a limiting meaning, and the scope of the present invention is limited only by the attached claims properly interpreted and the full range of equivalents given by the claims. In the accompanying drawings, the same numbers refer to the same or similar functions in several views.

[0043] Figure 1A schematic diagram illustrating the process flow for a customer / user to apply for a physical card and receive access to a virtual card according to an embodiment of the present invention is shown.

[0044] refer to Figure 1 , a customer or user 400 is applying for a (physical) credit card from a credit card issuer 300. A corresponding virtual card 150 is created and access to the virtual card credentials is provided to the user before the physical card arrives. This is done by Figure 2 The card management system 100 and its components shown in FIG.

[0045] The card management system 100 provides digital and physical orchestration by creating a digital or virtual representation of a physical card and supporting CNP transactions for the user 400 before the user 400 receives the physical card.

[0046] In particular, the card management system 100 acts as an intermediary entity between the card issuer 300 and the mobile banking application 330 (also referred to as the issuer application) through which the user 400 can access the virtual card 150 to perform CNP transactions.

[0047] The card management system 100 may be integrated or provided within the mobile banking application 330 via a complete SDK (Software Development Kit) containing a library 140 of APIs. The APIs may be customized to the issuer's request during the onboarding of the virtual card or in response to individual requests in the form of API calls. In any case, upon receiving a request to provide a virtual card data credential (VC credential for short) (e.g., received from the card issuer 300 during onboarding or via an API call from the card issuer application 330), the card management system 100 retrieves the VC credential from the database 112 and provides it to the card issuer application 330 to be pushed and thus displayed and made accessible to the user 400, preferably via the mobile banking application or any other suitable application running on the user's device (e.g., a mobile phone or desktop computer).

[0048] Virtual card VC credentials (also known as data credentials) can include PAN, static or dynamic expiration date, static or dynamic CVV, ePIN, card status and other card-related data.

[0049] The Primary Account Number (PAN) uniquely identifies a payment card and is generated when an account is opened by the card issuer.

[0050] The Card Verification Number (CVV) is a three-digit code located on the back of credit and debit cards. The CVV is considered a static value because it is imprinted on the card. In contrast, a dynamic Card Verification Value (dCVV) is a new code that is created periodically to increase the security of payment card transactions. The dynamic CVV may be provided by G+D, Visa, MasterCard, or any provider that provides the API services described throughout this specification.

[0051] The VC data credentials may be provided to the card management system 100 during onboarding, i.e., during registration of the card issuer with the card management system or card personalization agency 200, respectively, which process will be referred to below. Figure 3 , 5 and 5 are further described.

[0052] Figure 2 A structural diagram of the card management system 100 and other entities interacting with the card management system is shown. Figure 3 A preferred embodiment of frame A is shown in FIG.

[0053] refer to Figure 2 and Figure 3 , a request for VC credentials is received from the user 400 at the VC processor 130 via the API management gateway 140. The VC request includes a request ID and authentication information, and is stored in the private cloud 240. The VC processor 130 obtains the VC data credentials and provides them to the API management gateway 140 to the card issuer application 330 to be pushed to the user 400, thereby allowing card-not-present transactions on the card issuer application 330.

[0054] In addition to the VC processor 130, the card management system 100 may also include several components for providing VC services, such as a VC API service 131, a dCVV service 132, and a VC encryption service 134, which uses a plurality of security keys 135. Preferably, access to the VC cloud 240 from the API management gateway is provided through a firewall 241. The rule set 243 is used to specify access rules.

[0055] In one embodiment, the VC data credentials are provided directly to the VC processor by the card issuer 300 through the API management gateway 140. The VC credentials are stored in the VC processor, preferably in the cloud database 112. In other words, the cardholder data is stored and retrieved for reference through the API management gateway 140. The cardholder data is stored in such a way that it can be referenced by the request ID received at the VC. By storing the VC credentials in the VC processor private database 112, compliance with the Payment Card Industry Data Security Standard PCI-DSS is achieved.

[0056] In one embodiment, in addition to the VC processor 140 and the API management gateway 140 , the card management system 100 may further include an event orchestration system (EOS) 110 .

[0057] The Event Orchestration System (EOS) is responsible for managing all cardholder records for registered card issuers, but is also responsible for managing multiple requests received from users through card issuer applications (including unregistered card issuers). The availability of information stored at EOS enables data analysis at card personalization agencies as well as card issuers. EOS further allows information flexibility regarding multi-service support for data publishing.

[0058] As an alternative or in addition to the VC processor 130 receiving VC credentials directly from the card issuer, in a preferred embodiment, the VC credentials may be managed by the event orchestration system (EOS) 110 of the card management system 100. The EOS 110 creates multiple cardholder records for each of the multiple registered card issuers and stores them in the database 112. Each cardholder record may include the VC credentials of each user approved by the card issuer to receive a physical card. The EOS can be viewed as a data lake that collects data for all cardholders and supports input files and direct file creation. All data can be obtained through API requests from the issuer gateway 330 via the API management gateway 140.

[0059] The VC processor 130 can communicate with the EOS 110 through an API, such as the event synchronization queue API 120. VC requests received from the VC processor at the EOS are recorded in the EOS as EOS requests or events. The event synchronization queue API 120 can be hosted within the DMZ 230, thereby adding an additional layer of security.

[0060] Preferably, the VC request includes a request ID and authentication information, which is recorded and stored as an EOS event when received at the EOS. The authentication information may include a session key between the card issuer application 330 and the VC processor 130. Other forms of authentication may also be used, such as two-factor authentication via a pin and / or biometrics.

[0061] By sending a request from the issuer server 310 to the server of the card personalization agency 200, the request ID can be obtained at the issuer application 330, as will be described below in conjunction with Figure 6 Further described.

[0062] The VC processor 130 is also responsible for obtaining the VC credential from the EOS 110 and providing the VC credential to the card issuer application 330 to be pushed to the user 400. The VC credential is preferably provided to the user 400 via the API management gateway 140 and the issuer gateway 320.

[0063] The Digital Content Output Manager (DCOM) 150 is responsible for creating and managing further digital assets, particularly visual data, to be output to the Issuer Application 330. This may include creating a card image of a virtual card and providing the card image via the Issuer Gateway 320 for display within the Issuer Application 330 at the User 400.

[0064] exist Figure 8 An example of an image of a virtual card 150 displayed within the issuer application 330 is depicted in (a). The card image may be overlaid with the VC credentials received upon request from the VC processor. For example, Figure 8 The virtual card 150 in (a) shows the PAN, expiration date and static CVV. Instead of a static CVV, a dynamic CVV can be provided by the card management system and displayed in the issuer application 330, such as Figure 8 (b). Figure 8 As shown in (c), a dynamic expiration date may also be displayed, preferably based on a request.

[0065] Reference below Figure 4 and Figure 5 The functionality of the card management system 100 is presented.

[0066] Figure 4 A flow chart of a method for registering a card issuer and providing a user with access to a virtual card according to an embodiment of the present invention is shown. The method includes two parts, namely Figure 4 (a) shows the steps for logging in or registering with a card issuer, and Figure 4 (b) shows the steps performed by the card management system for virtual card output (i.e., for providing the user with access to the virtual card). Steps S1 and S2 are not necessarily performed by the card management system. These are preliminary steps, usually processed by the personalization system HSA 220 at the card personalization agency 200. Alternatively, the HSA may be integrated into the card management system 100.

[0067] exist Figure 5 FIG. 4 schematically illustrates the entire process from card personalization to virtual card output according to an embodiment of the present invention. Figure 5 The main steps depicted in Figure 4 The steps described in Figure 5 It also shows Figure 4 Additional or optional steps not shown.

[0068] Reference Figure 4 (a) In a preliminary first step S1, the card issuer 300 is registered with the card personalization agency 200 through the intermediary of the personalization system HSA 220. This allows the card issuer 300 to establish with the card personalization agency 200 to allow card fulfilment and personalization delivery for approved cardholders.

[0069] That is, the card issuer 300 is able to submit a card order request for personalization and fulfillment, along with the additional required data for each unique cardholder record delivered ( Figure 4 Step S2 in the above method; Figure 5 step "1" in ). This step may additionally include Figure 5 Step 3 depicted in , is used to prepare a personalized physical card. The personalized data is pushed to EOS 110 to be stored as a VC or personalized credential on EOS 110. To this end, a cardholder record is created in step S3 and stored in the database 112 of EOS 110 in step S3.

[0070] In parallel with steps S1 and S2 or independently of steps S1 and S2, the card issuer 300 (respectively its processor 310) may, in step S11 (corresponding to Figure 4 The dCVV (dynamic card verification value) is sent in step "1a" of the registration request. This can happen periodically, or every time a new dCVV is created. In other words, while a static CVV may be received with the enrollment request, a dynamic CVV may be received every time a new value is created at the card issuer.

[0071] Based on the received CVV (or dCVV) and card personalization data, a cardholder subscription or record is created in step S3 and stored in the database 112 in step S4. Thus, the cardholder record contains VC credentials that uniquely identify the virtual card of the user who has been approved to receive the corresponding physical card. This step is preferably implemented by the event orchestration system (EOS) 110.

[0072] In another possibly optional step S5, additional information, such as digital assets, may be created for each cardholder record and stored in step S6. The digital assets may be stored in the database 112 together with the cardholder records belonging to the same virtual card and may be uniquely identified, for example, by a record ID.

[0073] Figure 4 The flowchart in (b) depicts the steps performed by the card management system 100 for providing the virtual card 150 to the user 400 upon receiving a request for VC credentials in step S10 .

[0074] In step S20, the request ID and authentication information received in the VC request in step S10 are extracted from the VC request and stored. The authentication information may indicate a form of authentication, such as, for example, token-based authentication that generates a cryptographically secure token unique to each virtual card. The request ID and authentication information may be stored in a private cloud ( Figure 4 In the figure mark 240).

[0075] EOS 110 may record the received VC request as an EOS request or event uniquely identified by a request ID. Preferably, EOS 110 receives the VC request via an API, such as Figure 4 The event synchronization queue API in 120. Using a queue allows all VC requests to be processed in a well-defined order.

[0076] In step S30, the VC credential corresponding to the request ID is obtained from the database 112, and after authenticating the EOS 110 to the requesting card issuer 300 in step S40 ( Figure 4 ), providing the VC credentials to the card issuer application 330 to push ( Figure 4 Step 12) in step 12) to the user 400 for display via the mobile banking application at the user device.

[0077] After the user has received the VC credential, he / she can perform a CNP transaction. Figure 6 It is shown in a general way in Figure 7 Implementation and signaling details between the entities involved in a CNP transaction are shown.

[0078] refer to Figure 6 , the user can use the VC credentials provided by the issuer application 330 to add the payment method to an existing account, such as the application Apple Pay.

[0079] Alternatively, users can perform CNP transactions with merchants, such as Figure 7 shown.

[0080] In step S6-10, the user 400 enters credit card details at the merchant 500. This can be performed over the phone, over the internet or physically through a card payment device at the merchant. In step S6-11, the user 400 logs into his issuer application 330 and requests a VC credential.

[0081] Through a series of steps S6-12 to S6-22 (these steps correspond to the above combined Figure 4 (b) and Figure 5), the VC credentials are obtained from the card management system 100, and the card management system 100 is accessed from the issuer application as an SDK.

[0082] Specifically:

[0083] - In step S6-12, a request for a VC credential is sent from the issuer application 330 to the card management server 200 via the issuer server 310 (step S6-13). These steps correspond to Figure 4 (a) Step S10 and Figure 5 Step 8. The card management server can be Figure 1 The card personalization agency 200 provides.

[0084] - Generate a request ID at the card management server 200 and provide the request ID to the issuer application 330 via the issuer server 310 (step S6-15).

[0085] - Through the issuer application 330, the card management system 100 is provided with a request ID (step S6-16).

[0086] - Authenticating the request in steps S6-17 and S6-18.

[0087] - Authentication steps S6-17 to S6-19 verify the identity of the issuer application and the validity of the request.

[0088] - In step S6-21, the card management system 100 provides the VC credentials to the issuer application 330 for display to the user 400 in step S6-22.

[0089] - In step S6-23, the user may input the received VC credential into the merchant's payment system.

[0090] - In step S6-24, the merchant 500 requests the payment network 600 to process the transaction (step S6-25).

[0091] - In steps S6-26 to S6-29, the payment network 600 performs authorization and verification of the transaction with the card issuer server 310,

[0092] - If the authorization and verification are successful, a transaction confirmation is presented to the merchant in step S6-30.

[0093] The aspects and embodiments described herein allow for the creation of a near real-time virtual view of physical card details within a banking application before the physical card arrives. By instantly delivering card credentials, such as PAN, expiration data, static / dynamic CVV, both the card issuer and the user / cardholder are provided with an efficient and secure means for performing card-not-present transactions.

[0094] Further benefits include:

[0095] -Cardholders are encouraged to download and access the banking app to check their VC.

[0096] -Cardholders are encouraged to conduct online transactions before their cards arrive.

[0097] - Two subscription options, permanent and temporary, are provided to the card issuer by configuring the card management system to delete the cardholder record after a preset period of time has passed since the cardholder record was created.

[0098] - Provides an efficient and secure method for accessing VC credentials by leveraging the card issuer's existing secure login details.

[0099] -Authentication capabilities within the VC processor can be customized to different forms of authentication, allowing further layers of authentication to be provided (e.g., biometric scanning, two-factor authentication).

[0100] In the foregoing description, the present invention has been described with reference to specific embodiments of the present invention. However, it will be apparent that various modifications and changes may be made thereto without departing from the broader scope of the present invention. For example, the above process flow is described with reference to a specific ordering of process actions. However, the order of many of the described process actions may be changed without affecting the scope or operation of the present invention. Therefore, the description and drawings are to be regarded as illustrative rather than restrictive.

Claims

1. A method for providing access to a virtual card VC (150) through a card management system (100), wherein the VC (150) is issued to a user (400) by a card issuer (300), the card management system (100) comprising a virtual card VC processor (130) and an API management gateway (140), the method comprising: - receiving ( S10 ) a request for VC credentials at the VC processor ( 130 ), the request being sent by the user ( 400 ) through the API management gateway ( 140 ); - obtaining ( S30 ) a VC credential by the VC processor ( 130 ); and - providing (S50) the VC credentials to a card issuer application (330) via the API management gateway (140) to be pushed to the user (400), thereby allowing card-not-present transactions on the card issuer application (330).

2. The method according to claim 1, wherein: The VC request includes a request ID and authentication information, and the method further includes storing (S20) the request ID and the authentication information in a private cloud (240) of the card management system (100).

3. The method according to claim 2, further comprising: - obtaining (S30) a VC credential by retrieving a cardholder record corresponding to the request ID from the VC cloud storage (112); - performing (S40) authentication between the card issuer (300) and the VC processor (130); and - After successful authentication, the VC credentials are provided (S50) to the card issuer application (330).

4. The method according to claim 2 or 3, wherein: The authentication information includes a session key between the card issuer application (330) and the VC processor (130).

5. The method according to any of the preceding claims, further comprising registering (S1) the card issuer (300) with the card management system (100) prior to receiving a request for VC credentials from the card issuer application (330).

6. The method according to any of the preceding claims, further comprising receiving (S2) a request for card personalization from the card issuer (300), the request comprising data uniquely identifying each cardholder record of a plurality of cardholder records of a user requesting access to the virtual card, and the method further comprising performing (S2) card personalization for each cardholder record.

7. The method according to claim 5 or 6, further comprising receiving (S11) a card verification value for each personalized cardholder record from the card issuer (300).

8. The method according to claim 7, wherein: The card verification value is a dynamic card verification value dCVV or a static card verification value CVV.

9. The method according to any one of claims 5 to 8, wherein: The step (S2) of card personalization is performed by creating (S3) a subscription or cardholder record including the VC credentials for each cardholder record based at least on the received data and the received card verification value and storing the subscription record in a database (112), preferably located in a VC processor (130) private cloud (240).

10. The method according to any one of claims 5 to 9, comprising: - creating (S4) a digital asset, in particular a card image, for each cardholder record by a digital content output manager DCOM (150) of the card management system (100); and - For each cardholder record, storing (S5) the digital asset in the corresponding cardholder record, preferably storing the digital asset together with the VC credential in the corresponding cardholder record.

11. The method according to claim 10, comprising: - Upon receiving a VC image provision request from the card issuer application (330), providing (S6) the digital asset to the VC processor.

12. A card management system (100) for providing access to a virtual card VC (150), the VC (150) being issued by a card issuer (300) to a user (400), the card management system (100) comprising: -API Management Gateway (140); and - A virtual card VC processor (130), which is configured to: - receiving a request for VC credentials from the user (400) via the API management gateway (140); - Obtain VC credentials; and - Providing the VC credentials to the card issuer application (330) through the API management gateway (140) to be pushed to the user (400), thereby allowing card-not-present transactions on the card issuer application (330).

13. The card management system (100) of claim 12, further comprising an event orchestration system EOS (110) configured to create and store a plurality of cardholder records for each of a plurality of card issuers (300), each cardholder record comprising VC credentials for each user approved by the card issuer to receive a physical card.

14. The card management system (100) according to claim 13, configured to receive personalization information of a registered card issuer from a personalization system HAS (220) of a card personalization agency (200), wherein: The card management system (100) is configured to store cardholder records and provide VC credentials only to registered card issuers.

15. The card management system (100) according to claim 12 or 13, further comprising a digital content output manager DCOM (150), the DCOM (150) being configured to create digital assets, in particular card images, for each cardholder record, store the digital assets for each cardholder record, preferably store the digital assets together with the VC credentials in the corresponding cardholder record, and provide the digital assets to the VC processor upon receiving a VC image provision request from the card issuer application.

Images