WO2025064399A1 - Mobile application for corporate payments using virtual payment cards - Google Patents

Abstract

Virtual payment cards are provisioned by organizations for their employees and other authorized individuals using a supplier payment platform and a virtual payment mobile application deployed on the individual's mobile device. From an organization, a request to create a virtual payment card for the individual associated with the organization is received by the supplier payment platform. In response to the request, the supplier payment platform generates a virtual payment card having a virtual card number (VCN) and forwards the VCN to a mobile application executing on a mobile device associated with the individual. The supplier payment platform then receives an acknowledgment from the mobile application, the acknowledgement indicating receipt of the VCN, and responsive thereto forwarding details associated with the virtual payment card, including the VCN, to the organization.

Description

MOBILE APPLICATION FOR CORPORATE PAYMENTS USING VIRTUAL PAYMENT CARDS

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of, and priority to, U.S. Patent Application No. 63/583,575, filed on September 18, 2023, the entire disclosure of the above-referenced application is incorporated herein by reference.

BACKGROUND

Payment networks provide a multitude of services to both businesses and consumers, the most basic of which is the provision of payment processing systems that handle the authorization, clearing, and settlement of credit and debit card transactions. One of the services payment networks can provide to businesses includes a supplier payment management platform, allowing businesses to pay suppliers in a convenient way, leveraging the payment networks. A supplier payment management platform provides expense management tools allowing businesses to manage and control expenses, including the setting of spending limits, creation of custom spending rules, and monitoring of transaction activities in real time. The supplier payment management platform also provides detailed reporting and analytics to help businesses gain insights into spending patterns, identify cost-saving opportunities, and ensure compliance with company policies. Finally, the supplier payment management platform provides security features including transaction controls, authorization rules, and fraud prevention mechanisms.

Individuals, vendors, employees, and other users expect management of their expenses to be convenient for them. Existing solutions rely heavily on physical payment methods (e.g., cards or checks) which must be physically delivered to the users. While it is possible in some situations to add a physical payment method to the digital wallet of the user’s mobile device, many users forget to do so. As a result, in some situations, users will use their personal payment cards, checks, and/or cash for expenses and later file an expense report for reimbursement of these expenses. The reimbursement of purchases requires additional transaction costs including a lengthy reconciliation process, the maintenance of multiple payee records, inconvenience, and potential additional transaction expenses charged to the user (e.g., if bank fees or interest are applied to the transaction). SUMMARY

In some examples, aspects of the supplier payment platform and mobile application that are described herein allow for push provisioning of virtual payment cards directly to a digital wallet application of an individual using the mobile application executing on the individual’s mobile device.

In certain examples, a payment platform includes at least one processor and a data storage system having instructions therein that, when accessed by the at least one processor, cause payment platform to perform a method for provisioning virtual payment cards to a digital wallet application of an individual. In an example, from an organization, a request to create a virtual payment card for the individual is received by the payment platform. In response to the request, the payment platform generates a virtual card number (VCN) and forwards the VCN to a mobile application executing on a mobile device associated with the individual. After providing the VCN to the mobile application, the payment platform receives an acknowledgment from the mobile application, the acknowledgement indicating receipt of the VCN, and responsive thereto, the payment platform forwards the VCN to the organization.

In another aspect, a non-transitory machine readable medium comprising computer-executable instructions for a mobile application is provided. The computer-executable instructions causing a mobile device to perform a method. In the method, from a payment platform, a VCN is issued to a user of the mobile device and is received by the mobile application associated with the user. The organization is responsible for funding purchases made with the virtual payment card. A user interaction is received via a user interface from the user resulting in a registration of the user with a card management application server. Digitization data for the virtual payment card is received by the mobile application. The digitization data includes VCN provided in a format that the mobile application can use to add the VCN to the virtual wallet. Responsive to the receiving of the VCN, the user interaction resulting in the registration, and the digitization data, the digitization data is pushed to a digital wallet application deployed on the mobile device, thereby allowing the user to make purchase at near field communications (NFC) payment terminals using the virtual payment card.

In yet another aspect of the technology described herein, a method for provisioning a virtual payment card to a digital wallet application deployed on a mobile device using a mobile application executing on the mobile device associated with an individual is described. In the method, at a payment platform and from a server associated with an organization, a request to create a virtual payment card for the individual is received. In response to the request and by the payment platform, a virtual payment card for the individual is generated. The virtual payment card has a virtual card number (VCN). The payment platform forwards the VCN to the mobile application. At the payment platform and from the mobile application, an acknowledgment is received indicating receipt of the VCN. Responsive to the receiving of the acknowledgement, details associated with the virtual payment card, including the VCN, are forwarded to the organization.

BRIEF DESCRIPTION OF THE DRAWINGS

The present description will be better understood from the following detailed description read considering the accompanying drawings, wherein:

FIG. l is a block diagram illustrating an example environment including entities for push provisioning of virtual payment cards to a digital wallet for mobile payment;

FIGs. 2, 3, 4, and 5 illustrate by way of example, user interfaces generated by mobile device when provisioning virtual payment cards to a digital wallet for mobile payment;

FIG. 6 shows flowchart illustrating by way of example a method for push provisioning virtual payment cards to a digital wallet for mobile payment;

FIG. 7 shows time space diagram illustrating by way of example communications effectively authorizing (or “enabling”) an organization server with an issuer;

FIG. 8 shows time-space diagram illustrating by way of example a communication pattern for push provisioning virtual payment cards to a digital wallet for mobile payment;

FIG. 9 shows a time-space diagram illustrating by way of example a communication flow between different entities for push provisioning virtual payment cards to a digital wallet for mobile payment; and

FIG. 10 shows an exemplary computing apparatus according to an embodiment as a functional block diagram.

Corresponding reference characters indicate corresponding parts throughout the drawings. DETAILED DESCRIPTION

A virtual payment card, as the term is used herein, is a software construct that includes features of physical payment cards, including a tokenized version of a payment account number, the cardholder’s name, billing address, expiration date, and verification code (referred to as a “CVV” or “CVC”). As described herein, “VCN” refers to data pertaining to a virtual payment card comprising a unique, temporary, (typically 16-digit) payment account number (PAN) number generated by a supplier payment platform like MASTERCARD IN CONTROL® for Commercial Payments™ from a real card number of a funding account. As used herein, the terms, “VCN,” “mobile virtual payment card number (or “mVCN”),” “virtual payment card number” and “virtual card number” are interchangeable and refer to the unique account number associated with payment cards, that is associated with a virtual payment card. It is used for transactions, ensuring that the real card number remains protected.

A payment platform, such as a supplier payment platform, is described herein that provides additional convenience to an organization’s employees, contractors, suppliers, etc. as well as to users unaffiliated with the organization (collectively, “individuals”). In addition to the added convenience, the presently- described supplier payment platform both reduces friction and enables tighter controls on an organization’s spending. The reduced friction includes reduced transaction costs, reduced reliance externalities such as a postal service to deliver physical payment cards, and issuer bank’s provision of expense management services or interoperability. In some examples, the supplier payment platform hence reduces time and inconvenience associated with an organization’s management, while providing tighter spending controls, of spending by suppliers. The supplier payment platform furthermore improves overall process security by enabling organizations to easily issue virtual payment cards for limited purposes. Any number of virtual payment cards can be tied to a single funding primary account number, and therefore a single bank account within which purchases are credited.

Overall, due to the simplified nature of the deployment being direct from a supplier payment platform integrated within a payment network, there are reduced compute resources, network resources, and compute resources required for virtual card deployment. The solution pushes virtual payment cards directly to an individual’s mobile device for improved user efficiency. The individual can receive multiple different virtual payment cards, from one or more organizations, each with individual use-restrictions, including for particular purposes, for a particular time period, for use with a particular vendor, wherein these use-restrictions are defined by the organization. The individual is not required to remember to carry a physical payment card, reducing the likelihood that payments made by an individual will need to be later reimbursed by the organization, which can be quite costly and error prone.

Another important technical advantage presented by the presently described supplier payment platform is that, because of the tokenized virtual payment cards, a single mobile application residing on users’ devices can receive virtual payment cards from multiple different banks or issuers, without loss of issuer branding respective to each virtual payment card. In cases where issuers provision their own mobile app, they can still interface with application programming interfaces (APIs) provided by the present supplier payment platform thereby ensuring consistent security across virtual payment cards regardless of the issuer bank while each issuer bank obtaining the benefits thereof on the back end, and without duplication of processes across multiple data centers controlled by multiple different issuers.

For example, the individual can receive virtual payment cards that may be issued by a plurality of issuers from one or more organizations in a single mobile application executing on the mobile device. In this way, the same mobile application works for all organizations (e.g., the solution is bank-agnostic and organizationagnostic) and the individuals do not need to have their own payment cards or bank accounts for making payment using the digital wallet. This improves user convenience and reduces clutter on the mobile device’s interface (e.g., from having multiple apps from multiple issuers). An individual can view their transaction history without having to create a log-in via a browser to access the issuer bank’s account portal. Further, a tokenized virtual payment card, created using the aspects of the disclosure, is added to a digital wallet thereby allowing for purchases using the digital wallet, e.g., using near-field communications (NFC) payment terminals. The mobile application (e.g., a mobile application executing on a individual’s mobile device) is thus operable to manage virtual payment cards requested for the user by a plurality of different organizations using a variety of different issuer banks. This improves the functioning of the underlying device by storing virtual payment cards from a plurality of companies, eliminating the need for multiple different applications to execute on the device of an individual (e.g., a gig worker working for multiple companies or clients). This uses less memory, processing, and bandwidth resources of the underlying device. Further, for example, individuals no longer have to worry about keeping the right physical card on their person when making purchases for a particular employer-organization.

In some examples, an issuer bank enables an organization to access the supplier payment platform’s APIs by first assigning a real card number for a funding account to the organization. The issuer informs the supplier payment platform of the funding account information which enables the organization to then request VCNs tied to that funding account. The organization is thereby enabled for allocating virtual payment cards to an individual. The terms ‘individual’ or ‘employee’ are used herein to encompass any authorized user associated with the organization and who is authorized to spend money on behalf of the organization using virtual payment cards.

To request a VCN for an individual, an administrator creates a purchase request to issue a mobile virtual payment card number (VCN) associated with the individual. Responsive to the request, the individual receives an invitation (e.g., via email) with an invitation code and is invited to download the mobile app on the individuals’ mobile device. Once the mobile app is downloaded, the individual creates a profile and enters the invitation code that was sent within the invitation. Upon successful entry of the invitation code, the individual is prompted to verify their phone and email address. Once confirmed, a short message service (SMS) or other text message, or other multi-factor or one-time password authentication mechanism, is sent to the individual or otherwise used to verify their identity. If successful, the individual completes the registration process and has access to the mobile app and associated virtual payment cards. Once in the mobile application, based on the mobile device, the individual has the option to click on an add to wallet option to automatically push provision the virtual payment card to the digital wallet. For subsequent virtual payment cards that are issued to the individual, if their profile is active, the individual can log into the app to access the virtual payment cards.

If a company does not want to utilize the mobile app, they may opt to send the virtual payment card directly to an individual using secure email. The individual can then manually provision the virtual payment card directly into the digital wallet.

In some examples, adding the virtual payment card comprises adding a tokenized virtual payment card to the digital wallet that checks eligibility of the virtual payment card with a tokenization system. The tokenization system may request a real card number (RCN) associated with the VCN from a token management system. Upon receiving the RCN from the token management system, the tokenization system sends the VCN and the RCN to the token management system for validation. Upon receiving validation of the VCN and the RCN from the token management system, the tokenization system sends a tokenized virtual payment card to the digital wallet and to the mobile application. In such examples, the tokenized virtual payment card (instead of the actual VCN) is added to the digital wallet for making payments via the digital wallet. Tokenization of the virtual payment card allows the mobile application to work with a plurality of issuers (e.g., banks).

An issuer server may receive an enablement request from administrators associated with a plurality of companies for the same mobile application that may be provided by an entity different from the issuer associated with the issuer server. In some examples, there are a plurality of issuers using the same mobile application. The plurality of issuer servers may enable the plurality of companies for the mobile application. Thus, there may be a single mobile application for the plurality of companies enabled by the plurality of issuer servers associated with the plurality of issuers.

In some examples, receiving the request to create the virtual payment card associated with the individual includes receiving a name, an email address, and a phone number of the individual from the administrator of the company. When the request is received by the issuer server, the issuer server provides the virtual payment card to the administrator or directly to the individual. Based on the selection within the purchase request, the administrator may choose to send the virtual payment card to the mobile app which will directly initiate an email from the card management application server, a component of the supplier payment platform, to the individual which contains the invitation code and instructions to download the mobile app.

A plurality of virtual payment cards may be assigned to the individual by the same company or by different companies. For example, an individual is associated with a plurality of companies (e.g., as a supplier or contractor). The plurality of virtual payment cards may be displayed to the individual in a mobile application. The user interface of the mobile application may enable the individual to visualize one or more of card details associated with each of the plurality of virtual payment cards, a list of transactions performed using each of the plurality of virtual payment cards, and an available balance associated with each of the plurality of virtual payment cards.

FIG. 1 is a block diagram illustrating an example environment 100 including entities for push provisioning of virtual payment cards to digital wallet 165 for mobile payment and for handling transactions therefor. The entities include payment network 110, issuer bank 140, acquirer bank 145, organization 150, mobile device 160, and individual 162. Payment network 110 includes systems and processes for handling the authorization, clearing, and settlement of credit and debit card transactions. When individual 162 (e.g., an organization’s employee, contractor, or supplier) uses a card for a purchase, e.g., to cover a travel expense, the payment network facilitates the transfer of funds from the organization’s primary funding account (PF A) to the merchant’s account. Thus, payment network 110 manages the transaction data between the merchant (not shown), issuer bank 140, and the merchant’s acquirer bank 145, also referred to as the acquirer.

Payment network 110 includes supplier payment platform 120, which includes application programming interface and/or user interface (API/UI) server 122 and a card management application server 124, which are discussed in more detail below. In addition, the supplier payment platform 120 includes virtual spend control and alerts (VSCA) token manager (VTM) 126 of supplier payment platform 120.

Card management application server 124 communicates with a plurality of issuers 140 that manage or control a plurality of issuer servers (not shown). Issuer servers are responsible for approving transactions made by VCNs that are tied to a primary funding account maintained by issuer 140 further explained below with reference to FIG. 9. In some examples, card management application server 124 communicates with the administrators 158 of organization system 156 for ordering or purchasing (hereinafter, “requesting”) VCNs for individuals 162 associated with their organization.

The card management application server 124 communicates with a mobile application 164 on a mobile device 160, which belongs to an individual 162, which is associated with organization 150. Card management application server 124 receives and confirms registration information and upon confirmation, provisions mobile application 164 with virtual payment card information, enabling individual 162 to make purchases as further described below. VTM 126 issues virtual payment card numbers (VCNs) which mimic the functionality of a physical payment card but are used for specific, controlled transactions to enhance security by limiting the exposure of actual card numbers and by providing better control over payment processes. Businesses set parameters around token usage such as spending limits, transaction types, or specific vendors, thus ensuring that these tokens are used only as intended. In this way, VTM 126 helps businesses comply with industry standards and regulations related to payment security, such as the Payment Card Industry Data Security Standard (PCI DSS).

Digital enablement service 130 is shown in FIG. 1 as included within payment network 110, but could also be deployed by a separate entity. Digital enablement service 130 provides a tokenization service for issuers, wallet providers, merchants, and others, enabling digitization of virtual payment cards for mobile and online purchases.

Mobile application provider 135, also shown as a separate entity but which could be provided by another entity such as payment network 110, organization 150, Issuer 140, etc. provides a service for notifying users when a virtual payment card is issued to them as described in more detail below with reference to FIG. 7.

Issuer bank 140 is the bank that issues credit or debit accounts to organization 150, and maintains the primary funding account (PF A), from which funds are transferred to cover payments made by employees, suppliers, contractors, etc. (individuals 162) for organization 150. Acquirer bank 145 is associated with a merchant (not shown) where a virtual payment card may be used to make a purchase. The acquirer “acquires” the transaction from the merchant and then processes it through payment network 110 to ensure funds are transferred to the merchant’s account held with acquirer bank 145.

Organization 150 is any type of commercial, governmental, or economic entity that has a need to pay suppliers for its operation. For example, employees, contractors, suppliers, or other people (individuals 162) may need to make purchases on behalf of organization 150. For example, an individual 162 may be an employee that needs to book a flight for a business trip and pay for the airline ticket using a payment card or a contractor such as a plumber that needs to purchase parts or materials for a plumbing project. As such, individual 162 can use a VCN issued by issuer bank 140 to make purchases on behalf of organization 150, and payment network 110 and digital enablement service 130 will coordinate the processing of this transaction and the transfer of funds from the PFA held in issuer bank 140 by organization 150 to the airline’s account with acquirer 145. Organization 150 further includes administrator(s) 158 of organization system 156. Administrators 158 interact with organization system 156 for requesting virtual payment cards as herein described.

In some examples, organization system 156 comprises a physical or virtual desktop or laptop computer, or mobile device, operable by administrator 158 to access a web (or other) user interface of API/UI server 122. Alternatively, organization system 156 comprises a server system hosting an application accessible by administrator 158, the application interfacing with an API of API/UI server 122 to request VCNs or perform other administrative tasks in relation to supplier payment platform 120. Such a server may be a virtualized on-premises or cloud-based server as previously described. In one example, administrator 158 manages an accounting program which includes functionalities to programmatically request VCNs for a plurality of individuals 162, e.g., based on approved travel requests from an expense management platform or other configured purpose. In this case, the accounting program will automatically interface with API of API/UI server 122 to provision the requested VCN. In another example, a webserver providing a user interface communicates on the back end with an API server, which is also accessible via networks 105 via a secure connection. For the sake of clarity, API/UI server 122 is described herein as an abstraction that encompasses all these possible implementation details.

Individual 162 (e.g., employee, contractor, suppliers or other people associated with organization 150) owns, controls, or maintains a mobile device 160 having a mobile application 164 and digital wallet application 165 thereon. Mobile application 164 may be provided by payment network 110, issuer 140, or another party such as a financial institution.

Each of the entities in environment 100 including payment network 110, mobile application provider 135, issuer bank 140, acquirer bank 145, and organization 150 are able to communicate via network 105, which may comprise a plurality of networks including the internet, other private or public WAN networks, local area networks, wireless networks, etc.

Each of the servers and computing systems including authorization server 112, API/UI 122, card management application server 124, VTM 126, servers (not separately shown) of digital enablement service 130, mobile application provider 135, issuer 140, and acquirer 145, in various implementations, comprise one or more servers residing within a private datacenter maintained by the entity, or a public datacenter (e.g., a public cloud datacenter). Each server, which can also be considered a separate service, may be implemented using software executing on a physical computing platform such as a computing platform based on the x86 family of instruction set architectures. Other architectures such as reduced instruction set (RISC) based (e.g., ARM) architectures can also be used. Alternatively, the software of any server system executes on a virtualized infrastructure such as virtual machines or containerized computer architecture. In certain examples, the software and/or hardware is deployed behind a firewall and/or load balancer, and/or other network infrastructure components such as routers, switches, and middleboxes (not shown). As such, in exemplary implementations, one or more of the servers are scalable services for handling growing or shrinking loads by replicating or removing instances of the servers. In some instances, services provided by multiple ones of the servers shown can be aggregated onto a fewer number of physical or virtualized servers. In other instances, any services provided by any of the servers can be divided and refactored across a microservices architecture. As such, it should be understood that the form of physical deployment of the various services are depicted herein for illustrative purposes only and should not be considered limiting.

Digital wallet application 165 is an application typically included in smart phones, such as ones manufactured by Apple Inc., or ones that employ the Android operating system developed primarily by Google LLC. Digital wallet application 165 is capable of storing tokenized VCNs and interacting with point-of- sale terminals using near-field communication (NFC) interfaces. Additional information, in various implementations, include dynamic data elements such as onetime passwords, dynamic verification codes, device-specific information that binds the virtual payment card to a particular mobile device, a unique identifier of the device for security and authentication purposes, ensuring that the card can only be used on the authorized device, issue information, and transaction limits and controls.

FIGs. 2-5 illustrate by way of example, user interfaces generated by mobile device 160 when provisioning virtual payment cards to a digital wallet for mobile payment. Referring to FIG. 2, individual 162 receives an authorization code in a link in the invitation (e.g., an invitation email) and registers via the user interface (UI) 200 for the mobile application 164. By way of example, an invitation email includes a link to download mobile application 164 which, upon opening, displays a sign-in user interface 200 shown in FIG. 2.

User interface 200 includes a payment network logo 210, text box controls 220 for entering the user identifier (e.g., their email address) and password, an option 230 to enable biometric authentication, sign-in and/or sign-up button controls 240, and additional controls 250.

Individual 162 may sign up (if accessing the mobile application 164 for the first time) or sign in (if already registered in the mobile application 164) via user interface 200. Upon successful entry of the invitation code, individual 162 is prompted to verify their phone and email address. For example, card management application server 124 (see FIG. 1) receives a registration of individual 162 from mobile application 164 and confirms the user identity and password and/or other information related to the individual’s account against information previously provided as described in more detail below. Once confirmed, card management application server 124 sends a short message service (SMS) or other text message to individual 162 to verify their identity via their phone number. If successful, individual 162 completes the registration process and thereafter has access to services provided by or made accessible by mobile application 164, including associated virtual payment cards as further described with reference to FIG. 3.

Upon login into mobile application 164, user interface 300 illustrated by way of example in FIG. 3 is displayed. User interface 300 includes payment network logo 310, an available balance box 320, and a graphical depiction 330 of the virtual payment card. Selection of available balance box 320 may bring up a transaction history listing recent transactions made with the VCN. Depiction 330 is an illustration of an imaginary physical payment card that corresponds to the VCN, including the organization’s logo, the last four digits of the payment account number and, in the bottom right corner, the payment network logo. Other graphical designs (not shown) such as color scheme or representational graphics of branding of organization 150 and/or issuer 140 may also be included in depiction 330. If multiple payment cards are provisioned by supplier payment platform 120 to individual 162, then additional virtual payment cards would be depicted (only one shown) or button controls such as arrows for switching between selected payment cards would be visible.

Upon selection of a virtual payment card in user interface 300, a user interface 400 shown by way of example in FIG. 4 is displayed. User interface 400 includes a button control 410 for returning to user interface 300, a graphical representation or depiction 420 of the virtual payment card, button controls 430 for viewing card details or use constraints on the card, a button control 440 for adding the virtual payment card to the user’s digital wallet, a textbox control 450 providing a description of the virtual payment card, and individual’s 162 name 460. Upon selecting one button control 430, the card will display the full payment account number (PAN), expiration date, and security code associated with the card. With this information and the user’s knowledge of their zip code, the virtual payment card can be used to purchase goods or services such as an airline ticket, via an online airline or booking portal. A second button control 430 will display use limits imposed by organization 150, issuer 140, and/or payment network 110. Use limits may restrict the use of the virtual payment card to a period of time, geographical area, one or more vendors, a total or per-purchase spending limit, spending limits per category, e.g., dining limits per day or per meal, etc.

Upon activation of button control 440, the virtual payment card may be added to the user’s phone’s digital wallet using APIs, system calls, or other mechanisms provided by the digital wallet’s developer. When the user opens the digital wallet application, a user interface 500 illustrated by way of example in FIG. 5, showing the graphical depiction 420. The user can then use the virtual payment card in NFC payment transactions as described above.

Returning to FIG. 4, textbox control 450 includes a written description of the card that is, in certain examples, defined by administrator 158 when ordering the virtual payment cards for individual 162. For example, if the individual 162 is to attend a conference in a different city, administrator 158 may include a description of the intended use for the virtual payment card such as “to pay for expenses related to our annual conference.” The administrator may put limits on the use of the payment card to include booking expenses, dining expenses, etc., only for days leading up to and including the event, and the description in textbox control 450 will provide an overview of the purpose of the virtual payment card. FIG. 6 shows flowchart 600 illustrating by way of example a method for push provisioning virtual payment cards to a digital wallet for mobile payment. This flow chart will be described with reference to entities described above with reference to FIG. 1. The procedure begins at “begin” block 602 and proceeds to operation 604 wherein a company receives authorization (or “enablement”) for requesting VCNs for individuals 162. Organization 150 interacts with servers managed or controlled by issuer 140 to designate a primary funding account (PFA) to be tied with requested VCNs. Issuer, then communicates with supplier payment platform 120 enable organization 150 to request VCNs to be funded through the PFA. This ensures that a primary funding account is available for association with provisioned VCNs.

Once enabled, at operation 606, a purchase request is received by API/UI 122 of supplier payment platform 120 from an administrator 158. The request asks supplier payment platform 120 to create a virtual payment card for individual 162. As explained in further detail below, the request includes any use-restrictions, such as vendor restrictions, daily limits, time-of-use restrictions, total limits, etc., to be imposed by organization 150 on the VCN. In some examples, rather than create a virtual payment card that is pre-assigned to a particular individual, a generalized virtual payment card (that is not associated with any particular individual to use) is created and information pertaining thereto is provided to administrator 158. Administrator 158 can therefore request a number of generalized virtual payment cards in advance, and then then assign, at a later time, a particular generalized virtual card number (VCN) to individual 162.

At operation 608, individual 162 is invited to install mobile application 164 on mobile device 160. Such an invitation may be sent by mobile application provider 135, administrator 158 from organization system 156, or from card management application server 124. The invitation may include a link to install mobile application 164 on mobile device 160 belonging to individual 162. In addition, initial log-in credentials may be included so that individual 162 can initiate a registration procedure once they have completed installation of mobile application 164. At operation 610, registration of individual 162 may be received from mobile application 164. The registration is received by card management application server 124, e g., via API/UI 122. At operation 612, virtual payment card information including the 16- digit payment account number, expiration date, and security code (i.e., card verification code (CVC), card verification value (CVV) or card identification number (CID)) is provided to mobile application 164 and thus made accessible to individual 162 so that individual 162 may make purchases using the virtual payment card.

At operation 614, the virtual card information is automatically or manually added to digital wallet application 165 for making purchases. For example, individual 162 can have the convenience and ease of tap to pay using the digital wallet application 165 using the virtual payment card (i.e., VCN 167) at an NFC point-of-sale terminal. The method presented then ends as indicated by done block 616.

In some examples, the individual 162 may be provided with an option to delete the VCN from the digital wallet. In some other examples, the administrator may revoke the VCN associated with the individual and the VCN is deleted from the digital wallet, in this scenario.

FIGs. 7-9 show time space diagrams illustrating by way of example communications between different entities for push provisioning virtual payment cards to a digital wallet for mobile payment. These communications are communicated via a secure channel and/or are secured by encryption technologies such as public key encryption and are communicated in any suitable API protocol such as the REST API protocol.

FIG. 7 shows time-space diagram 700 illustrating by way of example a communication pattern for creating and push-provisioning VCNs to a digital wallet for mobile payment. In particular, time-space diagram 700 illustrates communication involving a supplier payment platform 120. Initially, organization system 156 sends message 702 comprising a request for a virtual payment card to the API/UI 122 of supplier payment platform 120. Message 702 can be an API call from an application running on system 156 or a hypertext transfer protocol (HTTP) transaction generated in response to an administrator interacting with a web page generated by API/UI 122. Message 702, in some use cases, includes identity information pertaining to individual 162 such that a generated virtual payment card created in response to the request will be associated with and automatically pushed to individual 162. The identity information may include an email address, name, and/or other identifying information. Request message 702 may also include use-restriction data that restricts the use of the VCN(s) being requested.

In response, API/UI 122 forwards message 704 to card management application server 124 comprising a request to allocate a VCN. Responsive thereto, card management application server 124 generates a new VCN in operation 706 and sends message 708 comprising the generated VCN back to API/UI 122. In this context, VCNs refers to the numbers associated with the provisioned virtual payment card including the virtual account number, expiration date, and security code and/or any other information that defines the virtual payment card.

Upon receiving the generated VCN, API/UI 122 sends message 710 to VTM 126 comprising a POST end user message. The POST message submits end user data, e.g., data related to individual 162, such as an email address, name, etc. Responsive thereto, VTM 126 sends message 712 comprising an acceptance of the POST message.

Upon receipt of that acceptance, API/UI 122 transmits message 714 comprising a POST end user, User ID, and VCNs to VTM 126. Message 714 may also include use-restriction data previously mentioned.

Responsive thereto, VTM 126 sends a message 716 comprising a POST user message to mobile app provider 135 and responsive thereto mobile app provider 135 responds with message 718 comprising acceptance of the POST message. Upon receipt of that acceptance, VTM 126 sends message 720 comprising a POST of user details and the VCN(s) to mobile application provider 135, which then responds with acceptance in message 722.

Upon receipt of message 722, VTM forwards in message 724 the approval to the API/UI 122 of supplier payment platform 120, which then sends message 726 comprising virtual payment card details with organization system 156.

Mobile app provider 135, also in response to recept of message 720, notifies individual 162 of the provision of a new VCN. The notification may be in the form of an email, text message, etc.

In summary, FIG. 7 shows a novel process of receiving a request from an organization, generating a VCN in response to the request, and pushing the VCN to a mobile app of an individual associated with the organization, as well as details of the VCN to the organization. It should be noted that organization 150 needs to be enabled prior to submitting the request as previously described. FIG. 8 shows a time-space diagram 800 illustrating by way of example a communication flow between different entities for enabling tokenization for the VCN provisioned to mobile application 164 in FIG. 7. Upon receipt of a notification of a new VCN and invitation to download mobile application 164, as previously described, individual 162 receives the notification and responds by installing (if necessary) and opening mobile application 164 and registering or signing into the application as indicated by communication 814. Thus, communication 814 includes an interaction by user with a user interface of mobile application on device 160, e.g., as previously described with reference to FIGs. 2-4. Once individual 162 arrives at user interface 400 shown in FIG. 4, they add the VCN 167 to digital wallet 165 by tapping control 440 shown in FIG. 4. Message 814 therefore combines the login and add-to-wallet operations by individual 162.

In response to the add-to-wallet interaction by individual 162 included in message 814, mobile application 164 sends message 816 comprising a request for digitization of the virtual payment card information to VTM 126. Digitization generates virtual payment card information in an encrypted format consumable by mobile application 164 so that the mobile application can then provide the digitized VCN to digital wallet 165. Message 816 requests VTM 126 to obtain issuer-initiated digitization data associated with the virtual payment card and responds with the issuer-initiated digitization data in message 818. The digitization is referred to as “issuer-initiated” because VTM 126 is acting as an issuer of the VCN or on the issuer’s behalf. The Mobile application 164 pushes the digitization data for the virtual payment card to the digital wallet via message 820, which may be a procedure call or API call within mobile device 160. Digital wallet application 165 sends message 822 to digital enablement service 130 to request confirmation of the eligibility of the virtual payment card information.

Digital enablement service 130 is preconfigured with a range of VCN numbers for which it is eligible for providing tokenization services. Digital enablement service 130, in operation 824, recognizes the payment account number of the virtual payment card being within the particular range configured for VTM 126 and, in response to confirming the VCN is within its preconfigured range, sends message 826 to VTM 126 to obtain a mapping of the real card number (RCN) to the virtual payment card. RCN is the account number for the primary funding account, and it, or its tokenized version, is also referred to as the funding primary account number (FPAN).

In response to the mapping request in message 826, VTM 126 sends message 828 comprising mapping information including the RCN information to the digital enablement service 130. Upon receipt of the mapping information in message 828, digital enablement service 130 sends message 830 comprising the terms and conditions (T&C) of use of the virtual payment card to digital wallet application 165, which presents the same in message 832 presented to individual 162, e.g., via a user interface generated by digital wallet application 165. Individual 162, by interacting with the user interface, indicates acceptance of the terms and conditions via message 834. Responsive thereto, digital wallet application 165 sends message 836 comprising the acceptance to digital enablement service 130.

Upon receipt of acceptance by individual 162 of acceptance of the terms and conditions, digital enablement service 130 sends message 838 comprising a request to authorize the service. The request includes the virtual card number and the RCN. Responsive thereto, VTM 126, in operation 840, validates the issuer-initiated digitization data. Operation 840 can include multiple steps based on recommendation from digital wallet 165. The digital wallet can provide a “green” flag which indicates the digitization data is approved; a “yellow” flag indicating additional verification is needed such as a confirmation of a one-time password or other second-factor authentication technique to verify the authenticity user’s interactions; an “orange” flag indicating mobile device 160 might be stolen, a “red” flag instructing VTM 126 to deny validation.

If validation is approved, VTM 126 sends message 842 comprising an approval indicating authorization for the VCN to digital enablement service 130. Responsive to receiving validation from VTM 126, digital enablement service 130 sends a first message 844 to digital wallet application 165 and a second message 846 to VTM 126. Message 844 includes a token for the VCN and notifies the digital wallet application 165 of the updated token that is assigned to the individual. The update includes a status change indicating that the VCN is “active” and therefore ready to use. Message 846 comprises a token event, including the token for VCN, causing VTM to send message 848 to mobile application 164 comprising a POST message including the user details including the name and identifier for individual 162, virtual payment card details including payment numbers and token to mobile application 164. Responsive thereto, mobile application 164 responds with message 850 comprising an acknowledgement. Separately, digital wallet application 165 sends message 852 to individual 162 (e.g., via a device notification) displayed the tokenized card to the individual in the digital wallet (e.g., as shown in FIG. 5).

FIG. 9 shows time space diagram 900 illustrating by way of example communications for processing a transaction authorization request using VCN 167. With this approach, a transaction is securely processed using tokenized representations of VCN, and use-restrictions imposed by organization 150 are enforced. Initially, merchant acquirer 145 sends message 902 to authorization server 112. Message 902 comprises a transaction authentication request including tokenized VCN (provided by digital wallet 165 in the course of the transaction) for payment authorization that may be performed on authorization server 112. Authorization server 112 recognizes in message 902 that it has received a token and forwards the token in message 904 to digital enablement service 130. Digital enablement service 130 maps the received token to the corresponding RCN. Digital enablement service 130 returns, in message 906, the token and the RCN (or a tokenized version of it) to authorization server 112. As previously described, the RCN is the account number corresponding to the primary funding account held by organization 150 and is linked to virtual payment cards requested by organization 150, and from which charges resulting from purchases of those virtual payment cards will be paid.

Upon receipt of the RCN in message 906, authorization server 112 sends message 908 including the RCN and the token to VTM 126. VTM 126, in operation 910, identifies the mapped VCN from the token and checks use-restrictions on the particular VCN imposed by organization 150, as previously described. The use-restrictions are communicated to VTM 126 in message 710 or 714 described above with reference to FIG. 7. Such use-restrictions can include a number of transactions, an identified payee or type of payee (e.g., restaurant, travel, etc.), a daily or total spending limit, etc. If the current transaction is not in violation of the userestrictions, then VTM 126 returns message 912, which includes the three-way mapping including RCN, token, and VCN. Authorization server 112 then sends message 914 comprising the three-way mapping including RCN, token, and VCN to issuer 140 for approval. Issuer 140 has a separate set of use-restrictions imposed on use of the primary funding account, such as a credit limit. Provided these userestrictions are not exceeded, issuer 140 responds with message 916 comprising an approval of the transaction. Authorization server 112 then forwards an approval message 918 to merchant acquirer 145 by which the merchant can then complete the sale.

In summary, FIG. 9 shows a transaction authorization process by which a tokenized VCN provided by digital wallet 165 in the course of a transaction with a merchant, is translated to an RCN, mapped to a VCN, use-restrictions thereon enforced by VTM 126, and then proceeds with an approval process with issuer 140.

Aspects of the disclosure are operable in various modes with issuers. In a partner mode, a partner provides their app with push provisioning leveraging application programming interface (API) technology of the mobile application, as described herein, that has tokenized VCN in the digital wallet. In manual provisioning, program administrators can utilize the supplier payment platform as described herein to create a request. Individuals can manually add the virtual payment card into their digital wallet. In an issuer-led approach, issuers may utilize their own app and connect to the API technology of the mobile application as described herein. In a supplier payment mobile application, the mobile application as described herein includes push provisioning virtual payment cards to the digital wallet. Because of the tokenized virtual payment cards, a single mobile application of the disclosure receives virtual payment cards from multiple banks or issuers. Some sections of the mobile application may include issuer branding.

Aspects of the disclosure are operable with any set of API commands to manage and control virtual payment cards. Example API commands made available by API/UI server 122 include:

GET: /users/{user_guid}/virtual-card-accounts - this API retrieves a list of virtual payment cards linked to a user.

POST: /users/{user_guid}/virtual-card-accounts - this API registers a virtual payment card linked to a user.

GET: /users/{user_guid}/virtual-card-accounts/{account_guid} - this API retrieves virtual payment card account details linked to a user.

PUT: /users/{user_guid}/virtual-card-accounts/{account_guid} - this API updates virtual payment card account details linked to a user.

DELETE: /users/ {user_guid}/virtual-card-accounts/{account_guid} - this API deletes a virtual payment card account linked to a user.

Exemplary APIs to manage tokens for cards include: POST: /users/{user_guid}/virtual-card- accounts/{account_guid}/tokens - this API registers a token linked to a user and a virtual payment card.

GET: /users/ {user_guid}/virtual-card- accounts/{account_guid}/tokens/{token_guid} - this API retrieves token details linked to a user and a virtual payment card.

PUT: /users/ {user_guid}/virtual-card- accounts/{account_guid}/tokens/{token_guid} - this API updates a token linked to a user and a virtual payment card.

DELETE:/users/{user_guid}/virtual-card- accounts/{account_guid}/tokens

/{token guid} - this API deletes a token linked to a user and a virtual payment card.

Additional Examples

In some examples, the individual is an employee of the organization. In other examples, the individual is not an employee of the organization, but may be a vendor, supplier, interviewee, etc. Some implementations of the disclosure operate as a replacement for checks. In some examples, any user (e.g., plumber, electrician, interviewee) can have a VCN delivered to their mobile. Other example use cases include: the user viewing a card balance on their mobile device, the user viewing authorized/cleared transaction details of the card on their mobile device, the user viewing control details (e.g., the card is usable only in a particular country) of the card on their mobile, and/or the user viewing the billing address of the card on their mobile device. Some of the use cases are functional even though the user does not have an account with any bank.

In some examples, a contractor can view the balance and transactions as the contractor spends. For example, a plumber is given a virtual card with $5000 USD value. The contractor spends $2000 USD on materials. With the mobile application as described herein, the contractor can view the virtual card balance as being $3000 USD and can see the transaction details indicating that he spent $2000 USD.

The present disclosure is operable with a computing apparatus according to an embodiment as a functional block diagram 1000 in FIG. 10. In an example, components of a computing apparatus 1018 are implemented as a part of an electronic device according to one or more embodiments described in this specification. The computing apparatus 1018 comprises one or more processors 1019 which may be microprocessors, controllers, or any other suitable type of processors for processing computer executable instructions to control the operation of the electronic device. Alternatively, or in addition, the processor 1019 is any technology capable of executing logic or instructions, such as a hard-coded machine. In some examples, platform software comprising an operating system 1020 or any other suitable platform software is provided on the apparatus 1018 to enable application software 1021 to be executed on the device. In some examples, performing push provisioning of virtual payment cards to a digital wallet for mobile payment as described herein is accomplished by software, hardware, and/or firmware.

In some examples, computer executable instructions are provided using any computer-readable media that is accessible by the computing apparatus 1018. Computer-readable media include, for example, computer storage media such as memory 1022 and communications media. Computer storage media, also referred to as non-transitory machine readable medium, such as a memory 1022, include volatile and non-volatile, removable, and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or the like. Computer storage media include, but are not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), persistent memory, phase change memory, flash memory or other memory technology, Compact Disk Read-Only Memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, shingled disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing apparatus. In contrast, communication media may embody computer readable instructions, data structures, program modules, or the like in a modulated data signal, such as a carrier wave, or other transport mechanism. As defined herein, computer storage media does not include communication media. Therefore, a computer storage medium is not a propagating signal. Propagated signals per se are not examples of computer storage media. Although the computer storage medium (the memory 1022) is shown within the computing apparatus 1018, it will be appreciated by a person skilled in the art, that, in some examples, the storage is distributed or located remotely and accessed via a network or other communication link (e.g., using a communication interface 1023).

Further, in some examples, the computing apparatus 1018 comprises an input/output controller 1024 configured to output information to one or more output devices 1025, for example a display or a speaker, which are separate from or integral to the electronic device. Additionally, or alternatively, the input/output controller 1024 is configured to receive and process an input from one or more input devices 1026, for example, a keyboard, a microphone, or a touchpad. In one example, the output device 1025 also acts as the input device. An example of such a device is a touch sensitive display. The input/output controller 1024 may also output data to devices other than the output device, e.g., a locally connected printing device. In some examples, a user provides input to the input device(s) 1026 and/or receives output from the output device(s) 1025.

The functionality described herein can be performed, at least in part, by one or more hardware logic components. According to an embodiment, the computing apparatus 1018 is configured by the program code when executed by the processor 1019 to execute the embodiments of the operations and functionality described. Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), Sy stem - on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), Graphics Processing Units (GPUs).

At least a portion of the functionality of the various elements in the figures may be performed by other elements in the figures, or an entity (e.g., processor, web service, server, application program, computing device, or the like) not shown in the figures.

Although described in connection with an exemplary computing system environment, examples of the disclosure are capable of implementation with numerous other general purpose or special purpose computing system environments, configurations, or devices. Examples of well-known computing systems, environments, and/or configurations that are suitable for use with aspects of the disclosure include, but are not limited to, mobile or portable computing devices (e.g., smartphones), personal computers, server computers, hand-held (e.g., tablet) or laptop devices, multiprocessor systems, gaming consoles or controllers, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, mobile computing and/or communication devices in wearable or accessory form factors (e.g., watches, glasses, headsets, or earphones), network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. In general, the disclosure is operable with any device with processing capability such that it can execute instructions such as those described herein. Such systems or devices accept input from the user in any way, including from input devices such as a keyboard or pointing device, via gesture input, proximity input (such as by hovering), and/or via voice input.

Examples of the disclosure may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices in software, firmware, hardware, or a combination thereof. The computer-executable instructions may be organized into one or more computerexecutable components or modules. Generally, program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. Aspects of the disclosure may be implemented with any number and organization of such components or modules. For example, aspects of the disclosure are not limited to the specific computer-executable instructions, or the specific components or modules illustrated in the figures and described herein. Other examples of the disclosure include different computer-executable instructions or components having more or less functionality than illustrated and described herein.

In examples involving a general -purpose computer, aspects of the disclosure transform the general-purpose computer into a special-purpose computing device when configured to execute the instructions described herein.

Examples have been described with reference to data monitored and/or collected from the users (e.g., user identity data with respect to profiles). In some examples, notice is provided to the users of the collection of the data (e.g., via a dialog box or preference setting) and users are given the opportunity to give or deny consent for the monitoring and/or collection. The consent takes the form of opt-in consent or opt-out consent.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages. It will further be understood that reference to ‘an’ item refers to one or more of those items.

The embodiments illustrated and described herein as well as embodiments not specifically described herein but within the scope of aspects of the claims constitute an exemplary means for detecting fraud transactions in peer-to-peer payments without an intermediary.

The term “comprising” is used in this specification to mean including the feature(s) or act(s) followed thereafter, without excluding the presence of one or more additional features or acts.

In some examples, the operations illustrated in the figures are implemented as software instructions encoded on a computer readable medium, in hardware programmed or designed to perform the operations, or both. For example, aspects of the disclosure are implemented as a system on a chip or other circuitry including a plurality of interconnected, electrically conductive elements.

The order of execution or performance of the operations in examples of the disclosure illustrated and described herein is not essential, unless otherwise specified. That is, the operations may be performed in any order, unless otherwise specified, and examples of the disclosure may include additional or fewer operations than those disclosed herein. For example, it is contemplated that executing or performing a particular operation before, contemporaneously with, or after another operation is within the scope of aspects of the disclosure.

When introducing elements of aspects of the disclosure or the examples thereof, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements. The term “exemplary” is intended to mean “an example of.” The phrase “one or more of the following: A, B, and C” means “at least one of A and/or at least one of B and/or at least one of C.” Having described aspects of the disclosure in detail, it will be apparent that modifications and variations are possible without departing from the scope of aspects of the disclosure as defined in the appended claims. As various changes could be made in the above constructions, products, and methods without departing from the scope of aspects of the disclosure, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.

Claims

1. A computerized method for provisioning and using a virtual card number (VCN) (167), the method comprising: receiving, at a supplier payment platform (120) from a system (156) associated with an organization (150) with whom an individual (162) is associated, a request (702) to provision the VCN (167) for a mobile application (164) deployed on a mobile device (160) associated with the individual (162), the request (702) including userestrictions on the VCN (167); in response to the request (702), generating (706), by the supplier payment platform (120), the VCN (167) for the individual (162) and forwarding (714, 720) the VCN (167) to a mobile application provider (135); receiving, at the supplier payment platform (120) from the mobile application provider (135), an acknowledgment (724) indicating receipt of the VCN; responsive to the receiving of the acknowledgement (724), forwarding (726) the VCN (167) to the organization (150); receiving, at a virtual spend control and alerts token manager (VTM) (126) from an authorization server 112, a real card number (RCN) and token associated with a transaction authorization request; applying the use-restrictions associated with the VCN (167) to determine that a transaction corresponding to the transaction authorization request is permitted according to the use-restrictions; upon the determining that the transaction is permitted, providing (912) a three- way mapping including the RCN, the VCN, and the token, to the authorization server (112) to further process the transaction authorization request.

2. The method of claim 1, in which: the supplier payment platform (120) comprises an application programming interface or user interface (API/UI) server (122) and a card management application server (124); and the request (702) is received at the API/UI server (122) which, responsive thereto, issues a request (704) to the card management application server (124) to perform the generating (706) of the VCN (167), the card management application server (124) performing the generating (706) in response to the request (704) to perform the generating (706).

3. The method of claim 1, in which the forwarding (714, 720) of the VCN to the mobile application (164) comprises forwarding (714) the VCN to the VTM (126), which forwards (720) the VCN to the mobile application (164).

4. The method of claim 1, further comprising: receiving, at the mobile application (164) a user interaction (814) via a user interface (200) from the individual (162) resulting in a registration of the individual (162) with a card management application server (124); receiving (818), at the mobile application (164), digitization data for the VCN (167), the digitization data comprising data used for making purchases at near-field communications (NFC) payment terminals; and responsive to the digitization data (818), pushing (820) the digitization data to a digital wallet application (165) deployed on the mobile device (160), thereby allowing the individual (162) to make the purchase the NFC payment terminal using the VCN (167).

5. The method of claim 4, in which the digitization data is received (818) from the VTM (126) in response to a request (816) for the digitization data sent from the mobile application (164).

6. The method of claim 4, in which the method further comprises displaying for the user (162) a depiction (420) of the VCN (167) including a description (450) of the VCN (167), the description being defined by an administrator (158) associated with the organization (150).

7. The method of claim 4, in which the method further comprises displaying for the individual (162) a depiction (420) of the VCN (167) and the userestrictions (430) on the use of the VCN (167), the use-restrictions (430) being defined by an administrator (158) associated with the organization (150).

8. The method of claim 4, in which the method further comprises displaying for the individual (162) a depiction of a plurality of VCNs in a user interface (300) of the mobile application (164), wherein the user interface (300) is configured to enable the individual (162) to visualize one or more of card details associated with each of the plurality of VCNs (167), a list of transactions performed using each of the plurality of VCNs (167) and an available balance associated with each of the plurality of VCNs (167).

9. The method of claim 4, further comprising: displaying for the individual (162) a depiction (420) of the VCN (167); and receiving a further user interaction (814) via the user interface (400, 440), responsive to the further user interaction, requesting (816) the digitization data from the VTM (126), the receiving (818) of the digitization data being responsive to the request (816) for the digitization data.

10. The method of claim 1, further comprising registering, by the organization (150), with an issuer (140), the registering identifying a primary funding account held by the organization (150) and the RCN that is tied to the primary funding account with the issuer (140) so that purchases made with the VCN (167) are processed using the RCN and the purchases are settled with funds transferred from the primary funding account.

11. The method of claim 1, further comprising: receiving, at the VTM (126), a second RCN and a second token associated with a second transaction authorization request; mapping the second RCN to a second VCN (167) associated with the second token; applying (910) second use-restrictions associated with the VCN (167) as defined by a second organization (150) to determine that a second transaction corresponding to the second transaction authorization request is permitted according to the second use-restrictions; upon determining that the second transaction is permitted, providing (912) a three-way mapping including the second RCN, the second VCN (167), and the second token, to the authorization server (112).

12. The method of claim 1, further comprising: receiving, at the supplier payment platform (120) from a second system (156) associated with a second organization (150), with whom a second individual (162) is associated, a second request (702) to create a second VCN (167) for the second individual (162); in response to the second request (702), generating (706), by the supplier payment platform (120), the second VCN (167) for the second individual (162), and forwarding (714, 720) the second VCN (167) to a second mobile application (164) executing on a second mobile device (160) associated with the second individual (162); receiving, at the supplier payment platform (120) from the second mobile application (164), a second acknowledgement (724, 722) indicating receipt of the second VCN (167); and responsive to the second acknowledgement, forwarding (726) the second VCN (167) to the second organization.

13. A supplier payment platform (120), comprising at least one processor (1019) and a data storage system (1022), the data storage system (1022) comprising instructions that, when accessed by the at least one processor (1019), cause supplier payment platform (120) to perform a method for provisioning virtual card numbers (VCNs) (167) to a digital wallet (165) of an individual (162), the method comprising: receiving, from an organization (150), a request (702) to create a VCN (167) for the individual (162) associated with the organization (150), the request (702) including use-restrictions on the VCN (167); in response to the request, generating (706) a VCN (167) and forwarding (714, 716) the VCN (167) to a mobile application provider (135); and receiving an acknowledgment (724, 722) from the mobile application provider (135), the acknowledgement (724, 722) indicating receipt of the VCN (167) and, responsive thereto, forwarding (726) the VCN to the organization (150).

14. The supplier payment platform (120) of claim 13, in which: the supplier payment platform (120) comprises an application programming interface or user interface (API/UI) server (122) and a card management application server (124); and the request (702) is received at the API/UI server (122) which, responsive thereto, issues a request (704) to the card management application server (124) to perform the generating (706) of the VCN (167), the card management application server (124) performing the generating (706) in response to the request (704) to perform the generating (706).

15. The supplier payment platform (120) of claim 13, in which the forwarding (714, 716) of the VCN (167) to the mobile application provider (135) comprises forwarding (714) the VCN (167) to a virtual spend control and alerts token manager (126), which forwards (716) the VCN (167) to the mobile application provider (135).

16. A non-transitory machine readable medium (1020) comprising computer-executable instructions (1021) for a mobile application (164), the computerexecutable instructions (1021) causing a mobile device (160) to perform a method, the method comprising: receiving a user interaction (814) via a user interface (200) from the user (162) resulting in a registration of the user with a card management application server (124); receiving (818) digitization data for a virtual card number (VCN) (167) comprising data for adding the VCN to a digital wallet application (165), the VCN being requested by an organization (150) with which the user (162) is associated, the organization (150) being responsible for funding purchases made with the VCN (167); and responsive to the receiving of the digitization data (818), pushing (820) the digitization data to the digital wallet application (165), thereby allowing the user (162) to make purchase at near-field communications (NFC) payment terminals using the VCN (167).

17. The machine readable medium (1020) of claim 16, in which the digitization data is received (818) from a virtual spend control and alerts token manager (126) in response to a request (816) for the digitization data sent from the mobile application (164).

18. The machine readable medium (1020) of claim 16, in which the method further comprises displaying for the user a depiction (420) of the VCN (167) including a description (450) of the VCN (167), the description being defined by an administrator (158) associated with the organization (150).

19. The machine readable medium (1020) of claim 16, in which the method further comprises displaying for the user (162) a depiction (420) of the VCN (167) and use-restrictions (430) on the use of the VCN, the use-restrictions (430) being defined by an administrator (158) associated with the organization (150).

20. The machine readable medium (1020) of claim 16, in which the method further comprises: displaying for the user (162) a depiction (420) of the VCN (167); and receiving a further user interaction (814) via the user interface (400, 440) causing the VCN (167) to be added to the digital wallet application (165), the pushing of the VCN (167) to the digital wallet (165) being responsive to the further user interaction (814).