Transaction systems and associated methods for enhanced account balance and status management

Abstract

A computer implemented method of performing a transaction using a payment account, typically handled by a payment account manager (PAM), comprises the steps of: receiving a first message from a top up terminal indicating that funds have been transferred to the payment account; setting or adjusting a funds limit of the payment account based on information in the first message; receiving an authorization or pre-authorization request from a first terminal and commencing a funds aggregation; receiving a second message indicating a pre-defined amount of funds which may be used in the transaction; blocking an amount of the funds limit of the payment account equivalent to the pre-defined amount; and sending an authorization response to the first terminal.

Claims

1. A computer implemented method of using a payment card network to rapidly update a payment account deny list, the method comprising the steps of: receiving, by a payment account manager (PAM) processor, a first message directly from a top up terminal indicating that funds have been transferred to the payment account; setting or adjusting a funds limit of the payment account by the PAM processor based on information in the first message; receiving by the PAM processor, directly from a first terminal, an authorisation or pre-authorisation request and commencing a funds aggregation responsive to the authorisation or pre-authorisation request; receiving by the PAM processor, directly from the first terminal, a second message indicating a pre-defined amount of funds which may be used in the transaction; blocking by the PAM processor an amount of the funds limit of the payment account equivalent to the pre-defined amount; sending an authorisation response by the PAM processor directly to the first terminal; placing the payment account on a deny list at the first terminal by the PAM processor when an unblocked amount of the funds limit is less than a minimum possible actual amount of funds used; sending an additional message directly from the top up terminal to the first terminal and to the PAM processor, indicating that further funds have been transferred to the payment account; and removing the payment account from the deny list at the first terminal in response to the additional message.

2. The method of claim 1, further comprising the steps of: receiving a third message from a second terminal indicating an actual amount of funds used; and adjusting the blocked amount of the funds limit of the payment account if the actual amount of funds used differs from the pre-defined amount.

3. The method of claim 1, further comprising the step of: sending a message to the first terminal indicating an updated, unblocked amount of the funds limit.

4. The method of claim 3, wherein the message indicating the updated, unblocked amount of the funds limit is only sent if the unblocked funds limit falls below or rises above a threshold amount.

5. The method of claim 1, further comprising the step of: continuing with the funds aggregation following removal of the payment account from the deny list.

6. The method of claim 1, wherein the funds limit of the payment account is set based on information detailing any existing funds in the payment account as well as information in the first message.

7. The method of claim 1, wherein the pre-defined blocked amount of the funds limit is equivalent to either an average value or a maximum value or a typical maximum value for the actual amount of funds used at the first terminal.

8. The method of claim 1, wherein the step of setting or adjusting the funds limit additionally takes into account any deposit that may previously have been paid into the payment account.

9. The method of claim 1, further comprising the step of: sending the funds aggregation and clearing the payment account of any remaining blocked funds and adjusting the funds limit accordingly.

10. The method of claim 1, wherein the authorisation or pre-authorisation request and the second message comprise a single message.

Description

BRIEF DESCRIPTION OF DRAWINGS

(1) Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

(2) FIG. 1 is a diagram showing the parties involved in known payment card pay as you go transaction models for transit applications and a simplified version of how they interact;

(3) FIG. 2 is a diagram showing the parties involved in payment card pay as you go transaction models for transit applications in accordance with an exemplary embodiment of the present invention;

(4) FIG. 3 is a diagram showing the parties of a known system such as the system of FIG. 1, but in greater detail;

(5) FIG. 4 is a diagram that shows a system, such as the system of FIG. 2, but in greater detail in accordance with an exemplary embodiment of the present invention;

(6) FIGS. 5 to 24 show the interactions between a top up terminal, a transport payment terminal, a retail payment terminal and a prepaid account managed by a PPAM via an intermediary network in accordance with an exemplary embodiment of the present invention.

DETAILED DESCRIPTION

(7) The present invention provides a system and computer implemented method that prevents the above outlined scenario, namely where a user is unable to make a journey until they have been removed from a Deny List, which can occur in known payment card pay as you go transaction models and where a user wishes to manage their balance close to zero (e.g. with only the fare required to make their journey).

(8) It should be noted that whilst the drawings show the use of the system in a transit system, it is not to be taken that this is the only use of the invention. For example, the invention may be equally applicable to loyalty scheme systems.

(9) FIG. 1 is a diagram showing the parties involved in known payment card pay as you go transaction models for transit applications and a simplified version of how they interact. FIG. 1 depicts a user 101 who holds a prepaid account with a prepaid account manager (PPAM) 102 that manages the current cleared and uncleared balances of the user (101), a transit agency infrastructure (TAI) 103 comprising transaction infrastructure (including payment terminals and top up terminals) supported by a transit back office all belonging to a transit agency and which manages the Deny List, and a cognitive transit aggregator 103a responsible for (amongst other things) fare calculation. The cognitive transit aggregator 103a may be managed by the transit back office and may be owned and operated by the transit agency, or it may be operated by a third party provider.

(10) FIG. 1 shows how a user's first tap in (step 1), in this instance to undertake a rail journey, on a given day at the transit infrastructure 103 (i.e. at a contactless terminal). Once the card is tapped at a reader or validator, it is locally authenticated using standard Chip card technology to authenticate the card and it is determined whether or not the card is on the Deny List. A zero value transaction is also performed. If the card is successfully authenticated, the zero value transaction is successful and the card is not on the Deny list, the user 101 will be allowed to commence their journey. Data associated with the tap is then sent to the transit infrastructure 103. Once the tap data arrives at the transit infrastructure 103, the cognitive transit aggregator 103a will examine the tap data and determine if an initial authorisation is required. Upon a set of pre-defined risk-based rules, the cognitive transit aggregator 103a may then initiate an initial authorisation request (step 2). That initial authorisation request commonly includes a request for authorisation of a nominal amount of, say, 0.10 and may include other indicators in the transaction message so that the PPAM 102 (or indeed any issuer) can clearly identify the transaction as a transit aggregation transaction. The request is sent to the PPAM 102 by the TAI 103. The PPAM 102 may then block an amount from the user's account for which it is accepting liability (not shown), e.g. 20, and responds with an authorisation response (step 3) that it sends back to the TAI 103. If the PPAM 102 has approved the transaction, then the user 101 may continue to travel unabated, however should the PPAM 102 decline the transaction then the user 101 should be added to the Deny List (not shown) and prevented from making any further journeys until such time as they have restored their account to good standing

(11) When the user taps out at the end of their rail journey (step 4), again at the TAI 103, the cost of the journey is recorded by the TAI 103. The user 101 may undertake several further journeys, for example a bus journey (step 5), which is set at a fixed price and only requires a single tap, and a further rail journey (steps 6 and 7), which requires a tap in at the beginning of the journey followed by a tap out once the journey has been completed. The transit aggregator 103a adds up the total amount of journeys.

(12) Typically, at the end of a given day (i.e. after the last possible journey in the given day has been completed), a clearing process is undertaken (step 8) where all of the aggregated costs are debited from the user's account (not shown). The clearing process may equally take place at any point in a given day. It is also possible in some systems where one authorisation (step 2, step 3) may permit multiple clearings (step 8) over several days. Such systems are known and some transit agencies, such as TfL are planning to implement such systems in the near future.

(13) Note that in some instances, steps 2 and 3 may be bypassed on a given day if the card scheme rules allow (e.g. either by the TAI 103 not undertaking a clearing process on a daily basis and allowing the aggregation to continue across multiple days or the TAI 103 enabling a clearing process to take place multiple times per single authorisation. In this latter case, subsequent risk management authorisations will be required from time to time).

(14) FIG. 2 is a diagram showing an embodiment of this invention. The parties involved are the same as those of FIG. 1. However, an enhanced bilateral communication between the TAI 103 and the PPAM 102 has been introduced.

(15) Steps 1 to 4 are similar to the steps taken in the system of FIG. 1. The user's first tap in (step 1) of a given day at the transit infrastructure 103 initiates an initial authorisation request (step 2) which is sent to the PPAM 102 by the TAI 103however, as in FIG. 1, the user will be permitted to travel so long as their card is genuine and they are not on the Deny List.

(16) In this invention, however, rather than sending a nominal amount, e.g. 0.10, the TAI 103 sends an amount representing a normal maximum fare from their current location (for example the TAI 103 may determine that from the user's current location the typical user will not pay more than 6.50, however there may be an absolute maximum fare that may be significantly higher than this amount but this would only be carried out by a very small minority of passengers. In this example, the TAI 103 would include 6.50 as the transaction amount in step 2). The PPAM 102 then blocks an amount from the user's prepaid account equivalent to this normal maximum fare and responds to the authorisation request with an authorisation response (step 3) which it sends back to the TAI 103.

(17) The authorisation response may include the available balance of the user. The TAI 103 may interpret the authorisation response in step 3 in the same way as it was interpreted in FIG. 1 (i.e. an approved authorisation allows the TAI 103 to start a new aggregation period whereas a declined authorisation would typically involve the TAI 103 from blocking the user from subsequent travel (e.g. by the use of the Deny List)).

(18) When the user taps out (step 4), again at the TAI 103, the cost of the journey is recorded by the TAI 103. However, following step 4, the TAI updates the PPAM by sending information indicating the cost of the last journey made by the user 101 (step 4a). Once the cost of subsequent journeys 5 and 6/7 is known they are again aggregated, as in the model of FIG. 1, however, the TAI 103 now sends the aggregated cost and/or the individual journey cost to the PPAM 102 (steps 5a and 7a). Accordingly, the PPAM 102 is provided with detailed information of the user's transit activity throughout the day. This information enables the PPAM 102 to produce much more detailed risk analyses of the users to which it provides prepaid accounts.

(19) At the end of a given day, a clearing process is undertaken (step 8) where all of the aggregated costs are debited from the user's account (not shown).

(20) Additionally (and not shown in FIG. 2), the PPAM 102 may send messages to the TAI 103 indicating that the user's available balance has dropped below one of a set of pre-defined thresholds. The TAI 103 may then decide to prevent the user from travelling until such point as the PPAM 102 informs the TAI 103 that the account is once again in good standing. Another message that may be sent to the TAI 103 may be to indicate that a card has been reported as lost/stolen.

(21) FIG. 3 is a diagram showing the parties of a known system such as the system of FIG. 1 in greater detail, namely, the TAI 103, the PPAM 102 and an intermediary network 201 which further comprises an acquirer interface platform 206 and a PPAM interface platform 207 such as the MasterCard Interface Platform. These interface platforms facilitate the communication of the TAI 103 and the PPAM 102 with the intermediary network 201. The TAI 103 comprises a transit back office 202, transaction infrastructure 203 and an acquiring account manager 204. The transaction infrastructure 203 may be part of the transit agency's systems or may be outsourced to a separate service provider. The acquiring account manager 204 is a third party that provides a mechanism to allow a merchant (e.g. transit agency) to send transactional data across a payment network (e.g. intermediary network 201) to an issuer (e.g. PPAM 102) for authorisation, clearing and settlement and which interacts with the PPAM 102 on behalf of the transit agency. Also shown are an exemplary terminal 205 which is part of the TAI 103 and a payment card (payment card) 208 held by to the user 101.

(22) It will be understood that, wherever the use of a form of payment card is described throughout the description, any payment device with suitable contactless payment functionality is also envisaged. For example, a mobile phone, tablet computer, key fob, sticker, watch, bracelet or any other device contained within a non-card form factor and with contactless payment functionality may be used.

(23) Although the specific examples described refer to a prepaid account and a prepaid account manager (PPAM), the invention may also be applied to any suitable form of payment account, linked to a payment device. Thus, for such payment accounts, the PPAM is more generally referred to as a payment account manager (PAM).

(24) FIG. 3 shows how the TAI 103 communicates with the PPAM 102 via intermediary network 201. This simplified diagram shows the exemplary steps of the first tap in authorisation request (step 2), the authorisation response (step 3) and the end of day clearing (step 8).

(25) A disadvantage of such systems as described in FIG. 3 for use in systems as described in FIG. 2 is that the load on the acquiring account manager 204 as a result of any intermediate aggregation messages and any Deny List management actions may be considerable, especially during peak use of the transit agency's transport system. The third party acquiring account manager 204 is thus likely to pass on the additional cost for dealing with this load to the TAI 103.

(26) FIG. 4 is a diagram that shows a system according to an embodiment of this invention. The system of FIG. 4 is similar to the system of FIG. 3, but further comprises an additional transaction infrastructure interface platform 301 which enables direct communication between the transaction infrastructure 203 and the PPAM 102 via the intermediary network 201.

(27) As such, the load on the acquiring account manager 204 is avoided and, as a result, any potential additional costs to the acquiring account manager 204 are also avoided.

(28) Alternatively, a direct connection between the transaction infrastructure 203 and the PPAM 102 may be created.

(29) In order to remain compliant with industry standard security requirements (such as Payment Card Industry Data Security Standard (PCI DSS)) the TAI's transit back office 202 and their readers 205 may implement some way of obfuscating the card number (Primary Account Number or simply PAN). Typically an existing form of tokenisation may be employed whereby the PAN is fed into a mathematical algorithm to create a [reasonably] unique identifier. Such an identifier should not readily allow any malicious individual or group to retrieve the original PAN.

(30) Such tokenisation allows an easy way for TAIs 103 to manage their PCI requirements, however there remains a need to translate the tokenised card details that are used whilst travelling and in the fare calculation back into the original PAN such that it may be used to facilitate a payment transaction.

(31) This operation is typically done in a secured environment at the TAI'S transaction infrastructure 203. This process ensures that clear card data is never able to be retrieved at a card reader 205 (or any equivalent ticket/revenue inspection device) or via a member of the TAI's staff employed at the back office 202. Staff engaged at the transaction infrastructure 203 would likewise not typically be able to access the clear PAN data due to the secured environment.

(32) Alternatively, a direct connection between the transit back office 202 and the PPAM 102, via the intermediary network 201 and through an additional interface platform, may be created. This would require the transit back office 202 to handle the PCI DSS burden by implementing PAN tokenisation techniques similar to or the same as those described above.

(33) Alternatively, a direct connection between the transit back office 202 and the PPAM 102 may be created, however this would create the same PCI DSS issues as above.

(34) All of the alternative options also avoid the above mentioned load on the acquiring account manager 204 and, as a result, any potential additional burdens on the acquiring account manager 204 are also avoided. However such a configuration would still function with the other aspects of this invention and need not be entirely excluded by a TAI 103 wishing to implement this.

(35) The intermediary network 201 may be a network run by a third party such as the Banknet network run by MasterCard.

(36) Alternatively, a purpose developed application programming interface (API) or a purpose developed web API may be used instead of the intermediary network 201.

(37) FIGS. 5 to 24 are a series of flow diagrams which represent processes which exemplify the system and method of the present invention.

(38) Each of these Figures shows a clock which provides an indication of an exemplary time of day at which the process shown in that Figure might occur. The times shown are not required times and it will be understood that each process shown in each Figure may occur at any time of day.

(39) Whilst the uncleared funds are shown as split into uncleared retail spend and uncleared transit spend in some of these Figures (see e.g. FIG. 11), this is only for illustrative purposes and to ease understanding. The cardholder would preferably only see a single uncleared funds balance representing a total of all uncleared spend and a single open to buy balance representing any remaining available funds.

(40) Any amounts or thresholds for alerts are merely demonstrative and would likely be based upon an agreement between the transit agency and the PPAM.

(41) All of FIGS. 5 to 24 show the interactions between a top up terminal 501, a transport payment terminal 502, a retail payment terminal 502a and a prepaid account 503 managed by a PPAM 102 via the above mentioned intermediary network 201.

(42) The transport payment terminal 502 forms part of the TAI 103. There are likely to be multiple transport payment terminals 502 in any one TAI 103. The TAI 103 interacts with external entities and in FIGS. 5 to 24 where the transport payment terminal 502 is shown as sending and receiving messages, this is taken to represent the wider TAI 103 as a whole sending and receiving messages, not necessarily the transport payment terminal 502 itself.

(43) The top up terminal 501, transport payment terminal 502 and retail payment terminal 502a may all be part of the TAI 103 belonging to and/or be operated by the transport agency and such terminals may be located at premises belonging to the transport agency. However, the top up terminal 501 and retail payment terminal 502a would typically be operated by and/or belong to third parties, and be located outside of the transport agency premises, for example at a merchant retailer premises, and would typically be completely independent of the TAI 103. This invention looks at how use at these locations may (through the intermediary network 201 and the PPAM 102) be communicated to the TAI 103 in a suitable way (for example the TAI 103 need not be aware of the purchase a user made in the standard retail environment, but would need to be aware if that purchase meant that there were now insufficient funds for a journey on the network).

(44) Throughout this section where a top up terminal 501 is referred to as a terminal, it should also be taken to mean the top up location. Typically terminals do not communicate directly with the intermediary network 201. For the exemplary purposes and those of simplicity the merchant and their acquirer are excluded from the drawings and explanations, but should be taken to form part of the top up location or top up terminal 501.

(45) The above also applies to the retail location and retail terminal 502a.

(46) Where any of these components are described as sending messages or information, for example to the intermediary network 201 or the PPAM 102, it should be understood this also refers to the TAI 103 as a whole sending the message or information.

(47) FIG. 5 shows a user 101 purchasing/acquiring a payment card 208 linked to a prepaid account 503 managed by the PPAM 102. The user 101 pays a deposit of 5 for the card and tops up the card with a further 20 at top up terminal 501. The deposit and top up amount may of course be of any suitable value and it will be understood that these values are illustrative only.

(48) A message is then sent by the top up terminal 501 to the PPAM 102 indicating that a top up of 20 has been made. The PPAM 102 then creates an open to buy (funds limit) in the prepaid account 503 of 20 and records also the deposit of 5.

(49) FIG. 6 shows a user 101 tapping their payment card 208 at a transport payment terminal 502 to begin a journey (tapping in). Here standard card checks are performed, these being any suitable known and/or currently used card checks, and the card is checked against a Deny List 601. If the checks are successful, the user 101 is allowed to commence their journey. The TAI 103 then sends a transit aggregation authorisation (or pre-authorisation) request to the PPAM 102 via the intermediary network 201.

(50) An amount representing a normal maximum fare from the specific transport payment terminal 502 is sent from the TAI 103 to the PPAM 102 alongside or as part of the authorisation or pre-authorisation request. An exemplary amount would be 7.50. The PPAM 102 would then block 7.50 from the open to buy (funds limit) of the prepaid account. The use of a normal maximum provides the PPAM 102 with information which enables it to better manage the open to buy balance of the user's account.

(51) As explained above, in existing transaction systems, the amount sent to the PPAM 102 for authorisation alongside or as part of the pre-authorisation request is just a nominal amount, such as 0.10. A known PPAM would then normally block the value for which they are accepting liability e.g. 20.

(52) Accordingly, the present invention provides the PPAM 102 with an indication of an accurate, appropriate amount to block from the prepaid account 103, whereas existing transaction systems do not. This has consequences for the account holder in that it is less likely that they will have a transaction denied for lack of funds and consequently provides a reliable mechanism for managing those users who manage their accounts with only sufficient funds for their travel (e.g. a balance close to zero).

(53) FIG. 7 shows the PPAM 102 sending an authorisation response back to the TAI 103 via intermediary network 201. The remaining open to buy (funds limit) may also be returned to the TAI 103. This may be retained by the transport payment terminal 502 for future use. Note that in this exemplary scenario the PPAM 102 has approved the transaction. In the event that the transaction were to be declined, the TAI 103 would typically add the user's card to the Deny List to prevent further travel.

(54) FIG. 8 shows the user 101 tapping their payment card 208 at a transport payment terminal 502 at the end of a journey (tapping out). The actual fare is worked out; which in this instance is 3, and is sent back to the PPAM 102 via the intermediary network 201. The PPAM then reduces the blocked/uncleared amount from 7.50 to 3. Here, any suitable adjustment may be made to account for any discrepancies between the nominal amount and the actual fare. The open to buy (funds limit) now stands at 17.

(55) FIG. 9 shows a user 101 tapping their payment card 208 at a transport payment terminal 502 to begin a further journey (tapping in). In this instance, no messages are required to be sent between the TAI 103 and the PPAM 102 because a suitable authorisation or pre-authorisation request has already been sent. The PPAM 102 is already aware, because of the earlier transaction, that the cardholder is travelling, and they therefore permit the transit agency to allow further travel.

(56) FIG. 10 shows the user 101 tapping out. The actual fare is communicated by the TAI 103 via the intermediate network 201 to the PPAM 102. In this instance, the fare is 5. The PPAM 102 then adjusts the blocked and open to buy (funds limit) amounts of the prepaid account accordingly, leaving 8 blocked and 12 open to buy.

(57) FIG. 11 shows the user 101 making a retail purchase using the payment card 208 at a retail purchase terminal 502a. A standard authorisation message is sent by the retail purchase terminal 502a via the intermediate network 201 to the PPAM 102 indicating the value of the purchase, which in this instance is 11.50. The PPAM 102 then blocks off a further amount, 11.50, from the open to buy as uncleared retail spend, leaving 50p in the open to buy.

(58) FIG. 12 shows the PPAM 102 sending a message to the TAI 103 via the intermediary network 201 indicating that there is now insufficient funds in open to buy (funds limit) of the prepaid account. The transport payment terminal 502 then adds the payment card 208 linked to the account to the Deny List. The updated Deny List is then communicated to the readers 502. This therefore allows the PPAM 102 and the TAI 103 to prevent the card being used for transportation until such time as the user 101 has made good their account 503 thereby reducing the associated liability risk for all parties involved, yet still providing a mechanism for a user to maintain a low balance and travel.

(59) In an exemplary embodiment, there may be provided different Deny List thresholds corresponding to differing minimum fares usually associated with different modes of transport. As such, the payment card 208 may be on the Deny List for more expensive modes of transport, but may still be able to travel on cheaper modes of transport if sufficient funds are available in prepaid account 503 to pay for the minimum fare.

(60) For example, a minimum train fare may be 3.50, but a bus fare may be 1.20. As such, a cardholder with 2.00 of open to buy in their PPAM account should be allowed to start a bus journey, but would not be allowed to start a train journey as their card has been added to a train Deny List for falling below the train Deny List threshold value.

(61) FIG. 13 shows the user topping up the card with a further 20 at top up terminal 501. A message is then sent by the top up terminal 501 to the PPAM 102 typically via intermediary network 201 indicating that a top up of 20 has been made. The PPAM 102 then adds an additional 20 to the open to buy (funds limit) in the prepaid account 503, which now stands at 20.50.

(62) Optionally, the intermediary network 201 connecting the top up terminal 501 to the PPAM 102 and the TAI 103 may forward the message received from the top up terminal 501 indicating that a top up of 20 has been made directly to the TAI 103.

(63) FIG. 14 shows the PPAM 102 sending a message to the TAI 103 indicating the current open to buy (available funds) of the prepaid account has been topped up (and optionally that it may now be above a threshold). The transit agency then decides, based on the transmitted information, whether the payment card 208 should be taken off the Deny List or, where multiple Deny Lists exist, all or selective ones of the Deny Lists.

(64) This could be done selectively where multiple Deny Lists exist which are associated with different minimum fare values, dependent upon the open to buy (funds limit) following the top up.

(65) Provided the payment card 208 is to be removed from the Deny List, the TAI 103 will then begin taking the payment card 208 off their Deny List. Depending on the communications infrastructure of the transit agency, this may take some time. Therefore, even though the card has been topped up, if the user's payment card 208 is still on the Deny List the user 101 when they start to travel, they will not be permitted to start their journey.

(66) Once the payment card 208 is removed from the Deny List, no further pre-authorisation request is triggered/required as the payment card 208 is purpose-issued and the previous aggregation may simply resume.

(67) FIG. 15 shows Deny List bypassing data being created at the TAI 103 following the decision of the transit agency to remove the payment card 208 from the Deny List or Lists. The Deny List bypassing data enables a payment card 208 to be used at a terminal even if the card is still on the Deny List. This is achieved through the TAI 103 preparing a piece of data and ultimately writing it back to the payment card 208. Once the data is securely written to the card (which may be done using existing techniques), then if that card is presented in the transit system whilst it is still on the Deny List, then this piece of data allows the payment card 208 to bypass the Deny List check and the card holder is granted access to the system. The fact that the bypassing data is on the card indicates to the TAI 103 and the terminal 502 that the payment card 208 and the associated account 503 are once again in good standing and that in this instance it is in fact safe to override the Deny List check.

(68) Where multiple Deny Lists exist which are associated with different minimum fare values, the Deny List bypassing data could selectively bypass Deny Lists dependent upon the open to buy (funds limit) of the prepaid account 503.

(69) The Deny List bypassing data is then sent to the PPAM 102 via intermediary network 201.

(70) Alternatively, the intermediary network 201 connecting the top up terminal 501 to the PPAM 102 and the transport payment terminal 502 may allow the TAI 103 to send the Deny List bypassing data directly to the top up terminal 501.

(71) FIG. 16 shows the PPAM 102 sending the Deny List bypassing data to the top up terminal 501 via intermediary network 201. The Deny List bypassing data is then written to the payment card 208 either over a contact interface or the contactless interface. The process of writing data securely to a payment card 208 may use existing methods.

(72) FIG. 17 shows the user 101 tapping the payment card 208 at the transport payment terminal (tapping in) 502 after a successful top-up with enough funds for travel, but before the payment card 208 has been removed from the Deny List or Deny Lists at the transport payment terminal 502. Previously, the user would have to have waited for the Deny List to be updated at the transport payment terminal 502 before they would be permitted to travel, but the Deny List bypassing data bypasses the Deny List and the user 101 is allowed to commence their journey.

(73) FIG. 18 shows the user 101 tapping out having completed their journey, which in this instance cost 4. The actual fare is sent back to the PPAM 102 via the intermediary network 201. The PPAM then changes the blocked/uncleared amount accordingly to a total of 23.50 leaving 16.50 of funds available.

(74) FIG. 19 shows the end of day clearing processes which take place at the end of the day clearing the uncleared amounts, leaving only the remaining 16.50 open to buy (funds limit) in the account, together with the deposit of 5.

(75) FIG. 20 shows a retail purchase being made by user 101 with a payment card 208 the next day. A standard authorisation request is sent by the retail payment terminal 502a to the PPAM 102 for a 6.50 purchase and the blocked/uncleared amount is adjusted accordingly to 6.50, leaving 10 in the open to buy (available funds).

(76) FIG. 21 shows a user 101 subsequently tapping their payment card 208 at a transport payment terminal 502 to begin a journey (tapping in). Here the standard card checks are performed and the card is checked against a Deny List 601. If the checks are successful the user 101 is allowed to commence their journey. The TAI 103 then sends a transit aggregation authorisation (or pre-authorisation) request to the PPAM 102 via the intermediary network 201.

(77) Again, a nominal amount representing a normal maximum fare at the TAI 103 is sent to the PPAM 102 alongside the pre-authorisation. An exemplary amount would be 7.50. The PPAM 102 then blocks that 7.50 from the open to buy (funds limit) of the prepaid account, leaving 2.50 in the open to buy.

(78) FIG. 22 shows the PPAM 102 sending an authorisation response back to the TAI 103 via intermediary network 201. Again, the remaining open to buy (funds limit) may also be returned to the TAI 103.

(79) FIG. 23 shows the user 101 tapping their payment card 208 at a transport payment terminal 502 at the end of a journey (tapping out). The actual fare is worked out, which in this instance is 13, and this is sent back to the PPAM 102 via the intermediary network 201. This exceeds the remaining open to buy (funds limit) and leaves only 2 of the deposit amount remaining (and a negative open to buy of 3).

(80) FIG. 24 shows the PPAM 102 subsequently sending a message to the TAI 103 via the intermediary network 201 indicating that there are now insufficient funds for the minimum fare. As a result, the payment card 208 would be placed on the Deny List at the terminal 502, as in the process described by reference to FIG. 12.

(81) The above mentioned process for removing the card from the Deny List as described by reference to FIGS. 13 to 16 may be repeated and the user 101 may continue to use their payment card 208. In this instance, any amount topped up to the card must first be used to pay off any spend in the deposit of the card before updating the open to buy with the remaining balance. For example, if the balance were 2.00 (2.00 of the deposit used) and the top up were for 20, the result would be a deposit of 5.00 and an open to buy of 18.

(82) The TAI 103 may itself be considered to be a terminal which consists of its constituent entities as outlined above.

(83) The flow charts and descriptions thereof herein should not be understood to prescribe a fixed order of performing the method steps described therein. Rather, the method steps may be performed in any order that is practicable. Although the present invention has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the invention as set forth in the appended claims.