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.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application is a U.S. National Stage filing under 35 U.S.C. §119, based on and claiming benefit of and priority to SG Patent Application No. 10201605514R filed Jul. 5, 2016. 
     
    
     SUMMARY OF THE INVENTION 
       [0002]    The present invention relates to methods and computer systems for implementing a payment card network, which permits consumers associated with one or more corresponding payment cards to make payments to merchants. 
       BACKGROUND OF THE INVENTION 
       [0003]    Payment cards used by individual card holders (here “consumers”) are conventionally associated with a payment network.  FIG. 1  shows the basic operation of a conventional payment system. A consumer holds a payment card, typically a credit or debit card, issued by an issuer bank. The payment card is associated with a payment network. One way of using the payment card is for the consumer to go to a POS (point-of-sales) terminal  1  operated by a merchant to make a payment transaction to purchase a product. Note that the term “product” is used in this document to include any of physical objects, data products (such as music or software) or services. The POS terminal  1  reads details of the payment card from an electromagnetically readable element of the payment card, such as a magnetic strip formed on the payment card, or an integrated circuit (such as an EMV chip) embedded in the card. The POS terminal  1  includes the details of the payment card in transaction data describing the proposed payment transaction. The transaction data also includes the amount of the purchase and typically other data (e.g. the identity of the POS terminal  1 ). The POS terminal  1  sends a payment authorization request including the transaction data to the server  3  of an acquirer bank at which the merchant maintains an account. The acquirer bank server  3  contacts a payment network server  5  of the payment network, and passes on the payment authorization request. The payment network server  5  uses the payment card details to identify the issuer bank. The payment network server  5  contacts an issuer bank server  7  operated by the issuer bank, and sends it the payment authorization request. The issuer bank server  7  performs an authorization procedure (in which for example it checks whether the consumer&#39;s account balance is large enough to make the payment) to decide either to authorize the payment, or not to. The issuer bank server  7  sends a corresponding message to the payment network server  5 . The payment network server  5  passes this information to the acquirer bank server  3 , which passes the message back to the POS terminal  1 . If the issuer bank server  7  authorized the payment, then the purchase is now completed. At some later time (during clearing and settlement operations), the issuer bank transfers the payment amount, less a fee, to the acquirer bank. Note that in a variant of the process, the acquirer bank server  3  is replaced by a gateway server of a third-party organization, but the operation of the gateway server is equivalent to that of the acquirer bank server described above. 
         [0004]    The same basic scheme is used when the consumer, instead of using the POS terminal  1 , uses a communication device  9  associated with the consumer to contact, using a communication network  11 , a server  13  which functions as an online store. The communication device may be a smart phone, a tablet computer or a PC. In this case, the online store server  13  replaces the POS terminal  1  in the payment process described in the preceding paragraph. The consumer enters the payment card details into the communication device  9 , or they may be pre-stored there. 
         [0005]    Another common use scenario for the payment card is to withdraw money from an ATM (automatic transaction machine) operated by a bank. Let us suppose that the bank is the one which operates the server  3 . The ATM reads the card data from the payment card, receives a PIN number (personal identity number) input by the consumer, and passes this data to the server  3 . The server  3  sends a payment authorization request to a payment network server  5 , requesting authorization to dispense money to the consumer. The payment network server  5  forwards the payment authorization request to the issuer bank server  7 , and the decision of the issuer bank server  7  is communicated via the payment network server  5  to the server  3 . 
         [0006]    The payment card details present on a payment card are defined by a standard called ISO 8583. The payment card details include a primary account number (PAN, which is typically 16 digits long), an expiry date of the card and a CVV (card verification value) number. The CVV (also called sometimes a card security code (CSC) or card validation code (CVC)) is formed from the expiry date (stated as a specific month of a specific year) and the PAN number using an algorithm known to the issuer bank but otherwise confidential. 
         [0007]    There are several types of CVV. A first, known as CVV 1  (or CVC 1 ) is encoded on track  2  of a magnetic strip of the payment card (and in some cards, stored also in an integrated-circuit smart card incorporated in the payment card). Conventionally, the magnetic strip (and/or smart card) also stores the PAN number and card expiry date. The CVV 1  is used for “card present” transactions, in which the payment card is used at a point-of-sale (POS) terminal  1  or ATM. The POS terminal  1  or ATM reads the CVV 1  code, PAN number and card expiry date. 
         [0008]    A second type of CVV, is known as CVV 2  (or CVC 2 ). Merchants have the option of asking the card holder for the CVV 2  in the case of “card-not-present” transactions (e.g. transactions occurring by mail, telephone or the internet). 
         [0009]    Certain card details are visible on the payment card. This is illustrated in  FIG. 2  which shows a known payment card issued by a payment card issuer (“Any-Bank”) to a customer (“A. Customer”). The payment card is embossed with the PAN number  21  and expiry date  22  (in a YY-MM format, where YY is a two digit number in the range 00 to 99, and MM is a two digit number in the range 00 to 12). The CVV 2  code  23  is printed on the payment card (often on the back surface of the payment card), but is not embossed (i.e. the CVV 2  code is printed substantially co-planar with the surface of the payment card, not upstanding from it). 
         [0010]    The card can only be used at times up to the end of the month which is the expiry date. Shortly before the expiry date, the issuer bank checks the credit status of the individual, and decides whether to issue a new payment card to the consumer, and whether to impose any conditions on the use of the payment card (e.g. in the case of a credit card, change a credit limit of the card). Thus, the expiry date provides a way of ensuring that the payment card cannot be used indefinitely, and that appropriate changes to the conditions of use of the card are made periodically. 
       SUMMARY OF THE INVENTION 
       [0011]    In general terms, the present invention proposes that the expiry date of a physical payment card is stored within an associated payment card record stored in an electronic database. The payment card record is accessible using other payment card details stored by the payment card (referred to as account data). The payment card is used to form payment authorization requests, which are processed in a procedure which includes checking the payment card record to ensure that the expiry date has not passed. After a certain time has passed, the expiry date in the payment card record is updated to an “extended expiry date”. Whenever the consumer (card holder) wishes to make a payment using the payment card after the updating of the expiry date, a further payment authorization request is generated using the payment card, and processed by the payment network and/or issuer bank without requiring that the further payment authorization request includes the extended expiry date. In other words, the same payment card is used to form payment authorization requests both before and after the updating of the expiry date. 
         [0012]    This has the advantage that the payment card does not have to be replaced when the expiry date is updated. Thus, the invention makes possible a payment network operating procedure which eliminates the cost of providing a new physical payment card at the expiry date of the card. Nevertheless, the operating procedure can be consistent with existing (and future) standards for operating a payment card network. 
         [0013]    The updating of the expiry date is typically performed at a time proximate the expiry date (e.g. during a month at the end of which the payment card expires, or period of 1-2 months before the expiry of the payment card). At this time, any desired check on the status of the consumer is carried out, and subject to this check the expiry date of the card in the payment card record is updated to an “extended expiry date”. Optionally, any conditions on the use of the payment card (e.g. a credit limit, or a payment amount limit) may be revised at this time. 
         [0014]    Optionally, the updating of the expiry date may be performed according to this procedure a plurality of times. 
         [0015]    When the consumer wishes to make a payment, a payment authorization request is generated using the account data. Upon receiving the payment authorization request, a computer system with access to the database can use the card details to look up the expiry date. It may then check that the payment card has not expired. Note that no check is performed that the expiry data is included in the payment authorization request. The account data may be such as to indicate that this check is not performed. That is, for a payment card for which this check is not performed, the account number may be chosen to have a certain characteristic, for example being in a certain range. 
         [0016]    The computer system which checks that the expiry date has not passed may be the payment card network server. 
         [0017]    Alternatively, the computer system which checks that the expiry date has not passed may be associated with the issuing bank for the payment card. 
         [0018]    To meet requirements of the existing payment card standard, the payment card be associated with an auxiliary date which is independent of the expiry date. Conveniently the auxiliary date may be an easily memorable date for the consumer, such as the consumer&#39;s month of birth. Alternatively, it may be a date which is notified to the consumer when the payment card is supplied to the consumer. 
         [0019]    The auxiliary date is stored in an electro-magnetically (or, in alternatively, optically readable) element of the payment card, together with the account data for the card. When the card is used with a POS terminal or an ATM, the account data and auxiliary date is read by the POS terminal or ATM in the conventional manner. 
         [0020]    For an online transaction to a merchant, the consumer enters the auxiliary date into a graphical user interface (GUI). Preferably, the auxiliary date is not visible on the payment card. The auxiliary date entered by the consumer is included in the payment authorization request, and compared with an auxiliary date stored in the database, to verify the identity of the user. This provides a level of security which is not present for a conventional online payment, which normally does not require the consumer to provide any information which is not printed on the card. Thus, this feature makes possible an anti-fraud measure which is not provided by known payment card network operating methods, while still being compatible with existing payment card standards. 
         [0021]    Optionally, at least one CVV may be generated as a function of the account data and the auxiliary date stored on the payment card. It is stored by the payment card in an electromagnetically- or optically-readable element of the payment card. The CVV may be printed on the payment card. Optionally a first CVV value may be stored in a data storage element of the payment card which is only readable automatically (e.g. on a magnetic element of the card, such as a magnetic strip, or in an integrated-circuit smart card), and a second CVV value may be printed on the payment card. 
         [0022]    As used in this document, the term “payment card” refers to any cashless payment device associated with a payment account, such as a credit card, a debit card, a prepaid card, a charge card, a membership card, a promotional card, a frequent flyer card, an identification card, a prepaid card, a gift card, and/or any other device that may hold payment account information (e.g. a key fob). The payment card has physical existence—that is, it is a “physical payment card”—in the sense that it exists as a physical object which a user can carry with him or her (e.g. in a wallet) and manipulate with his or her hands. It is typically printed with the account information. Thus, the payment card is not just a data structure in computer device, although the consumer may have the option to copy the account number of the payment card to a communication device (e.g. a mobile phone) so that the mobile phone may be used in place of the physical payment card for certain payment transactions. 
         [0023]    The term “printed” is used in this document to mean that, if a data item is printed on the payment card, the item is permanently visible to a human reader (rather than an automatic data-reading device). The term covers, but is not limited to, the possibility that the item is permanently displayed on the payment card by depositing an ink formation encoding the item onto a surface of the payment card. The term embraces the possibility that the portion of the surface of the payment card where the item is visible was formed at the same time as the formation of the rest of the surface of the payment card. 
         [0024]    As used in this application, the terms “component,” “module,” “engine,” “system,” “apparatus,” “interface,” or the like are generally intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a controller and the controller can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. 
         [0025]    Furthermore, the claimed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. For instance, the claimed subject matter may be implemented as a computer-readable medium embedded with a computer executable program, which encompasses a computer program accessible from any computer-readable storage device or storage media. For example, computer readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips . . . ), optical disks (e.g., compact disk (CD), digital versatile disk (DVD) . . . ), smart cards, and flash memory devices (e.g., card, stick, key drive . . . ). 
         [0026]    In particular, the present disclosure can further be implemented as a computer system operative to perform a method. In other words, the computer system comprises a processor and a data storage device storing program instructions operable by the processor to cause the processor to perform the method. 
     
    
     
       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&#39;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&#39;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&#39;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&#39;s PAN number, and the record contains the payment card&#39;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  224 a 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.