METHODS AND COMPUTER SYSTEMS FOR IMPLEMENTING A PAYMENT CARD NETWORK

Abstract

A computer-implemented method of operating a payment card network is proposed in which the expiry date of each payment card is stored, not on or in the payment cards themselves, but as a payment card record within an electronic database. When the payment card is used, the record is accessed using other payment card details to check that expiry date has not passed. The process does not require that the expiry date is read from the payment card. This has the advantage that the payment card does not have to be replaced at the expiry date. Instead, the expiry date can be updated by updating the record. In place of the expiry date, the card has an auxiliary date which is the birthdate of the consumer in the YYMM format.

Claims

1. A computer-implemented method for operating a payment card network, the method including: (a) at least once performing the set of steps of: (i) receiving a payment authorization request comprising account data identifying a payment card; and (ii) accessing a database using the account data to obtain a payment card record for the payment card, obtaining an expiry date in the payment card record, determining if the expiry date has passed, and rejecting the payment authorization request if the determination is positive; (b) at a time after performing step (a), updating the payment card record by replacing the expiry date with an extended expiry date which is later than the expiry date; and (c) at least once, at a time after performing step (b), performing the set of steps of: (i) receiving a further payment authorization request comprising the account data; and (ii) without verifying whether the further payment authorization request comprises data encoding the extended expiry date, accessing the database using the account data to obtain the payment card record for the payment card, obtaining the extended expiry date in the payment card record, determining if the extended expiry date has passed, and rejecting the payment authorization request if the determination is positive.

2. A computer-implemented method for operating a payment card network, the method including: (a) at least once performing the set of steps of: (i) obtaining account data from a physical payment card, the account data identifying a payment card; (ii) generating a payment authorization request comprising the account data; (iii) transmitting the payment authorization request; and (iv) accessing a database using the account data to obtain a payment card record for the payment card, obtaining an expiry date in the payment card record, determining if the expiry date has passed, and rejecting the payment authorization request if the determination is positive; (b) at a time after performing step (a), updating the database by replacing the initial expiry date with an extended expiry date which is later than the expiry date; and (c) at least once, at a time after performing step (b), performing the set of steps of: (i) obtaining the account data from the physical payment card, (ii) generating a further payment authorization request comprising the account data; and (iii) accessing the database using the account data to obtain the payment card record for the payment card, obtaining the extended expiry date in the payment card record, determining if the extended expiry date has passed, and rejecting the further payment authorization request if the determination is positive.

3. A computer-implemented method according to claim 1, further including: prior to performing step (a), fabricating the payment card storing the account data, and storing the expiry date in the corresponding payment card record; at intervals determining whether the expiry date meets a proximity criterion, and upon the determination being positive: determining whether the consumer meets one or more criteria; and if the consumer meets the one or more criteria, performing said step (b) of updating the database by replacing the expiry date with the extended expiry date.

4. A method according to claim 3 in which said step of fabricating the payment card does not include storing the expiry date on the payment card.

5. A method according to claim 1, in which in the further payment authorization request comprises an auxiliary date different from the expiry date, the method comprising determining whether the auxiliary date differs from an auxiliary date in the payment card record, and rejecting the payment authorization request if the determination is positive.

6. A method according to claim 3, in which in the further payment authorization request comprises an auxiliary date different from the expiry date, the method comprising determining whether the auxiliary date differs from an auxiliary date in the payment card record, and rejecting the payment authorization request if the determination is positive, wherein the step of fabricating the payment card includes encoding the auxiliary date in the payment card in an electro-magnetically or optically-readable element of the payment card.

7. A method according to claim 6 in which the electro-magnetically or optically-readable element of the payment card is a magnetic element or an integrated circuit smart card.

8. A method according to claim 6 further including forming at least one card verification value using the auxiliary date and the account data, and storing the card verification value in the payment card.

9. A computer system operative to: (i) receive a payment authorization request comprising account data identifying a payment card; and (ii) without verifying whether the payment authorization request comprises data encoding an expiry date, access a database using the account data to obtain a payment card record for the payment card, obtain an expiry date in the payment card record, determine if the obtained expiry date has passed, and reject the payment authorization request if the determination is positive.

10. A computer system according to claim 9, which is further operative to determine whether an auxiliary date in the payment authorization request matches an auxiliary date in the payment card record which differs from the expiry date, and reject the payment authorization request if the determination is negative.

11. A computer system according to claim 9 which is further operative to: initiate the fabrication of the payment card storing the account data; store the expiry date in the corresponding payment card record; at intervals determine whether the expiry date meets a proximity criterion, and upon the determination being positive: determine whether the consumer meets one or more criteria; and if the consumer meets the one or more criteria, update the payment card record by replacing the expiry date with the extended expiry date.

12. A computer system according to claim 11, which is further operative to cause the auxiliary date to be stored in the payment card.

13. A computer system according to claim 12 which is further operative to form at least one card verification value using the auxiliary date and the account data, and cause the at least one card verification value to be stored in the payment card.

14. A computerized payment card network, the network including: (a) a merchant device operative to: (i) obtain account data from a physical payment card, the account data identifying a payment card; (ii) generate a payment authorization request comprising the account data; and (iii) transmit the payment authorization request; (b) a computer system operative to, without verifying whether the payment authorization request comprises data encoding the extended expiry date, access a database using the account data to obtain a payment card record for the payment card, obtain the extended expiry date in the payment card record, determine if the extended expiry date has passed, and reject the payment authorization request if the determination is positive.

15. A computerized network according to claim 14, in which the computer system is further operative to determine whether an auxiliary date in the payment authorization request matches an auxiliary date in the payment card record which differs from the expiry date, and reject the payment authorization request if the determination is negative.

16. A computerized network according to claim 14, further including a payment card fabrication unit, the computer system being further operative to: control the payment card fabrication unit to initiate fabrication of the payment card storing the account data; store the expiry date in the corresponding payment card record; at intervals determine whether the expiry date meets a proximity criterion, and upon the determination being positive: determine whether the consumer meets one or more criteria; and if the consumer meets the one or more criteria, update the payment card record by replacing the expiry date with the extended expiry date.

17. A computerized network according to claim 16, in which the computerized system is further operative to control the payment card fabrication unit to store the auxiliary date in the payment card.

18. A computerized network according to claim 17 in which the computer system which is further operative to form at least one card verification value using the auxiliary date and the account data, and control the payment card fabrication unit to store the at least one card verification value in the payment card.

Description

BRIEF DESCRIPTION OF THE EMBODIMENTS

[0027] Exemplary embodiments according to the present disclosure will now be described for the sake of example with reference to the following figures in which:

[0028] FIG. 1 shows schematically a known payment card network;

[0029] FIG. 2 shows a known payment card;

[0030] FIG. 3 shows an exemplary payment card;

[0031] FIG. 4 shows the steps of a first exemplary method;

[0032] FIG. 5 shows schematically a first exemplary payment card network;

[0033] FIG. 6 shows the steps of a second exemplary method which may be employed by the payment card network of FIG. 5 in one step of the first exemplary method;

[0034] FIG. 7 shows schematically a second exemplary payment card network;

[0035] FIG. 8 shows the steps of a third exemplary method which may be employed by the payment card network of FIG. 7; and

[0036] FIG. 9 shows the structure of a computer server of the payment card networks of FIGS. 5 and 7.

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0037] Referring to FIG. 3, an exemplary payment card 25 is illustrated. Superficially, the payment card 25 appears similar to the payment card 2 of FIG. 2. The payment card is planar, and on one surface displays a 16-digit account number 26 (PAN), which may be embossed. Also, there is CVV number 27 (which may be on the same surface of the payment card as the account number 26, or on the opposite surface). Preferably, the CVV number is printed, not embossed.

[0038] The payment card 25 includes an electromagnetically readable element (not shown). The electromagnetically readable element may be a magnetic strip or embedded integrated circuit, or possibly an optically-readable element, stores the PAN number, an auxiliary date and a CVV number (optionally the same as the printed CVV number 27, but more typically different).

[0039] The auxiliary date is known to the consumer, and may be a memorable month, such as the consumer's month of birth. The CVV is calculated from the auxiliary date and the PAN number, e.g. according to a known CVV-generation algorithm.

[0040] The method 100 by which the payment card 25 is created, and the expiry date is updated at intervals, is illustrated in FIG. 4.

[0041] In step 101, an issuer bank server sets the account number (PAN) of the card 25, and an initial expiry date of the card 25 by a conventional method. The issuer bank server also defines the auxiliary date as the consumer's month and year of birth. This information is typically present in the customer records of the issuer bank, and/or in an application form the issuer bank may ask the consumer to complete to obtain the payment card. Note that in variations of the invention, the issuer bank server may set another date as the auxiliary date, which is different from, and chosen independently of, the expiry date.

[0042] In step 102, the issuer bank server uses the auxiliary date and the account number of the payment card to generate at least one CVV value by a conventional algorithm.

[0043] In step 103, the issuer bank server generates a payment card record in a database (as explained below with reference to FIG. 5, the database is the one labelled 15 in FIG. 5). The payment card record includes the expiry date for the card, and also the auxiliary date and the at least one CVV value. The payment card record is accessible in the database using the account number 26.

[0044] In step 104, the issuer instructs a payment fabrication unit to fabricate the payment card 25. The fabricated payment card 25 is then transmitted to the consumer. If the auxiliary date is one generated by the issuer bank server, then the auxiliary date also is notified to the consumer.

[0045] In step 105, the issuer server processes any payment authorization requests it receives related to the payment card. This is done by the method of FIG. 6 explained below. It does not include checking whether the payment authorization request includes the expiry date.

[0046] Step 106 is performed periodically, e.g. once per month. The issuer bank server reviews the payment card record in the database to identify if the expiry date meets at least one proximity criterion (e.g. it is within a predetermined time window in the future, such as within the next 2 months).

[0047] If so, in step 107 the issuer bank server initiates a procedure (as in a conventional system) to determine whether to continue to provide payment card services to the consumer, and if so, whether the conditions of usage of the payment card (e.g. the credit card limit) should be changed.

[0048] If it is determined that payment card services should not continue to be provided to the consumer, then in step 108 the issuer bank server notifies the consumer.

[0049] If it is determined that payment card services should continue to be provided to the consumer, then in step 109 the issuer bank server updates the expiry date in the database, and sends a communication to the consumer notifying the consumer of the revised expiry date and any revisions to the conditions of usage of the payment card. Note that the issuer bank server does not have to send the consumer a revised CVV number, since the previously applicable number continues to be valid.

[0050] Note that in variation of the method 100, the issuer bank may use two servers. A first server performs steps 101-104 and 106-109, while a second server performs just step 105 using the database records generated and updated by the first server. This means that the second server is not given a load in addition to the load of performing step 105. In the following text, however, the two servers of the issuer bank are considered as a single computer system.

[0051] Turning to FIG. 5, a first exemplary computerized network is shown in which the payment card 25 can be used. Elements having the same meaning as in FIG. 1 are given the same reference numerals. In contrast to the known system of FIG. 1, the issuer bank server 7 has access to a database 15 containing records for respective payment cards. The database 15 is the one in which the payment card record was created during step 103 of the method 100 of FIG. 4, and the payment card record in the database 15 is updated each time step 109 is performed. Each record includes, and is identifiable using, the account number 26 of the payment card 25, and the record contains the payment card's expiry date and the auxiliary date.

[0052] Upon the consumer initiating a payment transaction using the POS terminal 1, the POS terminal reads the PAN number, auxiliary date and CVV from the electromagnetically-readable element of the payment card 25. The POS terminal 1 forms transaction data in the usual way. The transaction data includes the PAN number, the auxiliary date, the CVV, the amount of the proposed transaction and optionally other data. The POS terminal 1 forms a payment authorization request including the transaction data, and passes it to the acquirer server 3. In this step the POS terminal 1 operates in the same manner as a conventional POS terminal, although the data it handles has a different significance. The acquirer bank server 3 transmits the payment authorization request to the payment network server 5, as in the conventional process. The payment network server 5 transmits the payment authorization request to the issuer bank server 7 as in the conventional process.

[0053] Upon receiving the payment authorization request, the issuer bank server 7 performs the method 200 of FIG. 6. In step 201, the issuer bank server 7 determines whether the PAN number is in a predetermined range indicating that the payment card 25 is one according to the present disclosure. If not, the issuer bank server 7 processes the card according to the conventional procedure described above (step 202).

[0054] If the PAN number is in the predetermined range, in step 203 the issuer bank server 7 uses the PAN number to access the record for the payment card in the database 15.

[0055] In step 204, the issuer bank server 7 compares the auxiliary date in the transaction data with the auxiliary date in the record. If there is no match, then in step 205 the issuer bank server 7 indicates to the payment network server 5 that the payment transaction has failed. This information is relayed back to the POS terminal 1. The issuer bank server 7 updates a field of the record of the payment card in the database 15 which indicates the number of times this failure has happened. If the field indicates that this has happened more than a predetermined number of times, optionally, a security protocol may be initiated (e.g. the issuing bank server may cancel the card, i.e. marks the record for the payment card such that it will never again authorize a transaction using the payment card, and optionally issue a new payment card to the consumer).

[0056] Alternatively, if there was a match in step 204, the issuer bank server 7 proceeds to step 206, in which the issuer bank server 7 extracts the expiry date from the record, and checks whether the payment card has expired (i.e. the month indicated by the expiry date has finished). If the payment card has expired, the issuer bank server 7 indicates (step 207) to the payment network server 5 that the payment transaction has failed. Optionally, a security protocol may be initiated.

[0057] Alternatively, if the payment card has not expired, then in step 208 the issuer bank server 7 processes the authorization request according to the conventional authorization procedure described above. Optionally, the database 15 stores data sufficient for the issuer bank server 7 to do this (e.g. storing the balance of the financial account associated with the payment card); alternatively the database storing the data required to perform the authorization procedure may be a separate database. The issuer bank server 7 passes the result back to the payment network server 5 for relay to the POS terminal 1. The method 200 then terminates.

[0058] In the case that the consumer uses the payment card to make a purchase to the online store, the consumer enters the card details visible on the card into a GUI (graphical user interface) generated by the online store and displayed by the communication device 9 (either by the communication device 9 running a browser which communicates with the merchant server 13, or using a dedicated application running on the communication device 9). When prompted to enter a date, the consumer enters the auxiliary date (not the expiry date). The online server 13 then generates the payment authorization request according to the conventional procedure described above, and passes it to the acquirer bank server 3, which passes it to the payment network server 5, which passes it to the issuer bank server 7.

[0059] In this case too, the issuer bank server 7 performs the method 200, as described above. In this case, however, step 204 is more important, since it enables the issuer bank server 5 to verify the identity of the consumer (if it is assumed that no-one but the consumer knows the auxiliary date, which, as mentioned above, is not visible on the payment card 25).

[0060] Similarly, if the consumer attempts to withdraw money from an ATM (not shown) operated by the bank server 7, the ATM reads the account number 26, auxiliary date and expiry date from the payment card 25. The bank server 7 generates a payment authorization request, which is relayed to the issuer bank by the payment network server 5, and the issuer bank server 7 processes it by the process of FIG. 6. The result is relayed back to the bank server 7 via the payment network server 5, and the ATM provides money to the consumer accordingly.

[0061] Turning to FIG. 7, a second exemplary computerized network is shown in which the payment card 25 can be used. Elements having the same meaning as in FIGS. 1 and 5 are given the same reference numerals. In contrast to the exemplary system of FIG. 5, the payment network server 5 has access to a database 30 containing records for respective payment cards. The database 30, like the database 15, stores records for each payment card 25. Each record includes, and is identifiable using, the payment card's PAN number, and the record contains the payment card's expiry date and the auxiliary date. Thus, the database 30 mirrors the database 15. Like the database 15, the database 30 may be created during step 103 of the method 100 of FIG. 4, and updated each time step 109 is performed. In a variation of the payment card network of FIG. 7, the databases 15, 30 are combined into a single database which is accessed by both the payment card server 5 and the issuer bank server 7.

[0062] Upon the consumer initiating a payment transaction using the POS terminal 1, the POS terminal reads the PAN number, auxiliary date and CVV from electromagnetically-readable medium. The POS terminal 1 forms a payment authorization request in the manner described above with reference to FIG. 4, and passes it to the acquirer server 3, which transmits the payment authorization request to the payment network server 5.

[0063] The payment network server 5 performs the method 300 of FIG. 8. In step 301, the payment network server 5 determines whether the PAN number is in a predetermined range indicating that the payment card is one according to the present disclosure. If not, the payment network server 5 processes the card according to the convention procedure described above (step 302), by forwarding it to issuer bank server 7.

[0064] If the PAN number is in the predetermined range, in step 303 the payment network server 5 uses the PAN number to access the record for the payment card in the database 30.

[0065] In optional step 304, the payment network server 5 compares the auxiliary date in the transaction data with the auxiliary date in the record. If there is no match, the payment network server 5 indicates to the acquiring bank server 3 (step 305) that the payment transaction has failed. Optionally, a security protocol may be initiated (e.g. the issuing bank may be informed that the payment card has been compromised).

[0066] Alternatively, if there was a match in step 304, the payment network server 5 proceeds to step 306, in which the payment network server 5 extracts the expiry date from the record, and checks whether the payment card has expired (i.e. the expiry date is in the past). If the payment card has expired, the payment network server 5 indicates (step 307) to the acquiring bank 3 that the payment transaction has failed. Optionally, a security protocol may be initiated (e.g. the issuing bank may be informed that someone has attempted to use an expired card).

[0067] Alternatively, if the payment card has not expired, then in step 308 the payment network server 5 forwards the payment authorization request to the issuing bank server 7. The issuing bank server determines whether to authorize the payment, and passes a corresponding message to the payment network server 5 which relays it to the acquirer bank 3, which relays it to the POS terminal 1. The method 300 then terminates.

[0068] In the case that the consumer uses the payment card to make a purchase to the online store, the consumer enters the card details visible on the card into a GUI generated by the online store and displayed by the communication device 9 (either by the communication device 9 running a browser which communicates with the merchant server 13, or using a dedicated application running on the communication device 9). When prompted to enter a date, the consumer enters the auxiliary date (not the expiry date). The online server 13 then generates the payment authorization request according to the conventional procedure described above, and passes it to the acquirer bank server 3, which passes it to the payment network server 5.

[0069] In this case too, the payment network server performs the method 300, as described above. In this case, however, step 304 enables the payment network server 5 to verify the identity of the consumer (if it is assumed that no-one but the consumer knows the auxiliary date, which, as mentioned above, is not visible on the payment card 25).

[0070] Similarly, if the consumer attempts to withdraw money from an ATM (not shown) operated by the bank server 7, the ATM reads the account number 26, auxiliary date and expiry date from the payment card 25. The bank server 7 generates a payment authorization request and sends it to the payment network server 5 which performs the method of FIG. 8. In step 308, the payment network server 5 relays the payment authorization request to the issuer bank. The issuer bank server 7 processes it by the conventional payment authorization process. The result is relayed back to the bank server 7 via the payment network server 5, and the ATM provides money to the consumer accordingly.

[0071] Note that in contrast to the method 200, the load on the issuing bank server 7 is less if the payment network server 5 has carried out method 300, since the payment network server 5 filters out any payment authorization requests in respect of payment cards which have not expired, or which do not contain a correct auxiliary date. Furthermore, since, in the method 300, the checks that the auxiliary date in the transaction data matches the payment card record, and that the expiry date has not passed, have been done in the payment network server 5, the issuer bank server 7 does not have to perform the whole of the method 200, but only the step 208.

[0072] Whenever step 108 of the method 100 is carried out by the issuer bank server 7, the issuer bank server 7 notifies the payment network server 5, and the payment network server 5 updates the database 30 accordingly. Thus, the payment network server 5 processes further payment authentication requests after the databases 15, 30 are updated.

[0073] FIG. 9 is a block diagram showing a technical architecture of the payment network server 5. The issuer bank server 7 may also have this technical architecture.

[0074] The technical architecture includes a processor 222 (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage 224 (such as disk drives), read only memory (ROM) 226, random access memory (RAM) 228. The processor 222 may be implemented as one or more CPU chips. The technical architecture may further comprise input/output (I/O) devices 230, and network connectivity devices 232.

[0075] The secondary storage 224 is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM 228 is not large enough to hold all working data. Secondary storage 224 may be used to store programs which are loaded into RAM 228 when such programs are selected for execution.

[0076] In this embodiment, the secondary storage 224 has a processing component 224a comprising non-transitory instructions operative by the processor 222 to perform various operations of the method of the present disclosure. The ROM 226 is used to store instructions and perhaps data which are read during program execution. The secondary storage 224, the RAM 228, and/or the ROM 226 may be referred to in some contexts as computer readable storage media and/or non-transitory computer readable media.

[0077] I/O devices 230 may include printers, video monitors, liquid crystal displays (LCDs), plasma displays, touch screen displays, keyboards, keypads, switches, dials, mice, track balls, voice recognizers, card readers, paper tape readers, or other well-known input devices.

[0078] The network connectivity devices 232 may take the form of modems, modem banks, Ethernet cards, universal serial bus (USB) interface cards, serial interfaces, token ring cards, fiber distributed data interface (FDDI) cards, wireless local area network (WLAN) cards, radio transceiver cards that promote radio communications using protocols such as code division multiple access (CDMA), global system for mobile communications (GSM), long-term evolution (LTE), worldwide interoperability for microwave access (WiMAX), near field communications (NFC), radio frequency identity (RFID), and/or other air interface protocol radio transceiver cards, and other well-known network devices. These network connectivity devices 232 may enable the processor 222 to communicate with the Internet or one or more intranets. With such a network connection, it is contemplated that the processor 222 might receive information from the network, or might output information to the network in the course of performing the above-described method operations. Such information, which is often represented as a sequence of instructions to be executed using processor 222, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave.

[0079] The processor 222 executes instructions, codes, computer programs, scripts which it accesses from hard disk, floppy disk, optical disk (these various disk based systems may all be considered secondary storage 224), flash drive, ROM 226, RAM 228, or the network connectivity devices 232. While only one processor 222 is shown, multiple processors may be present. Thus, while instructions may be discussed as executed by a processor, the instructions may be executed simultaneously, serially, or otherwise executed by one or multiple processors.

[0080] Although the technical architecture is described with reference to a computer, it should be appreciated that the technical architecture may be formed by two or more computers in communication with each other that collaborate to perform a task. For example, but not by way of limitation, an application may be partitioned in such a way as to permit concurrent and/or parallel processing of the instructions of the application. Alternatively, the data processed by the application may be partitioned in such a way as to permit concurrent and/or parallel processing of different portions of a data set by the two or more computers. In an embodiment, virtualization software may be employed by the technical architecture 220 to provide the functionality of a number of servers that is not directly bound to the number of computers in the technical architecture 220. In an embodiment, the functionality disclosed above may be provided by executing the application and/or applications in a cloud computing environment. Cloud computing may comprise providing computing services via a network connection using dynamically scalable computing resources. A cloud computing environment may be established by an enterprise and/or may be hired on an as-needed basis from a third party provider.

[0081] It is understood that by programming and/or loading executable instructions onto the technical architecture, at least one of the CPU 222, the RAM 228, and the ROM 226 are changed, transforming the technical architecture in part into a specific purpose machine or apparatus having the novel functionality taught by the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules.

[0082] Whilst the foregoing description has described exemplary embodiments, it will be understood by those skilled in the art that many variations of the embodiment can be made within the scope and spirit of the present invention.