System and method for issuer-specified domain control on payment instruments

Abstract

The present application discloses a system and method for issuer-specified domain control on a payment instrument. In one embodiment, in an information processing device including at least one computer processor, a method for issuer-specified domain control on a payment instrument may include: (1) receiving an identification of a domain control or restriction on a payment token for the financial instrument from an issuer of the financial instrument, the domain control or restriction to be applied by the issuer; (2) requesting generation of a payment token with a pass indicator from a token service provider; (3) receiving the payment token from the token service provider; and (4) storing an association of the domain control or restriction with the payment token.

Description

[0001] Related Applications

[0002] This application claims the benefit of U.S. Provisional Patent Application Serial No. 62 / 630,505, filed on February 14, 2018, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure generally relates to systems and methods for issuer-specified domain control on payment instruments. Background Art

[0004] Token service providers such as Visa often include domain restrictions or controls on the tokens they generate to reduce or eliminate fraud. For example, tokens supplied for Apple Pay may be limited to Apple Pay-enabled devices. As another example, a token supplied for one merchant may not be used with another merchant. However, a financial instrument issuer may wish to specify which domain restrictions or controls, if any, are used when requesting a token from a token provider. For example, an issuer may not want a payment network to use any domain restrictions or controls on a transaction, but may apply its own restrictions or controls to the transaction. Summary of the invention

[0005] A system and method for issuer-specified domain control on a payment instrument is disclosed. In one embodiment, in an information processing device including at least one computer processor, a method for issuer-specified domain control on a payment instrument may include: (1) receiving, from an issuer of the financial instrument, an identification of a domain control or restriction on a payment token for the financial instrument, the domain control or restriction to be applied by the issuer; (2) requesting generation of a payment token with a pass indicator from a token service provider; (3) receiving the payment token from the token service provider; and (4) storing an association of the domain control or restriction with the payment token.

[0006] In one embodiment, the pass indicator may include a bank identification number, cryptographic parameters for a payment token, or the like.

[0007] In one embodiment, the token service provider may not be associated with a payment network.

[0008] In one embodiment, domain controls or restrictions may be applied by the publisher.

[0009] In one embodiment, domain controls or restrictions may be dynamic.

[0010] In one embodiment, domain controls or restrictions may control the use of payment tokens in specific environments, at specific times, in specific geographic areas, or at specific authentication levels with specific merchants, on specific devices.

[0011] In another embodiment, in an information processing device including at least one computer processor, a method for processing a transaction using issuer-specified domain controls may include: (1) receiving a transaction including a payment token from a payment network, the payment token including a pass indicator; (2) retrieving domain controls or restrictions associated with the payment token; and (3) applying the controls or restrictions to the transaction.

[0012] In one embodiment, the pass indicator may be a bank identification number, a cryptographic parameter for a payment token, or the like.

[0013] In one embodiment, domain controls or restrictions may control the use of payment tokens in specific environments, at specific times, in specific geographic areas, or at specific authentication levels with specific merchants, specific devices.

[0014] In one embodiment, domain controls or restrictions may be dynamic.

[0015] In one embodiment, domain controls or restrictions may be stored in a database.

[0016] In one embodiment, the method may further include updating the domain controls or restrictions stored in the database.

[0017] In one embodiment, the payment network may apply payment network-level domain controls or restrictions on transactions.

[0018] According to another embodiment, a system for processing transactions using issuer-specified domain controls may include an issuer of a financial instrument system; a payment network; and a token service provider system. The payment network may receive a transaction including a payment token including a pass indicator and may pass the transaction to the issuer. The issuer system may receive domain controls or restrictions associated with the payment token and may apply the controls or restrictions to the transaction.

[0019] In one embodiment, the pass indicator may be a bank identification number, a cryptographic parameter for a payment token, or the like.

[0020] In one embodiment, domain controls or restrictions may control the use of payment tokens in specific environments, at specific times, in specific geographic areas, or at specific authentication levels with specific merchants, on specific devices.

[0021] In one embodiment, the payment network may apply payment network-level domain controls or restrictions to the transaction before passing the transaction to the issuer. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] For a more complete understanding of the present invention, its objects and advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:

[0023] Figure 1 Describing a system for issuer-specified domain control on a payment instrument according to one embodiment;

[0024] Figure 2 Describes a method for token creation with issuer-specified domain control according to one embodiment; and

[0025] Figure 3 A method for processing transactions using issuer-specified domain controls according to one embodiment is depicted. DETAILED DESCRIPTION

[0026] Embodiments are directed to systems and methods for issuer-specified domain control on payment instruments.

[0027] In an embodiment, as part of the token request process, a financial instrument issuer may specify controls or restrictions, if any, on a token, such as a payment token. A token service provider may then generate and / or issue a token based on the token request. In an embodiment, a token service provider may associate controls or restrictions, or lack thereof, on a token based on a bank identification number, or BIN, for the token. Thus, when a transaction is conducted using the token, the payment network may enforce the restriction(s) or control(s) associated with the BIN.

[0028] In another embodiment, the token service provider may associate the restrictions or controls (if any) with the token, and may store the association in the token service provider's token repository. Thus, when a transaction is conducted using the token, the payment network may retrieve the control(s) or restriction(s) (if any) from the token service provider's token repository and enforce the retrieved restriction(s) or control(s).

[0029] In another embodiment, tokens generated by a third party may be used. Because these tokens are not generated by the token service provider, the payment network may ignore the tokens and allow the tokens to pass through the payment network to the issuer without implementing any controls or restrictions.

[0030] In another embodiment, a unique password may be used to identify a restriction or control. For example, a unique password may be attached to or associated with a token and may identify or reference one or more controls or restrictions associated with the token. Any suitable password may be used. Examples of passwords that may be used are provided in U.S. Patent Application Serial No. 62 / 552,506, the disclosure of which is incorporated herein by reference in its entirety.

[0031] In embodiments, combinations of any of the above may be used as needed and / or desired.

[0032] In one embodiment, once the token is passed to the issuer through the payment network, the issuer can impose its own controls or restrictions on the token, which can be based on any of the above techniques or any other techniques as needed and / or desired. Additional techniques can also be used as needed and / or desired, such as internally mapping the token to one or more controls or restrictions.

[0033] In one embodiment, both the payment network and the issuer can apply controls or limits. For example, the payment network can apply coarse-grained controls or limits (e.g., verifying that a token provisioned for Apple Pay is received from an Apple Pay-enabled device), and the issuer can apply fine-grained controls or limits (e.g., only allowing transactions up to a certain amount).

[0034] Reference Figure 1 According to one embodiment, a system for issuer-specified domain control on payment instruments is disclosed. System 100 may include an issuer 110 that may issue financial instruments (e.g., credit cards, debit cards, etc.) to a customer 170. Issuer 110 may be a financial institution, a financial technology service provider, etc.

[0035] The issuer 110 may receive transactions from merchants 160 via acquirers 150 and payment networks 130. The issuer 110 may further interact with a token service provider 120, which may manage payment tokens and store the tokens in a TSP token repository 125. In one embodiment, the token service provider 120 may be affiliated with the payment network 130, such that the payment network 130 may take one or more actions (such as enforcing controls or restrictions) based on tokens issued or managed by the token service provider 120.

[0036] The issuer 110 may also interact with a third-party token provider 140. The third-party token provider 140 may provide tokens to the issuer 110 and may store its tokens in a third-party token vault 145. In one embodiment, the payment network 130 and the third-party token vault may not have any association; therefore, the actions that the payment network 130 may take on the tokens of the third-party token provider 140 may be limited or non-existent.

[0037] In one embodiment, a combination lockbox (not shown) may be used to generate the combination locally at merchant 160. Examples of combination lockbox systems and methods are disclosed in US Patent Application Publication No. 62 / 680,674, the disclosure of which is incorporated herein by reference in its entirety.

[0038] The password lockbox can generate a password or other parameters that can be used to indicate domain controls or restrictions. In one embodiment, the owner of the lockbox (e.g., issuer 110) can modify the parameters directly or remotely to change the way domain controls or restrictions are applied.

[0039] In one embodiment, the issuer 110 may host a controls / restrictions database 112, which may store associations between tokens and controls or restrictions to be applied by the issuer 110. The issuer 110 may further host an issuer token repository 114, which may store associations between tokens and related financial instruments.

[0040] In one embodiment, two or more of the issuer token repository 114, the TSP token repository 125, and the third party token repository 145 may be synchronized. Examples of systems and methods for synchronizing two or more of these token repositories are disclosed in U.S. Patent Application Serial No. 16 / 010,766, U.S. Provisional Patent Application Serial No. 62 / 556,530, and U.S. Patent Application Serial No. 16 / 126,201, the disclosure of each of which is incorporated herein by reference in its entirety.

[0041] Reference Figure 2 , according to one embodiment, a method for token creation with issuer-specified domain controls is disclosed. In step 205, the issuer may identify controls or restrictions to be placed on the token. In one embodiment, the controls or restrictions may be domain restrictions that may prevent the token from being used with certain merchants, certain devices (e.g., smartphones, no ATMs, etc.), in certain environments (e.g., online only, in-person only, etc.), at certain times, in certain geographic areas, at certain authentication levels, below certain quantities, token usage speeds (e.g., limited number of uses), etc. In one embodiment, the controls or restrictions may be dynamic because they may vary and change over time.

[0042] The issuer may have controls or restrictions applied by the payment network, or may have the payment network pass the transaction to the issuer in step 210. If the payment network is to apply controls or restrictions, the issuer may provide the controls or restrictions to the token service provider in step 215. In one embodiment, the issuer may provide a bank identification number (BIN) or BIN range for the token that may indicate this.

[0043] In another embodiment, the issuer may identify a flag, indicator, field, cryptographic parameter, etc. that may be included in or associated with the token to indicate that the payment network is to apply controls or restrictions.

[0044] In one embodiment, rules may be provided for cryptographic enforcement of tokens, such as how long a password is valid, how many times a password may be used, whether a password is required, etc. In one embodiment, the rules may be managed by a token service provider and / or issuer, and may be enforced by a payment network and / or issuer.

[0045] The token service provider may generate a token with controls or restrictions in step 220. In one embodiment, the token may be generated by generating a unique 15-digit number with a specified BIN (ie, the first six digits) and calculating a check digit for the sixteenth digit.

[0046] In step 225, the token service provider may store the token with the controls or restrictions in a token repository of the token service provider.

[0047] If the payment network is to pass transactions involving the token to the issuer without applying controls or restrictions in step 210, the issuer may request the token service provider to generate a token in step 230. The issuer may provide an indication to the token service provider that the payment network will pass transactions to the issuer without applying controls or restrictions. In one embodiment, the issuer may provide a BIN or BIN range for the token that may indicate this.

[0048] In another embodiment, the issuer may identify a flag, indicator, field, cryptographic parameter, etc. that may be included in or associated with the token that indicates that the payment network will pass the transaction to the issuer without applying controls or restrictions.

[0049] In one embodiment, rules may be provided for cryptographic enforcement of tokens, such as how long a password is valid, how many times a password may be used, whether a password is required, etc. In one embodiment, the rules may be managed by a token service provider and / or issuer, and may be enforced by a payment network and / or issuer.

[0050] In step 235, the token service provider may generate a token with a specified BIN, as described above, and may return the token to the issuer. In one embodiment, the token service provider may generate a token with an indication that the payment network will pass the transaction to the issuer without action by the payment network. In another embodiment, the BIN may indicate that the token will be passed to the issuer without action by the payment network.

[0051] In one embodiment, instead of a token service provider, a third-party token provider can generate tokens for the issuer and can return the tokens to the issuer. In one embodiment, the third-party token provider can store the tokens and cross-references to real account numbers in its token library. The third-party token provider can also manage (one or more) controls or restrictions and can return decisions to the issuing system.

[0052] A third party token provider may perform any desired combination of these and other functions.

[0053] In step 240, the issuer may associate the token with the control or restriction and may store the association in a database.

[0054] In step 245, the issuer may add, modify, or delete controls or restrictions for the token. For example, the controls or restrictions may be dynamic because the issuer may enable, disable, add, delete, or modify the controls or restrictions as needed and / or desired. In one embodiment, the controls or restrictions may be updated in a database.

[0055] Reference Figure 3 , according to one embodiment, a method for processing transactions using issuer-specified domain controls is disclosed.

[0056] In step 305, a transaction between a merchant and a customer may be received at a payment network via an acquirer. In one embodiment, the transaction may include a token.

[0057] In step 310, the payment network may identify any restrictions or controls on the use of the token. In one embodiment, the payment network may identify these controls or restrictions based on the BIN, based on a password, based on an indicator in the token, a field in or associated with the token, a combination thereof, or the like.

[0058] In one embodiment, the payment network may retrieve the controls or limits from the token repository.

[0059] In one embodiment, an indicator in or associated with the token (e.g., a BIN, password, indicator, field, etc.) may specify that the payment network is to pass the transaction to the issuer without applying any controls or restrictions.

[0060] In step 315 , if controls or limits are to be applied by the payment network, then in step 320 , the payment network may apply the controls or limits to the transaction.

[0061] In step 325 , if the controls or limits are not applied by the payment network, then in step 325 , the payment network may pass the transaction to the issuer without applying the controls or limits to the transaction.

[0062] In step 330, the issuer may retrieve controls or restrictions for the token. In one embodiment, the issuer may retrieve the controls or restrictions from a database, or may retrieve the controls or restrictions associated with the BIN.

[0063] In step 335, the issuer may apply the retrieved controls or restrictions to the transaction, and the transaction may be approved or denied.

[0064] It should be appreciated that the embodiments disclosed herein are not mutually exclusive; features and elements of one embodiment may be used with other embodiments as needed and / or desired.

[0065] In the following, general aspects of embodiments of the systems and methods of the present invention will be described.

[0066] For example, the system of the present invention or a portion of the system of the present invention may be in the form of a "processing machine" such as a general-purpose computer. As used herein, the term "processing machine" should be understood to include at least one processor using at least one memory. The at least one memory stores an instruction set. The instructions may be permanently or temporarily stored in one or more memories of the processing machine. The processor executes the instructions stored in the one or more memories to process data. The instruction set may include various instructions for performing one or more specific tasks such as those described above. Such an instruction set for performing a specific task may be characterized as a program, a software program, or simply as software.

[0067] In one embodiment, the processing machine may be a special purpose processor.

[0068] As described above, the processing machine executes instructions stored in one or more memories to process data. For example, the processing of the data may be in response to commands of one or more users of the processing machine, in response to previous processing, in response to a request from another processing machine, and / or any other input.

[0069] As described above, the processor used to implement the present invention can be a general-purpose computer. However, the processor can also utilize any of a variety of other technologies, including a special-purpose computer, a computer system including, for example, a microcomputer, a minicomputer or a mainframe, a programmed microprocessor, a microcontroller, a peripheral integrated circuit component, a CSIC (customer-specific integrated circuit) or an ASIC (application-specific integrated circuit) or other integrated circuit, a logic circuit, a digital signal processor, a programmable logic device (such as an FPGA, PLD, PLA or PAL), or any other device or arrangement of devices capable of implementing the steps of the process of the present invention.

[0070] The processor used to implement the present invention can utilize a suitable operating system. Thus, embodiments of the present invention may include operating systems running iOS operating systems, OS X operating systems, Android operating systems, Microsoft Windows TM Operating system, Unix operating system, Linux operating system, Xenix operating system, IBM AIX TM Operating system, Hewlett-Packard UX TM Operating system, Novell Netware TM Operating system, Sun Microsystems Solaris TM Operating system, OS / 2 TM Operating system, BeOS TM Operating system, Macintosh operating system, Apache operating system, OpenStep TM Operating system or other operating system or platform processor.

[0071] It should be understood that in order to practice the method of the present invention as described above, the processor and / or memory of the processing machine do not have to be physically located in the same geographical location. That is, each of the processor and memory used by the processing machine can be located in geographically different locations and connected to communicate in any suitable manner. In addition, it should be understood that each of the processor and / or memory can be composed of different physical equipment pieces. Therefore, it is not necessary that the processor is a single equipment piece in one location and the memory is another single equipment piece in another location. That is, it is expected that the processor can be two equipment pieces located in two different physical locations. Two different equipment pieces can be connected in any suitable manner. In addition, the memory can include two or more parts of the memory in two or more physical locations.

[0072] For further explanation, as described above, processing is performed by various components and various memories. However, it should be understood that according to another embodiment of the present invention, as described above, processing performed by two different components can be performed by a single component. In addition, as described above, processing performed by a different component can be performed by two different components. In a similar manner, according to another embodiment of the present invention, as described above, memory storage performed by two different memory portions can be performed by a single memory portion. In addition, as described above, memory storage performed by a different memory portion can be performed by two memory portions.

[0073] In addition, various techniques may be used to provide communication between various processors and / or memories, as well as to allow the processor and / or memory of the present invention to communicate with any other entity; for example, to obtain more instructions or to access and use remote memory storage. For example, such techniques for providing such communication may include a network, the Internet, an intranet, an extranet, a local area network, an Ethernet, wireless communication via a cellular tower or satellite, or any client server system that provides communication. For example, such communication techniques may use any suitable protocol such as TCP / IP, UDP, or OSI.

[0074] As described above, instruction sets may be used in the processing of the present invention. The instruction set may be in the form of a program or software. The software may be in the form of system software or application software, for example. For example, the software may also take the form of a collection of separate programs, a program module in a larger program, or a portion of a program module. The software used may also include modular programming in the form of object-oriented programming. The software tells the processor how to handle the data being processed.

[0075] In addition, it should be understood that the instructions or instruction sets used in the embodiments and operations of the present invention may be in a suitable form that allows a processing machine to read the instructions. For example, the instructions forming the program may be in the form of a suitable programming language that is converted into a machine language or object code to allow one or more processors to read the instructions. That is, a compiler, assembler, or interpreter is used to convert written lines of programming code or source code in a particular programming language into machine language. Machine language is a binary-coded machine instruction that is dedicated to a particular type of processing machine, such as a particular type of computer. A computer understands machine language.

[0076] According to various embodiments of the present invention, any suitable programming language may be used. Illustratively, the programming language used may include, for example, assembly language, Ada, APL, Basic, C, C++, COBOL, dBase, Forth, Fortran, Java, Modula-2, Pascal, Prolog, REXX, Visual Basic, and / or JavaScript. In addition, it is not necessary to utilize a single type of instruction or a single programming language in conjunction with the operation of the system and method of the present invention. Instead, any number of different programming languages ​​may be used as needed and / or desired.

[0077] Likewise, the instructions and / or data used in the practice of the present invention may utilize any compression or encryption techniques or algorithms as needed. An encryption module may be used to encrypt data. In addition, for example, a suitable decryption module may be used to decrypt files or other data.

[0078] As described above, the present invention can be illustratively embodied in the form of a processor including, for example, a computer or a computer system, which includes at least one memory. It should be understood that, as required, the instruction set (i.e., software, for example) that enables the computer operating system to perform the above operations can be included in any of a variety of one or more media. In addition, the data processed by the instruction set can also be included in any of a variety of one or more media. That is, for example, the specific medium (i.e., the memory in the processor) for maintaining the instruction set and / or data used in the present invention can take any of a variety of physical forms or transmissions. Illustratively, the medium can be paper, paper transparency, optical disc, DVD, integrated circuit, hard disk, floppy disk, optical disc, tape, RAM, ROM, PROM, EPROM, wire, cable, optical fiber, communication channel, satellite transmission, memory card, SIM card or other remote transmission and any other medium or data source that can be read by the processor of the present invention.

[0079] In addition, the one or more memories used in the processing machine implementing the present invention can be any of a variety of forms to allow the memory to hold instructions, data or other information as needed. Therefore, the memory can take the form of a database to hold data. For example, the database can use any desired file arrangement such as a flat file arrangement or a relational database arrangement.

[0080] In the system and method of the present invention, various "user interfaces" can be utilized to allow the user to interact with one or more processors for implementing the present invention. As used herein, a user interface includes any hardware, software, or a combination of hardware and software that allows the user to interact with the processor. The user interface can be, for example, in the form of a dialogue screen. The user interface can also include any one of a mouse, a touch screen, a keyboard, a keypad, a voice reader, a voice recognizer, a dialogue screen, a menu box, a list, a check box, a toggle switch, a button, or any other device that allows the user to receive information about the operation of the processor when the processor processes an instruction set and / or provides information to the processor. Therefore, a user interface is any device that provides communication between a user and a processor. The information that the user provides to the processor through the user interface can be, for example, a form of command, data selection, or some other input.

[0081] As mentioned above, the processing machine utilizes the user interface to execute the instruction set so that the processing machine processes data for the user. The user interface is usually used by the processing machine to interact with the user to convey information or receive information from the user. But, it should be understood that according to some embodiments of the system and method of the present invention, the human user does not actually have to interact with the user interface used by the processing machine of the present invention. On the contrary, it can also be expected that the user interface of the present invention can interact with another processing machine rather than the human user, that is, convey and receive information. Therefore, another processing machine can be characterized as a user. In addition, it can be expected that the user interface used in the system and method of the present invention can partially interact with another or more processing machines, and also partially interact with the human user.

[0082] Those skilled in the art will readily appreciate that the present invention is susceptible to widespread use and application. Without departing from the spirit or scope of the present invention, many embodiments and adaptations of the present invention other than those described herein and many variations, modifications and equivalent arrangements will be apparent or reasonably suggested by the present invention and its preceding description.

[0083] Therefore, although the present invention has been described in detail with respect to exemplary embodiments of the present invention, it should be understood that the present disclosure is only an illustrative and exemplary disclosure of the present invention, and is provided to provide a feasible disclosure of the present invention. Therefore, the foregoing disclosure is not intended to restrict or limit the present invention, or to exclude any other such embodiments, adaptations, variations, modifications or equivalent arrangements.

Claims

1. A method for generating a payment token having an issuer-specified domain control, comprising: In an information processing device comprising at least one computer processor: receiving, from an issuer of a financial instrument, issuer-specified domain controls or restrictions on a device-specific payment token for the financial instrument, the device-specific payment token being provided to an electronic wallet on an electronic device, the issuer-specified domain controls or restrictions being applied by the issuer and the device-specific payment token being restricted to transactions only from the electronic device; requesting, by said issuer of a financial instrument and from a third party token service provider, generation of said device-specific payment token having a pass indicator from said third party token service provider; receiving the device-specific payment token from the third-party token service provider; as well as storing an association of the issuer-specified domain control or restriction with the device-specific payment token; wherein the payment network receives a transaction request involving the device-specific payment token and passes through the transaction request due to the pass-through indicator without applying any domain controls or restrictions to the transaction; and The issuer of the financial instrument applies domain controls or restrictions specified by the issuer.

2. The method according to claim 1, wherein: The access indicator is a bank identification number.

3. The method according to claim 1, wherein: The pass indicator is a cryptographic parameter of the device-specific payment token.

4. The method according to claim 1, wherein: Said third party token service provider is not associated with a payment network.

5. The method according to claim 1, wherein: The issuer-specified domain controls or restrictions are dynamic.

6. The method according to claim 1, wherein: The issuer-specified domain controls or restrictions also limit use of the device-specific payment token with specific devices within specific environments, at specific times, in specific geographic regions, or under specific authentication levels.

7. A system for processing transactions using an issuer-specified domain control, comprising: Issuer systems for issuers of financial instruments; Payment networks; and Third-party token service providers; in: the payment network being configured to receive a transaction including a device-specific payment token provided to an electronic wallet on an electronic device, the device-specific payment token including a pass indicator and the device-specific payment token being restricted to transactions only from the electronic device; The payment network is configured to, in response to the pass-through indicator, pass the transaction to the issuer without applying any domain controls or restrictions to the transaction; The issuer system is configured to receive the issuer-specified domain controls or restrictions associated with the device-specific payment token; and The issuer system is configured to apply the issuer-specified domain controls or restrictions to the transaction.

8. The system according to claim 7, wherein: The access indicator is a bank identification number.

9. The system according to claim 7, wherein: The pass indicator is a cryptographic parameter of the device-specific payment token.

10. The system according to claim 7, wherein: The issuer-specified domain controls or restrictions control use of the device-specific payment token with specific devices in specific environments, at specific times, in specific geographic regions, or under specific authentication levels.

11. The system according to claim 7, wherein: The payment network applies payment network-level domain controls or restrictions to the transaction before passing the transaction to the issuer.

Images