Card on file enrolment method and system

Abstract

A method of enrolling a payment card as a card on file by a payment processing platform. The method comprising the steps of: receiving, from a card issuer platform associated with the payment card, a registration request comprising data associated with the payment card; storing, on a secure storage means, the data associated with the payment card; sending, to the card issuer platform, a registration receipt; receiving, from a merchant platform, the registration receipt; generating a merchant token; and sending, to the merchant platform, the merchant token useable as a card on file.

Description

[0001] CARD ON FILE ENROLMENT METHOD AND SYSTEM

[0002] CROSS-REFERENCE TO RELATED APPLICATION

[0003] This application claims the benefit of, and priority to, Italian Patent Application No. 102023000013695, filed June 30, 2023. The entire disclosure of the above application is incorporated herein by reference.

[0004] FIELD OF THE DISCLOSURE

[0005] The present disclosure relates to a card on file enrolment method and system.

[0006] BACKGROUND

[0007] Many remote e-commerce payment platforms exist currently which allow a customer to pay for their products on an e-commerce site with very little friction. However, the enrolment of users into those e-commerce platforms is complex and requires multiple user interactions with online forms. These requirements, in particular the multiple user interactions, induce friction in the customer enrolment procedure which can cause potential customers to abandon the enrolment journey prior to completing it. This reduces customer uptake of e-commerce payment platforms that provide a higher quality of user interaction over the classic approach of entering payment card details into an online form, leading to increased complexity of user interaction in the long run and more complex and computationally intensive requirements for processing of payments compared to specialist e-commerce payment platforms.

[0008] Currently, a cardholder wishing to onboard or enrol with a merchant that requires card details to be stored, for example to maintain a subscription for a service, has to manually enter card details associated with a payment card. The payment card may be either a soft, virtual card or a physical card having an associated personal account number (PAN). Such manual entry may require multiple user interactions with online forms, for example when entering a card number associated with the payment card, which may in turn induce friction in the customer enrolment procedure, which can cause potential customers to abandon the enrolment process prior to completion. Accordingly, customer uptake of merchant goods or services may be reduced due to the friction introduced by this manual card detail entry process. Additionally, once card details have been entered, the cardholder may also have to authenticate themselves, for example via a mobile banking app which uses two factor authentication for security to ensure that it is the cardholder who is utilising the payment card. This further increases the number of user interactions required to register a payment card.

[0009] The present disclosure has been devised to mitigate or overcome at least some of the above-mentioned problems.

[0010] SUMMARY OF THE DISCLOSURE

[0011] In accordance with a first aspect of the present disclosure, there is provided a method of enrolling a payment card as a card on file using a payment processing platform, the method comprising the steps of: receiving, from a card issuer platform associated with the payment card, a registration request comprising data associated with the payment card; storing, on a secure storage means, the data associated with the payment card; sending, to the card issuer platform, a registration receipt; receiving, from a merchant platform, the registration receipt; generating a merchant token; and sending, to the merchant platform, the merchant token useable as a card on file.

[0012] The proposed method may advantageously provide a means for enrolling a card on file without requiring an input from a user adding their payment card details to a merchant service. In particular, the enrolment of the card on file may occur at backend systems, with communication between the card issuer platform, the merchant platform, and the payment processing platform.

[0013] Additionally advantageously, the proposed method may reduce an amount of data sent by a user computing device. In particular, the user computing device may not have to transmit data representing their payment card details to the merchant platform. Instead, transmission of payment card data may occur between the payment processing platform and the card issuer platform. These platforms may be optimized for such data transfer, for example using encrypted and secure communication channels, and as such, data transfer may also be optimized.

[0014] Further advantageously, due to the use of a merchant token, the merchant platform may never receive or store user information such as funding primary account number (FPAN), address, or any other relevant information. In particular, the merchant platform may initiate a transaction by sending the merchant token to the payment processing platform along with transaction details. Instead, this information may be stored on the card issuer platform and / or the payment processing platform. Thus, sensitive information associated with the user or cardholder may be secured in few places, and may also be less vulnerable.

[0015] Strong customer authentication (SCA) may be standardized and performed by an issuer mobile banking application stored on the user computing device. Thus, a user or cardholder taking part in the proposed method may be provided with an additional layer of security in the form of SCA without including additional authentication steps that may otherwise generate further cardholder onboarding friction.

[0016] The registration request may comprise data associated with the payment card. Thus, data associated with the payment card may be transferred to the payment processing platform. Advantageously, the payment processing platform may utilize this data, for example for generating a payment card token.

[0017] The registration request may be received from the card issuer platform via a push provisioning API. Advantageously, the registration request may invoke a process at the payment processing platform automatically. Automatic invocation may reduce an overall processing time for enrolling a card on file. A reduction in overall processing time may in turn advantageously reduce the number of cardholders leaving the onboarding process.

[0018] The registration receipt may comprise a unique identifier associated with the payment card. The unique identifier may be used in a subsequent step to identify relevant data for carrying out said step. Thus, the unique identifier may reduce an overall processing time. A reduction in overall processing time may in turn advantageously reduce the number of cardholders leaving the onboarding process.

[0019] The registration receipt may be received from the merchant platform via an enrolment API. Advantageously, the registration request may invoke a process at the payment processing platform automatically, the process being the merchant token generation process. Automatic invocation may reduce an overall processing time for enrolling a card on file. A reduction in overall processing time may in turn advantageously reduce the number of cardholders leaving the onboarding process.

[0020] The method may further comprise storing a copy of the merchant token in the secure storage means. Storing a copy of the merchant token may assist in subsequent validation of the merchant token. The method may also further comprise storing an indicator in the secure storage means, the indicator arranged to associate the merchant token with the data associated with the payment card. The indicator may advantageously facilitate validation and authentication of a transaction.

[0021] The method may further comprise determining that a cardholder associated with the payment card is not already registered for a digital payment solution. The digital payment solution may be Click To Pay. This step may occur prior to the other steps of the method, and the other steps may occur only upon determination that the cardholder is not already registered. Thus, unnecessary duplication of processing steps may be avoided if the payment card is already registered for the digital payment solution.

[0022] Determining that the payment card is not already registered for the digital payment solution may comprise: receiving one or more cardholder details associated with the cardholder; and determining that the one or more cardholder details are not associated with an account stored on the account database.

[0023] Advantageously, the payment processing system may easily determine that the cardholder is not already registered for the digital payment solution.

[0024] The data associated with the payment card may comprise data corresponding to at least one of: card primary account number, FPAN, email address, telephone number, address. Thus, the data associated with the payment card may provide sufficient data for a transaction to occur.

[0025] The method may further comprise: receiving, from the merchant platform, a transaction request comprising the merchant token and transaction details; and initializing an authorization process. Thus, the payment processing platform may also advantageously facilitate a transaction using the merchant token.

[0026] The transaction details may comprise at least one of: a transaction amount; a transaction currency; and a transaction identification (id). Thus, the payment processing platform may advantageously be provided with sufficient information to initialize the authorization process for the transaction.

[0027] Initializing the authorization process may comprise: verifying that the merchant token is valid; and sending an authorization request to the card issuer platform including the transaction details. Accordingly, the payment processing platform may advantageously communicate with the card issuer platform to carry out the transaction. Verifying that the merchant token is valid may comprise comparing the merchant token to the merchant token stored on the secure storage means. Advantageously, the merchant token may easily be verified.

[0028] In accordance with a second aspect of the present disclosure, there is provided a payment processing platform comprising: a secure storage means; and one or more processors adapted to perform the steps of the first aspect.

[0029] It will be appreciated that any features described herein as being suitable for incorporation into one or more aspects or embodiments of the present disclosure are intended to be generalizable across any and all aspects and embodiments of the present disclosure. Other aspects of the present disclosure can be understood by those skilled in the art in light of the description, the claims, and the drawings of the present disclosure. The foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the claims.

[0030] BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The present disclosure will now be described, by way of example only, by reference to the accompanying drawings, in which:

[0032] Figure l is a schematic representation of a payment card registration system according to an aspect of the present disclosure;

[0033] Figures 2A and 2B show a flow diagram of a payment card registration process using the system of Figure 1; and

[0034] Figure 3 is a flow diagram of an example method for validating transactions.

[0035] DESCRIPTION OF THE DISCLOSURE

[0036] Referring now to Figure 1, a payment card enrolment system 100 comprises a user device 102, a merchant platform 104, a payment processing platform 106, and a card issuer platform 108.

[0037] The system 100 also comprises an application programming interface (API) broker processor (not shown) for push provisioning, and a push provisioning engine (not shown). Typically, the push provisioning engine comprises a push provisioning API (not shown). By way of non-limiting example, the push provisioning API is associated with a payment scheme such as MasterCard®. The user device 102 is a device associated with a user or consumer intending to purchase or sign up for a product or service. The user device 102 comprises a card issuer application 120 stored in a memory (not shown). The card issuer application 120 is an application associated with a card issuer that has issued a payment card to the consumer. The card issuer and card issuer application 120 are associated with the card issuer platform 108. The user device 102 also comprises a merchant application 122. The merchant application 122 is an application stored in the memory of the user device 102, associated with a merchant offering a product or service. The merchant application 122 and the merchant are associated with the merchant 104. It will be appreciated that the card issuer application 120 can be a card issuer website, and the merchant application 122 can be a merchant website.

[0038] In the present example, the user device 102 is a mobile computing device comprising a touch screen (not shown) for receiving user input. It will be appreciated that the user device 102 may be any suitable device, such as a desktop computing device. The user device 102 is in communication with the merchant platform 104 and the card issuer platform 108 via a secure communications channel.

[0039] The merchant platform 104 is a platform operated by, or associated with, a merchant. The merchant is a party offering a product or service, such as a streaming service. The merchant platform 104 comprises one or more computing devices arranged to carry out a range of functions. The merchant platform 104 is in communication with the user device 102, the payment processing platform 106, and the card issuer platform 108 via one or more secure communication channels.

[0040] The payment processing platform 106 is an entity that comprises systems and infrastructure for facilitating the processing of electronic payment transactions. The payment processing platform 106 facilitates registration of a payment card associated with the cardholder for a payment service, such as Click to Pay™. The payment processing platform 106 comprises a tokenization engine (not shown), arranged to generate a token corresponding to the payment card and merchant. The payment processing platform 106 is in communication with the merchant platform 104 and the card issuer platform 108 via one or more secure communication channels.

[0041] The card issuer platform 108 is operated by, or is associated with, a card issuer that has issued a payment card to the consumer. The card issuer platform 108 is associated with the card issuer application 120. The card issuer platform 108 validates a transaction, authenticates the consumer, and communicates with the payment processing platform 106 and the merchant platform 104 to register and facilitate registration of the payment card associated with the cardholder for card provisioning. The card issuer platform 108 is in communication with the user device 102, the merchant device 104, and the payment processing platform 106.

[0042] Referring now to Figures 2A and 2B, a flow diagram of a method 200 of enrolling a payment card as a card on file is depicted. In the example of method 200, the merchant platform 104 offers a service in exchange for a monthly subscription of a monetary amount. For example, the merchant platform 104 offers a streaming service having a monthly subscription of €10.00 a month. Furthermore, in the example of method 200, the user device 102 is a smartphone comprising a touch screen. In Figures 2A and 2B, the payment processing platform 106 is depicted as having two components. This is to illustrate that the payment processing platform 106 may comprise more than one element for carrying out different method steps.

[0043] A first step 202 of method 200 includes the user device 102 communicating a sign-up request to sign-up, purchase, or register for the service offered by the merchant platform 104. The communication may be in response to a user interaction with a hyperlink on the website or application associated with the merchant platform 104. The communication may comprise a requested URL, user session data, and / or other parameters.

[0044] In response to the request, the merchant platform 104 communicates a redirect response to redirect the user device 102 to a registration page. The redirect response may comprise one or more HTTP headers comprising information specifying a URL associated with the registration page.

[0045] Once the user device 102 receives the redirect response, it displays the registration page by initiating a new HTTP request or navigating to a new page of the application. The registration page may comprise a UI having one or more fields (for example, HTML forms) for registering to the service. For example, the registration page may comprise an email field, a plan selection field, and a sign-up field. The email field is arranged to receive input of an email address associated with the user. The plan selection field is arranged to allow the user to select a plan associated with the service, from a selection of one or more payment plans. The sign-up field is arranged to provide a means for the user to consent to registration to the service. The user device 102 may receive input from the user to populate the one or more fields with relevant information, and may subsequently send a registration form to the merchant platform 104 comprising registration data. The registration data comprises the information input to the one or more fields, such as the user email address, payment plan, etc.

[0046] The merchant platform 104 may compare the registration data to data already stored on the merchant platform 104 to determine whether the registration data matches pre-existing registration data.

[0047] In step 204, the merchant platform 104 communicates a check request to the payment processing platform 106 for determining whether the registration data is associated with an account that has already enrolled into a payment service. The payment service may be, for example Click To Pay.

[0048] At step 206, the payment processing platform 106 responds with a communication comprising data indicating whether the registration data is associated with an account that has already enrolled into the payment service. For example, the payment processing platform 106 compares an email address comprised in the registration data to one or more email addresses associated with accounts stored on the payment processing platform 106 datastore, and communicates the result to the merchant platform 104. In the present example, the payment processing platform 106 determines that none of the registration data is associated with any accounts stored on the payment processing platform 106.

[0049] At step 208 of the method 200, the user device 102 provides a means for initiating a payment card enrolment process. For example, if the user device 102 is using the merchant application 122 associated with the merchant platform 104, the merchant application 122 causes, for display on the user device 102, a user interface comprising an interactable element. If the user device 102 is using a merchant website associated with the merchant platform 104, the merchant website redirects the user device 102 to a new URL corresponding to a webpage comprising a user interface having an interactable element. The interactable element of the merchant application may be substantially similar to the interactable element of the merchant application. The interactable element map comprises a dropdown menu comprising one or more options, each option corresponding to a respective card issuer. At least one of the options corresponds to the card issuer platform 108. At step 210, the user device 102 communicates a bank selection communication to the merchant platform 104. The bank selection communication comprises data indicative of a card issuer selected from one or more card issuers. This communication from the user device 102 is in response to a user interaction with the interactable element, the interaction being a selection of a dropdown menu element corresponding to a card issuer. A second user interaction may also occur prior to communication of the bank selection communication, for example when an interaction occurs with a second interactable element, the second interactable element being a ‘confirmation’ interactable element.

[0050] At step 212, transaction data is communicated to the card issuer platform 108. In particular, the merchant application 122 initiates the launch of the card issuer application 120 by known means. The merchant application 122 passes transaction data to the card issuer application 120 by appending one or more transaction parameters to the URL associated with the card issuer application 120. The transaction parameters may include one or more of: a transaction amount (e.g., €10.00); a transaction frequency (e.g., monthly); a merchant identity (e.g., Netflix); a merchant service ID (e.g., a unique code that identifies the merchant in the payment processing platform 106); a session ID; and a call back (e.g., a URL for use by the card issuer platform to redirect the user device 102 to the merchant application 122). If the card issuer application 120 is not installed on the user device 102, the user will be prompted to install it prior to launch.

[0051] At step 214, the cardholder is authenticated. For example, the card issuer application 120 presents a user interface on the user computing device 102, the user interface comprising one or more fields for the user to input one or more login credentials. The user can enter login credentials, such as an email address and password to the one or more fields. The card issuer application 120 establishes a secure communication channel with the card issuer platform 108, and sends the input login credentials to the card issuer platform 108. The card issuer platform 108 determines whether the login credentials match login credentials stored in records of a user database of the card issuer platform 108. Optionally, the card issuer application 120 prompts the user to complete strong customer authentication (SC A) to verify that they are the authorised cardholder. It will be appreciated that any means for authenticating the cardholder may be used. The card issuer application platform 108 may generate a proof of authentication (e.g., a package of information comprising data indicating that the card issuer authenticated the payment card for the payment amount).

[0052] Additionally in step 214, the card issuer also validates the transaction. In particular, the card issuer validates the transaction to ensure that the transaction data appended to the URL is correct (e.g., that it has not been altered). An example method 300 for validating the transaction data sent in step 212 is shown in Figure 3. In a first step 302 of the method 300, the merchant platform 104 publishes a public key and a public key certificate, for example as a JSON web key set (JWKS) at a known location such as an endpoint URL 301 (e.g., at a well-known URL). At step 304, the merchant platform 104 creates a transaction token or transaction URL comprising one or parameters associated with the transaction, for example as part of a body of a JSON web token (JWT). The one or more parameters include one or more of: a transaction amount; a transaction frequency; a merchant name; a service identification; a session identification; and a call back. The JWT also comprises, or is signed with (e.g., as part of a header comprising the text “this JWT is from Merchant X and was signed with Key Y”), an issuer claim that indicates the party that issued the JWT, and a key identifier claim for identifying which key within the JWKS (i.e., the well-known URL) is used to sign the transaction token. At step 306, the merchant platform 104 sends the JWT to the card issuer platform 108 (step 212). At step 308, the card issuer platform 108 accesses the endpoint URL to access the public key certificate and the public key indicated by the key identifier. At step 310, the card issuer platform 108 validates the public key certificate and the one or more transaction parameters comprised in the JWT.

[0053] Returning to the method 200, at step 216, a review user interface comprising a confirmation interactable element is presented on the user device 102. In particular, the card issuer application 120 presents a review page user interface comprising a confirmation interactable element. The confirmation interactable element is a portion of the user interface with which a user can interact, for example by clicking a button with a mouse cursor or tapping a button on a touchscreen of the user device 102. The review page user interface also comprises a payment summary comprising details related to the service, such that the user is provided with a summary of what they intend to sign up to or purchase.

[0054] At step 218, a confirmation communication is sent. In particular, the user device 102 captures a user interaction with the confirmation interactable element and communicates a confirmation message to the card issuer platform 108. Accordingly, the user can interact with the confirmation interactable element, for example by tapping the button on the touchscreen of the user device 102, to communicate their approval to the card issuer platform 108.

[0055] At step 220, the card issuer platform 108 sends a registration request to the payment processing platform 106. The registration request corresponds to the payment card associated with the cardholder. The payment card is the payment card to be used for the transaction. The registration request comprises data associated with the payment card. For example, the registration request comprises a funding primary account number (FPAN) of the payment card, and any other relevant payment card information. The payment processing platform 106 stores the data associated with the payment card. To ensure the security of the payment card information, the registration request is encrypted according to standard encryption means prior to transmission of the registration request. The registration request is sent as an API call. In particular, the registration request is sent via a push provisioning API. The push provisioning API causes the payment processing platform 106 to create a click to pay profile.

[0056] At step 222, the payment processing platform 106 sends a registration receipt to the card issuer platform 108. The payment processing platform 106 sends the registration receipt to the card issuer platform 108 after receiving the registration request. The registration receipt comprises a unique identifier associated with the payment card. The payment processing platform 106 uses this unique identifier in a subsequent step for enrolment of the payment card to the payment service of the merchant platform 104. The payment processing platform 106 stores the information associated with the payment card, such as the FPAN and any other relevant payment card information, in a secure storage means.

[0057] At step 224, the card issuer platform 108 forwards the registration receipt to the merchant platform 104. The card issuer platform 108 also shares the proof of authentication generated in step 214 with the merchant platform 104. The card issuer platform 108 thus provides the merchant platform 104 with the unique identifier associated with the payment card. The card issuer platform 108 forwards the registration receipt to the merchant platform 104 via a secure communications channel.

[0058] At step 226, the merchant platform 104 forwards the registration receipt to the payment processing platform 106. The merchant platform 104 initiates an API call to the payment processing platform 106. In particular, the merchant platform 104 forwards the registration receipt via an enrolment API. Thus, the merchant platform 104 invokes a process at the payment processing platform 106. The merchant platform 104 also forwards the proof of authentication received in step 224 to the payment processing platform 106.

[0059] At step 228, a merchant token corresponding to the payment card is generated. In particular, the tokenization engine of the payment processing platform 106 generates a merchant token corresponding to the merchant. The merchant token is a unique identifier corresponding to the merchant generated by known means. The merchant token can only be used by the merchant platform 104 to initiate an authorization process, thus limiting risks of a data breach. The payment processing platform 106 stores a copy of the merchant token in a secure storage means. Additionally, the payment processing platform may store an indicator in the secure storage means, arranged to associate the merchant token with the data associated with the payment card. The merchant token may also comprise the proof of authentication received in step 226. For example, the merchant token may be generated comprising a string “this was authenticated by Issuer A for the amount XX”.

[0060] In some embodiments, the tokenization engine also generates a token corresponding to the payment card. The token is representative of ‘sensitive’ payment card information, and substitutes the sensitive information with equivalent ‘nonsensitive’ identification that may be mapped back to the payment card information. For example, the token may be created by applying a hash function to the payment card information. The tokenization engine securely stores the token on a secure storage means alongside an identifier associated with the merchant, cardholder and / or the card issuer.

[0061] At step 230, the payment processing platform 106 sends the merchant token to the merchant platform 104. The merchant token is sent to the merchant platform 104 via a secure communication channel, encrypted so as to further increase the security of the process. The merchant platform 104 stores the merchant token in a secure storage means. The merchant platform 104 thus possesses a merchant token that may be used to process transactions. Since the merchant token is not the same as the payment card details, the merchant platform 104 does not have access to, or store, the payment card details at this stage, thus improving security. Furthermore, unauthorized access to the merchant token does not compromise the security of the cardholder, because the merchant token alone cannot be used to derive the payment card information without knowledge of the function used to generate the merchant token.

[0062] At step 232, the merchant platform 104 sends a transaction request to the payment processing platform 106, the transaction request comprising the merchant token and transaction details. The transaction details comprise, for example, a transaction amount, a transaction currency, a transaction ID, and any other suitable information associated with the transaction. Thus, the payment processing platform 106 is provided with enough data to initiate an authorization process for the transaction. In this example, the transaction details comprise: a transaction amount of 10.00, a transaction currency of Euros, and any other suitable transaction information. In line with standard payment processes, the transaction request is first sent to an acquirer platform (not shown) via a proprietary communications channel prior to being forwarded to the payment processing platform 106.

[0063] At step 234, the payment processing platform 106 initializes an authorization process. The authorization process is initialized following the acquirer platform forwarding the transaction request to the payment processing platform 106 via a proprietary communications channel. The authorization process comprises known means for authorizing a transaction. For example, the payment processing platform 106 verifies that the merchant token is valid. The payment processing platform 106 verifies that the merchant token is valid by comparing the merchant token to the merchant token stored on the secure storage means. The payment processing platform 106 sends an authorization request to the card issuer platform 108 including the transaction details. In particular, the payment processing platform 106 maps the merchant token to the FPAN and shares the FPAN with the issuer. Thus, the merchant platform 104 uses the merchant token, and the issuer platform 108 receives the FPAN.

[0064] At step 236, the card issuer platform 108 authorizes the transaction. The card issuer platform 108 determines that the transaction can be approved (e.g., that the bank account associated with the payment card has an adequate amount of available funds for the transaction) and sends a transaction confirmation to the merchant platform 104.

[0065] At a final step 238, the user device 102 shows a confirmation user interface. The confirmation user interface is provided by the merchant application 122. The confirmation user interface comprises a graphical element depicting a confirmation that the transaction has been approved and / or that a subscription has been set up.

[0066] The system 100 and method 100 provide a means for registering a payment card, for example for subscribing to a service. From the user’s perspective, the only interactions required with the user device 102 include communicating a signup request to register or subscribe to a service offered by the merchant platform 104, inputting registration information, performing a user interaction to select a bank, and performing a user interaction to confirm the subscription. There is therefore no input of card details or other information required and as such, a significant amount of time is saved in subscribing to the service. Accordingly, user effort onboarding to a merchant service can be reduced as a result of the reduced burden on the user.

[0067] Additionally, due to the use of a merchant token, the merchant platform 104 never receives or stores user information such as FPAN. The merchant platform 104 initiates a transaction by sending the merchant token to the payment processing platform 106 along with transaction details.

[0068] In general, the routines executed to implement the embodiments of the invention, whether implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions, or even a subset thereof, may be referred to herein as "computer program code," or simply "program code." Program code typically comprises computer readable instructions that are resident at various times in various memory and storage devices in a computer and that, when read and executed by one or more processors in a computer, cause that computer to perform the operations necessary to execute operations and / or elements embodying the various aspects of the embodiments of the invention. The computer readable program instructions for carrying out operations of the embodiments of the invention may be, for example, assembly language or either source code or object code is written in any combination of one or more programming languages.

[0069] The program code embodied in any of the applications / modules described herein is capable of being individually or collectively distributed as a program product in a variety of different forms. In particular, the program code may be distributed using the computer readable storage medium having the computer readable program instructions thereon for causing a processor to carry out aspects of the embodiments of the invention. Computer readable storage media, which is inherently non-transitory, may include volatile and non-volatile, and removable and non-removable tangible media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. Computer readable storage media may further include RAM, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other robust state memory technology, portable compact disc read-only memory (CD-ROM), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and which can be read by a computer. A computer-readable storage medium should not be construed as transitory signals per se (e.g., radio waves or other propagating electromagnetic waves, electromagnetic waves propagating through a transmission media such as a waveguide, or electrical signals transmitted through a wire). Computer readable program instructions may be downloaded to a computer, another type of programmable data processing apparatus, or another device from a computer readable storage medium or an external computer or external storage device via a network.

[0070] Computer readable program instructions stored in a computer readable medium may be used to direct a computer, other types of programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions that implement the functions / acts specified in the flowcharts, sequence diagrams, and / or block diagrams. The computer program instructions may be provided to one or more processors of a general -purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the one or more processors, cause a series of computations to be performed to implement the functions and / or acts specified in the flowcharts, sequence diagrams, and / or block diagrams.

[0071] In certain alternative embodiments, the functions and / or acts specified in the flowcharts, sequence diagrams, and / or block diagrams may be re-ordered, processed serially, and / or processed concurrently without departing from the scope of the invention. Moreover, any of the flowcharts, sequence diagrams, and / or block diagrams may include more, or fewer blocks than those illustrated consistent with embodiments of the invention.

[0072] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the embodiments of the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms "comprise" and / or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. Furthermore, to the extent that the terms "includes", "having", "has", "with", "comprised of', or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprising".

[0073] While a description of various embodiments has illustrated all of the inventions and while these embodiments have been described in considerable detail, it is not the intention to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications will readily appear to those skilled in the art. The invention in its broader aspects is therefore not limited to the specific details, representative apparatus and method, and illustrative examples shown and described. Accordingly, departures may be made from such details without departing from the spirit or scope of the general inventive concept.

Claims

CLAIMS1. A method of enrolling a payment card as a card on file by a payment processing platform, the method comprising the steps of: receiving, from a card issuer platform associated with the payment card, a registration request comprising data associated with the payment card; storing, on a secure storage means, the data associated with the payment card; sending, to the card issuer platform, a registration receipt; receiving, from a merchant platform, the registration receipt; generating a merchant token; and sending, to the merchant platform, the merchant token useable as a card on file.

2. The method of claim 1, wherein the registration request comprises data associated with the payment card.

3. The method of any preceding claim, wherein the registration request is received from the card issuer platform via a push provisioning API.

4. The method of any preceding claim, wherein the registration receipt comprises a unique identifier associated with the payment card.

5. The method of any preceding claim, wherein the registration receipt is received from the merchant platform via an enrolment API.

6. The method of any preceding claim, further comprising storing a copy of the merchant token in the secure storage means.

7. The method of claim 6, further comprising storing an indicator in the secure storage means, the indicator arranged to associate the merchant token with the data associated with the payment card.

8. The method of any preceding claim, further comprising:determining that a cardholder associated with the payment card is not already registered for the digital payment solution.

9. The method of claim 8, wherein determining that the payment card is not already registered for the digital payment solution comprises: receiving one or more cardholder details associated with the cardholder; and determining that the one or more cardholder details are not associated with digital payment solution account stored on the account database.

10. The method of any preceding claim, wherein the data associated with the payment card comprises data corresponding to at least one of: card primary account number, FPAN, email address, telephone number, address.

11. The method of any preceding claims, further comprising: receiving, from the merchant platform, a transaction request comprising the merchant token and transaction details; and initializing an authorization process.

12. The method of claim 11, wherein the transaction details comprise at least one of: a transaction amount; a transaction currency; and a transaction id.

13. The method of claim 11 or claim 12, wherein initializing the authorization process comprises: verifying that the merchant token is valid; and sending an authorization request to the card issuer platform including the transaction details.

14. The method of claim 13, wherein verifying that the merchant token is valid comprises comparing the merchant token to the merchant token stored on the secure storage means.

15. A payment processing platform comprising: a secure storage means; and one or more processors adapted to perform the steps of any of claims 1 to

Images