System and method for clearing point-of-sale terminal pre-authorizations

A point-of-sale terminal includes a card interface, and is configured to receive a plurality of pre-authorization requests, each comprising an authorization and further comprising an account number received from the card interface. The terminal is further configured, in response to each said pre-authorization request, to locate in a pre-authorization database a database record associated with the respective account number, confirm that the respective authorization amount is not greater than an offline authorization threshold, generate an authorization confirmation message comprising the respective account number and the respective authorization amount, and save the authorization confirmation message in a clearing database. The terminal is further configured to generate a clearing payload comprising the plurality of saved authorization confirmation messages, and transmit the clearing payload over a computer network.

FIELD

This patent application relates to a system and method for clearing authorizations stored at a point-of-sale terminal.

BACKGROUND

A consumer might elect to use a point-of-sale (POS) terminal and a payment card (e.g. credit card or debit card) to complete a financial transaction with a merchant (e.g. pay for a merchant's wares/services). After the consumer interfaces the payment card with the POS terminal, and the terminal reads the account number from the payment card, the POS terminal may generate an online authorization request (e.g. authorization amount, and account number), and transmit the authorization request to the merchant's financial institution (acquirer) via a secure acquirer network.

The acquirer initiates clearing of the transaction by transmitting the authorization request over a secure payment network to the issuer of the payment card. If the consumer's account with the card issuer has a credit or balance that is sufficient to complete the transaction, the card issuer posts the authorization amount to the consumer's account, generates an authorization response message, and transmits the authorization response message to the acquirer via the secure payment network. The acquirer returns the authorization response message to the POS terminal via the secure acquirer network.

The security requirements of the acquirer network and the payment network, together with the data traffic over those networks increases the latency of the online authorization/clearing process.

SUMMARY

This patent application discloses a point-of-sale (POS) terminal and associated method that clears pre-authorized transactions that are initiated at the POS terminal.

In accordance with a first aspect of this disclosure, there is provided a POS terminal that includes a card interface and at least one processor. The at least one processor is coupled to the card interface, and is configured to receive a plurality of pre-authorization requests, each including an authorization amount and further including an account number that is received from the card interface.

The at least one processor is configured to (in response to each pre-authorization request) locate in a pre-authorization database a database record that is associated with the respective account number, confirm that the respective authorization amount is not greater than an offline authorization threshold, generate an authorization confirmation message that includes the respective account number and the respective authorization amount, and save the authorization confirmation message in a clearing database.

The at least one processor is also configured to generate a clearing payload that includes the plurality of saved authorization confirmation messages, and to transmit the clearing payload over a computer network.

In accordance with a second aspect of this disclosure, there is provided a method of clearing POS terminal pre-authorizations. The method involves a POS terminal receiving a plurality of pre-authorization requests, each including an authorization amount and further including an account number that is received from a payment card that is interfaced with the POS terminal.

The method also involves the POS terminal (in response to each pre-authorization request) locating in a pre-authorization database a database record that is associated with the respective account number, confirming that the respective authorization amount is not greater than an offline authorization threshold, generating an authorization confirmation message that includes the respective account number and the respective authorization amount, and saving the authorization confirmation message in a clearing database.

The method also involves the POS terminal generating a clearing payload that includes the plurality of saved authorization confirmation messages, and transmitting the clearing payload over a payment network.

In accordance with a third aspect of this disclosure, there is provided a computer-readable medium that stores comprising computer processing instructions for execution by at least one processor of a POS terminal. The POS terminal includes a card interface.

The processing instructions, when executed by the at least one processor, cause the POS terminal to receive a plurality of pre-authorization requests, each comprising an authorization amount and further comprising an account number that the POS terminal receives via the card interface.

The processing instructions also cause the processor (in response to each pre-authorization request) to locate in a pre-authorization database a database record that is associated with the respective account number, confirm that the respective authorization amount is not greater than an offline authorization threshold, generate an authorization confirmation message that includes the respective account number and the respective authorization amount, and save the authorization confirmation message in the clearing database.

The processing instructions also cause the processor to generate a clearing payload that includes the plurality of saved authorization confirmation messages, and transmit the clearing payload over a computer network.

In one implementation, one or more of the database records of the pre-authorization database store one of the offline authorization thresholds in association with one of the account numbers. The processing instructions cause the processor to locate the one offline authorization threshold that is associated with the one account number in the pre-authorization database, and to confirm that the respective authorization amount is not greater than the located offline authorization threshold.

In one implementation, a computer server receives the clearing payload. For each authorization confirmation message that is included in the clearing payload, the computer server locates, in a customer account database, a database record associated with the respective account number, and posts to the located customer account database a database entry that includes the authorization amount.

The POS terminal may receive, from the computer server, a pre-authorization payload that includes at least one pre-authorization data set, and may update the pre-authorization database with the pre-authorization payload. One of the pre-authorization data sets may include one of the account numbers and the associated offline authorization threshold.

Since the POS terminal generates each authorization confirmation message without going online, and transmits multiple saved authorization confirmation messages as a single clearing payload, the latency of the authorization and clearing process may be less than that of the conventional online authorization/clearing process.

DETAILED DESCRIPTION

Payment Clearing Network

FIG. 1is a schematic view of the payment authorization/clearing network, denoted generally as100. As shown, the payment authorization/clearing network100comprises a point-of-sale (POS) terminal200, an acquirer server270and a payment card issuer server300, and is configured to process financial transactions initiated by a payment cardholder at one of the POS terminals200. As used herein, a “financial transaction” includes “online” transactions for which the POS terminal200may request authorization from the issuer server300in real-time, and “off-line” transactions which the POS terminal200may authorize immediately without seeking prior authorization from the issuer server300.

The POS terminals200are typically deployed at a merchant's business premises, and are configured to communicate with one of the acquirer servers270via a secure acquirer network106. Where the merchant deploys a plurality of POS terminals200, the merchant's POS terminals200may be deployed on a local area network that is maintained by the merchant, and may be configured to communicate with the merchant's acquirer server270via the merchant's local area network and the secure acquirer network106.

As non-limiting examples, one or more of the POS terminals200may be implemented as a fully-integrated (“dumb”) pin-pad terminal that interfaces with an electronic cash register (ECR) and communicates sensitive card data to the acquirer server270via the ECR, or as a semi-integrated (“smart”) pin-pad terminal that communicates sensitive card data directly to the acquirer server270via the merchant's local area network and the acquirer network106.

Each acquirer server270is associated with a respective merchant, and is configured to communicate with the POS terminals200that are deployed at each merchant premises via the acquirer network106and each merchant's local area network (if any). The acquirer servers270are also configured to communicate with the issuer server(s)300via a payment network108, such as VisaNet or the Mastercard Network.

Each issuer server300may be associated with and administered by a card issuer (e.g. a financial institution, independent card issuer) that issues payment cards to cardholders (or authorizes a third party to issue the payment cards). Each issuer server300is configured to communicate with the acquirer servers270via the payment network108, and may maintain a secure accounts database that includes a plurality of database records each associated with a respective cardholder account. Each database record of the accounts database may identify, for example, a primary account number that is uniquely associated with a cardholder's payment card212, and a credit/deposit entry to the associated cardholder account.

Each issuer server300may also maintain, for each payment card212issued by the card issuer, a respective cryptographic master key and also a transaction counter which the issuer server300increments in response to each online authorization request received from the associated payment card212.

Although the payment authorization/clearing network100is shown comprising only a single POS terminal200, a single acquirer server270and a single issuer server300, the payment authorization/clearing network100typically includes a plurality of the POS terminals200, a plurality of the acquirer servers270, and a plurality of the issuer servers300.

Payment Card

As will be discussed in greater detail below, the POS terminal200may include a payment card interface210that allows the POS terminal200to communicate with a payment card212.

The payment card212may have a contact form factor and/or a contactless (e.g. ISO 14443 based) form factor, and may be implemented as a plastic smartcard, chip card or integrated circuit card that includes a built-in micro-controller and a protected memory. The micro-controller and protected memory may together provide a secure self-contained computing environment for running cryptographic (e.g. data encryption standard (DES), triple-DES, advanced encryption standard (AES)) algorithms. Alternately, the payment card212may be implemented in software executing on a portable communications device, such as a smart phone.

Where the payment card212is implemented as a plastic card, preferably the payment card212is configured to facilitate online authorization of financial transactions using the Europay Mastercard Visa (EMV) payment card standard. Alternately, where the payment card212is implemented in software executing on a portable communications device, preferably the payment card212is configured to implement the payment card requirements of the EMV standard and to facilitate online authorization of financial transactions using the EMV standard.

The payment card212stores a primary account number that is uniquely associated with the payment card212by the card issuer, and may also store a respective cryptographic master key. The payment card212may also maintain a transaction counter which the payment card212increments for each online authorization request generated by the payment card212.

Where the payment card212is implemented as a plastic payment card, the primary account number and the cryptographic master key may be stored in the protected memory of the payment card212prior to delivery of the payment card212to the intended user. Where the payment card212is implemented in software executing on a portable communications device, the payment card212may be configured with the account number and the cryptographic master key when the payment card212is installed on the portable communications device.

POS Terminal

In the example shown inFIG. 2, the POS terminal200includes an input device202, a display device204, a network interface206, and a data processing system208that is coupled to the input device202, the display device204and the network interface206.

The input device202may be implemented as a keyboard, touchpad, touchscreen or other input device suitable for allowing a user of the POS terminal200to input data and/or commands that may be required to complete the financial transaction. The display device204may be implemented as a liquid crystal display (LCD) panel, cathode ray tube (CRT) display, plasma display panel, or other display device suitable for displaying transaction information to the user. Depending upon the configuration (e.g. fully-integrated, semi-integrated) of the POS terminal200, the network interface206allows the data processing system208to communicate with an associated ECR and/or with the merchant's local area network.

The POS terminal200also includes a payment card interface210that allows the data processing system208to communicate with a payment card212that may be interfaced with the payment card interface210. The payment card interface210may comprise a physical port (e.g. smartcard reader) that allows the data processing system208to communicate directly with payment cards212that have a contact form factor. Alternately (or additionally), the payment card interface210may comprise a wireless interface that allows the data processing system208to communicate, using a wireless protocol, such as ISO 14443, with payment cards212that have a contactless form factor The payment card interface210may also be configured to communicate, using short-range communications protocols, such as Bluetooth and/or Near Field Communications (NFC), with payment cards that are implemented in a portable communications device.

The data processing system208may include one or more microprocessors214, and one or more non-transient computer-readable media216. As a non-limiting example, the computer-readable media216may be provided as non-volatile electronic computer (e.g. FLASH) memories.

One or more of the computer-readable media216may store a clearing database218of financial transactions which the POS terminal200has authorized offline. Alternately, the clearing database218may be stored on the ECR (if any) that is associated with the POS terminal200. The clearing database218may include, for each financial transaction, the payment amount (“authorization amount”) that the merchant required from the customer to complete the financial transaction with the merchant, and the primary account number of the payment card212that the customer used in the financial transaction.

One or more of the computer-readable media216may store a pre-authorization database220of payment cards for which the card issuer has pre-authorized the POS terminal200to authorize a financial transaction offline (i.e. without communicating with the issuer server300). Alternately, the pre-authorization database220may be stored (i) on the ECR (if any) that is associated with the POS terminal200, or (ii) locally on a server (not shown) that serves the POS terminals200on the merchant's local area network.

The pre-authorization database220includes a plurality of database records each associated with a respective payment card212. In one implementation of the pre-authorization database220, each database record stores the primary account number of the associated payment card212, and also stores a respective offline authorization threshold that is associated with the primary account number.

In another implementation of the pre-authorization database220, each database record stores the primary account number of the associated payment card212but without an associated offline authorization threshold. Further, the computer-readable media216may store a default offline authorization threshold. Alternately, the default authorization threshold may be stored (i) on the ECR (if any) that is associated with the POS terminal200, or (ii) locally on a server (not shown) that serves the POS terminals200on the merchant's local area network.

In another implementation of the pre-authorization database220, one or more of the database records store the primary account number of the associated payment card212and an associated offline authorization threshold, and the remainder of the database records store the primary account number of the associated payment card212but without any associated offline authorization threshold. Further, the computer-readable media216stores a default offline authorization threshold. Alternately, the default authorization threshold may be stored (i) on the ECR (if any) that is associated with the POS terminal200, or (ii) locally on a server (not shown) that serves the POS terminals200on the merchant's local area network.

The computer-readable media216may also store computer processing instructions which, when accessed and executed by the microprocessor(s)214, implement an operating system222and a transaction processor224. Alternately, all or a portion of the functionality of the transaction processor224may be implemented instead in electronics hardware, such as a field programmable logic gate array (FPGA) or a complex programmable logic device (CPLD).

The operating system222allows the POS terminal200to accept user input from the input device202and to control the display device204and the payment card interface210.

The functionality configured into the transaction processor224will be discussed in greater detail below. By way of overview, the transaction processor224is configured to receive pre-authorization requests, each comprising a primary account number and further comprising the payment amount (“authorization amount”) that the merchant may require from the customer to complete a financial transaction with the merchant. As will be explained, the transaction processor224receives the primary account number from a payment card212that may be interfaced with the payment card interface210. The transaction processor224may receive the authorization amount via the data input device202, or from the associated ECR (if any) via the network interface206.

The transaction processor224is also configured to (in response to each pre-authorization request) i) locate in the pre-authorization database220a database record that is associated with the primary account number, ii) confirm that the authorization amount is not greater than an offline authorization threshold, iii) generate an authorization confirmation message that includes the primary account number and the authorization amount, and iv) save the authorization confirmation message in the clearing database218.

The transaction processor224is also configured to generate a Clearing Payload that includes the saved authorization confirmation messages, and to transmit the Clearing Payload over the payment network108(e.g. via the acquirer network106, and the acquirer server270). The transaction processor224may also be configured to purge the saved authorization confirmation messages from the clearing database218.

The transaction processor224may be configured to transmit the Clearing Payloads (and optionally purge the saved authorization confirmation messages) when the number of stored authorization confirmation messages reaches a predetermined maximum number of massages. Alternately, or additionally, the transaction processor224may be configured to transmit the Clearing Payloads (and optionally purge the saved authorization confirmation messages) periodically (e.g. once at the end of each business day), and/or earlier when the capacity in the clearing database218for additional authorization confirmation messages reaches or approaches a maximum capacity.

As discussed above, one or more of the database records of the pre-authorization database220may store a primary account number and an associated offline authorization threshold. In this implementation, the transaction processor224may be configured to locate the offline authorization threshold that is associated with the primary account number in the pre-authorization database220, and to confirm that the respective authorization amount is not greater than the located offline authorization threshold.

It should be understood, however, that the process(es) implemented by the POS terminal200for offline (and online) authorization/settlement of financial transactions may differ from that described in the foregoing overview, depending upon various configuration parameters, including the configuration of the pre-authorization database220, the magnitude of the authorization amount for the financial transaction, and the configuration of the transaction processor224.

For example, if each database record of the pre-authorization database220stores a primary account number and an associated offline authorization threshold, the transaction processor224may be configured to authorize the financial transaction offline where the primary account number of the customer's payment card212matches one of the primary account numbers stored in the pre-authorization database220, and the authorization amount does not exceed the respective offline authorization threshold that is associated with the primary account number of the customer's payment card212in the pre-authorization database220.

In this implementation, the transaction processor224may be configured to initiate online authorization of the financial transaction with the issuer server300where the primary account number of the customer's payment card212does not match any of the primary account numbers stored in the pre-authorization database220. The transaction processor224may also be configured to initiate online authorization of the financial transaction with the issuer server300where the primary account number of the customer's payment card212matches one of the primary account numbers stored in the pre-authorization database220, but the authorization amount exceeds the offline authorization threshold that is associated with the primary account number of the customer's payment card212in the pre-authorization database220.

Alternately, if each database record of the pre-authorization database220stores a primary account number of the associated payment card212but without an associated offline authorization threshold, the transaction processor224may be configured to authorize the financial transaction offline where the primary account number of the customer's payment card212matches one of the primary account numbers stored in the pre-authorization database220, and the authorization amount for the financial transaction does not exceed the default offline authorization threshold.

In this implementation, the transaction processor224may be configured to initiate online authorization of the financial transaction with the issuer server300where the primary account number of the customer's payment card212does not match any of the primary account numbers stored in the pre-authorization database220. The transaction processor224may also be configured to initiate online authorization of the financial transaction with the issuer server300where the primary account number of the customer's payment card212matches one of the primary account numbers stored in the pre-authorization database220, but the authorization amount exceeds the default offline authorization threshold

If one or more of the database records of the pre-authorization database220store a primary account number and an associated offline authorization threshold, and the remainder of the database records of the pre-authorization database220store a primary account number but without any associated offline authorization threshold, the transaction processor224may be configured to authorize the financial transaction offline where the primary account number of the customer's payment card212matches one of the primary account numbers stored in the pre-authorization database220, the associated database record stores a respective offline authorization threshold, and the authorization amount does not exceed the offline authorization threshold. The transaction processor224may also be configured to authorize the financial transaction offline where the database record associated with the primary account number of the customer's payment card212does not store an offline authorization threshold, but the authorization amount does not exceed the default offline authorization threshold.

In this implementation, the transaction processor224may be configured to initiate online authorization of the financial transaction with the issuer server300where the primary account number of the customer's payment card212does not match any of the primary account numbers stored in the pre-authorization database220. The transaction processor224may also be configured to initiate online authorization of the financial transaction with the issuer server300where the primary account number of the customer's payment card212matches one of the primary account numbers stored in the pre-authorization database220, but the authorization amount exceeds the offline authorization threshold that is associated with the primary account number of the customer's payment card212in the pre-authorization database220.

In this implementation, the transaction processor224may also be configured to initiate online authorization of the financial transaction with the issuer server300where the primary account number of the customer's payment card212matches one of the primary account numbers stored in the pre-authorization database220, the database record associated with the primary account number of the customer's payment card212does not store a respective offline authorization threshold, but the authorization amount exceeds the default offline authorization threshold.

Method of Clearing Authorized Transactions

As discussed, the payment authorization/clearing network100implements a method of clearing authorized transactions. A sample embodiment of the transaction authorization/clearing method will be discussed with reference toFIGS. 3A, 3B and 4. As will be explained, in this embodiment the POS terminal200receives a plurality of pre-authorization requests, each comprising a primary account number and further comprising the authorization amount that the merchant may require from the customer to complete a financial transaction with the merchant. The POS terminal200receives the primary account number from a payment card212, and may receive the authorization amount from the data input device202or from the network interface206.

In response to each pre-authorization request, the POS terminal200i) locates in the pre-authorization database220a database record that is associated with the primary account number, ii) confirms that the authorization amount is not greater than an offline authorization threshold, iii) generates an authorization confirmation message that includes the primary account number and the authorization amount, and iv) saves the authorization confirmation message in the clearing database218.

Thereafter, the POS terminal200generates a Clearing Payload that includes the saved authorization confirmation messages, and transmits the Clearing Payload over the payment network108.

An example method of processing authorization requests will now be discussed in detail with reference toFIGS. 3A and 3B.

A customer attends at a merchant's POS terminal200to complete a financial transaction (e.g. pay for wares and/or services) with the merchant. At step S300, the POS terminal200receives the authorization amount from the data input device202, or from the associated ECR (if any) via the network interface206.

The POS terminal200displays the authorization amount on the display device204, and prompts the customer to approve the displayed authorization amount via the input device202. The POS terminal200also prompts the customer to interface a payment card212with the payment card interface210of the POS terminal200.

After the customer (cardholder) interfaces a payment card212with the payment card interface210and approves the displayed authorization amount, the transaction processor224of the POS terminal200transmits to the payment card212a Read Record command requesting various data elements from the payment card212. Typically, the Read Record command requests at least the primary account number, and the expiry date of the payment card212.

The payment card212responds to the payment terminal200, at step S302, with the primary account number and any other data requested by the Read Record command. In this example, the authorization amount, primary account number and the other data requested by the Read Record command (if any) constitute the aforementioned pre-authorization request.

As discussed, the POS terminal200may be configured with a pre-authorization database220(or may be in communication with a pre-authorization database220that is maintained on an ECR, or on a server that serves the POS terminals200on the merchant's local area network) of payment cards for which the card issuer has pre-authorized the POS terminal200to authorize a financial transaction offline.

Accordingly, at step S304, the transaction processor224queries the pre-authorization database220(whether stored internally or externally to the POS terminal200) with the primary account number received from the payment card212for a database record associated with the primary account number (i.e. a database record has an account field matching the received primary account number).

If the query, at step S304, does not locate a database record that is associated with the primary account number in the pre-authorization database220, the card issuer has not pre-authorized the specified primary account number for offline authorization of any financial transactions. Accordingly, in that case, at step S320the transaction processor224initiates online authorization and clearing of the financial transaction.

Conversely, if the query, at step S304, locates a database record that is associated with the primary account number in the pre-authorization database220, the card issuer has pre-authorized the specified primary account number for offline authorization of financial transactions. Accordingly, in this case, the transaction processor224initiates offline authorization of the financial transaction by confirming that the authorization amount does not exceed any applicable offline authorization threshold.

In order to confirm that the authorization amount does not exceed any applicable offline authorization threshold, at step S306the transaction processor224may scan the located database record to determine whether the database record includes an offline authorization threshold that is associated with the primary account number (i.e. the record has an offline authorization field that is populated with data). If the located database record does not include an offline authorization threshold, at step S312the transaction processor224may then determine whether the authorization amount does not exceed a default offline authorization threshold.

If the located database record includes an offline authorization threshold, at step S308the transaction processor224may determine whether the authorization amount exceeds the offline authorization threshold specified in the database record. If the authorization amount exceeds the specified offline authorization, at step S320the transaction processor224initiates online authorization and clearing of the financial transaction.

However, if the authorization amount does not exceed the specified offline authorization threshold, at step S310the transaction processor224generates an authorization confirmation message confirming that the financial transaction was successfully authorized offline, and saves the authorization confirmation message in the clearing database218. The saved authorization confirmation message may include the primary account number and the authorization amount.

If the located database record does not include an offline authorization threshold, at step S312the transaction processor224may search the computer-readable media216and/or the merchant's local area network for a default offline authorization threshold.

If the search, at step S312, does not locate a default offline authorization threshold, at step S320the transaction processor224initiates online authorization and clearing of the financial transaction.

Conversely, if the search, at step S312, locates a default offline authorization threshold, at step S314the transaction processor224may determine whether the authorization amount exceeds the default offline authorization threshold. If the authorization amount exceeds the default offline authorization threshold, at step S320the transaction processor224initiates online authorization and clearing of the financial transaction.

However, if the authorization amount does not exceed the default offline authorization threshold, at step S310the transaction processor224generates an authorization confirmation message confirming that the financial transaction was successfully authorized offline, and saves the authorization confirmation message in the clearing database218. As noted above, the saved authorization confirmation message may include the primary account number and the authorization amount.

If the pre-authorization database220does not store a database record that is associated with the primary account number of the customer's payment card212, or the pre-authorization database220stores such a database record but the authorization amount exceeds (i) the offline authorization threshold associated with the primary account number (if applicable) or (ii) the default offline authorization threshold (if applicable), at step S316the transaction processor224initiates online authorization of the financial transaction by transmitting to the payment card212a Generate Application Cryptogram command that requests an online cryptogram from the payment card212. The Generate Application Cryptogram command includes at least the authorization amount.

Upon receipt of the Generate Application Cryptogram command, the payment card212may generate an online Application Request Cryptogram (ARQC) by (i) generating a session key by applying the payment card's cryptographic master key and the transaction counter as inputs to a cryptographic algorithm, and (ii) applying the session key, the primary account number, and the authorization amount as inputs to the cryptographic algorithm. The payment card212may transmit the online cryptogram ARQC to the POS terminal200, at step S318.

The transaction processor224may generate an Authorization Request message that includes the primary account number, the authorization amount, and the online cryptogram ARQC, and forward the Authorization Request message to the acquirer server270via the merchant's local area network and the acquirer network106. At step S320, the acquirer server270may direct the Authorization Request message to the issuer server300, over the payment network108, for validation.

At step S322, the issuer server300may verify that the payment card212generated the online cryptogram ARQC from the authorization amount. To do so, the issuer server300may (i) recover the payment card's session key by applying the payment card's cryptographic master key and transaction counter as inputs to the cryptographic algorithm, (ii) decrypt the online cryptogram ARQC with the recovered session key, (iii) compute a message authentication code from the primary account number and the authorization amount, and (iv) compare the computed message authentication code against the decrypted cryptogram.

At step S322, the issuer server300also determines whether the cardholder account that is associated with the primary account number in the card issuer's secure accounts database has sufficient credit/funds to complete the transaction (i.e. the authorization amount does not exceed the credit/funds balance for the account).

If the issuer server300determines that the payment card212generated the online cryptogram ARQC from the authorization amount, and the cardholder account has sufficient credit/funds to complete the transaction, at step S324the issuer server300may generate an authorization code that indicates that the financial transaction was authorized, generate an Authorization Response message that includes the authorization code, and may transmit the Authorization Response message to the acquirer server270over the payment network108. The acquirer server270may forward the Authorization Response message to the POS terminal200via the merchant's local area network and the acquirer network106.

The transaction processor224repeats steps S300to S324for each pre-authorization request received at the POS terminal200.

An example clearing method will now be discussed in detail with reference toFIG. 4.

As pre-authorization requests for financial transactions become authorized offline, the clearing database218will become populated with authorization confirmation messages. However, until the particulars of those transactions are cleared with the respective issuer servers300, merchants will not receive payment for any pre-authorized financial transactions that were authorized offline.

Therefore, to initiate clearing of these pre-authorized transactions, at step S400the transaction processor224generates a Clearing Payload that includes all (or a smaller portion) of the authorization confirmation messages that are saved in the clearing database218, and transmits the Clearing Payload to the merchant's acquirer server270via the merchant's local area network and the acquirer network106.

At step S400, the transaction processor224may also purge these authorization confirmation messages from the clearing database218. Alternately, the transaction processor224may track the time/date of each authorization confirmation message and the time/date of the previous Clearing Payload transmission, and may incorporate into the Clearing Payload only the authorization confirmation messages that were saved in the clearing database218subsequent to the last Clearing Payload transmission.

The acquirer server270may then bundle together the authorization confirmation messages that are received from all of the acquirer's POS terminals200, and transmit the authorization confirmation messages to the respective card issuer servers300via the payment network108.

As discussed, the transaction processor224may transmit the Clearing Payloads (and optionally purge the saved authorization confirmation messages) when the number of stored authorization confirmation messages reaches a predetermined maximum number of massages. Alternately, or additionally, the transaction processor224may transmit the Clearing Payloads (and optionally purge the saved authorization confirmation messages) periodically (e.g. once at the end of each business day), and/or earlier when the capacity in the clearing database218for additional authorization confirmation messages reaches or approaches a maximum capacity.

At step S402, each card issuer server300may complete clearing of its respective transactions by posting the authorization amounts to the respective cardholder accounts in the secure accounts database. At step S404, each card issuer server300may then effect settlement of any amounts owed to the respective acquirers, in the conventional manner.

Merchants will also not receive payment for any of the financial transactions that were authorized online until after the particulars of those transactions are cleared with the respective issuer servers300. Therefore, to initiate clearing of these latter transactions, at step S402, the issuer server300may clear each financial transaction that was authorized online by posting the respective authorization amounts to the respective cardholder accounts. At step S404, the issuer server300may then effect settlement of any amounts owed to the respective acquirers, in the conventional manner.

As discussed above, each POS terminal200may store (or be in communication with) a pre-authorization database220of payment cards. However, as the value of the offline authorization thresholds associated with the respective primary account numbers (if any) in the pre-authorization database220) can be used to establish whether a particular financial transaction can be authorized offline, the issuer servers300may periodically update the pre-authorization databases220based on the current credit risk of the card issuers' respective cardholders.

The issuer servers300may determine the credit risk of the card issuers' respective cardholders based, for example, on the Clearing Payloads and/or the Authorization Request messages received from the POS terminals200.

The issuer servers300may update the pre-authorization databases220by, for example, (i) generating one or more pre-authorization data sets, each including a primary account number and optionally an associated offline authorization threshold, (ii) incorporating the pre-authorization data sets into a pre-authorization payload, and (iii) transmitting the pre-authorization payload to the POS terminals200. The POS terminals200may then update their respective pre-authorization databases220with the pre-authorization payloads.

Alternately, where a merchant's deployment includes a local server that serves POS terminals200on the merchant's local area network, the issuer servers300may transmit the pre-authorization payloads to one or more merchant local servers, and the local servers may update their respective pre-authorization databases220with the pre-authorization payloads.

In one embodiment, the issuer server300determines from the Clearing Payloads that a particular cardholder is presenting an unacceptable credit risk. For example, the issuer server300may determine that the frequency of occurrence of authorization confirmation messages involving a particular account number (i.e. the number of authorization confirmation messages confirming that a particular payment card212was used for authorizing financial transactions offline within a particular time frame) exceeds a predetermined maximum limit.

In response, the issuer server300may reduce the offline authorization threshold that is associated with the primary account number of the payment card212by (i) generating an updated offline authorization threshold that is less than the offline authorization threshold that is associated with the primary account number in the pre-authorization database220, and (ii) generating a pre-authorization data set that includes the primary account number and the updated offline authorization threshold.

The issuer server300may then incorporate the pre-authorization payload into an Authorization Response message, and transmit the Authorization Response message to one of the POS terminals200, via the acquirer network106and the payment network108, in response to an Authorization Request message received from the POS terminal200. Upon receipt of the pre-authorization payload, the POS terminal200may replace the database entries in its pre-authorization database220with the corresponding pre-authorization data sets. Alternately, where the POS terminals200are served by a local server on the merchant's local area network, the issuer server300may push the pre-authorization payload to the local server, and the local server may replace the database entries in the pre-authorization database220with the corresponding pre-authorization data sets.

If the default offline authorization threshold is less than the offline authorization threshold, and the card issuer determines that the default offline authorization threshold would likely reduce the cardholder's credit risk to an acceptable level, the issuer server300may instead generate a pre-authorization data set that includes the primary account number but does not include any associated offline authorization threshold.

As discussed above, the issuer server300may transmit the pre-authorization payload to one of the POS terminals200as part of an Authorization Response message, or may push the pre-authorization payload to a local server on the merchant's local area network. Upon receipt of the pre-authorization payload, the POS terminal200(or local server, as applicable) may replace the database entries in the pre-authorization database220with the corresponding pre-authorization data sets.

Conversely, if the card issuer determines that the default offline authorization threshold would not reduce the cardholder's credit risk to an acceptable level, the issuer server300may generate a plurality of pre-authorization data sets for each payment card212that presents an acceptable credit risk, and exclude from those pre-authorization data sets any data set that includes the primary account number associated with the cardholders payment card212.

The issuer server300may transmit the pre-authorization payload to one of the POS terminals200as part of an Authorization Response message, or may push the pre-authorization payload to a local server on the merchant's local area network. Upon receipt of the pre-authorization payload, the POS terminal200(or local server, as applicable) may replace the pre-authorization database220with the pre-authorization data sets.

In another embodiment, the issuer server300determines from the Authorization Request messages that a particular cardholder is presenting an acceptable credit risk. For example, the issuer server300may determine that the frequency of occurrence of Authorization Request messages involving a particular account number (i.e. the number of authorization requests for online authorization of financial transactions using a particular payment card212within a particular time frame) exceeds a predetermined minimum threshold.

In response, the issuer server300may increase the offline authorization threshold that is associated with the primary account number of the payment card212by (i) generating an updated offline authorization threshold that is greater than the offline authorization threshold that is associated with the primary account number in the pre-authorization database220, and (ii) generating a pre-authorization data set that includes the primary account number and the updated offline authorization threshold.

The issuer server300may transmit the pre-authorization payload to one of the POS terminals200as part of an Authorization Response message, or may push the pre-authorization payload to a local server on the merchant's local area network. Upon receipt of the pre-authorization payload, the POS terminal200(or local server, as applicable) may replace the database entries in the pre-authorization database220with the corresponding pre-authorization data sets.