Automatic data transfer.

(54) Title: AUTOMATIC DATA TRANSFER.

(54) Title: AUTOMATIC DATA TRANSFER.

(57) Summary

Described herein is a computer-implemented method for requesting a data transfer, the method comprises: transmitting a first request for a data transfer in response to use of a user device: determining that the first request for data transfer data has been rejected; detecting an event indicating that the data transfer in response to use of the user device can be accepted; and transmitting a second request for data transfer depending on the detection that the event has occurred.

(57) Abstract

Disclosed herein is a computer-implemented method for requesting a transfer of data, the method comprising: transmitting a first request for a transfer of data in response to the use of a user device; determining that the first request for the transfer of data has been declined; detecting an event that indicates that the transfer of data in response to the use of the user device can be accepted; and transmitting a second request for the transfer of data in dependence on detecting that the event has occurred.

AUTOMATIC DATA TRANSFER DESCRIPTION OF THE INVENTION

The present invention relates generally, though not exclusively, to automatic data transfer. According to one embodiment of the invention, a request for a data transfer is made only when an event has occurred indicating that the request is likely to be accepted. The requests include the rapid update of a list of device statuses that are denied the use of a system. In another embodiment, data is automatically transferred between systems to update the status lists for each system.

The transport systems of many large cities, including London, Paris and Singapore, require users to have a dedicated transport card to pay for their journey. It should be much more convenient for users of a transportation system who do not require such transit cards. The transportation system of some transportation agencies is therefore adapting to accept standard bank-issued cards, with payment for a journey made by the user as an online transaction. One problem that is experienced when allowing users to use a bank card to validly enter and exit a transportation system is that the time required to perform an online transaction with the user's bank card is longer than a duration of time acceptable to delay a user entering and exiting the transportation system.

Known implementations of transportation systems that allow users to pay for their journey with bank cards, therefore, they typically do not perform an online transaction with the cards with the user's entry and / or exit from the transportation system. The transport system securely only authenticates that each user card is a suitable card for payment and that the card is not on a list of cards that are denied access to the transport system, that is, a list of states . The list of states, which can be considered as a black list, includes details of cards that have balances to be paid and also details of cards that are denied travel for other reasons, such as the card that is reported as stolen or the card user who is prohibited from traveling on the transport system.

In order for the journey to be paid, the transaction is made by the purchaser of the transport system who sends a request to pay to the issuer of the user's bank card. The request is sent either when the user is traveling in the transport system or when the user has already left the transport system. If the payment request is denied by the issuer, the user is in debt to the transportation agency that provides the transportation system since they have consumed the travel services.In order to ensure that the debt is recovered, the transportation system typically adds the user's bank card details to the card's transport system status list. Therefore, the user is prevented from traveling on the transportation system until the outstanding balance has been settled.

One problem with the prior art of listing a user's status is that the user is not informed that their cards have been added to the status list and therefore has a bad experience when they refuse their next login attempt. to the transportation system. On the other hand, even if a user is aware that his card has been put on the status list, the user is required to go through the inconvenient process of manually performing a task before he is able to travel again.

In order to solve the above problems, automatic debt recovery can be performed. To perform automatic debt recovery, the transportation system automatically sends one or more additional requests to pay to the card issuer (through its acquirer). If one of those requests is approved by the issuer and payment is made, therefore, the transportation agency will automatically and typically remove the user's card details from the status list. Thus, a user can be added and removed from the status list without the user manually performing a task, or the user even recognizes that their card was entered into the status list. However, a problem experienced by known automatic debt recovery techniques is that it is highly speculative whether or not they will work. The number of requests allowed for the technique is typically limited and the acquirer can only guess a time to transmit each request and there is no way of knowing if the request is likely to work. On the other hand, requests for automatic debt recovery typically cannot begin until 4 days after a declined authorization of a transaction and a user may well attempt to ride the transportation system before an automatic debt recovery request has been submitted. .

Furthermore, with respect to the actual updating of the state list, the mechanism for updating the state list is inherently slow and restricted by the way the transport system obtains transaction data.

Therefore, there is a need to improve automatic data transfer in general.

According to a first aspect of the invention, a computer-implemented method for requesting a data transfer is provided, the method comprises:

transmitting a first request for a data transfer in response to use of a user device; determining that the first request for the data transfer has been rejected; detecting an event indicating that the data transfer in response to use of the user device can be accepted; and transmitting a second request for data transfer depending on the detection where the event has occurred.

Preferably, the method further comprises: generating the first request by a first system; wherein transmitting the first request comprises transmitting, by means of the first system, the first request to a third system by means of a second system; the second system is configured to transfer messages and data between the first and third systems; and the third system is configured to provide data that is transferred to the first system in response to the acceptance of the first and / or second request.

Preferably, the event comprises detecting a data transfer in the third system; wherein the data transfer is identified as corresponding to the use of the user device.

Preferably, the method further comprises transmitting an indication that the event has occurred to the second system and, optionally, the first system.

Preferably, determining that the first request for a data transfer has been rejected comprises detecting, by the second system, a message, transmitted from the third system to the first system, which rejects a request for the data transfer.

Preferably, the event comprises the detection of a message, transmitted from the third system to the first system, that accepts an additional request for data transfer.

Preferably, the method further comprises transmitting, by the second and / or third system, in response to detecting that an event has occurred, a message to the first system indicating that an additional request should be made.

Preferably, the method further comprises automatically transmitting the second request, by the first system to the third system, in response to receiving the message indicating that an additional request should be made.

Preferably the method further comprises receiving, by the first system, a message indicating that a request for a data transfer in response to use of a user device has been rejected; transmitting, by the first system to a fourth system, a message indicating that the request for the data transfer was rejected; and adding, by the fourth system, the user's identification information to a list of user devices that have been rejected for use by the fourth system.

Preferably the method further comprises receiving, by the first system, a message indicating that a request for a data transfer in response to use of a user device has been accepted; transmitting, by the first system to a fourth system, a message indicating that the request for the data transfer was accepted; and removing, by means of the fourth system, the identification information of the user device from the list of user devices that have been rejected for use by the fourth system.

Preferably, the first system is an acquirer; and the third system is a sender for the user device.

Preferably, the fourth system is a transportation system.

Preferably, the user device is at least one of a standard issue credit card, debit card, prepaid card, business card, charge card, mobile phone, sticker, watch, or key fob.

Preferably, the user device is any device capable of making contactless payments.

Preferably, such a step for transmitting a second data transfer request is also dependent on a desired determination of the data transfer.

Preferably, the method further comprises:

determining that the second request for the data transfer has been rejected; and repeating, until a request for the data transfer has been accepted, the steps of: detecting an event indicating that the data transfer in response to use of the user device can be accepted; and transmitting a request for data transfer depending on the detection in which the event has occurred.

In accordance with a second aspect of the invention, one or more systems configured to perform the method of any of the preceding claims are provided.

According to a third aspect of the invention, a computer-implemented method of updating a list of user devices is provided, the method comprises: sending, by a first system in response to the use of a user device, a request from a data transfer to the first system; sending, in response to receiving the request, a message rejecting the requested data transfer to the first system; detecting the message rejecting the requested data transfer; sending, in response to the detection, a message to a second system indicating to the second system that the requested data transfer to the first system was rejected; and adding the identification data of the user device to a list of user devices that denies their use in the second system.

Preferably, the method of the third aspect further comprises adding, in response to the first system that receives the message rejecting the transfer of data to the first system, the identification data of the user device to a list of user devices that denies its transfer. use in the first system.

Preferably, the method of the third aspect further comprises: detecting a message sent to the first system, wherein the message accepts a request for data transfer to the first system; sending, in response to the detection, a message to the second system indicating that a request for a data transfer to the first system has been accepted; and deleting, or changing the state of, the user device identification data from the list of user devices that denies its use in the second system depending on the receipt of the message.

Preferably, in the method according to the third aspect, the user device is at least one of a standard issue credit card, debit card, prepaid card, charge card, mobile phone, sticker, watch, key fob or any device capable of making contactless payments.

In accordance with a fourth aspect of the invention, a first system, second system, third system and fourth system are provided, wherein: the first system is configured to send, in response to the use of a user device, a request to the fourth system through the third system, wherein the request is for a data transfer to the first system; the fourth system is configured to send, in response to receiving the request, a message to the first system via the third system, wherein the message rejects the requested data transfer to the first system; the third system is configured to detect the message rejecting the requested data transfer and to send, in response to the detection, a message to the second system indicating to the second system that the requested data transfer to the first system was rejected; and the second system is configured to add the identification data of the user device to a list of user devices that denies its use in the second system.

Preferably, in the method according to the fourth aspect, the first system is further configured to add, in response to the first system receiving the message rejecting the data transfer to the first system, the identification data of the user device to a list of user devices that denies use on the first system.

Preferably, in the method according to the fourth aspect, the third system is configured to detect a message sent to the first system, wherein the message accepts a request for data transfer to the first system; the third system is configured to send, in response to detection, a message to the second system indicating that a request for a data transfer to the first system has been accepted; and the second system is configured to remove the identification data of the user device from the list of user devices that denies its use in the second system depending on the reception of the message.

Preferably, in the method according to the fourth aspect, the user device is at least one of a standard issue credit card, debit card, prepaid card, charge card, mobile phone, sticker, watch, key fob or any device capable of making contactless payments.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 shows a system according to a first embodiment of the invention;

Figure 2 is a flow chart of the first embodiment of the invention;

Figure 3 shows a system according to a second embodiment of the invention;

Figure 4 is a flow chart of the second embodiment of the invention;

A first embodiment of the invention provides an automatic data transfer operation that is performed shortly after an event has been detected indicating that the automatic data transfer is likely to be successful.

The first modality is particularly advantageous for requesting automatic debt recovery, as may be required by a transportation agency that provides a transportation system that users pay to use with a standard issue bank card. However, the modalities are in no way restricted to automatic debt recovery and may be applicable for automatic data transfer in general. On the other hand, the modalities are not restricted to applications with transportation agencies and are applicable in a wide variety of applications, such as people paying to enter a venue or stadium.

In addition, a second modality provides a technique to improve the speed and accuracy with which state lists from more than one transportation agency are updated.

The first modality is described below with reference to the automatic recovery of debts by a transport agency. Users of a transport system supported by the transport agency pay for their journeys with a standard issue bank card.

Figure 1 shows a system according to a first embodiment. The system comprises a transportation agency 101, an acquirer 102 of the transportation agency 101, a data transfer system 103, and an issuer 104.

Transportation agency 101 provides a transportation system, such as a city train or bus system. The transportation agency 101 is shown to comprise a list of states. The list of states includes details of bank cards that deny the use of the transportation system. Bank card details are securely stored and can be tokenized. The list of states may alternatively be provided by a separate system of the transportation agency 101.

The acquirer 102 of the transportation agency 101 is in communication with the transportation agency 101 and the data transfer system 103. The acquirer 102 is responsible for obtaining payments from the users of the transportation agency 101 and can be provided through the systems of the transportation agency 101 bank.

The data transfer system 103 is in communication with the acquirer 102 and the issuer 104 of each user's bank card. Although only one issuer 104 is shown, the data transfer system 103 may be in communication with many issuers of bank card schemes accepted by the transportation agency 101 to pay for the trips. In addition, the data transfer system 103 is also in communication with other acquirers than that of the transportation agency 101 and is capable of supporting other types of transaction between an acquirer 102 and an issuer 104, in addition to those of the agency 101 of transport. The data transfer system 103 transfers messages, payments and any other transaction data between sender 104 and acquirer 102 systems. The data transfer system 103 can be provided, for example, by a card scheme such as MasterCard® systems.

Sender 104 is in communication with data transfer system 103. The issuer 104 contains the amount of cards that a user has used to try to pay for their journey. Issuer 104 can be provided through bank systems.

A user uses his bank cards at the entrance of the transport agency 101. The card details are read and compared with the card details in a list of statuses. A plurality of versions of the state list can exist, with each state list stored locally in each of the respective plurality of card readers, or a single state list can be stored in a central location that is in communication with the plurality of card readers. If the card details are not in the list of states and the card is determined to be suitable for paying for the card user's journey, then the user's card is accepted and the user is allowed to use agency 101. transport. Because the time required to perform an online transaction is greater than what could be acceptable to delay the passage of a user at the entrance of the transport agency 101, which will be especially the case if real-time communication with the bank card issuer 104 is not available, the user is allowed to travel on the transportation system 101 before an online transaction has been completed to obtain payment for their journey.

The transportation agency 101 can only require users to present a bank card at the beginning of their journey and generate a transaction based on the card data read at the entrance of the transportation agency 101 alone. Alternatively, the transportation agency 101 may also require users to present their bank card at the exit of the transportation agency 101 and then generate a transaction depending on the card data read when a user leaves the transportation agency 101.

The user's card details are transmitted from the acquirer 102 with payment for the user's journey. In addition to the card details, other transaction data or payment data may be transmitted to the acquirer 102. The acquirer 102 receives the card details and sends a transaction request for payment from the card issuer 104.

If the request is accepted, a transaction response message approval is sent from issuer 104 to acquirer 102 and payment is made for the user's path.

If the transaction request is rejected, as could be the case if the user had insufficient funds to pay for their journey in their bank account, a response message is sent from the issuer 104 to the acquirer 102 informing the acquirer 102 that it has been rejected the transaction request.

After receiving a message that a transaction has been declined, the acquirer 102 sends a message to the transportation agency 101 to inform the transportation agency 101 that it was not possible to pay for the user's journey with the user's card. The transportation agency 101 then adds the user's card details to a list of card statuses that prevent the use of the transportation agency 101.

Once the user cannot make the journey, he is required to remedy the situation both with his issuer 104 and with the transport agency 101. There are several ways this can happen. A non-exhaustive list is as follows:

The user started through a website - in this case the transport agency 101 provides a website that allows the user to show their debts, and make attempts to pay them and restart the trip.

The user initiated through a call center in this case the transportation agency 101 provides a telephone call center that allows the user to listen to his debt, and make attempts to pay them and restart the trip.

The user initiated via a ticket vending machine - in this case the transportation agency 101 provides a ticket vending machine that allows the user to display their debts, and make attempts to pay them and restart the trip.

The user started through a ticket office / kiosk in this case the transport agency 101 provides a ticket office or attended cabin, which allows the user to show their debts, and make attempts to pay them and restart the trip.

The user started by means of an entry pass reader - in this case the transport agency 101 detects that the cardholder who wishes to travel and while, they are denied entry since their details are in the list of states, the agency 101 of Transport may take this as a sign that the user wishes to travel and as such initiates an attempt to recover the money owed and allow the user to restart the journey.

In addition to this, a transportation 101 agency may attempt automatic debt recovery transactions. Typically this may involve multiple attempts over an agreed period of time, and may not start until a few days after the debt is incurred.

All of these mechanisms have problems - whether they require the user to perform a set of actions (which can be complex, or difficult to understand, particularly for foreign visitors to a city), or the transport agency 101 is trying to recover debts. on a purely speculative basis and potentially incurring the transaction fees of its acquirer 102.

The modalities improve on techniques known to issuer 104 which automatically performs a debt recovery operation, while having a possible chance of success, so that the user's card details are quickly and automatically removed from the list. Of states.

The invention has realized that a common reason for a user account having insufficient funds to pay for a ride is due to depleted funds in the account on days before the user is paid their salary, typically in order of month. Therefore, the user can be expected to have sufficient funds to pay for their commute in the near future, when their salary is deposited into their account.

According to the first modality, an event is monitored to indicate that a user has sufficient funds in their account to make a payment that was previously declined. In response to the detection of such an event, an automatic debt recovery operation which is performed, since the event has occurred, can be expected to be successful. Therefore, a user card is quickly and automatically removed from the status list in response to payment.

In a first implementation of the first embodiment, the data transfer system 103 monitors messages transmitted from the sender 104 to the acquirer 102 via the data transfer system 103. When the data transfer system 103 detects that a message rejecting a transaction request is transmitted by the sender 104, the data transfer system 103 transmits both of the message to the acquirer 102 and also records that a transaction request was rejected by the acquirer 102. The data transfer system 103 therefore generates a record, or list, of card details such as Primary Account Numbers (the number stamped or printed on a payment card, also referred to as a PAN), and / or any other identification data, of cards that have had a rejected transaction request.

The data transfer system 103 monitors all transaction request messages that are transmitted over the data transfer system 103 between acquirers and issuers. If the data transfer system 103 detects one or more transaction requests comprising the card details of a card found in the registry, the data transfer system 103 monitors the response of the request sent from the issuer 104 of the card. card. If the response approves a requested transaction, it is detected as an event indicating that a user's account is once again in good standing and that the user likely has sufficient funds in their account to make a payment that was previously declined. .

An approved transaction can result from the user using their card to make any type of purchase. Since the transaction was successful, it is reasonable to assume that the user's account has had funds transferred into it, for example due to the user receiving his salary payment, therefore this is detected as an event.

Alternatively, a user may have a salary payment, or another source of input (which includes for example a transfer from another bank account of the same individual (for example, a savings account), or which includes a transfer from another individual ), transferred to your account as a charge to your card. The data transfer system 103 monitors for such a transfer for card details found in the registry and detects this as an event indicating that a user has sufficient funds in their account to make a payment that was previously declined.

After detecting any of the events described above, the data transfer system 103 sends a message to the acquirer 102 of the transportation agency 101 informing the acquirer 102 that it may be an appropriate time to perform an automatic recovery process of debts. In response to receiving this message, acquirer 102 automatically sends one or more transaction requests to sender 104 to retrieve payment for the user path. If one of those transaction requests is approved, the acquirer 102 automatically sends a message to the transportation agency 101 informing the transportation agency 101 that the user can be removed from the list of states.

In an alternative of the present modality, the acquirer 102 sends the determination that the user account is once again in a regular situation to the transport agency 101 and the transport agency, then determines whether or not to try to recover the debt. The acquirer 102 only sends one or more transaction requests to the issuer 104 to recover the payment upon receipt of an instruction to do so from the transportation agency 101.

A second implementation of the first modality is similar to the first implementation except that the issuer 104 that deletes a transaction request from the acquirer 102 of the transport agency 101 maintains such a record that includes details of cards that have had a transaction request rejected. Issuer 104 then monitors each card's account in the registry and detects events that indicate that a user has insufficient funds in their account to make a payment that was previously declined due to insufficient funds. For example, the issuer 104 detects as events a salary payment, or any other payment of funds, in the corresponding account of a card with its details in the register. After detecting such an event, the sender 104 sends a message to the data transfer system 103 which in turn sends the message to the acquirer 102 of the transport agency 101 informing the acquirer 102 that it is the right time to carry out a process of automatic debt recovery and the process proceeds as already described in the first implementation.

Advantageously, the second implementation may result in the acquirer 102 reporting that it is the right time to perform debt recovery faster than the first implementation since it is not necessary to wait for a user to perform a successful transaction, or for a user to receive a payment as a charge to your card, in order for an event to be detected.

A third implementation is a combination of both the first and second implementations described above. Both the sender 104 and the data transfer system 103 are capable of detecting an event and sending a message to the acquirer 102 of the transport agency 101 informing the acquirer 102 and the transport agency 101 that it is the right time to attempt a automatic debt recovery process.

Advantageously, the modalities quickly and automatically remove a user from the list of states without the requirement that the user have to perform any steps. In addition, the modalities provide a greater degree of certainty and it is speculated that there are fewer automatic debt recovery techniques. By waiting for an event that indicates that a user has sufficient funds in their account, the automatic debt recovery process is performed with a high probability of success. On the other hand, automatic debt recovery is initiated when the data transfer system 103 and / or the issuer 104 inform the acquirer 102 that it is the right time to carry out the process. When such a data transfer system 103 is implemented and / or the issuer 104 initiates the automatic debt recovery process, the acquirer 102 is not constrained by the operational restrictions of acquirers acting autonomously when performing an automatic debt recovery process. debts and are not provided with an indication that you are at the right time to perform an automatic debt recovery process.

A flow chart of a computer-implemented process is shown in Figure 2 according to the first modality.

In step 201, start the process.

In step 203, a first request is transmitted for data transfer in response to use of a user device. This can be initiated by a user who makes the entry pass with his card in a transport agency 101, in this way indicates that he wants to travel.

In step 205, the process determines that the first request for the data transfer has been rejected.

In step 207, the process detects an event indicating that the data transfer in response to use of the user device can be accepted.

In step 209, the process transmits a second request to recover the debt for the data transfer depending on the detection in which the event has occurred. If this is also rejected, the process can repeat steps 207 and 209 until the second request is accepted.

In step 211, the process ends.

A second mode is described below that improves how quickly the state lists are updated and thus their accuracy.

According to the second embodiment, a data transfer system 103, which may be the data transfer system 103 as shown and described with reference to Figure 1, is used to update a plurality of lists of states of a plurality respective systems. For example, the data transfer system 103 updates the state lists of the transportation agency 101, as shown in Figure 1, as well as the state lists of other transportation agencies, or any other systems that have their own. state lists. The data transfer system 103 can be provided, for example, by a MasterCard® system.

The second embodiment is described below with reference to the data transfer system 103 which updates a plurality of status lists of a respective plurality of transportation agencies. However, this is exemplary only and the state lists can be from any type of system.

Figure 3 shows a data transfer system 103, and a plurality of additional systems, according to the second embodiment.

TAI, TA2, TA3 and TA4 are all transportation agencies and each transportation agency can be the agency

101 of transport as described by the first mode. Transportation agencies 101, 301, 302 and 303 can provide different modes of transportation, such as train or tram, and / or operate over different regions. Although four transportation agencies are shown in Figure 3, any number of transportation agencies can be supported. Each of the transportation agencies TAI, TA2, TA3 and TA4 comprises an acquirer 102 and a transportation system as described by the first embodiment. Furthermore, each of the transport agencies TAI, TA2, TA3 and TA4 may use the services of the same acquirer 102, or may use a different acquirer, or some may use one acquirer and some may use another. All acquirers connect to the data transfer system 103.

Each transportation agency is in communication with the data transfer system 103 through its respective acquirer. The data transfer system 103 is also in communication with one or more or all of the issuers that support transactions through the user cards of each transportation agency.

Each transportation agency maintains its own version of a state list that comprises details of the cards denied from the transportation agency's use. Each list of states can be as described by the first mode. The data stored within each status list can be any card details, such as a Primary Account Number, PAN, which can be stored in a tokenized form and can even include card details such as expiration date and expiration date. numerical sequence of the card within such a token.

As described by the first modality, a transport agency TAI sends a request for payment to an issuer 104 through its acquirer and the data transfer system 103.

The issuer 104 sends a message back to the TAI, via the data transfer system 103 and the relevant acquirer, informing the TAI that the requested payment is rejected. The TAI then adds the card to a list of TAI states.

According to the second modality, the data transfer system 103 detects the message that rejects the payment that is sent from the issuer 104 and automatically sends a message to TA2, TA3 and TA4 that informs those other transport agencies that a request was rejected. request for payment made with the card. In response to the receipt of the message from the data transfer system 103, TA2, TA3 and TA4 then it may be decided to add the card to its status lists as well. Therefore, a user card can be added to a list of states of a transport agency even though the user has not had problems in paying for a trip with that specific transport agency. Advantageously, each transport agency is able to quickly update its list of states to avoid traveling a user who is unable to pay for their journey.

The data transfer system 103 also generates a record comprising details of the cards that have had a declined transaction. The data transfer system 103 then monitors the messages sent on the data transfer system 103. If the data transfer system 103 detects a message from an issuer 104 that is an approval of a payment for one of the registered cards, the data transfer system 103 then sends a message to all transport agencies informing that that it is a transaction that has been approved by the card. In response to receiving the message, each of the transportation agencies can then remove the card from their status list. Advantageously, a user card can be automatically removed from all status lists.

In an alternative implementation, before a card is removed from a list of states, a transportation agency can also determine if there is any payment due thereto from the card issuer 104. Only transportation agencies for which there is no payment limit then could automatically remove the card details from their list of states while transportation agencies that still require payment could keep the card on their list of states. Transportation agency can even carry out an automatic debt recovery operation, if required, in response to receiving the messages.

Advantageously, the state lists of a plurality of separate systems are updated quickly and automatically.

A flow diagram of a computer-implemented process according to the second modality is shown in Figure 4.

In step 401, start the process.

In step 403, the process sends, by a first system 101 in response to the use of a user device, a request for a data transfer to the first system 101. This can be initiated by a user making the entry pass with his / her card in a transport agency 101, thus indicating that you want to travel.

In step 405, the process sends, in response to receiving the request, a message rejecting the requested transfer of data to the first system 101.

At step 407, the process detects the message rejecting the requested data transfer.

In step 409, the process sends, in response to the detection, a message to a second system 301, 302, 303 indicating to the second system 301, 302, 303 that the requested transfer of data to the first system 101 was rejected.

In step 411, the process adds the user device identification data to a list of user devices that denies their use in the second system 301, 302, 303.

At step 413, the process ends.

Many modifications and variations can be made to the embodiments described above without departing from the scope of the invention.

For example, the second mode has been described with messages that are sent to and from transportation agencies. Experienced individuals may understand that the payment request messages and response messages could be sent and received by an acquirer from each of the transportation agencies. The acquirer for each transportation agency can be provided within the transportation agency, as shown in Figure 5. Alternatively, each acquirer can be provided separately from the shipping agency, as shown in Figure 1.

In both the first and second modes, the messages communicated through the data transfer system 103 can be a Standard Authorization Request, Approving Responses and Rejecting Response messages as known in data transfer systems.

In the embodiments described above, one or more respective system state lists are maintained. Each system can also have a white list that includes details of the cards that will never be denied use by the system. Also, when a payment is received that corresponds to the details of a card in the list of states, so that the card is prevented from being used by a transportation agency, the card details may only have their status changed to allow have the card used by the transportation agency rather than actually removing the card details from the list.

Through the methods described above, users who make payments using cards are described. The card can be any standard issue bank card, such as a credit card, debit card, prepaid card, business card, or charge card. The modalities are not restricted to the use of cards and more generally include the use of any user device that can pay for the use of a system. The user device can be, for example, a mobile phone, sticker, watch, keychain, or any other cardless form factor that is capable of contactless payments.

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