MX2010001392A - Method of providing secure payment and transaction reconciliation. - Google Patents

Abstract

A method of paying a merchant for a transaction associated with a program. The method including the steps of receiving a request from a merchant for a payment associated with a purchase, generating a payment identifier, generating a payment number having a predetermined limit amount and a predetermined expiration date, associating the payment identifier with the payment number and transmitting the payment number to the merchant for payment of the request.

Description

METHOD TO PROVIDE SAFE PAYMENT AND RECONCILIATION OF TRANSACTION DESCRIPTION OF THE INVENTION CROSS REFERENCE TO RELATED REQUESTS This application is a continuation in part of the U.S. Patent Application. No. 10 / 708,247 titled "Method to Provide Secure Payment and Reconciliation of Transaction" filed on February 19, 2004, which claims the priority benefits of the U.S. Provisional Patent Application. 60 / 481,140 entitled "Method of Reconciliation of Stored Value Card" filed on July 25, 2003, being that the content of these requests is incorporated in this document by reference.

FIELD OF THE INVENTION The present invention relates to data processing for financial operations. More specifically, this invention relates to a method for providing protection against fraud and reconciliation for credit card transactions.

BACKGROUND OF THE INVENTION In the traditional credit card processing industry, fraudulent charges to credit cards and surcharges are a common experience. It is not uncommon to charge a customer's credit card by a merchant or to present an unauthorized charge to the card, either intentionally or unintentionally. The fraudulent charge can be directed to the credit card company that issues the card. However, the process is time consuming and does not provide a refund guarantee to the customer. In addition, frequently in a fraudulent dispute the client does not realize the fraudulent charge until the reconciliation at the end of the period covered by the account statement, which results in an additional delay with respect to the resolution on reimbursement. Surcharges present a different problem. Most companies set a maximum limit for surcharges (overdrafts). When the charges exceed the limit the merchant is contacted and a reversal or settlement is requested. This also occurs at the end of the period covered by the statement, which results in further investigation of the charges due to the time elapsed.

In a typical surcharge scenario, a merchant fails to charge a credit card administrator with a portion of a transaction, such as towing a vehicle to a repair shop as part of a repair. To correct the oversight the credit card is passed a second time for an amount of sixty-five dollars of towing charge. The second charge results in a surcharge condition that is not evident until the two individual charges are reconciled at the end of the period covered by the statement. In another scenario, an additional ten dollars is charged initially to the credit card because the merchant knows that ten dollars is not enough to cause a dispute, which results in a fraudulent credit card surcharge.

The largest expense incurred when using a credit card to make payments is the consumer time process of reconciling the credit card statement with the payments that were processed in this way. In many large credit card management organizations there is a whole group of individuals who are dedicated to this task. The investigation indicates that at least one person is required for one week per month to reconcile a statement with no more than three hundred charges. If a charge can not be reconciled, additional personnel are involved with an additional expense to determine how to cancel the net balances.

The purchase cards are known in the art as a means to expedite the traditional processes of order of purchase and payment of transactions of little value. Users, typically corporations and government agencies, are aware that a disproportionate number of payments of a few dollars, those less than $ 1,000, constitute the majority of payments, since they represent a small percentage of the total dollars spent. The cost per transaction to make these payments using the traditional process is the same regardless of the dollar amount of the payment. Frequently the cost of making the payment exceeds the value of the object purchased. A purchase card simplifies the process and reduces the cost per transaction.

A purchase card can be used to track charges that were made by purchasing agents, and large corporations use them very widely to track the activity of buyers. The merchant's card device identifies that the card being processed is a purchase card that requires a code to be entered after the card is passed. This code can be provided in the billing report to assist in reconciliation. However, purchase cards are only effective to provide an improvement in reconciliation if used with a merchant whose card point of sale system requests the purchase code. Most point-of-sale card readers are not programmed for this functionality. Additionally, a purchase card does not provide protection against fraud or surcharge.

It is also known in the art to add an authorization code field to the claims record in the administrator database. In this scenario, those individuals responsible for payment to the merchant or claims examiners supply the merchant with the card number and the authorized amount, and then wait for the merchant to swipe the card. When the purchase is completed and the authorization is printed, the merchant reads the authorization code to the examiner and the examiner types the code into a data field associated with the payment. Reconciliation can be done by matching the authorization codes of the credit card statement with the authorization codes in the payment file.

Although the incorporation of authorization codes has been accredited so far as the most effective method of improving reconciliations, it consumes an extremely long time. In this process, the credit card administrator spends three to five additional minutes on the telephone for payment, resulting in higher work and capital expenses. The incorporation of authorization codes does not provide a guarantee of reconciliation. Even by incorporating this method that consumes time in the credit card process it is demonstrated that at most it is only possible to reconcile 85% of the payments. Additionally, the incorporation of the authorization codes does not provide protection against fraud or surcharge.

In a specific example that refers to an insurance claim, when an insured client needs repair or replacement of a product, many service institutions require the insurance company to provide a credit card so that immediate payment is made. While the insurance company may prefer to send a check, the delay in printing, delivering, depositing and accessing these funds is not attractive to the service provider. The benefit of receiving credit card information is the speed with which funds and payment can be guaranteed.

The insurance company can adopt several ways to proceed when providing information about credit cards. The insurance company can fax the credit card number to the service institution with the authorized amount, or call the service institution by telephone and read the number by phone. Frequently, the service institution and the insurance company may not agree on the charges that each considers appropriate. For example, in the event of a breakdown of a vehicle the insurance company may agree to pay for a new water pump for the car, but not with the crane charge to tow the vehicle to the service shop. Frequently, once you are in possession of the credit card information the service institution will charge jobs not authorized by the insurance company. Alternatively, the service institution may debit less in view of the authorized amount. The inconsistency and fraud that is perpetrated against the insurance company and the credit card institution that issued the card result in substantial losses, particularly in view of the substantial amounts involved in warranty claims.

When the insurance company receives the credit card bill, the information contained in the account statement is severely limited for reconciliation purposes. A single credit card statement from an insurance company may contain thousands of different claims charges. Matching each charge by service institution and quantity is often cumbersome, if not impossible. As mentioned above, service institutions can recharge or debit less than the authorized amount. Therefore there are no matching transactions to reconcile. In addition, if the service institution is a franchise, it may be that multiple claims are charged under the same franchise name, with which reconciliation becomes even more difficult.

What is required in the industry is an improved means by which customers can make payments to a merchant that provides additional protection against fraud and surcharges while eliminating the need to track authorization codes and purchase codes. A payment method is required that provides a quick payment to the merchant while also allowing the payment service administrator to reconcile the commercial payments to the merchants and to the corresponding transactions.

SUMMARY OF THE INVENTION The old, hitherto unsatisfied need for a method to provide payments to merchants that reduces fraud and provides reconciliation benefits is now fulfilled by a new, useful and not obvious invention.

The present invention is a method of providing an undoubted payment number for the purpose of replacing the current process for payments to merchants via credit card. A fixed limit amount is associated with the payment number. The payment number also includes the ability to specify variable expiration options, the ability to trace directly to the transaction, and the ability to load into existing payment management systems. It is within the scope of the present invention to both provide a payment number in physical form, as commonly associated with a credit card or purse card, or a virtual payment number that does not exist in physical form, as is commonly used in online transactions.

In accordance with the present invention, a method for paying a merchant is provided. The method includes buying a product or service from a merchant by a member of a program, receiving a request from a merchant for a payment associated with the purchase, generating a payment identifier, generating a payment number having a predetermined limit amount and a default expiration date, associate the payment identifier with the payment number and transmit the payment number to the merchant for payment.

The payment identifier of the present invention may include the payment number, a contract number associated with the program, an identifier for the program member, a confirmation of the charge of the predetermined limit amount, the associated limit amount, and the date expiration of the payment number. It is within the scope of the present invention to store additional data with the payment identifier to include the merchant's number, the purchase order number or any other useful features to identify the transaction.

After the payment identifier has been established and associated with the payment number, the payment number is provided to the merchant for payment of the purchase. The merchant then uses the payment number to submit a transaction amount associated with the service provided. The merchant receives the payment and the merchant payment is tracked, and due to the association provided by the payment identifier the transaction is automatically reconciled with the payment number and the payment identifier.

In a further embodiment of the present invention it is possible for a payment number to be used only for a single transaction. After the payment number is submitted by the merchant for the payment of a transaction, the predetermined limit amount becomes zero and the card expires. Then any remaining funds associated with the payment number are downloaded and dissociated from the payment number in a program determined by the program administrator.

Additionally, the merchant's payment request can also be assigned an acceptance code. The acceptance code is used to provide either approval or denial of the limit amount associated with the payment number transmitted. The acceptance or denial is based on the availability of funds for payment. The method of the present invention also includes verification of a valid date based on the expiration date associated with the payment number. The acceptance code is associated with the payment identifier, eliminating the need to reconcile the transaction report.

In accordance with an embodiment of the present invention the method further includes requesting a fund load equal to the predetermined limit amount, executing the fund load, generating a confirmation of the execution of the fund load and reconciling the payment number and the payment identifier with the confirmation of the execution of the loading of the funds.

In accordance with a further embodiment of the present invention, a payment number having a predetermined limit amount and a predetermined expiration date of a predetermined group of payment numbers is selected. Accordingly, the payment number can be reused after a sufficient time to ensure that all transactions that are associated with a particular payment number are reconciled. Additionally it is possible to assign a group of payment numbers to a specific program administrator.

The method of the present invention can be used to provide payment to a merchant in relation to a multitude of program purchases, including an insurance claim or a warranty claim.

The payment number according to the present invention can be a credit card number, a prepaid card number, a debit card number, a check card number or a purse card number.

In another embodiment of the present invention, a method for paying a merchant a claim service provided to a claimant is provided, the method includes receiving a request from a merchant for a payment associated with a claim, the request further comprising an estimate of the cost of the repair, verify that the request received from the merchant is covered by a contract associated with the claimant, establish a predetermined limit amount for the repair, generate a claim identifier, select a payment number, being that the payment number has the predetermined limit amount and a predetermined expiration date, associate the claim identifier with the selected payment number, transmit the payment number to the merchant for payment of the claim, provide the funds for the predetermined limit amount associated with the selected payment number, trace a transaction amount transaction associated with the selected payment number and associate the payment number and the claim identifier with the amount of the transaction, thereby eliminating the need for subsequent reconciliation. Accordingly, the method further includes tracking a multitude of transaction amounts and the association of the payment number and claim identifier with the multitude of transaction amounts.

In one embodiment of the invention, the merchant provides an estimated cost of the repair. The estimated cost of the repair can then be used to determine the limit amount associated with the payment number. The limit can be equal to the estimate provided by the merchant, or the limit amount can also be based on limit amounts that in the industry are associated with similar types of repairs.

When a request is received from a merchant it is possible to provide verification of coverage. Verification of coverage provides the merchant with a guarantee that the services provided to the claimant are covered by a valid contract with a program administrator. Then the claimant's contract number can be associated with the claim number that must be included in the claim identifier.

An advantage of the present invention is the elimination of surcharges due to fraud or carelessness. The present invention establishes a predetermined limit amount and an expiration date that are associated with the payment number. Providing this merchant payment number eliminates the possibility of a surcharge for the service provided because the amount of the authorized charge is limited by the predetermined limit amount.

Another advantage of the present invention is the elimination of the costs associated with the reconciliation process. In accordance with the present invention, a payment identifier is associated with each payment number. By associating the payment identifier with the payment number the program administrator can easily reconcile the transactions to the appropriate transactions, thereby greatly reducing the time for reconciliation required by the prior art methods.

The method according to the present invention eliminates the entire reconciliation process by associating the application for deposit of funds, the confirmation of the charge, any rejection of the card and the purchase transaction with the current details of the claim or transaction for the reconciliation of electronic and immediate payment.

The method in accordance with the present invention eliminates the entire check processing scenario that is commonly associated with the payment of warranty and insurance claims. When a load of funds is requested, the administrator is returned within a few seconds the card number, the expiration date of the card and the confirmation that the funds were loaded correctly.

In additional aspects the present invention provides a system for notification of variation of payment in program contracts. The payment variation notification system communicates with program managers and financial institutions via a network. The system includes a memory that stores a set of instructions and data related to a plurality of authorized program payments and a processor to run the set of instructions. The processor is in communication with the memory and the network. The processor is operative to facilitate reconciliation and notifications of payment deviation to program administrators. The processor performs this function through the operations of (1) receiving data for payment authorization from the program administrator's computer, where the data includes one or several payment identification elements and a quantity of charge, being that the combination of payment identification elements uniquely identifies a transaction and constitutes a first transaction identifier, (2) receiving data for the payment transaction from the financial institution's computer, where the data includes a second transaction identifier and a transaction amount to be paid, being that the second transaction identifier may be either the first transaction identifier or a payment identification number, (3) compare the data of the load amount of the administrator's computer of the program and the amount of the payment transaction of the computer of the financial institution to identify For example, the notification of the deviations between the amount of the payment transaction and the amount of charge substantially contemporaneous with the detection of these deviations in the comparison stage, the notification comprising the first transaction identifier and the amount of the payment transaction, and (5) store the data received from the bank's computer for subsequent dissemination to the program administrator.

In an advantageous embodiment of the payment variation notification system, the processor is operative to transmit payment authorizations to one or more merchants. The payment authorizations may include the second transaction identifier and a loading amount.

In additional embodiments of the payment variation notification system, the processor is operative to transmit payment by fax to one or more merchants. Payment by fax can include a transaction identifier and a charge amount. Advantageously, the processor is operative to transmit notification to the program manager of a failed payment by fax transmission, the notification comprising the first transaction identifier. The notification may also include the time and description of the failed transmission. The notification may also include a fax number associated with the failed transmission.

In additional embodiments of the payment variation notification system the processor is operative to transmit an authorization to a merchant. The authorization may include a payment card number and an authorized amount. The payment card number can be operated in a card processing system, and the authorized amount corresponds to the amount of charge. In an advantageous embodiment, the authorization may include the second transaction identifier.

In still further embodiments of the payment variation notification system, the processor is operative to detect rejected transactions against a payment card number. The detection of the rejected transaction causes a notification transmission to a program administrator. The notification may include a transaction identifier and the payment card number associated with the declined transaction. The notice may also include the amount of the transaction declined.

In further embodiments of the payment variation notification system, the processor is operative to detect multiple payment transactions against a charge amount. The detection of a second or subsequent payment transaction causes a notification transmission to a program administrator, where the notification includes the first transaction identifier and the amount of the payment transaction. The notification may include the transaction amounts of payment of prior payment transactions against the amount of authorized charge.

In additional embodiments of the payment variation notification system, the processor is operative to detect refunds against settled payment transactions corresponding to a charge amount. The detection of the refund causes the transmission of a notification to a program administrator. The notification includes the first transaction identifier and the amount of the refund. The notification may also include the amount of the payment transaction settled.

In a further aspect the present invention provides a system for the exceptional handling of failing fax transmission transmissions. The system includes a first computer that is associated with a repository that defines a repository computer. The repository computer is associated with an electronic communication network, and is located to receive authorizations for payment of a second computer associated with a program administrator and additionally located to provide payment by fax to a plurality of third computers associated with commercial accounts . Payment authorizations are made in response to requests for payment from a merchant. The first computer includes a memory that stores a set of instructions and data related to a plurality of authorized program payments and a processor to run the set of instructions. The processor is in communication with the memory and the network. The processor is operative to receive payment authorizations from a program administrator and transmit them as payment by fax to a plurality of merchants. Additionally, the first computer is operative to carry out the exceptional handling of failed fax payment transmissions. Exceptional handling is carried out through the operations of (1) receiving the data indicating a payment by failed fax transmission, wherein the received data includes a fax number and a transaction identifier, (2) transmit notification of the payment by failed fax transmission to the program administrator, where the notification includes the transaction identifier, (3) receive data from the program administrator, where the received data includes a revised fax number and the transaction identifier, and (4) retransmit the payment by fax using the revised fax number. In an advantageous embodiment, the notification includes the time and description of the failure.

BRIEF DESCRIPTION OF THE FIGURES For a more complete understanding of the invention, reference should be made to the following detailed description in conjunction with the appended figures, in which: Figure 1 is a flow chart of the payment method in accordance with the present invention.

Figure 2 is a detailed flow diagram of the payment method in accordance with the present invention.

Figure 3 is a diagram illustrating the reconciliation characteristics in accordance with the present invention.

Figure 4 is an exemplary illustration of a payment method in accordance with the present invention.

Figure 5 is a flow chart of the charge card transaction and customer account in accordance with the present invention.

Figure 6 is a flowchart of the charging process transaction in accordance with the present invention.

Figure 7 is a flow diagram of the reconciliation process transaction in accordance with the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT With reference to Figure 1, the method according to the present invention includes receiving from a merchant a request for payment associated with the purchase of a member of a program 10. The purchase can be a service or a product provided by the merchant. A payment identifier 15 is generated. The payment identifier may consist of a multitude of elements (i.e., payment identification elements) that include the payment number, the contract number, the merchant information, the adjuster's number or any additional information that would be effective in identifying the transaction. A payment number, or payment identification number ("PID") is generated having a predetermined limit amount and a predetermined expiration date 20. The payment identifier is then associated with the payment number 25. The association can be established by a database structure as is commonly known in the art. Therefore, the payment identifier and the payment number uniquely identify the transaction, and it is possible to refer to these two terms collectively as a "transaction identifier". It should also be noted that the payment identifier and the payment number are not necessarily the same, despite the fact that both uniquely identify the transaction. The payment number is then transmitted to the merchant to satisfy the purchase payment 30. With this method, the program administrator responsible for payment of the request is provided with the assurance that the requested amount will not exceed the predetermined limit amount. In addition, the program administrator is provided with transaction information associated with the specific payment number to facilitate the reconciliation of payments to the appropriate transactions.

It is within the scope of the present invention to use the method with a variety of programs, including insurance policies, guarantee policies, purchase card groups and various other programs involving commercial transaction limits.

In accordance with the present invention it is also possible to provide fund confirmation and transaction event tracking. Referring to Figure 2, the method according to the present invention includes receiving from a merchant a payment request associated with a transaction 10. In addition to the request for payment, an estimated cost of the transaction is received by the merchant 35. Verification is provided that the request received from the merchant is covered by an effective contract associated with the buyer 40. The service provider can provide this verification. A predetermined limit amount is then authorized based on the estimate provided and possibly additional historical data which relate to the request 45. A payment identifier 15 is generated. A payment number having a predetermined limit amount and a predetermined expiration date is then generated 20. The payment number is then associated with the payment identifier 25. A request to load funds equivalent to the predetermined limit amount 50 is then sent. Charge of funds may be requested from the payment contract processor by the service contract administrator. Then the payment number processor can then request the loading of the funds to the bank responsible for providing the funds to the payment number, as is typical in a credit card transaction process. The fund load is then executed as requested and a confirmation of the fund load 60 is generated. The confirmation of the fund load is then associated with the payment number 65 by means of the payment identifier, thus providing information of additional reconciliation. The payment number is then transmitted to the merchant to satisfy the payment of the request 30. In addition, upon receipt of a request for payment by a merchant, a determination is made as to whether or not there are sufficient funds for the payment request. , and that the request is within the window of the expiration date for the payment number 75. If the payment request has the correct funds dedicated and is within the expiration date, the indicator is returned to the merchant. approval 80, the approval indicator is associated with the payment number for reconciliation purposes 85 and the funds are dedicated to the 100 merchant account. If the payment request does not have the correct funds or if the expiration date passed, it will be returns a denial indicator to dealer 90, and a denial indicator is associated with the payment number for reconciliation 95. This process will be followed for each sun and each request for commercial payment, thereby establishing a reconciliation transaction repository that includes the payment identifier, the payment number and the multitude of transactions.

The detail of a reconciliation transaction repository is as shown in Figure 3, in which the components of the payment identifier, including the payment number, the contract number and the information of the merchant 110 are stored in a repository of reconciliation transaction 105. Then the payment number 115 including the limit at and the expiration date is associated with the payment number in the reconciliation transaction repository 105. Next the transactions associated with the payment number 120, included payments to merchants, funds charges and approval or denial indicators are associated and stored with the claim number and the payment number in the reconciliation transaction repository 105. The associations that the reconciliation transaction repository establishes eliminate the need of a subsequent reconciliation of the transaction account statement by the administrator grama.

In an exemplary embodiment illustrated in FIG. 4, a service provider 125 submits a payment request for a claim 127 to a program contract administrator 129. The program administrator requests a payment number and the fund load 133. The payment number and the claim identifier are stored in the reconciliation transaction repository 137. The payment and confirmation number is returned 135 to the program manager 129. Then the payment number is supplied to the merchant 131. An application Charge transaction 141 is sent to the payment number processor 142 associated with the bank responsible for issuing the payment number 151. A confirmation of the charge is returned 143 and stored in the reconciliation transaction repository 137. The issuing bank 151 it is notified about the load 149 and dedicates the funds of the load 147. The commercial payment transactions are sent to the issuing bank for the dedi 153. Then the confirmations of the payments to merchants are transmitted 139 and stored in the reconciliation transaction repository 137. The bank account 157 of the program manager is debited by the processed charges 155.

As is common in the processing of financial transactions it is possible to carry out a daily sweep of bank accounts and record and transmit the appropriate transactions at that time.

Referring now to Figure 5, the method according to the present invention includes card debit and customer account debit transactions. The process begins with the request for payment 301 from a service provider 201 to a program manager 202. A member of a program purchases products or services from a service provider / merchant 201. By "merchant" as used in the description detailed and associated claims means an entity that trades goods and / or services. Therefore, a trader would include a person who trades goods of a certain type and has experience in the area of goods and practices of their trade, or who employs others who have this experience. A merchant as understood in this document would also include a person who provides services (ie, "service provider") of a certain type and who has experience in the service area and practices to provide these services, or who employs to others who have this kind of experience. The program administrator oversees a program for the benefit of a member of that program, providing payment to the merchant for the delivery of goods or services to the member. Examples of this type of program would include coverage of guarantees on goods or contracts and insurance policies. For example, the guarantee may cover black line goods, which are relatively light durable consumer electronic products such as televisions, radios, CD and DVD players and computers., or white goods, which are heavy consumer products such as air conditioners, refrigerators, stoves, washing machines and dishwashing machines. Similarly, the warranty contract can cover motorized vehicles such as automobiles, light and heavy duty trucks, boats, motorcycles, ATVs and RVs, providing coverage of mechanical repairs, repair of collisions, coverage of damage or defects of tires and tires. . Additionally, a program may cover payments to medical providers for services rendered in a health care aspect, such as those covered under health insurance plans, HMOs, PPOs, and the like. It is further contemplated that in a program of this type other types of insurance policies may be assumed, such as automobile insurance for collision repair or other damage to motorized vehicles.

Therefore, there is a "program contract" that provides a contractual / mandatory obligation to provide payment for goods and / or services for the benefit of a covered third party. Additionally, the program contract may arise based on coverage by an insurance policy. Accordingly, the service provider / merchant 201 provides the product or service to the member and requests payment. The member presents the documentation stipulating payment by the program manager 202. The service provider / merchant 201 contacts the program manager 202 for payment 301. The program administrator 202 reviews the charges and agrees to a payment.

When a payment amount is agreed upon, program administrator 202 initiates an application 302 for a payment card number and a fund load for the agreed amount. The request is sent to portal 204 through a secure network service provided by the reconciliation transaction repository (RTR) database maintainer 205. Request 302 includes data that is required and desirable for the reconciliation of billing once the charge was made. Examples of the data include the claim number, the certificate number, the examiner's code, the distributor's code, the purchase order, the member number and the repair order number.

The RTR 205 holds the reconciliation data for future use and sends 303 the load request to the card processor of the issuing bank 206. This is done by a secure API provided by the card processor of the issuing bank 206. The data sent to through the API include but are not limited to the load data of the program administrator 202 and the requested load amount. Therefore, the payment is made using a network of an association. MasterCard is an example of an association of this type that can be used to facilitate payment to a merchant. Visa, Discover and American Express can serve functions analogous to the MasterCard network. To carry out the tasks necessary for payment, a primary account number (PAN) is created with a specific prefix of bank identification number (BIN) (or identification number prefix). of the issuer (UN for its acronym in English)). Therefore, the PAN is analogous to a credit card number or debit card number. It allows an electronic transaction to be directed to the correct authorization processor, a function that is performed by the RTR database conservator. A unique payment identification number (PID) is associated with each payment request. Therefore, the PID can be used to distinguish one payment from another. In contrast, PAN can be used repeatedly in the process. For example, the PAN used by a conservator of an RTR may employ a MasterCard BIN. This will allow the transaction to move through the MasterCard association network. Note that although MasterCard is used as an example, it is contemplated that the association may employ other networks designed to facilitate the transfer of money between the parties.

The card processor of the issuing bank 206 verifies that the account of the program manager is active and requests 304 the transfer of the amount of the charge from the issuing bank 208 to an available credit card number. The issuing bank 208 moves 306 the requested charge amount to the credit card account in the card processor of the issuing bank 206.

The card processor 206 of the issuing bank then returns the correct charge confirmation transaction to the portal 204. The returned data includes the card number, the expiration date, the I.D. of transaction and the amount of charge. From the portal, the returned data is added to the reconciliation transaction repository (RTR) database 205.

Once the data was returned to the RTR through the portal, a delivery authorization decision 307 is made according to customer selection 203. The customer controls allow either the creation and transmission of the payment authorization fax for the customer. client 307b or the return of the load confirmation with the card number assigned to the program administrator 202 through the same network service mechanism as the load transaction 307a allows.

If the RTR 205 is not responsible for sending the fax to the service provider 201, the program manager 202 provides the service provider 201 with the card number, the card's expiration date, the security code of the card. card and the name of the cardholder. The service provider 201 then runs a "card not present" transaction for the payment of the service.

As a result, the issuing bank 208 debits 309 the funds dedication account of program manager 207 in a negotiated program to reimburse the bank for the charges. This debit is carried out through the ACH network of the Federal Reserve.

After reimbursement 309, the issuing bank 208 transmits 310 all the detailed transactions that create the ACH debit summary to the portal 204 so that they are added to the RTR 205 database. The RTR data is then used to reconcile the generated payment transactions by the program administrator 202 to the summary debit of the fund dedication account of program manager 207 by issuing bank 208.

Now with reference to Figure 6, the method according to the present invention includes a charge transaction process. The process begins when a service provider 201 receives 320 a card number and payment authorization from a program administrator 202 or via portal 204 (see also steps 307a or 307b, respectively of figure 5). After receiving 307th the payment card number that was loaded with the exact payment amount from via portal 204, the administered !: program 202 provides 320 merchant 201 with the card number to be charged. The delivery 320 is handled either by the program manager 202 or a delivery 320 by fax via the portal (see also steps 307a or 307b, respectively of figure 5).

The service provider 201 then makes a charge 321 to the card number through its existing processing terminal 210. The transaction is routed 322 from the processing terminal 210 to the merchant processor 211. The merchant processor 211 uses the card's BIN number to determine 323 the network 212 of the card and routes 324 the transaction to the correct card processor 214. The card processor 214 routes the transaction to the card processor 206 of the issuing bank.

The card processor 206 of the issuing bank makes a decision 326 to accept the charge 329 or reject the charge based on the credit limit and the available expiration date (which are assigned by the charging process). The accepted charges 329 follow their movement and the rejected charges are returned via the same network.

The card processor 206 of the issuing bank sends 327 either an accepted or rejected transaction via portal 204 where it is added to the RTR database 205. The RTR database 205, via portal 204, delivers the information of transaction to the program manager 202 during the reconciliation process (see also figure 7).

If a rejection transaction occurs the reason for the rejection is sent by email 328 (email as it is known in English) to the program manager 202 to allow a proactive response to the service provider / merchant 201. The email is sent 328 generally to the designated payment officer of the program administrator with information describing the cause of the rejection. Less charges are also reported to the payment officer by email to facilitate a proactive response.

If the charge is accepted, the charge to the issuing bank 208 is notified. The issuing bank 208 then reserves the funds for the service provider 201 waiting to be settled.

In order for the service provider 201 to claim the funds that the issuing bank 208 reserved in its name, the service provider must remit its terminal transactions to the network. The card network will then settle the transactions allowing the transfer of funds 330 from the issuing bank 208 to the merchant bank 209 (i.e., the service provider's bank).

Referring now to Figure 7, the method according to the present invention includes a reconciliation process. The reconciliation process eliminates the need for a printed account statement at the end of each month. All payment details are summed and processed as a lump sum ACH refund transaction. This method allows a single reconciliation of credit debit with all supporting details if required.

The process begins when the program administrator 202 issues a payment upload request to the portal 204 via the platform system 216 of the program manager. The network service requires a specific set of data that can be used to tie the charge request and any additional transactions in the card number to this particular payment.

The load request data is retrieved from the network service where 341 is delivered to the reconciliation transaction repository (RTR) 205 and maintained with a unique key. The unique key allows you to associate all other transactions that relate to this card number to this particular charge transaction.

When the loading of funds is effected by the card processor 206 of the issuing bank the load confirmation transaction is returned 342 to the portal 204 where it is added to the RTR 205 and matched to the appropriate load transaction.

Charge transactions, if any, are transmitted 343 to portal 204 for addition to RTR 205 and are matched to the appropriate load transaction. Cargo transactions may include reserve funds, rejection for insufficient funds, rejection by invalid expiration date, accepted charges, less charges, balances and any other transaction that may occur in the network. These data are retained for statistical purposes and trend reporting.

The ACH transactions that were processed by the issuing bank 208 to bill the appropriate program administrator for the Load Transactions are transmitted 344 to the portal 204 where they are added to the RTR 205 and matched to the appropriate load transaction.

The reconciliation data is delivered 345 to the program manager 202 via the platform system 216 of the program manager and the website 217 of the payment card for invisible electronic reconciliation. The transactions that are stored in the RTR 205 are made available to the program administrator 202 through the payment card website 217 and / or are delivered to the administrator via the 216 platform administrator system in the form electronic for reconciliation. The load transactions maintain unique data that allows the program manager to match them with particular payment transactions. Payment transactions are added to the balance sheet for a set of scheduled ACH transactions. This creates an invisible electronic reconciliation process available to the program administrator daily. The reconciliation process is further described in the examples that follow. The examples illustrate the exceptional handling process, and payment notification.

Examples - exceptional handling (EX) and payment notification (PN) A program contract administrator 202 (payer / administrator) requests 302 that a payment be made to a merchant / service provider 201 (beneficiary), as discussed in the foregoing with reference to Figure 5. The data of the payer's payment request is collected and delivered to the reconciliation transaction repository 205 of the portal conservator associated with the RTR. Payment can be requested in a number of ways, including those such as point-of-sale (POS) transactions of a credit or debit card, normal check or electronic funds transfer (EFT).

Normal check processing is carried out by acquiring data from the RTR and constructing an image that reflects all the standards required to process checks. The images are then distributed to a check processing center to be printed and distributed to merchants. The bank, when processing checks, delivers a check file to the conservator to enter it into the RTR.

In each case, payment through POS, EFT or check, the payment is received from the payer, distributed to the correct receiver / beneficiary and reconciled without human intervention.

POS transactions are delivered by acquiring data from the RTR and constructing an image incorporating a credit or debit card number for payment. The POS payment image is then delivered to the payment fax platform (PFP according to its acronym in English) to be delivered to the beneficiary (ie the merchant / service provider). If for any reason the fax payment delivery fails, the PFP records the time, date, reason and description of the failure in the RTR. When inserted into the RTR database, the failure information causes the payer to be notified by email to a specified distribution list. The notification allows the payer access to the RTR, acquire data of the specific payment and update the fax number to resubmit it to the PFP.

Example EX.l - notification by email for a failed fax: EFT transactions are delivered by acquiring data from the RTR 137 and building an Automated Compensation House (ACH) file formatted according to a National Automated Compensation House (NACHA) standard that is delivery to the bank for processing. Each payment record in the ACH file has a reference number that links this transaction back to the payer's payment request. When the ACH response file is received from the bank, the data is inserted into the RTR and an image with the payment reference number is constructed. The EFT payment image is then delivered to the PFP to be delivered to the beneficiary. If for any reason the fax payment delivery fails (PBF for its acronym in English), the PFP records the time, date, reason and description of the failure in the RTR. The reasons for the failure include an invalid fax number, one that has been uploaded, human voice detection, a busy signal or lack of response. When inserted into the RTR database, the failure information causes the payer to be notified by email to a specified distribution list. This allows the payer to access the RTR, acquire data of the specific payment and update the fax number to submit it again to the PFP. Upon receipt by the beneficiary, the EFT image serves as an additional method of reconciliation to the beneficiary to identify EFT deposits to the beneficiary's account. An email for a failed fax transmission from support @ curator. com or another email address that is associated with the RTR curator can automatically generate an email with the following information: Failed outgoing payment by fax: Client / payer: G G From: GLOBAL WARRANTY GROUP Beneficiary: ACME IMPORTS Claim number: 343202 Repair Order: 646315 Contract number: IN1S124794 Example PN.1 - fraud attempt and notification of variation of payment: Since POS transactions are received from the association networks (for example, MasterCard), they are delivered to the reconciliation repository and associated with the original payment request.

The original payment request maintains a specific balance that is credited or debited based on the activity of the beneficiary. To obtain complete reconciliation without human intervention there can be no deviation from the amount of the original payment request, stored in the RTR, and the balance that remains after the paqo was made. To achieve this level of reconciliation, each associated network transaction is inserted into the RTR for validation and analysis. By generating notification of each thing (product or service) that does not reconcile at the time of the variation instead of at the end of the period, the variation can be tracked and managed more effectively, saving time and improving the ability to track the origin of the variation.

Example PN.2 - notification of attempted surcharge: The rules of the RTR do not allow surcharges. Therefore it is impossible for a merchant to obtain a prior authorization for payment that exceeds the original value of the RTR for a payment. If a merchant attempts to charge an amount that exceeds the original value of the RTR, an RTR trigger sends an email to the appropriate parties including the beneficiary to notify this action using the conservator's customer distribution list.

It is possible to automatically generate an email from support @ curator. com with the following information: Virtual card authorization variation: Reserve funds rejected amount of $ 1,077.35 that does not match the amount charged of $ 1,047.35.

Payer: GWG Entity: WHZ11V Beneficiary: Acmé Industries Applicant: Robert Adams Claim: 382412 Example PN.3 - Less bill notification: If a beneficiary charges less on the bill the deficit is reported to the RTR and triggers an email using the conservator's customer distribution list to notify about this action. The difference is represented in the RTR and returned to the customer via EFT.

It is possible to automatically generate an email from support @ curator. com with the following information: Virtual card authorization variation: Funds reserved by the merchant for the amount of 262.61 do not match the amount charged of 262.62.

Payer: GWG Type: CLVCP Entity: IAS001 Beneficiary: ACME ENTERPRISES Applicant: Robert Richards Claim: 336255 In the previous example, "type" would refer to the type of payment requested. Since payments can be requested in various formats, such as POS (credit card type) transactions, check and electronic fund transfers, a type can be associated with a given payment notification. In the present case, the variation is in a card-type charge.

Example P.4 - notification of attempted multiple charges If a beneficiary attempts to charge the account more than once, that action is reported to the RTR and triggers an email using the conservator's customer distribution list, for notification of this action.

It is possible to automatically generate an email from support @ curator. com with the following information: Multiple virtual card transactions There are multiple rejections of reserve funds Client: GWG Type: CLVCP Entity: IAS002 Beneficiary: Allied Acmé, Inc.

Applicant: Robert Smith Claim: 336275 Example PN.5 - Balance variation notification: If a beneficiary places a transaction (settlement) for an amount that varies from the transaction amount charged, the action is reported to the RTR and triggers an email using the conservator's customer distribution list, for notification of this action.

It is possible to automatically generate an email from support (jjcurator.com with the following information: Variation of virtual card balance The amount of the balance $ 1,494.45 does not match the amount charged of $ 1,500.00.

Client: G G Type: CLVCP Entity: IAS003 Beneficiary: Acmé International, Ltd.

Applicant: Robert cAllen Claim: 336755 Example PN .6 - forced transaction notification of multiple transactions: If a merchant forcefully applies or forces a second charge on the account through the network, this action is reported to the RTR and triggers an email to the distribution list of customers of the SE, for notification of this action.

It is possible to automatically generate an email from support @ curator. com with the following information: Multiple virtual card transactions Multiple balances were found Client: GWG Type: CLVCP Entity: IAS004 Beneficiary: Acmé Ventures, Inc.

Applicant: Robert Alexander Claim: 346255 Example PN.7 - Refund variation notification If by chance a merchant refunds funds to the account instead of debiting the funds from the account, the action is reported to the RTR and triggers an email according to the conservator's customer distribution list, for notification of this action. This allows the client to work proactively with the merchant to reconcile the account without waiting for a billing cycle to complete.

It is possible to automatically generate an email from support @ curator. com with the following information: Virtual card rebate variation The amount of $ 6.29 reimbursed by the merchant does not match the amount charged of $ 75.00 Client: GWG Type: CLVCP Entity: IAS005 Beneficiary: General Acmé, Inc.

Applicant: Robert Jones Claim: 336255 Example PN.8 - Forced Reimbursement Notification Sometimes a merchant will send a reimbursement amount through the network after a successful balance has been applied. This action is reported to the RTR and triggers an email according to the conservator's client distribution list, for notification of this action.

This allows the client to work proactively with the merchant to reconcile the account without waiting for a billing cycle to complete.

It is possible to automatically generate an email from support@curator.com with the following information: Forced reimbursement of virtual card The amount of 150.00 reimbursed by the merchant was forced.

Beneficiary: General Industries, Inc.

Applicant: Robert Andrews Claim: 337464 Example P .9 - image advances: The data is delivered by the administrator / payer of the program in support of a payment.

The received data is inserted into the RTR when it is received and stored for image creation. When the payment is scheduled, the PFP is triggered to send a payment. The data is acquired from the RTR, it is moved to image production (it can be a POS image, check or EFT) and they are programmed in the PFP. Programming, delivery and / or failure is recorded to the RTR for reconciliation. The image is then delivered to the provider by the appropriate route (for example, fax transmission) to make the payment. Accordingly, the image may vary based on the type of payment being made and the associated industry in which the contract is dedicated.

Example PN.10 - Deviation of merchant category: Merchants are assigned category codes called the Industry Standard Code ("SIC") or Merchant Category Code ("MCC" for its acronym in English). These codes are used by the Tax Collection Service (IRS), the processor banks and other institutions as a numerical identifier of the commercial industry of an entity. It is possible to maintain and use a white list of merchant category codes against which to compare each transaction. It is expected that certain codes will be associated with a particular transaction or type of transaction. If the code is not in the accepted white list, a notification is sent to the client / administrator in order to inform them about the deviation in the SIC / MCC code presented by the merchant. The email that is built contains the information, as in the following example: Deviation of merchant category - not on the whitelist SIC / MCC Code 5969 - direct marketing - not classified elsewhere Client: XTL Type: CLVCP Entity: XTLMED Beneficiary: ADVANTAGE HEALTH PRIM CARE Applicant: XTL3387452 Claim: V0302975 All references cited in the present application are incorporated herein in their entirety by reference in the scope that is not inconsistent with this.

It will be appreciated that the advantages set forth in the foregoing and those that became apparent from the foregoing description are obtained efficiently, and in view of the fact that in the foregoing construction it is possible to effect certain changes without departing from the scope of the invention it is intended to that all objects contained in the foregoing description or shown in the appended figures shall be construed as illustrative and not in a limiting sense.

It should also be understood that the following claims are intended to cover all generic and specific features of the invention described herein, and all declarations of the scope of the invention that for reasons of language may be said to be located within this .

Claims (18)

1. System for notification of variation of payment in program contracts in which the payment variation notification system communicates with program administrators and financial institutions via a network, and in which the system includes a memory that stores a set of instructions and data related to a plurality of authorized program payments, and a processor to run the set of instructions, being that the processor is in communication with the memory and the network, wherein the processor is operative to facilitate reconciliation notifications and deviation from payment to program administrators, characterized by the operations of receiving data for the authorization of the payment of the program administrator's computer, since the data include one or more elements of payment identification and a charged amount, where the combination of payment identification elements uniquely identifies a transaction tion and constitutes a first transaction identifier; receive data for the payment transaction from the computer of the financial institution, where the data includes a second transaction identifier and a payment transaction amount, * where the second transaction identifier is selected from the group consisting of the first identifier of transaction and the payment identification number; compare the data for the load of the program administrator's computer and the amount of the payment transaction from the financial institution's computer to identify deviations; transmit notification to the program administrator of the deviations between the amount of the payment transaction and the amount of the charge substantially contemporaneously with the detection of these deviations in the comparison stage, being that the notification comprises the first transaction identifier and the amount of the payment transaction; and store the data received from the bank's computer for subsequent dissemination to the program administrator.

2. Payment variation notification system according to claim 1, characterized in that the processor is also operative to transmit payment authorizations to one or more merchants, wherein the payment authorization includes the second transaction identifier and a charge amount.

3. Payment variation notification system according to claim 1, characterized in that the processor is also operative to transmit payment by fax to one or more merchants, being that the fax payment includes a transaction identifier and a charge amount.

4. Payment variation notification system according to claim 3, characterized in that the processor is also operative to transmit notification to the program manager of a failed fax transmission, wherein the notification includes the first transaction identifier.

5,. Payment variation notification system according to claim 4, characterized in that the notification also includes the time and description of the failed transmission.

6. Payment variation notification system according to claim 4, characterized in that the notification further comprises a fax number associated with the failed transmission.

7. Payment variation notification system according to claim 1, characterized in that the processor is also operative to transmit an authorization to a merchant, wherein the authorization includes a payment card number and an authorized amount, being that the number of Payment card can be operated in a card processor system and the authorized amount corresponds to the amount of charge.

8. Payment variation notification system according to claim 7, characterized in that the authorization also includes the second transaction identifier.

9. Payment variation notification system according to claim 7, characterized in that the processor is also operative to detect rejected transactions against a payment card number, being that the detection of the rejected transaction causes a transmission of notification to a payment administrator. program, where the notification includes a transaction identifier and the payment card number associated with the rejected transaction.

10. Payment variation notification system according to claim 9, characterized in that the notification also includes the amount of the transaction rejected.

11. Payment variation notification system according to claim 1, characterized in that the processor is also operative to detect multiple payment transactions against a charge amount, wherein the detection of a second or subsequent payment transaction causes a notification transmission to a program administrator, being that the notification includes the first transaction identifier and the amount of the payment transaction.

12. Payment variation notification system according to claim 11, characterized in that the notification also includes the payment transaction amounts of prior payment transactions against the authorized charge amount.

13. Payment variation notification system according to claim 1, characterized in that the processor is also operative to detect refunds against settled payment transactions corresponding to the amount of charge, wherein the detection of the refund causes a transmission of notification to a program administrator, being that the notification includes the first transaction identifier and the amount of the refund.

14. Payment variation notification system according to claim 13, characterized in that the notification also includes the amount of the payment transaction settled.

15. Payment variation notification system according to claim 1, characterized in that the processor is also operative to detect mismatch category codes for a merchant transaction, where the detection of a mismatch causes a notification transmission to a program administrator, where the notification includes the first transaction identifier and a category code received from the merchant.

16. Payment variation notification system according to claim 15, characterized in that the category code is selected from the group consisting of an SIC code and an MCC code.

17. System for the exceptional handling of failing fax transmission transmissions, characterized in that the system comprises a first computer associated with a repository defining a repository computer, being that the repository computer is associated with an electronic communication network, it is emplaced for receive payment authorizations from a second computer associated with a program administrator that defines a program administrator computer, and additionally located to provide payment by fax to a plurality of third computers associated with commercial accounts, being that the payment authorizations are made in response to requests for payment from a merchant, and wherein the first computer includes a memory that stores a set of instructions and data related to a plurality of authorized program payments, and a processor for running the set of instructions, wherein the processor is in communication with the memory and the network, where the processor is operative to receive payment authorizations from a program administrator and transmit payment by fax to a plurality of merchants, and also in that the computer is operative to carry out the exceptional handling of failing fax transmission transmissions through the operations of: receiving the indicative data of a payment by failed fax transmission, the data received including a fax number and a transaction identifier; transmit notification of payment by failed fax transmission to the program administrator, where the notification includes the transaction identifier; receive data from the program administrator, where the received data includes a revised fax number and the transaction identifier; retransmit the payment by fax using the revised fax number.

18. System for the exceptional handling of failing fax transmission transmissions according to claim 17, characterized in that the notification also includes the time and description of the failure.