WO2017180360A1 - Système et procédé pour fournir des cartes d'entreprise d'employés basées sur des jetons - Google Patents

Système et procédé pour fournir des cartes d'entreprise d'employés basées sur des jetons Download PDF

Info

Publication number
WO2017180360A1
WO2017180360A1 PCT/US2017/025840 US2017025840W WO2017180360A1 WO 2017180360 A1 WO2017180360 A1 WO 2017180360A1 US 2017025840 W US2017025840 W US 2017025840W WO 2017180360 A1 WO2017180360 A1 WO 2017180360A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
mobile device
token
organization
account
Prior art date
Application number
PCT/US2017/025840
Other languages
English (en)
Inventor
Saravana Perumal SHANMUGAM
Original Assignee
Mastercard International Incorporated
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US15/097,816 external-priority patent/US11823161B2/en
Priority claimed from US15/097,856 external-priority patent/US20170300907A1/en
Priority claimed from US15/097,705 external-priority patent/US20170300906A1/en
Priority claimed from US15/097,775 external-priority patent/US20170300894A1/en
Application filed by Mastercard International Incorporated filed Critical Mastercard International Incorporated
Publication of WO2017180360A1 publication Critical patent/WO2017180360A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/229—Hierarchy of users of accounts
    • G06Q20/2295—Parent-child type, e.g. where parent has control on child rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules

Definitions

  • parents sometimes provide their adolescent or young adult children with payment cards that are linked to the parents' payment accounts. Again, however, ordering and receiving the child's payment card may entail inconvenience. Moreover, it may not be a straightforward matter for the parent to establish and enforce limits and accountability with respect to the child's use of the payment card provided to him/her.
  • FIG. 1 is a block diagram that illustrates a conventional payment system.
  • FIG. 2 is a block diagram mat illustrates a payment system in which aspects of the present disclosure may be applied.
  • FIGS. 3-9 are block diagrams that illustrate various aspects of payment systems provided according to teachings of the present disclosure.
  • FIG. 10 is a block diagram that shows some features of a typical mobile device that may perform a role m one or more of the payment systems illustrated in FIGS. 3-9.
  • FIG.11 is a block diagram that illustrates a computer system that may perform a role in one or more of the payment systems illustrated in FIGS. 3-9.
  • FIG.12 is a block diagram that illustrates another computer system that may perform a role in one or more of the payment systems illustrated in FIGS 3-9.
  • FIGS. 13 and 14 are flow charts mat illustrate processes that may be performed in accordance with aspects of the present disclosure m one or more of the payment systems illustrated in FIGS. 3-9.
  • FIG. IS shows a simplified example user interface screen display mat may be provided in connection with the process illustrated in FIG. 14.
  • FIGS. 16-18 are flow charts mat illustrate processes that may be performed in accordance with aspects of the present disclosure in one or more of the payment systems illustrated in FIGS. 3-9.
  • FIG. 19 shows a simplified example user interface mobile screen display mat may be provided in connection with the process illustrated in FIG. 18.
  • FIG. 20 is a flow chart that illustrates a process that may be performed in accordance with aspects of the present disclosure in one or more of the payment systems illustrated in FIGS. 3-9.
  • FIGS. 21-24 are simplified example mobile screen displays mat may be provided to a parent payment account holder in accordance with aspects of the present disclosure.
  • payment tokens are provisioned to mobile devices m lieu of providing employee or child physical payment cards.
  • the mobile devices are carried by the employees or account holder's child, as the case may be.
  • a corporate administrative person or the parent may control and initiate the provisioning of the payment token to the mobile device in question.
  • the payment token that is provisioned may be associated with a corporate/departmental/parent's payment account and with the PAN (primary account number) that identifies the payment account in question.
  • the provisioning service in some embodiments, may be performed by a service provider that provides provisioning services to mobile devices as an entity mat is trusted by the account issuers.
  • Payment application programs may be downloaded as required to the mobile devices that are to receive the provisioriing of the payment tokens.
  • the corporate administrative person or parent may control the provisioning by operating a mobile device or other computing device to interact with the token provisioning service provider.
  • the mobile device used by the parent to initiate provisioning of the payment token to the child device may in itself be a payment-enabled mobile device that allows the parent to access the parent's payment account for use in payment transactions.
  • the mobile devices used to initiate provisioning of payment tokens to other devices may also have received downloads of suitable application programs (also referred to as "apps") for that purpose.
  • the corporate administrative person or parent may engage in a rule setup process to define one or more rules mat may constrain use of the provisioned payment tokens with respect to payment transactions.
  • the rules may be stored and/or enforced applied at a central facility such as a payment network or a token service provider.
  • the administrator or parent may also interact with a remote computer (e.g., a payment network or token service provider) to block use of a payment token after it has been provisioned to the employee child mobile device.
  • the administrator/parent may receive reports and/or alerts relating to payment transactions performed using the payment token(s) that have been provisioned to employee/child mobile devices.
  • a central computer system may keep records of the transactions using the payment tokens mat have been provisioned to employee/child mobile devices.
  • provisioning of the payment token to the child's (or employee's) device may be via short range communications (or scanning a OR code) from the parent ' s/administrator ' s mobile device.
  • FIG. 1 is a block diagram that illustrates a conventional payment system 100 that may be considered the operating environment and background in which aspects of the present disclosure may be deployed.
  • the system 100 includes a conventional payment card/device 102 (which may alternatively be, for example, a payment IC card or a payment-enabled mobile device that stores a payment card account number or payment token and runs a payment app).
  • the system 100 further includes a reader component 104 associated with a POS terminal 106. In some known manner (depending on the type of the payment card device 102) the reader component 104 is capable of reading the payment card account number token and other information from the payment card/device 102.
  • the reader component 104 and the POS terminal 106 may be located at the premises of a retail store and operated by a sales associate of the retailer for the purpose of processing retail transactions.
  • the payment card/device 102 is shown in FIG. 1 to be interacting with the reader component 104 and the POS terminal 106 for the purpose of executing such a transaction.
  • Reference numeral 107 indicates a user/account holder who is a customer at the retail store and who has presented the payment card/device 102 to the reader component in order to settle the retail transaction.
  • a computer 108 operated by an acquirer is also shown as part of the system 100 in FIG. 1.
  • the acquirer computer 108 may operate in a conventional manner to receive a payment account transaction authorization request message (sometimes referred to as an "authorization request") for the transaction from the POS terminal 106.
  • the acquirer computer 108 may route the authorization request via a payment network 110 to the server computer 112 operated by the issuer of a payment account that is associated with the payment card device 102.
  • the payment account transaction authorization response message also referred to as an "authorization response” generated by the payment account issuer server computer 112 may be routed back to the POS terminal 106 via the payment network 110 and the acquirer computer 108.
  • the payment card issuer server computer 112 may be operated by or on behalf of a financial institution ("FI") that issues payment accounts to individual users and other entities.
  • FI financial institution
  • the payment account issuer server computer 112 may perform such functions as (a) receiving and responding to requests for authorization of payment account transactions to be charged to payment accounts issued by the FI; and (b) tracking and storing transactions and maintaining account records.
  • the components of the system 100 as depicted in FIG. 1 are only those that are needed for processing a single transaction.
  • a typical payment system may process many purchase transactions (including simultaneous transactions) and may include a considerable number of payment account issuers and their computers, a considerable number of acquirers and their computers, and numerous merchants and their POS terminals and associated reader components.
  • the system may also include a very large number of payment account holders, who carry payment cards or other devices for initiating payment transactions by presenting an associated payment account number or token to the reader component of a POS terminal.
  • payment account numbers and/or payment tokens may also be employed in online shopping transactions.
  • the user/customer may interact with a shopping website hosted by the merchant's e- commerce server computer (not shown).
  • the merchant's e- commerce server computer may perform many of the functions ascribed above to the POS terminal 106. Such functions may include initiating a payment transaction authorization request message and receiving back a payment transaction authorization response message.
  • Payment tokens have been defined as "surrogate values that replace [PANs]" in part of a payment system.
  • FIG. 2 is a block diagram mat illustrates a system 200 in which teachings of the present disclosure may be applied.
  • FIG. 2 is adapted from the " Figure 1" presented on page 10 of the Payment Token Interoperability Standard (issued by MasterCard International Incorporated (the assignee hereof), Visa and American Express in November 2013). Reference is also made to the EMV* Payment Tokenisation Specification, published March 2014, and available for downloading from www.emvco.com.
  • FIG. 2 As is familiar to the reader, the vast majority of the users 202 may habitually carry with them mobile devices such as smartphones, tablet computers, or the like. (To simplify the drawing, these devices are not explicitly shown.) It is assumed that many of the mobile devices may be provisioned with respective payment tokens, in accordance with at least one use case described in the Payment Token Interoperability Standard.
  • FIG. 2 also includes a block 204 mat represents a token service provider.
  • the token service provider 204 may in some embodiments also be the operator of a payment network (block 206), such as the well-known Banknet ® system operated by MasterCard International Incorporated, the assignee hereof.
  • the token service provider 204 may be authorized in the system 200 to issue tokens.
  • the payment tokens may be issued to token requestors such as the token requestor represented by block 208 in FIG. 2. (As set forth in the Payment Token
  • token requestors may, for example, include payment card account issuers; card-on-file merchants; acquirers, acquirer-processors, etc.; OEM device manufacturers; and digital wallet providers).
  • Each token requestor 208 may be required to register with the token service provider 204.
  • the token service provider 204 may perform such functions as operating and maintaining a token vault 210, generating and issuing payment tokens assuring security and proper controls, token provisioning (e.g., provisioning NFC-capable mobile devices with token values; personalizing payment cards with token values), and registering token requestors.
  • token provisioning e.g., provisioning NFC-capable mobile devices with token values; personalizing payment cards with token values
  • registering token requestors e.g., registering token requestors.
  • block 204 should also be understood to represent one or more computer systems operated by the token service provider.
  • Block 212 in FIG. 2 represents an issuer of payment card accounts held by the cardholders 202.
  • the issuer is typically a bank or other financial institution, and may provide banking services to the cardholders 202 in addition to issuing payment card accounts (e.g., credit card accounts, debit card accounts) to the cardholders 202.
  • issuers 212 may also have the role of token requestor (block 208) in the system 200.
  • Block 214 in FIG. 2 represents a merchant to which the cardholders 202 may present payment devices (payment cards and/or payment-enabled mobile devices— e.g., NFC-enabled and token-provisioned mobile devices, etc., none of which are shown in the drawing) to consummate a purchase transaction.
  • the merchant 214 may also be a token requestor 208 (e.g., for implementing a tokenized card-on-file arrangement for e-commerce transactions with a cardholder 202).
  • the merchant may receive a token value from a cardholder's payment device and issue an authorization request to initiate processing of a payment transaction in the system 200.
  • Block 216 in FIG. 2 represents an acquirer.
  • the acquirer may be a financial institution that provides banking services to the merchant 214, and that receives and routes payment transaction authorization requests originated from the merchant 214.
  • FIG. 2 is a block 218, representing another payment network with which the token service provider 204 may interact
  • system 200 may include numerous merchants, token requestors, acquirers and issuers, rather than one of each as depicted in FIG. 2. It may also be the case that mere is more man one token service provider in the system.
  • FIG. 3 is a block diagram that illustrates certain aspects of a payment system mat may be provided according to teachings of the present disclosure and that may incorporate some or all of the elements of the payment systems illustrated in FIGS. 1 and 2.
  • the digitization support server computer 302 may provide support to payment account issuers in connection with the electronic logistics involved in provisioning PANs and/or payment tokens to mobile devices.
  • the digitization support server computer 302 may implement functionality as is currently made available via the MasterCard Digital Enablement Service (MDES), a service of MasterCard International Incorporated, the assignee hereof.
  • MDES MasterCard Digital Enablement Service
  • the digitization support server computer 302 may provide additional functionality as described herein.
  • the digitization support server computer 302 may also be in the role of a token requestor (as represented by block 208 in FIG. 2).
  • a typical account holder organization 304 which may be a corporation, a not-for-profit organization, or the like.
  • the account holder organization 304 may be the holder of one or more payment accounts issued by an account issuer 212.
  • Block 304 should also be understood to represent one or more computing devices (e.g., smartphones, tablet computers, laptop or notebook computers, personal computers) owned by and operated on behalf of the account holder organization 304. It will be understood that each payment account held by the account holder organization 304 may be identified by a respective PAN. (In practical embodiments of the systems disclosed herein, there may be numerous account holder organizations that are participants in the systems.)
  • a mobile device 306 which is the target for the provisioning of a payment token, as described further below.
  • the mobile device 306 is operable to function as a payment-enabled device like the element 102 shown in FIG. 1.
  • Reference numeral 308 indicates an individual who serves as an administrator for the account holder organization 304 in the processes involved in making corporate "card" accounts available to employees of the organization 304 by provisioning payment tokens to the employees' mobile devices.
  • One such employee in the latter category is indicated by reference numeral 310 and is shown as the user of the mobile device 306.
  • the mobile device 306 may be owned by the account holder organization 304 and supplied for the employee's use while remaining the property of the account holder organization 304; or, alternatively, the mobile device may be owned by the employee 310 and used with the consent of the account holder organization 304 in connection with business of the account holder organization according to a "BYOD" (bring your own device) program of the account holder organization. In either case, the mobile device 306 may in effect be registered to the employee 310 in mobile device management records of the account holder organization 304.
  • the administrator 308 may issue a corporate "card" to the employee 310 by interacting with the digitization support server computer 302 via a computing device (e.g., as represented by block 304) to request that the digitization support server computer 302 provision a payment token to the mobile device 306 used by the employee 310.
  • the digitization support server computer 302 may obtain consent from the account issuer 212 or otherwise interact with the issuer 212 in connection with provisioning the payment token to the mobile device 306.
  • the payment token may be associated with the PAN that identifies a payment account issued by the account issuer 212 to the account holder organization 304.
  • the administrator 308 may prescribe and or set-up one or more rules to govern/constrain the use of the payment token in payment transactions. Further details concerning rule setting will be provided below.
  • the digitization support server computer 302 may provide reports to the account holder organization 304 concerning transactions performed by the payment-enabled mobile device 306 using the payment token. Those transactions may be charged to the PAN for the account holder organization's corresponding payment account at the level of the account issuer 212.
  • FIG. 4 is a block diagram that illustrates certain aspects of a payment system that may be provided according to teachings of the present disclosure and that may incorporate some or all of the elements of the payment systems illustrated in FIGS. 1 and 2. Unlike FIG. 3, which is primarily concerned with streamlining provision of corporate "cards" to employees, FIG. 4 is illustrative of functionality to aid an account holder/parent to provide payment account access to a child or other family member.
  • Reference numeral 402 indicates the "target" mobile device, i.e., the mobile device used by the child/family member (not shown) of the account holder (not shown).
  • a payment app that has been downloaded to the mobile device 402 is indicated at 404.
  • Hie mobile device owned operated by the parent primary account holder is indicated by reference numeral 406.
  • An app that supports the account holder's token provisioning request is indicated at 408. It will be appreciated that the latter app may have been downloaded to the mobile device 406 to allow the account holder to proceed with one or more token provisioning requests.
  • the account issuer 212 has issued to the account holder a payment account to which the child family member is now to be given access. (In practical embodiments of the systems disclosed herein, the systems may include, as participants, numerous account holders of the type referred to above in connection with mobile device 406.)
  • the account holder may use the mobile device 406 to interact "over the air" with the digitization support server computer 302 to request a payment token to be provisioned to the child mobile device 402 via the account holder mobile device 406. It may typically be the case mat the digitization support server computer 302 obtains consent from the account issuer 212 before fulfilling the provisioning request from the account holder. Moreover, it may often be the case that the account issuer 212 will engage in an ID&V (identification and verification) process with respect to the account holder who is making the provisioning request Alternatively, the digitization support server computer 302 may perform the ID&V or some other form of user authentication without involving the account issuer 212. For example, where the account holder's mobile device is payment-enabled, and with biometric user authentication typically performed for each transaction, in such a case it may be sufficient for the account holder to be authenticated by the customary biometric user authentication method.
  • ID&V identification and verification
  • FIG. 5 is a block diagram that illustrates certain aspects of a payment system that may be provided according to teachings of the present disclosure and that may incorporate some or all of the elements of the payment systems illustrated in FIGS. 1 and 2.
  • FIG. S may be compared with FIG. 3.
  • the desired functionality is to fulfill provisioning of a payment token to the mobile device 306 used by an employee 310 of an account holder organization (block 304, which also represents one or more computing devices operated on behalf of the account holder organization).
  • FIG. 5 does not show a digitization support server computer. Instead, it is assumed that the account issuer 212a handles directly the electronic logistics involved in provisioning payment tokens to mobile devices.
  • the account issuer 212a may function as a token requester, and may request and receive payment tokens from the token service provider 204 (shown in FIG. 5 as well as in FIG. 2).
  • an administrative employee (reference numeral 308) of the account holder organization is shown in FIG. 5.
  • the administrator 308 may initiate the employee's access to a "corporate card" by interacting with the account issuer 212a to request that the account issuer provision a payment token (obtained by the account issuer from the token service provider 204) to the mobile device 306 used by the employee 308.
  • FIG. 3 In many if not all respects, the above description of FIG. 3 is generally applicable to the functionality achieved according to the arrangement shown in FIG. 5.
  • FIG. 6 is a block diagram that illustrates certain aspects of a payment system mat may be provided according to teachings of the present disclosure and that may incorporate some or all of the elements of the payment systems illustrated in FIGS. 1 and 2.
  • FIG. 6 may be compared with FIG. 4; the differences between FIG. 6 and FIG. 4 are analogous to the differences between FIG. 5 and FIG. 3. That is, FIG. 6, unlike FIG. 4, does not show a digitization support server computer. Rather, for the arrangement of FIG. 6, h is assumed that the account issuer 212a handles the electronic logistics of provisioning account numbers/payment tokens to mobile devices without enlisting the services of a service provider such as MDES.
  • a service provider such as MDES.
  • the desired functionality in the arrangement of FIG. 6 is to provision a payment token to the mobile device 402 used by the account holder's child family member (not shown) so as to permit the child/family member to have (possibly controlled) access to the account holder's payment account
  • the provisioning of the payment token to the child's mobile device 402 may be initiated by the account holder by interacting with the account issuer 212a via the account holder's mobile device 406. Presumably ID&V and or some sort of user
  • the account issuer 212a may request and receive the payment token from the token service provider 204 for provisioning to the child's mobile device 402.
  • the provisioning of the payment token to the child mobile device 402 may be via the account holder's mobile device 406.
  • FIG. 4 In many if not all respects, the above description of FIG. 4 is generally applicable to the functionality achieved according to the arrangement shown in FIG. 6.
  • FIG. 7 is a block diagram that illustrates certain aspects of a payment system mat may be provided according to teachings of the present disclosure and that may incorporate some or all of the elements of the payment systems illustrated in FIGS. 1 and 2.
  • FIG. 7 may be viewed as another variation on the arrangement of FIG. 3.
  • the arrangement of FIG. 7 differs from the arrangement of FIG. 3 only in that the arrangement of FIG. 3 assumes provisioning of the payment token from the digitization support server computer 302 to the employee mobile device 306 occurs "over the air", whereas in the arrangement of FIG. 7— for enhanced security— the mobile device 306 is brought to an ATM (automated teller machine) 702 to receive provisioning of the payment token.
  • ATM automated teller machine
  • the payment token may be communicated via secure data channel from the digitization support server computer 302 to the ATM 702, and then the provisioning may be completed through a local wireless data communication link between the ATM 702 and the mobile device 306.
  • FIG. 8 is a block diagram that illustrates certain aspects of a payment system that may be provided according to teachings of the present disclosure and that may incorporate some or all of the elements of the payment systems illustrated in FIGS. 1 and 2.
  • FIG. 8 may be viewed as still another variation on the arrangement of FIG. 3.
  • the digitization support server computer 302, the employee mobile device 306, the employee 310 and the issuer 212 are shown, as before.
  • a block that represents the account holder organization 304 is shown as incorporating an administrator 308, the administrator's computing device 802 (e.g., a
  • the mobile app server 804 may provide functionality to the account holder organization 304 in connection with distributing mobile apps to mobile devices operated by employees of the account holder organization 304.
  • the mobile app server 804 may provide overall management and tracking of all apps supplied by the account holder organization 304 to its employees' mobile devices.
  • One of the types of apps distributed by the mobile app server 804 may be a payment app suitable for programming the employees' mobile devices to be payment-enabled with payment tokens provisioned to the employees' mobile devices.
  • “over the air" provisioning of a suitable app from the mobile app server 804 to the employee mobile app 306 is schematically indicated at 806.
  • the arrangement of FIG. 8 may function in substantially the same manner as the arrangement of FIG. 3, except that in the arrangement of FIG. 8 the mobile device 306 receives the payment app from the account holder organization 304 via the mobile app server 804 rather than from the digitization support server computer 302 or an app store, etc.
  • FIG. 9 is a block diagram that illustrates certain aspects of a payment system that may be provided according to teachings of the present disclosure and that may incorporate some or all of the elements of the payment systems illustrated in FIGS. 1 and 2.
  • FIG. 9 may be viewed as a modification of the conventional payment system shown in FIG. 1, with adaptations to accommodate aspects of the present disclosure. It will be appreciated that FIG. 9 represents aspects of a payment system in regard to a purchase transaction, whereas FIGS. 3-8 primarily are concerned with arrangements for provisioning the employee's child's mobile device with a payment token.
  • the purchaser initiator of the payment transaction is shown as being the employee 310, though alternatively the purchaser may be the child family/ member referred to m connection with FIGS. 4 and 6.
  • the payment device is shown as the employee's payment-enabled mobile device 306, although alternatively the payment device may be the child mobile device 402 shown in FIGS. 4 and 6.
  • the reader 106 and the POS terminal 108 shown in FIG. 9 may have the same functions as described above in connection with FIG. 1.
  • Block 108 may also have the same function as in FIG. 1, except that in FIG. 9 block 108 is re-labeled to illustrate mat the role of the transaction acquirer may (as is a common practice) alternatively be performed by a transaction processor that represents the merchant's acquirer bank.
  • Block 110a in FIG. 9 represents the payment network.
  • the payment network 110a may perform the same functions as the payment network 110 in FIG. 1; further, the payment network 110a may perform one or more additional functions - related to aspects of the present disclosure. These additional functions may include storing and enforcing rules relating to use of payment tokens provisioned to mobile devices as discussed above. More details about types of rules and enforcement thereof will be provided below.
  • the payment network 110a may be commonly operated with the digitization support server computer 302 shown in previous drawings and may co-operate with the digitization support server computer 302, at least for the purpose of storing and implementing account holder preferences/options communicated by account holders to the digitization support server computer 302 (or to an account issuer, as the case may be).
  • the additional functions of the payment network 110a may also include de-tokenization, as described, for example, in the above-referenced documents relating to tokenization standards/specifications. Moreover, the additional functions of the payment network 110a may include providing reports and/or transaction alerts to the account holder (indicated at 308 in FIG. 9; alternatively, the account holder may be an individual parent, as discussed in connection with FIGS. 4 and 6, rather than the account holder organization administrative employee as expressly indicated in FIG. 9). As another possible additional function of the payment network 110a, it may give the account holder the opportunity to
  • the payment network 110a may store records of payment token transactions for reporting to account holders.
  • the payment network 110a may communicate with the account holder via a mobile device 802 (FIG. 8) or 406 (FIGS. 4 and 6), as the case may be.
  • the communication between the payment network 110a and the mobile device 802 or 406 is indicated at 902 in FIG. 9.
  • account issuer 112 which may have the same functions as in the system depicted in FIG. 1.
  • FIG. 10 is a block diagram that shows some features of a typical mobile device (e.g., items 306, 802, 402, 406, as shown in previously discussed drawing figures) that may perform a role in one or more of the payment systems illustrated in FIGS. 3-9.
  • the mobile device will be assigned the reference numeral 1000.
  • the mobile device 1000 may include a housing 1003.
  • the front of the housing 1003 is predominantly constituted by a touchscreen (not separately shown), which is a key element of the user interface 1004 of the mobile device 1000.
  • the mobile device 1000 further includes a mobile processor/control circuit 1006, which is contained within the housing 1003. Also included in the mobile device 1000 is a storage memory device or devices (reference numeral 1008).
  • the storage memory devices 1008 are in communication with the processor/control circuit 1006 and may contain program instructions to control the processor/control circuit 1006 to manage and perform various functions of the mobile device 1000.
  • a device such as mobile device 1000 may function as what is in effect a pocket-sized personal computer (assuming for example that the mobile device is a smartphone), via programming with a number of application programs, or "apps", as well as a mobile operating system (OS).
  • apps are represented at block 1010 in FIG.
  • the mobile device 1000 may include mobile communications functions as represented by block 1012.
  • the mobile communications functions may include voice and data communications via a mobile communication network with which the mobile device 1000 is registered.
  • the mobile device 1000 may include short-range radio communications capabilities (block 1014), including for example NFC and/or Bluetooth. These capabilities may, in some use cases, also facilitate the mobile device's receipt of a payment token that is being provisioned to the mobile device 1000.
  • short-range radio communications capabilities including for example NFC and/or Bluetooth. These capabilities may, in some use cases, also facilitate the mobile device's receipt of a payment token that is being provisioned to the mobile device 1000.
  • the mobile device 1000 may include a camera 1016.
  • these may include a payment app and/or a wallet app.
  • the payment app may include one or more features to facilitate receipt of the payment token.
  • a suitable app for that purpose may be included among the apps 1010.
  • Such an app may include further features mat support rule-setting for the payment capabilities of the other mobile device, and for receiving reports, alerts, and or requests to approve particular current payment transactions with respect to payment transaction activity of the other mobile device.
  • the blocks depicted in FIG. 10 as components of the mobile device 1000 may in effect overlap with each other, and/or mere may be functional connections among the blocks which are not explicitly shown in the drawing. It may also be assumed that, like a typical smartphone, the mobile device 1000 may include a rechargeable battery (not shown) that is contained within the housing 1003 and that provides electrical power to the active components of the mobile device 1000.
  • a rechargeable battery not shown
  • mobile device 1000 may be embodied as a smartphone, but this assumption is not intended to be limiting, as mobile device 1000 may alternatively, in at least some cases, be constituted by a tablet computer or by other types of mobile computing devices.
  • FIG. 11 is a block diagram that illustrates an example embodiment of the digitization support server computer 302.
  • the digitization support server computer 302 may be constituted by server computer and/or mainframe computer hardware.
  • the digitization support server computer 302 may include a computer processor 1100 operatrvely coupled to a communication device 1101, a storage device 1104, an input device 1106 and an output device 1108.
  • the computer processor 1100 may be in communication with the communication device 1101, the storage device 1104, the input device 1106 and the output device 1108.
  • the computer processor 1100 may be constituted by one or more processors. Processor 1100 operates to execute processor-executable steps, contained in program instructions described below, so as to control the digitization support server computer 302 to provide desired functionality.
  • Communication device 1101 may be used to facilitate communication with, for example, other devices (such as devices operated by account holders, administrators, employees of account holder organizations, etc.).
  • communication device 1101 may comprise numerous communication ports ' (not separately shown), to allow the digitization support server computer 302 to communicate simultaneously with a large number of other devices and computers, including communications as required to receive and fulfill numerous requests to provision payment tokens to account holder organization employees and/or children or other family members of account holders.
  • Input device 1106 may comprise one or more of any type of peripheral device typically used to input data into a computer.
  • the input device 1106 may include a keyboard and a mouse.
  • Output device 1108 may comprise, for example, a display and/or a printer.
  • Storage device 1104 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., hard disk drives), optical storage devices such as CDs and/or DVDs, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as so-called flash memory. Any one or more of such information storage devices may be considered to be a computer-readable storage medium or a computer usable medium or a memory.
  • magnetic storage devices e.g., hard disk drives
  • optical storage devices such as CDs and/or DVDs
  • semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as so-called flash memory.
  • RAM Random Access Memory
  • ROM Read Only Memory
  • Storage device 1104 stores one or more programs for controlling processor 1100.
  • the programs comprise program instructions (which may be referred to as computer readable program code means) mat contain processor-executable process steps of the digitization support server computer 302, executed by the processor 1100 to cause the digitization support server computer 302 to function as described herein.
  • the programs stored by the storage device 1104 may include one or more operating systems (not shown) that control the processor 1100 so as to manage and coordinate activities and sharing of resources in the digitization support server computer 302, and to serve as a host for application programs that run on the digitization support server computer 302.
  • operating systems not shown
  • the storage device 1104 may also store a software interface 1110 that facilitates interaction between the digitization support server computer 302 and various computers operated by account issuers. Such interaction may be necessary, for example, when the digitization support server computer 302 is required to obtain consent from an account issuer before fulfilling a request to provision a payment token to a mobile device.
  • the storage device 1104 may further store a provisioning request handling application program 1112.
  • the provisioning request handling application program 1112 may control the processor 1100 to enable the digitization support server computer 302 to handle payment token provisioning requests, as described herein.
  • the storage device 1104 may store a rule set-up handling application program 1114.
  • the rule set-up handling application program 1114 may control the processor 1100 to enable the digitization support server computer 302 to interact with users (e.g., account holders and/or "corporate card” administrators) to permit the users to select and/or define rules to constrain use of the payment tokens that are provisioned to employee/child/family member mobile devices.
  • the rule setup handling application program may also program the digitization support server computer 302 to cause the rules selected defined by the users to be stored and administered by a suitable component of the payment system, such as the payment network 110a (as per FIG. 9), or— in other embodiments— a token service provider such as the component 204 shown in FIG. 2. More details of the functionality provided through the rule set-up handling application program 1114 will be provided below.
  • the digitization support server computer 302 may be a source of payment token activity reports for account holders.
  • the storage device 1104 may store a reporting program 1116 that programs the digitization support server computer 302 to provide suitable reporting functionality.
  • the storage device 1104 may further store database management programs and an internal reporting application (both not separately shown), the latter of which may respond to requests from computer system administrators for reports on the activities performed by the digitization support server computer 302; the storage device 1104 may also store communication software, device drivers, etc.
  • the storage device 1104 may also store one or more databases 1118 required for operation of the digitization support server computer 302.
  • FIG. 12 is a block diagram illustration of a payment network computer 1200 that may implement functions of the payment network 110a shown in FIG. 9.
  • the payment network computer 1200 may be constituted by server computer and/or mainframe computer hardware.
  • the payment network computer 1200 may include a computer processor 1202 operatively coupled to a communication device 1201, a storage device 1204, an input device 1206 and an output device 1208.
  • the computer processor 1202 may be in communication with the communication device 1201, the storage device 1204, the input device 1206 and the output device 1208.
  • the hardware architecture of the payment network computer 1200 may resemble that of the digitization support server computer 302 as described above, and the above description of components of the digitization support server computer 302 may also apply to like-named components of the payment network computer 1200.
  • Storage device 1204 stores one or more programs for controlling processor 1202.
  • the programs comprise program instructions (which may be referred to as computer readable program code means) that contain processor-executable process steps of the payment network computer 1200, executed by the processor 1202 to cause the payment network computer 1200 to function as described herein.
  • the programs stored by the storage device 1204 may include one or more operating systems (not shown) that control the processor 1202 so as to manage and coordinate activities and sharing of resources in the payment network computer 1200, and to serve as a host for application programs that run on the payment network computer 1200.
  • operating systems not shown
  • the storage device 1204 may also store a transaction handling application program 1210 that programs the processor 1202 to control the payment network computer 1200 such mat h is enabled to handle payment transactions, including routing of transaction authorization request messages and transaction authorization response messages, as occurs in a conventional payment network.
  • a transaction handling application program 1210 programs the processor 1202 to control the payment network computer 1200 such mat h is enabled to handle payment transactions, including routing of transaction authorization request messages and transaction authorization response messages, as occurs in a conventional payment network.
  • the transaction handling application program 1210 may support additional functionality of the payment network computer 1200 such that it performs
  • the storage device 1204 may store rule administration software 1212.
  • the rule administration software 1212 may program the processor 1202 to control the payment network computer 1200 to store and apply rules defined and/or selected by account holders to constrain use of payment tokens linked to their payment accounts.
  • the storage device 1204 may store a de-tokenization software module 1214.
  • the de-tokenization software module 1214 may program the processor 1202 to control the payment network computer 1200 to perform "de-tokenization” (i.e., translation of payment tokens into the corresponding PANs) in accordance with applicable tokenization standards and/or specifications. As is understood by those who are skilled in the art, this may involve interaction with a "token vault” such as that shown at 210 in FIG. 2.
  • the storage device 1204 may also store an alerts and/or approvals application program 1216.
  • the application program 1216 may program the processor 1200 to control the payment network computer 1200 such mat the payment network computer 1200 provides functionality, as described herein, in regard to alerts and/or account holder approvals with respect to transactions performed using payment tokens that have been provisioned to employee/child/family member mobile devices.
  • the storage device 1204 may further store database management programs and an internal reporting application (both not separately shown), the latter of which may respond to requests from computer system administrators for reports on the activities performed by the payment network computer 1200; the storage device 1204 may also store communication software, device drivers, etc.
  • the storage device 1204 may also store one or more databases 1218 required for operation of the payment network computer 1200.
  • FIG. 13 is a flow chart that illustrates a process that may be performed in accordance with aspects of the present disclosure.
  • FIG. 13 is illustrative of a process in which a payment token is provisioned to an employee's mobile device in an arrangement such as mat shown in FIG. 3, 7 or 8.
  • the process as depicted in FIG. 13 assumes that the mobile device 306 (FIG. 3, e.g.) that is to be provisioned with the payment token has already been loaded with a suitable payment app to receive and employ the payment token. This may have occurred, for example, through downloading of such a payment app from the mobile app server 804 in the arrangement as shown in FIG. 8. Alternatively, the mobile device 306 may have been used to download the payment app from an app store, or the like.
  • the downloading of the payment app to the mobile device 306 may be via the digitization support server computer 302, and may be part of the provisioning process.
  • the downloading of the payment app to the mobile device 306 may have been initiated by the employee 310, or alternatively the digitization support server computer 302 or the mobile app server 804 may have "pushed" the app to the mobile device 306.
  • a wallet app, as well as a payment app may be loaded into the mobile device 306.
  • the digitization support server computer 302 receives a provisioning request In informal terms, this may be referred to as providing an employee with a company payment "card"; in accordance with aspects of the present disclosure, this is a request to provision a payment token to the employee's mobile device 306 to make the mobile device 306 fully payment-enabled. From previous discussion, it will be understood mat the digitization support server computer 302 may receive this request from the applicable administrator 308 employed by the account holder organization 304 that employs the employee 310.
  • the provisioning request may specify the relevant departmental or organizational payment account by PAN.
  • the provisioning request may further specify the mobile telephone number for the mobile device 306 (thereby identifying the mobile device).
  • the employee 310 may be identified by name and job title and/or job code.
  • the request may explicitly identify the department to which the employee belongs.
  • security and user authentication with respect to the administrator 308 may be such, and the convention between the digitization support server computer 302 and the account issuer may be such, mat the digitization support server computer 302 is not required to obtain approval from the account issuer before fulfilling the provisioning request
  • strong communication channel security and mutual authentication between the digitization support server computer 302 and the payment account administrator 308 for the organization 304 may be in place to support provisioning fulfillment without direct account issuer approval for each request
  • the payment account administrator may be, for example, a trusted departmental finance staff member or a trusted member of the central finance staff for the organization 304.
  • the digitization support server computer 302 may (as indicated at block 1304 in FIG. 13) check in with the account issuer for the organization's payment accounts) to confirm the status of the payment account for which the payment token is being issued, and/or to allow the account issuer to perform ID&V or take other security measures with respect to the requesting payment account administrator 308 and/or the computing device through which the payment account administrator 308 is submitting the provisioning request Assuming that the account issuer 212 (FIG. 3) approves the provisioning request or that no such approval was required, then block 1306 in FIG. 13 may follow block 1302 or block 1304, as the case may be.
  • the digitization support server computer 302 may request a payment token tram the token service provider 204 (FIG.2) for provisioning to the employee mobile device 306. In doing so, the digitization support server computer 302 may identify the relevant PAN, i.e., the PAN that identifies the payment account to which the payment token will be linked
  • Block 1308 may follow block 1306 in the process of FIG. 13.
  • the digitization support server computer 302 may receive the requested payment token from the token service provider 204.
  • Block 1310 may follow block 1308 in the process of FIG. 13.
  • the digitization support server computer 302 may provision the payment token received at 1308 to the employee mobile device 306. This may involve, for example, an interaction "over the air” between the digitization support server computer 302 and the payment app previously loaded into the mobile device 306. The interaction may involve transmission over the air of the payment token from the digitization support server computer 302 to the mobile device 306.
  • the processing at block 1310 may involve authentication of the mobile device 306 or of the payment app in the mobile device which is to receive the payment token.
  • the processing at block 1310 may involve authentication of the mobile device 306 or of the payment app in the mobile device which is to receive the payment token.
  • original provisioning request at 1302 may have included data to identify the device by device I.D. or to identify the copy of the payment app (e.g., if it has been downloaded to the mobile device 306 via the mobile app server 804 (FIG. 8)) to aid the digitization support server computer 302 m authenticating the particular device and or copy of the app.
  • Block 1312 may follow block 1310 in the process of FIG. 13.
  • Block 1312 is concerned with establishing rules that may govern or constrain the use of the payment token for payment transactions. Details of an embodiment of the processing at block 1312 will be described below in connection with FIGS. 14 and 1 S .
  • Block 1314 may follow block 1312 in the process of FIG. 13.
  • the digitization support server computer 302 may arrange that the payment token provisioned at 1310 to the mobile device 306 is stored in the token vault 210 (FIG. 2) in association with the relevant PAN. Consequently, in payment transactions utilizing the payment token and the payment-enabled mobile device 306, the de- tokenization stage of the transaction will result in translation of the payment token to the relevant PAN,
  • FIG. 14 is a flow chart that illustrates an example process that may be performed in accordance with aspects of the present disclosure.
  • FIG. 14 illustrates an example embodiment of block 1312 in FIG. 13. That is, FIG. 14 illustrates an example set-up process for rules to govern or constrain the use of the payment token provisioned at 1310.
  • the process of FIG. 14 may begin with a decision block 1402.
  • the digitization support server computer 302 may determine whether the set of rules to be applied to use of the payment token is to be a predefined set of rules or a custom set of rules.
  • the digitization support server computer 302 may make this determination in accordance with a preference indicated by the administrator 308 in interacting with the digitization support server computer 302. Alternatively, the digitization support server computer 302 may make this determination based on the job title or job code for the employee 310 and in the absence of any countervailing indication from the administrator 308.
  • the digitization support server computer 302 may read data indicative of the status or classification of the employee 310. This data may, for example, have been included in the provisioning request received at block 1302 in FIG. 13. For example, this data may indicate a job code and or job title for the employee 310.
  • Block 1406 may follow block 1404 in the process of FIG. 14.
  • the digitization support server computer 302 may cause a set of rules to be stored that has been predefined for the type of employee indicated by the employee status or classification that was read at block 1404.
  • the rules governing their use of their payment-enabled mobile phones may include rules such as (a) a daily $250 limit on transactions; (b) permitted use at any gas station; (c) permitted use at any restaurant; (d) approval required for use at any type of merchant other than a gas station or a restaurant.
  • the rules may permit use of then- payment tokens only for transactions with certain specified software vendors and app stores.
  • the rules may permit up to $10,000 per day in total transactions, but may require mat the payment token be used only with certain approved vendors.
  • block 1408 may follow decision block 1402 in the process of FIG. 14.
  • FIG. IS is an example screen display that may be presented to the administrator 308 to allow the administrator to provide input for defining a custom set of rules. Reference will now be made to various portions of the example display illustrated in FIG. IS.
  • the administrator 308 may set a maximum number of transactions ("swipes") for which the payment token may be used on any given day.
  • the administrator 308 may set a maximum amount per transaction.
  • the administrator 308 may indicate the mobile telephone number of a mobile device (e.g., for the administrator's own smartphone or the phone of a "duty officer" for the finance department) to receive alerts on occasions when the payment token is used or attempted to be used in violation of the applicable set of rules.
  • a mobile device e.g., for the administrator's own smartphone or the phone of a "duty officer" for the finance department
  • a maximum spend limit may be set by the administrator 308.
  • the administrator 308 may set a maximum spend limit
  • the administrator 308 may define a rule that forbids use of the payment token at a particular car rental company.
  • the administrator 308 may set a maximum spend limit
  • block 1410 may follow block 1408.
  • the digitization support server computer 302 may cause a set of rules to be stored in accordance with the input provided at 1408 by the administrator 308.
  • FIG. 16 is a flow chart that illustrates a process that may be performed in accordance with aspects of the present disclosure.
  • FIG. 16 is illustrative of a process in which a payment token is provisioned to a child's or family member's mobile device in an arrangement such as that shown in FIG. 4.
  • the digitization support server computer 302 receives a provisioning request.
  • this may be referred to as providing a child/family member with a payment "card” linked to (providing access to) an account holder's payment account; in accordance with aspects of the present disclosure, this is a request to provision a payment token to the child's mobile device 402 as part of making the mobile device 402 payment-enabled.
  • the digitization support server computer 302 may receive this request from the account holder via the account holder's mobile device 406 (FIG. 4).
  • a suitable app to support this functionality in the account holder's mobile device 406 may have previously been downloaded to the account holder's mobile device 406.
  • Block 1604 may follow block 1602 in the process of FIG. 16.
  • the digitization support server computer 302 may make the account issuer 212 (FIG. 4) aware of the provisioning request, so that the account holder 212 may undertake a suitable ID&V process in regard to the account holder who has just submitted the provisioning request. Assuming that the ID&V process is completed successfully (or, alternatively, assuming that the digitization support server computer 302 has successfully completed a prescribed user authentication process with respect to the account holder), then block 1606 in FIG. 16 may follow block 1604.
  • the digitization support server computer 302 may request a payment token from the token service provider 204 (FIG. 2) for provisioning to the child mobile device 402 (FIG. 4). In doing so, the digitization support server computer 302 may identify the relevant PAN, i.e., the PAN that identities the (account holder's) payment account to which the payment token will be linked.
  • Block 1608 may follow block 1606 in the process of FIG. 16.
  • the digitization support server computer 302 may receive the requested payment token from the token service provider 204.
  • Block 1610 may follow block 1608 in the process of FIG. 16.
  • me digitization support server computer 302 may transmit the payment token to the account holder's mobile device 406 to permit the account holder's mobile device 406 to re-transmit the payment token to the child's mobile device 402.
  • FIG. 17 Reference will now be made to FIG. 17 to describe one example of a manner in which the processing of block 1610 may be performed.
  • a suitable payment app may be downloaded to the child's mobile device 402, as indicated at block 1702.
  • the child's mobile device 402 may be operated to access an app store.
  • the digitization support server computer 302 may provide a feature that may be accessed by prospective "target" mobile devices to download a suitable payment app.
  • the downloaded app is represented by block 404 in FIG. 4.
  • block 1704 may follow block 1702 or may be performed in conjunction with block 1702.
  • the child's mobile device 402 may be placed in proximity to the account holder's mobile device 406, and the mobile devices 402 and 406 may be placed in a condition to exchange short-range radio data communication messages with each other via, for example, NFC or Bluetooth.
  • the app 404 in the child's mobile device 402 may be in communication with the app 408 in the account holder's mobile device 406.
  • the payment app in the child's mobile device 402 may be placed in a condition or state such that it is prepared to receive participate in receipt of provisioning of a payment token.
  • block 1706 indicates that the account holder's mobile device 406 is or remains in communication with the digitization support server computer 302, e.g., via the app 408 in the account holder's mobile device 406.
  • the child's mobile device 402/app 404 may transmit the public encryption key for the app 404 to the account holder's mobile device 406 and the app 408 in the mobile device 406; it will be understood that the account holder's mobile device 406 and the app 408 may receive the transmission of the public encryption key for the app 404.
  • the account holder's mobile device 406/app 408 may relay/re-transmit the public encryption key for the app 404 to the digitization support server computer 302.
  • the digitization support server computer 302 encrypts— with the public encryption key for the app 40— the payment token to be provisioned to the child's mobile device 402, and as a result the payment token is placed in an encrypted form. In that form (perhaps with one or more additional layers of encryption) the digitization support server computer 302 may transmit the payment token to the account holder's mobile device 406/app 408. As indicated at block 1712 in FIG. 17, the account holder's mobile device 406/app 408 may receive the encrypted payment token from the digitization support server computer 302.
  • the account holder's mobile device 406/app 408 may lack the secret encryption key required to reverse the encryption implemented with the public encryption key for the app 404; consequently, the actual "in the clear" version of the payment token may not be accessible to the account holder's mobile device 406/app 408.
  • the account holder's mobile device 406/app 408 may relay (re-transmit) the encrypted payment token to the child's mobile device 402 app 404.
  • the child's mobile device 402 app 404 may decrypt the encrypted payment token and install the decrypted payment token in the app 404, thereby completing the provisioning of the payment token to the child's mobile device 402 via the account holder's mobile device 406. Consequently, the child's mobile device 402 is now payment-enabled and equipped to use the payment token for purchase transactions.
  • Block 1612 may follow block 1610.
  • Block 1612 is concerned with establishing rules that may govern or constrain the use of the payment token for payment transactions. Details of an embodiment of the processing at block 1612 will be described below in connection with FIGS. 18 and 19.
  • Block 1614 may follow block 1612 in the process of FIG. 16.
  • the digitization support server computer 302 may arrange that the payment token provisioned at 1610 to the child's mobile device 402 is stored in the token vault 210 (FIG. 2) in association with the relevant PAN (i.e., in association with the PAN that identifies the payment account of the account holder who is the user of the mobile device 406). Consequently, in payment transactions utilizing the payment token and the payment-enabled mobile device 402, the de-tokenization stage of the transaction will result in translation of the payment token to the relevant PAN.
  • the mobile device 406 communicated data (such as an encrypted payment token) to the mobile device 402 via NFC, Bluetooth, or the like.
  • data such as an encrypted payment token
  • transfer of data to the mobile device 402 may occur by the mobile device 406 displaying a barcode such as a QR code, and the mobile device scanning/reading the barcode.
  • FIG. 18 is a flow chart mat illustrates an example embodiment of the processing that may occur at block 1612 in FIG. 16.
  • the account holder may use his/her mobile device 406 to interact with the digitization support server computer
  • FIG. 19 is an example screen display that may be presented to the account holder to allow the account holder to provide input for defining a set of rules to constrain use of the payment token provisioned at block 1610. Reference will now be made to various portions of the example display illustrated in FIG. 19.
  • the account holder may set a maximum number of transactions ("swipes") for which the payment token may be used on any given day.
  • the account holder may set a maximum amount per transaction.
  • the account holder may indicate the mobile telephone number of a mobile device (e.g., for the account holder's mobile device 406) to receive alerts on occasions when the payment token is used or attempted to be used in violation of the applicable set of rules.
  • a mobile device e.g., for the account holder's mobile device 406
  • a maximum daily spend limit may be set by the account holder.
  • the account holder may set a maximum weekly spend limit
  • the account holder may set a maximum limit on the number of transactions per week.
  • the account holder may be allowed to define rules with an expiration date, i.e., rules that will be in effect starting at the present time, and then will expire and cease to be in effect on the expiration date.
  • block 1804 may follow or be associated with block 1802.
  • data indicative of the desired rules is transmitted from the account holder's mobile device 406 to the digitization support server computer 302.
  • the digitization support server computer 302 may receive the transmitted data regarding the account holder's definition of rules for use of the payment token.
  • Block 1808 may follow block 1806 in the process of FIG. 18.
  • the digitization support server computer 302 may cause a set of rules to be stored in accordance with the input provided by the account holder and in association with a data record relating to the payment token provisioned at block 1610.
  • rule definition versus token provisioning may be reversed.
  • FIG. 20 is a flow chart that illustrates an example process that may be performed in accordance with aspects of the present disclosure.
  • FIG. 20 is concerned with handling of a particular payment transaction for which a payment token (as provisioned to an employee/child/family member mobile device pursuant to FIG. 1 or 16) is to be used.
  • the processing depicted m FIG. 20 may be performed by or in association with the payment network 110a (FIG. 9) and/or the token service provider 204 (FIG.2). Without meaning to foreclose other possibilities, H will be assumed for the discussion of FIG. 2 that the processing is performed at the token service provider 204.
  • the processing depicted in FIG. 20 is concerned with administration/enforcement of the sort of rules established by processes like those depicted in FIGS. 14 and 18.
  • the token service provider 204 may receive a de-tokenization request with respect to a current transaction undertaken with the payment-enabled mobile device 306 or 402. It may be assumed that up to mat point, transaction processing has occurred generally in accordance with the transaction model illustrated in FIG. 1 and or in accordance with tokenization standards or specifications as referred to above.
  • Block 2004 may follow block 2002 in the process of FIG. 20.
  • the token service provider 204 may access a set of usage rules that has been stored with respect to the payment token for which it is now desired to obtain translation to a PAN.
  • Block 2006 may follow block 2004 in the process of FIG. 20.
  • the token service provider 204 may apply the rules accessed at 2004 to the transaction at hand. Then, at 2008, based on the rules, the token service provider 204 may determine whether, in accordance with the rules, the proposed transaction is permissible. (If so, it may be presumed that the transaction is completed, or at least de-tokenization is completed and a suitable transaction authorization request message is sent on for approval by the account issuer.)
  • the token service provider 204 may send an alert concerning the pending transaction to the account holder/account holder organization, as the case may be.
  • the token service provider may request the account holder/account holder organization to approve the pending transaction.
  • the request may take the form of a text message, in- app communication, etc.
  • the token service provider 204 (or payment network, as the case may be) may defer processing routing the transaction for a short time to give the individual who received a request an opportunity to respond.
  • the token service provider may cause the transaction to be declined. In some embodiments and/or in some situations, the token service provider 204 may cause a notice of the declined transaction to be sent to the account holder/account holder organization.
  • FIGS. 21-24 are simplified example mobile screen displays that may be provided to a parent payment account holder in accordance with aspects of the present disclosure. That is, the screen displays of FIGS. 21-24 may be relevant to the situations otherwise illustrated in FIGS. 4 and 6.
  • the screen display shown therein may provide the account holder of an overview listing of the payment tokens that have been provisioned in connection with the account holder's payment account
  • each of lines 2102, 2104, 2106 may identify a respective payment token associated with the PAN indicated at 2108.
  • the screen display of FIG. 21 may include a button 2110 which may be actuated by the account holder to initiate a token provisioning request.
  • a transaction history report is presented for a token identified at 2202.
  • Each of the line items 2204, 2206, 2208, 2210 and 2212 corresponds to a respective transaction, and indicates the time of the transaction, transaction amount and merchant It will be noted that the line items are grouped by day of transaction.
  • the screen display in FIG. 23 allows the account holder to take certain actions with respect to the payment token identified at 2302.
  • One of the actions is "freezing" a token (temporarily disabling the token from being used in transactions), and may be accomplished by interacting with a slide button display element at 2304.
  • Another action may be to temporarily increase the dairy spend limit for the token for the current day.
  • Data entry field 2306 allows entry of the increased amount of the daily spend limit, and actuation of the button 2308 causes the increased spend limit amount to be put into effect
  • the screen display shown therein may provide the account holder with a list of the rules mat the account holder has established for the payment token identified at 2402.
  • Global limits are listed in section 2404, including a daily spend limit shown at 2406 and a geographic limit shown at 2408.
  • Merchant-specific maximum transaction limits are presented in section 2410.
  • Section 2412 lists a merchant for which transactions are blocked.
  • the digitization support server computer 302 may cause a suitable flag to be stored with the payment network 110a (FIG. 9), the token service provider 204 (FIG. 2), or at another suitable point in the payment system to disenable de-tokenization for the payment token in question or in some other way to prevent consummation of further payment transactions using the payment token.
  • freezing blocking of use of the payment token may alternatively be applied via the app in the child/family member mobile device.
  • the account holder may initiate
  • the parent may have direct supervisory privileges over the payment app in the child family member mobile device so that the parent may directly provide input to the child family member mobile device to disable the payment app.
  • this may be done by specific amending of rules by the administrator/parent
  • the administrator may provide a suitable update to the digitization support server computer 302. This may result in a new pre-defined set of rules being put into effect with respect to the employee's payment token (to reflect the employee's new job status or classification) and or may cause the payment token to be linked to the PAN for a different department in place of the PAN to which the payment token was previously linked.
  • the payment app in the child family member mobile device may be operative to itself store and enforce rules regarding the use of the payment token provisioned to the child/family member mobile device.
  • the payment app in the child family member mobile device may be operative to itself store and enforce rules regarding the use of the payment token provisioned to the child/family member mobile device.
  • parent account holder may enter input indicative of desired rules into the parent's mobile device, and then the corresponding rule data may be transferred from the parent's mobile device to the app in the child family member mobile device by short- range radio communication or display and scan of a QR code.
  • the parent may be an additional/supervisory user of the child family member mobile device and may directly input desired transaction rules into the child/family member mobile device.
  • the app in the child/family member mobile device may enforce geo-location restrictions on use of the payment token in addition to usage rules expressly defined by the parent account holder for storage and self- enforcement in the child/family member mobile device.
  • peer-to-peer provisioning of a payment token may in some situations be applied in the context of an
  • the payment tokens has been primarily described in the context of in-store purchase transactions. However, the payment tokens may also be usable for e-commerce transactions, e.g., through operation of the payment app to which the payment token was provisioned.
  • the term "computer” should be understood to encompass a single computer or two or more computers in communication with each other.
  • processor should be understood to encompass a single processor or two or more processors in communication with each other.
  • memory should be understood to encompass a single memory or storage device or two or more memories or storage devices.
  • a "server” includes a computer device or system that responds to numerous requests for service from other devices.
  • the term "payment card system account” includes a credit card account, a deposit account that the account holder may access using a debit card, a prepaid card account, or any other type of account from which payment transactions may be consummated.
  • the terms “payment card system account” and “payment card account” and “payment account” are used interchangeably herein.
  • the term “payment card account number” includes a number that identifies a payment card system account or a number carried by a payment card, or a number that is used to route a transaction in a payment system that handles debit card and/or credit card transactions.
  • the term “payment card” includes a credit card, debit card, prepaid card, or other type of payment instrument, whether an actual physical card or virtual.
  • the term "payment system” refers to a system for handling purchase transactions and related transactions.
  • An example of such a system is the one operated by MasterCard International
  • the term "payment system” may be limited to systems in which member financial institutions issue payment accounts to individuals, businesses and/or other organizations.
  • a method includes receiving a message from an organization.
  • the message identifies (a) an individual who is a member of the organization; and (b) a mobile device used by the identified individual.
  • the method further includes provisioning a payment token to the identified mobile device, and associating the payment token with a PAN (primary account number) assigned to the organization.
  • the received message may identify a department of the organization.
  • the identified individual may be a member of the identified department
  • the PAN may be assigned to the identified department
  • the organization may be a corporation or a not-for-profit entity.
  • the method may further include receiving a request for a payment transaction based on the payment token.
  • the method may further include applying a usage rule to the request The usage rule may have been established with respect to the payment token.
  • the method may further include performing detokenization with respect to the request
  • the mobile device may be identified by a mobile telephone number assigned to the mobile device.
  • the mobile device may be a smartphone.
  • a method may include identifying a plurality of employees of an organization. Each of the employees may carry a respective mobile device. The method further includes provisioning a respective payment token to each of the mobile devices. All of the payment tokens may be associated with a PAN (primary account number) assigned to the organization. The method may further include storing a respective set of usage rules in association with a respective data record that corresponds to each of the payment tokens. The respective set of usage rules may be for governing use of the payment token in question in connection with payment transaction. At least one of the sets of usage rules is different from at least one other of the sets of usage rules. The plurality of employees may include at least 100 employees. The organization may be a corporation.
  • an apparatus includes a processor and a memory in communication with the processor.
  • the memory stores program instructions.
  • the processor is operative with the program instructions to perform certain functions, the functions may include receiving a message from an
  • a method includes communicating with a remote server computer via a first mobile device to receive in the first mobile device a payment token associated with a PAN (primary account number) that identities a payment account owned by a user of the first mobile device.
  • the method further includes provisioning the payment token from the first mobile device to a second mobile device in proximity to the first mobile device.
  • the provisioning step includes transfer of data from the first mobile device to the second mobile device.
  • the transfer of data may occur by the second mobile device scanning a bar code displayed on the first mobile device.
  • the bar code may be a QR code.
  • the transfer of data may alternatively be via short-range radio data communications between the first mobile device and the second mobile device.
  • the payment token may be provisioned to an application program running on the second mobile device.
  • the method may further include receiving a public encryption key by the first mobile device from the application program running on the second mobile device.
  • the public encryption key may be digitally signed by the application program running on the second mobile device to prevent tampering with the public encryption key.
  • the method also may include relaying the public encryption key in a message to the remote server computer via the first mobile device.
  • the message is digitally signed by the first mobile device to prevent tampering with the message.
  • the payment token— as received in the first mobile device, is in an encrypted form resulting from encryption of the payment token using the public encryption key.
  • the first mobile device may transfer the payment token in encrypted form to the second mobile device.
  • the first and second mobile devices may be smaitphones.
  • a method includes providing a first mobile device.
  • the first mobile device runs an application program for supervising usage of a payment token mat has been provisioned to a second mobile device.
  • the second mobile device is different from the first mobile device.
  • the method also includes operating the first mobile device to block usage of the payment token.
  • the operation of the first mobile device to block usage of the payment token may include operating the application program to interact with a remote server computer.
  • the interaction with the remote server computer may include causing data to be stored in the remote server computer to indicate that the payment token is blocked.
  • the remote server computer may be operated by a token service provider or a payment network operator.
  • the operation of the first mobile device to block usage of the payment token may include bringing the second mobile device into proximity to the first mobile device and transmitting a communication from the first mobile device to the second mobile device.
  • the communication may cause the second mobile device to be disabled from using the payment token for payment transactions.
  • the communication from the first mobile device to the second mobile device may include the first mobile device displaying a bar code and the second mobile device scanning the displayed barcode.
  • the bar code may be a QR code.
  • the communication from the first mobile device to the second mobile device may be via short range radio transmission between the first and second mobile devices.
  • a mobile device may include a processor and a memory in communication with the processor.
  • the memory may store program instructions.
  • the processor may be operative with the program instructions to perform certain functions.
  • the functions may include communicating with a remote server computer to receive a payment token in the first mobile device.
  • the payment token may be associated with a PAN (primary account number) that identifies a payment account owned by a user of the first mobile device.
  • the functions may also include provisioning the payment token to another mobile device.
  • the provisioning function may include transfer of data to the second mobile device.
  • the transfer of data may occur by the other mobile device scanning a bar code.
  • the bar code may be a QRcode.
  • the transfer of data may be via short-range radio data communications to the other mobile device.
  • a method includes operating a first mobile device to define at least one rule.
  • the rule(s) is(are) for constraining use of a payment token in payment transactions.
  • the payment token is for being provisioned to a second mobile device that is different from the first mobile device.
  • the method further includes transmitting the rule(s) from the first mobile device to a remote server computer.
  • the rule(s) is(are) defined by interaction with an application program that runs on the first mobile device.
  • the rule(s) may alternatively be defined by interacting with the remote server computer via a browser program that runs on the first mobile device.
  • the remote server computer may be operated by a token service provider or a payment network operator.
  • the rule(s) may (a) define a list of merchants with which the payment token can be used, and (b) forbid use of the payment token with all merchants not included in the list of merchants defined at (a).
  • the rule(s) may define a maximum transaction amount applicable to at least some payment transactions for which the payment token is used.
  • Hie rule(s) may include one or more of the following: (a) a rule that lists one or more postal codes and/or one or more telephone area codes in which the payment token is allowed to be used; (b) a rule that specifies a central point and also specifies a distance radius from the central point to define a geographic area in which the payment token is allowed to be used; (c) a rule that defines at least one of a maximum frequency of transactions at a given merchant and a maximum frequency of transactions with a given category of merchants; and (d) a rule that defines a maximum amount per transaction at a given merchant or with a given category of merchants.
  • the payment token may be associated with a PAN (primary account number.
  • the PAN may identify a payment account that belongs to a user of the first mobile device.
  • the payment token may be associated with a PAN that identifies a payment account that belongs to an organization.
  • the organization may have the user of the second mobile device as a member of the organization.
  • a method includes operating a computing device to define at least one rule.
  • the rule(s) may be for constraining use of a payment token in payment transactions.
  • the payment token is for being provisioned to a mobile device.
  • the payment token is associated with a PAN (primary account number).
  • the PAN identifies a payment account that belongs to an organization.
  • the organization has a user of the mobile device as a member of the organization.
  • the method also includes transmitting the rule(s) from the computing device to a remote server computer.
  • the organization may be a corporation or a department of a corporation.
  • the rule(s) may be defined by interacting with the remote server computer via a browser program that runs on the computer device.
  • the rule(s) may indicate at least one category of merchants with which the payment token may be used.
  • the rule(s) may define a maximum transaction amount applicable to at least some payment transactions for which the payment token is used.
  • a mobile device includes a processor and a memory in communication with the processor.
  • the memory stores program instructions.
  • the processor is operative with the program instructions to perform certain functions.
  • the functions include defining at least one rule.
  • the rule(s) may be for constraining use of a payment token in payment transactions.
  • the payment token is for being provisioned to another mobile device different from the first mobile device.
  • the functions also include transmitting the rule(s) from the mobile device to a remote server computer.
  • the rule(s) may be defined by interaction of a user with an application program that runs on the first mobile device. Alternatively, the rule(s) may be defined by interacting with the remote server computer via a browser program that runs on the mobile device.
  • the remote server computer may be operated by a token service provider.
  • a method includes storing transaction data relating to a plurality of payment transactions. All of the payment transactions may have been performed using a (the same) payment token.
  • the payment token had been provisioned to a first mobile device.
  • the method further includes downloading the stored transaction data to a second mobile device.
  • the second mobile device is owned by an account holder.
  • the account holder had been issued a payment account identified by a PAN (primary account number).
  • the payment token in question had been associated with the PAN.
  • the payment transaction may have been performed using the first mobile device.
  • the first and second mobile devices may be smartphones.
  • the transaction data may be stored in and downloaded from a computer that is remote from the first mobile device.
  • the server computer may be operated by a token service provider.
  • the method may further include receiving a request from the second mobile device, and the downloading step may be performed in response to the request from the second mobile device.
  • a method includes receiving a request for a payment transaction.
  • the request indicates a payment token to be used for the payment transaction.
  • the payment transaction is initiated by a first mobile device to which the payment token was previously provisioned.
  • the method also includes transmitting an alert concerning the payment transaction to a second mobile device mat is different from the first mobile device.
  • the second mobile device is used by an account holder.
  • the account holder had been issued a payment account identified by a PAN (primary account number), the payment token had been associated with the PAN.
  • the method may further include deferring completion of the payment transaction pending approval of the transaction by the account holder.
  • the method may further include requesting the account holder to approve the transaction.
  • the method may further include receiving an indication from the account holder that the account holder approves the transaction.
  • the indication that the account holder approves the transaction may be received via a message transmitted from the second mobile device.
  • the request for the payment transaction may be received by, and the alert transmitted from, a server computer that is remote from the first and second mobile devices.
  • the message transmitted from the second mobile device is received by the server computer.
  • the first and second mobile devices may be smartphones.
  • an apparatus includes a processor and a memory in communication with the processor.
  • the memory stores program instructions.
  • the processor is operative with the program instructions to perform certain functions.
  • the functions may include storing transaction data relating to a plurality of payment transactions. All of the payment transactions may have been performed using a (the same) payment token.
  • the payment token had been provisioned to a first mobile device.
  • the functions may also include downloading the stored transaction data to a second mobile device.
  • the second mobile device is owned by an account holder.
  • the account holder had been issued a payment account
  • the payment account is identified by a PAN (primary account number).
  • the payment token had been associated with the PAN.
  • the payment transaction may have been performed using the first mobile device.
  • the first and second mobile devices may be smartphones.
  • the processor and memory may be components of a server computer that is remote from the first mobile device.
  • the server computer may be operated by a token service provider.
  • the processor may perform the further function of receiving a request from

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Health & Medical Sciences (AREA)
  • Child & Adolescent Psychology (AREA)
  • General Health & Medical Sciences (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Un message est reçu d'une organisation. Le message identifie un individu qui est un membre de l'organisation et un dispositif mobile utilisé par l'individu identifié. Un jeton de paiement est fourni au dispositif mobile identifié. Le jeton de paiement est associé à un numéro de compte primaire (PAN) attribué à l'organisation.
PCT/US2017/025840 2016-04-13 2017-04-04 Système et procédé pour fournir des cartes d'entreprise d'employés basées sur des jetons WO2017180360A1 (fr)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US15/097,816 US11823161B2 (en) 2016-04-13 2016-04-13 System and method for peer-to-peer assistance in provisioning payment tokens to mobile devices
US15/097,705 2016-04-13
US15/097,775 2016-04-13
US15/097,816 2016-04-13
US15/097,856 US20170300907A1 (en) 2016-04-13 2016-04-13 System and method for providing token based employee corporate cards
US15/097,705 US20170300906A1 (en) 2016-04-13 2016-04-13 System and method for setting authorization and payment rules regarding usage of payment tokens
US15/097,856 2016-04-13
US15/097,775 US20170300894A1 (en) 2016-04-13 2016-04-13 System and method for providing reports on usage of payment token

Publications (1)

Publication Number Publication Date
WO2017180360A1 true WO2017180360A1 (fr) 2017-10-19

Family

ID=58579277

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/025840 WO2017180360A1 (fr) 2016-04-13 2017-04-04 Système et procédé pour fournir des cartes d'entreprise d'employés basées sur des jetons

Country Status (1)

Country Link
WO (1) WO2017180360A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019108303A1 (fr) * 2017-11-29 2019-06-06 Mastercard International Incorporated Systèmes et procédés de génération de jetons lors de transactions
EP3956848A4 (fr) * 2019-04-17 2023-01-11 Capital One Services, LLC Systèmes et procédés de traitement en temps réel

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130110658A1 (en) * 2011-05-05 2013-05-02 Transaction Network Services, Inc. Systems and methods for enabling mobile payments
WO2015179649A1 (fr) * 2014-05-21 2015-11-26 Mastercard International Incorporated Procédés de gestion du cycle de vie de jetons de paiement sur un dispositif mobile

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130110658A1 (en) * 2011-05-05 2013-05-02 Transaction Network Services, Inc. Systems and methods for enabling mobile payments
WO2015179649A1 (fr) * 2014-05-21 2015-11-26 Mastercard International Incorporated Procédés de gestion du cycle de vie de jetons de paiement sur un dispositif mobile

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019108303A1 (fr) * 2017-11-29 2019-06-06 Mastercard International Incorporated Systèmes et procédés de génération de jetons lors de transactions
EP3956848A4 (fr) * 2019-04-17 2023-01-11 Capital One Services, LLC Systèmes et procédés de traitement en temps réel

Similar Documents

Publication Publication Date Title
US20230368173A1 (en) System and method for peer-to-peer assistance in provisioning payment tokens to mobile devices
US11972433B2 (en) System and method for provisioning payment token to payment accessory device
US11379818B2 (en) Systems and methods for payment management for supporting mobile payments
US20220270078A1 (en) Method and system for reloading prepaid card
US20180225666A1 (en) Methods and systems for providing an entity with the ability to control behaviors and capabilities of the entity's accounts and/or account transactions on a per-user basis
US20170300906A1 (en) System and method for setting authorization and payment rules regarding usage of payment tokens
US20170300894A1 (en) System and method for providing reports on usage of payment token
US20150348006A1 (en) Smart wallet
US20120179558A1 (en) System and Method for Enhancing Electronic Transactions
US20130080275A1 (en) Transaction device and processing system
US20130080272A1 (en) Transaction device and processing system
US20170300907A1 (en) System and method for providing token based employee corporate cards
KR20140051640A (ko) 휴대 단말에서의 결제 수행 방법 및 장치와 그 방법에 대한 프로그램 소스를 저장한 기록 매체
US11386413B2 (en) Device-based transaction authorization
US12118521B2 (en) Real-time transaction and receipt processing systems
US11514437B1 (en) Encapsulation of payment accounts with tokenization
US11908004B2 (en) Method and system for obtaining credit
CA3133106C (fr) Systemes et procedes de traitement en temps reel
US20130080271A1 (en) Transaction device and processing system
US20130080270A1 (en) Transaction device and processing system
CA2912066C (fr) Systeme et methode de recharge de cartes prepayees
KR20180089330A (ko) 가상결제정보를 이용한 비대면 거래 및 정산 방법, 관리 서버
WO2017180360A1 (fr) Système et procédé pour fournir des cartes d'entreprise d'employés basées sur des jetons
US11568408B1 (en) Apparatus and method for processing virtual credit cards for digital identities
US11636468B1 (en) Encapsulation of payment accounts with nested tokens

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17718657

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17718657

Country of ref document: EP

Kind code of ref document: A1