AU2006241298A1 - Financial Transaction Processing Method and System - Google Patents

Financial Transaction Processing Method and System Download PDF

Info

Publication number
AU2006241298A1
AU2006241298A1 AU2006241298A AU2006241298A AU2006241298A1 AU 2006241298 A1 AU2006241298 A1 AU 2006241298A1 AU 2006241298 A AU2006241298 A AU 2006241298A AU 2006241298 A AU2006241298 A AU 2006241298A AU 2006241298 A1 AU2006241298 A1 AU 2006241298A1
Authority
AU
Australia
Prior art keywords
credit
seller
provider
transaction
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
AU2006241298A
Inventor
Anthony Hynes
Cameron Oreo
Daniel Stones
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
PSP Corp Pty Ltd
Original Assignee
PSP Corp Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by PSP Corp Pty Ltd filed Critical PSP Corp Pty Ltd
Priority to AU2006241298A priority Critical patent/AU2006241298A1/en
Priority to PCT/AU2007/001395 priority patent/WO2008036998A1/en
Publication of AU2006241298A1 publication Critical patent/AU2006241298A1/en
Abandoned legal-status Critical Current

Links

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

EDITORIAL NOTE There are 18 pages of Description ,0 FINANCIAL TRANSACTION PROCESSING METHOD AND SYSTEM
C
C
FIELD OF THE INVENTION
O
z This invention relates to a system and method of conducting and providing e 5 financial transactions between a provider and a reseller of the provider.
Cl 00 BACKGROUND OF THE INVENTION OA typical sales arrangement includes at least one customer, a reseller, and an end service provider. In this sales arrangement, the reseller offers (for sale, purchase, lease, etc.) to a O 0 consumer one or more goods/services of the provider. The consumer obtains the goods/services
C
S from the reseller, and in turn, the reseller assumes a financial obligation to the provider for the value of the goods/services.
The conventional process for payment of goods/services in a "customer/reseller/end-service-provider" model mandates that a series of interdependent financial transactions be processed in order to transfer value (also referred to herein as "money," "assets," or "funds") from the customer through to the reseller, who is then required to pay an amount to the end service provider. For example, a consumer of airline tickets may consult a travel agency the reseller) for tickets from an airline the provider). Accordingly, in a typical sale purchase) of an airline ticket by the consumer, the consumer purchases the !0 ticket from the reseller, who would then be required to pay a corresponding amount to the provider, as commonly arranged in a trade agreement between the reseller and the provider.
Thus, once the customer arranges payment for the transaction with the reseller, the transaction between the two parties is effectively complete (notwithstanding delivery of the goods/services purchased). A second transaction must then occur between the reseller and the provider, as the reseller must pay the provider for the goods/services purchased.
Under many trade agreements, access to a line of credit is typically established prior to the transaction. The line of credit defines the terms for settling invoices raised for goods/services sold on the end service provider's behalf. Conventionally, the terms of credit are expressed as a value (the total amount of funds up to which the end service provider will allow the reseller to defer payment) and a time period (which defines the length of time over which payment may be deferred).
DC:486379.2 0 As a result, if the reseller has available funds and elects to be invoiced for the
O
O transaction value of the originating transaction, then the end service provider will not receive Cl payment until the end of the credit time period is reached. While the practice of allowing trade 0 S credit is widely accepted, it is not an optimal situation for the end service provider, who would e 5 have no choice but to assume the risks associated with offering credit whether payment will be made by the reseller), regardless of the fact that the good/services may be consumed in the 00 meantime.
N To facilitate the clearance and settlement of funds between each party in the C"l conventional sales/reseller model, a level of control and vigilance over the billing and settlement Cl 0 process by the end service provider is generally required. These controls are primarily
C
S concerned with the relationship between the reseller and the end service provider and include, for example, the establishment of trading terms (trade credit accounts), and maintenance of credit balances against purchases made (managing and observing credit limits and validating available credit prior to purchasing). Additionally, there must also exist an agreed upon processing arrangement involving at least one mechanism that would ensure that sufficient payment methods cash, credit, or check) exist and that the value (of the funds) can be readily transferred from the reseller to the end service provider in accordance with the credit terms established. These controls are typically and collectively referred to as "billing and settlement" controls.
!0 The responsibility for establishing the billing and settlement controls is typically the domain of the end service provider and day-to-day governance of the controls is often outsourced to a third party. In some cases, the third party billing and settlement controller may act on behalf of a single end service provider, or may, in fact, operate as a primary billing and settlement controller offering this service on behalf of participants across an entire industry.
Moreover, conventionally, while a customer settles the originating transaction with the reseller or previous to the originating transaction in a trade agreement, the provider may typically extend credit to the reseller for a predetermined period. For example, the end service provider may provide some value and/or time to pay the outstanding balance. Upon expiration of the agreed credit period, the party responsible for controlling billing and settlement will typically attempt to extract the funds owed from the reseller. The methods for collection 2 DC:486379.2 0 generally include the use of one or more of the following: bank checking accounts, credit card
C
O accounts, debit and charge accounts.
The conventional system of credit transactions as described above allows the 0 S reseller to receive payment immediately from the customer and having access to the funds for the e 5 duration of the credit term as per the arrangement with the end service provider. The financial institutions banks, credit card companies) benefit from the terms of transaction fees and the interest collected. Additionally, the external billing and settlement provider, if used to control billing and settlement, would also enjoy similar benefits.
The conventional system and methods for conducting credit transactions has a S0 number of drawbacks, however, particularly with respect to the financial welfare of the provider.
C
S Primarily, the conventional system and methods create a high level of fragmentation, making the processing of credit transactions inefficient and costly. Typically, the end service provider must carry significant receivables risk due to lengthy delays in receiving money owed or otherwise settling outstanding debts. As the process tends not only to be inefficient, but may prove to be costly as an end-service-provider typically has no choice but to carry significant receivables risk.
This problem is exacerbated due to the length of time during which credit is extended, which has negative impacts on cash flow and may also lead to increases in a number of subsequent operation costs and the cost associated with obtaining business finance.
There is a need in the art for a method and system of providing financial !0 transactions that streamlines the process of arranging payment and reconciling outstanding debts due to issued credit, preferably from a provider to a reseller.
SUMMARY OF THE INVENTION The present invention meets the needs of the art by providing a streamlined and efficient system and method of providing financial transactions, such as the seamless extension issuance) of credit from a provider to a reseller of the provider's transaction items, such as goods and/or services of the provider.
Preferred embodiments of the present invention are directed to methods for conducting financial transactions. In accordance with the method, a seller is provided with the right to transfer a transaction item from a provider. An originating transaction is conducted to transfer the transaction item from the seller to a buyer for a determined amount. In some 3 DC:486379.2 variations, the transaction item is in the inventory of the provider at the time of the originating 0 O transaction. A request is electronically transmitted, preferably substantially concurrent with the
C,
originating transaction, and received by the provider for issuance of credit to the seller 0 S corresponding to, and preferably for, the determined amount. The request for credit is validated e 5 to confirm the identity of the seller and to determine the credit available to the seller and the C"l credit, which is associated only with the originating transaction, is electronically issued to the seller. The credit is ultimately settled by the seller. In some variations, the provider's bank conducts the receiving, the validating and the issuing steps disclosed herein.
C"l In some embodiments of the present invention, the originating transaction Cxl 0 comprises a limited number of transactions, such as one transaction, which may be substantially 0 o concurrent.
In other embodiments of the present invention, the credit only applies to the provider issuing the credit and the credit is issued corresponding only to the originating transaction. In certain embodiments of the present invention, the credit available to the seller is a credit limit assigned to the seller minus any cumulative credit that is outstanding from the provider to the seller when the request is validated.
In yet other embodiments, the reconciling step includes identifying the seller provided with the credit, determining the amount of the credit due to the provider; and then collecting payment to the provider for the amount of the credit due within a predetermined time !0 period.
In yet other preferred embodiments, the method includes generating an identifier that uniquely identifies the credit issued corresponding to the originating transaction. Preferably, the identifier conforms to ISO standard 7812. In addition, the identifier may not be used for any transaction or credit issuance other than the originating transaction and the credit issued thereto.
It is preferred that the request for credit is transmitted over a first communication network and the issuing of the credit is transmitted to the seller on a second communication network.
Other embodiments of the present invention include a financial transaction system for conducting financial transactions. The system includes a receiving network that communicates a credit request from a seller to a provider, such as a bank. Preferably, the credit is specifically for an amount corresponding to an originating transaction between the seller and a 4 DC:486379.2 0 buyer. Additionally, the system may include a credit processor connected to the network and 0 O configured for identifying the seller and assessing the credit available to the seller when the request is received. In some variations, the credit processor is connected to communicate with a 0 S plurality of computers to receive credit requests from a plurality of sellers. A credit issuer is e 5 preferably included in the system and is connected to the processor and configured to issue the credit to the seller. Moreover, a credit reconciliator, which is configured for enabling the settlement of the credit upon payment of an incurred debt based on the credit issued, is included in the system. In addition, a settlement system is used for settling the credit.
C"l In certain preferred variations, a processing system that is configured and adapted 0 to communicate with a plurality of computers is also included. The process system is preferably S arranged to accept communication from a plurality of sellers.
In yet other embodiments, the credit processor, the credit issuer, and the credit reconciliator are stored on a computer readable medium.
Any of the embodiments illustrated above and below stand independently or features may be combined to achieve preferred embodiments. Additional advantages and embodiments of the invention will also become more apparent to those of ordinary skill in the art upon review of the teachings of the present application.
BRIEF DESCRIPTION OF THE DRAWINGS !0 Figure 1 is a process flow diagram illustrating a method of issuing a Virtual Account Number to pay for goods/services ultimately provided by an end service provider, according one embodiment of the invention; Figure 2 is an event driven process diagram for the generation of VANs, according to one embodiment of the invention; Figure 3 is an event driven diagram outlining a method for meeting the settlement and processing requirements, according to one embodiment to the invention; Figure 4 presents hardware, software or a combination thereof that may be implemented in one or more computer systems or other processing systems to carry out the functionality, of the present invention, in accordance with one embodiment of the present invention; and DC:486379.2 0 Figure 5 presents an exemplary system diagram of various hardware components
O
O and other features, in accordance with an embodiment of the present invention.
O
S DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS en 5 The present invention encompasses business to business and/or business to consumer financial transactions including a transfer of a transaction item from a provider to a purchaser via a seller. As used herein, the "purchaser" is also referred to herein as a "buyer" or "payor." In some instances, such as in a retail sales environment, the buyer is commonly referred to as a "customer" or "consumer," in which the buyer is a non-business 0 entity. When the consumer is not a business, but the provider or seller is a business, the 0 S transaction is deemed to be B2C. In other instances, the buyer is a business entity. Generally, a purchaser is defined as any party obtaining the rights to a good/service through a transfer for value.
The seller has acquired from the provider the right to transfer the transaction item to the buyer. The seller can be a reseller, in the case that it purchases the transaction item from the provider and resells it; a consignee, in the case that it has the fight to sell or otherwise transfer the transaction item from the provider, such as for a commission; a retailer; an agent; an intermediate consumer (or non-business entity) seeking to further transfer rights in the transaction item, or can have another relationship with the provider to transfer the item to a !0 buyer. The buyer can actually purchase the transaction item outright or obtain another right thereto, such as a lease, an option, or a share. The provider can be a primary seller, who sells the transaction item to the seller; a consignor, who retains ownership of the transaction item until the item is sold the buyer on consignment; an end service provider; or can have another relation to the seller, buyer, and the transaction item. The provider in this embodiment can also be the creditor or payee.
As used herein, an "originating transaction" involves the seller and the buyer, in which the seller transfers a good/service to the buyer in exchange for value.
As used herein, "reconciling" encompasses "balancing," "payment," or "settling" the debt incurred by the seller as a result of assuming the credit issued by the provider.
The invention disclosed herein provides an improved automated system and method of conducting and reconciling settling outstanding balances) between business 6 DC:486379.2 s0 parties, such as sellers and providers, for example, which are two parties that typically have a 0 O trade relationship with one another.
C,
The present invention allows the reduction of the risks associated with offering 0 S credit, most particularly, whether payment will be made by the seller. Embodiments of the e 5 present invention provide the provider with instantaneous, preferably real time, information as to Cl whether a particular seller has available funds. If credit is issued, the present invention allows the provider to avoid traditional invoicing of the seller. Payment of funds to the provider is expedited through the issuance of a virtual credit card. As a result, payments are typically made in a timely fashion, as opposed to the payment in the conventional art in which payment is not 0 typically provided until the end of the credit time period is reached, thereby negatively affecting S the cash flow of the provider.
Generally, the present invention provides a system and method of providing financial transactions that provides credit, preferably a VAN identifying said credit, and/or a credit account on behalf of the seller, in which the credit account is specifically linked to one or more transactions, and preferably one transaction the originating transaction) between a seller of the provider's goods/services and a purchaser. Generally, the seller must repay the outstanding cost of the goods/services transferred to the purchaser, such as by sale, lease, rental, offer, or other provision of the goods/services.
The present invention relates to the balancing of the seller's outstanding debt to !0 the provider. In embodiments of the present invention, credit accounts are established based on efficient processing of the seller's credit profile. Additionally, the credit account and credit extended are linked to processes to efficiently and systematically reconcile the outstanding debt, for instance, through a billing and settlement and payment processing and clearing service.
In certain embodiments, systems and methods are provided to create and issue a limited use, preferably one time use, virtual credit card or the like a VAN) to a seller from a provider. The virtual credit card may be used as currency allowing the seller to acquire goods/services from the provider, and in preferred embodiments, to transfer funds to settle the virtual credit card debt owed to the provider.
Figure 1 illustrates an exemplary overview of the transactional scheme encompassed by embodiments of the present invention. As discussed, the transactional scheme is based on an originating transaction between one or more purchasers and a seller of the 7 DC:486379.2 s0 provider's goods/services. Once the purchaser pays the seller for the transfer, as would be 0 O understood to those skilled in the art, the originating transaction is confirmed and complete Cl (notwithstanding delivery of the goods/services purchased, if applicable). Following the 0 S completion of, or substantially concurrent with the completion of, the originating transaction, the e 5 seller and provider would engage in a subsequent transaction (interchangeably referred to herein C"l as the "credit transaction"), which represents an agreement between the seller and provider for the seller to pay the provider for the goods/services acquired by the purchaser. Preferably, the agreement provides the seller access to a line of credit from the provider.
As used herein, "substantially concurrently" encompasses any time proximal to C"l 0 the completion of the originating transaction, in which the costs associated with the transaction 0 S are known, and preferably locked in place. In preferred embodiments, the initiation of the credit transaction occurs within about 30 minutes of the close of the originating transaction, more preferably within about 10 or 2 minutes, and most preferably within one minute, and more preferably within about 30 or 10 seconds of the close of the originating transaction. As defined herein, "completion" or "close" of the originating transaction encompasses an agreement by the purchaser and seller to engage in a transaction, preferably in which the purchaser agrees to repay the provider with funds for the seller's goods/services. In preferred embodiments, a closed originating transaction is an executed purchase agreement between the purchaser and the seller.
In other embodiments, the initiation of credit encompasses a period after the !0 completion of the originating transaction. That is, the initiation of the credit transaction can occur at any agreed upon time after the close of the originating transaction. In some variations, the initiation of credit can be done in batches and sent at a predetermined time, for example, once a day, once a week, etc. When the initiation of credit is done in batches of transactions, some of the transactions can be concurrent with the initiation of credit.
The seller sends a communication requesting the issuance of credit to the provider a VAN request message). In the communication, the seller requests the issuance of credit and/or the establishment of a credit account for credit corresponding to the originating transaction, as generally depicted by Figure 1, and more specifically illustrated in Figure 2.
The communication between the seller and the provider is preferably conducted on a preferably dedicated communication channel or network of an Integrated System that communicably links one or more sellers and the provider. In certain embodiments, the 8 DC:486379.2 Integrated System may functionally include additional operations, such as performing the 0 O function of a distribution channel, specifically the sourcing of goods/services available by the purchaser from the provider's inventory and confirming and recording any resulting purchase 0 S made by the seller on behalf of a purchaser. For example, Integrated Systems within the travel e 5 and tourism industry can include Airline Internet Booking Engines Global Distribution Systems GDS New Entrants("GNEs") and Centralized Airline Ticketing Systems 00
("CATS").
OFollowing receipt of the request, the modalities of the present invention generate a C"l credit card number for the seller using an credit card issuing system the VAN Issuing 0 System), preferably operating on a second communication channel or network of an Issuing
O
O System, as discussed below. A response message, generated, for example, by a processor that is able to analyze the issuance of credit, is delivered to the seller. Accordingly, information is provided as to whether credit has been issued, and if so, a credit issuing feature, such as a credit issuer, for example, may provide other pertinent information, such as the predetermined time to remit payment and/or the amount of the credit, for instance.
At the predetermined time after issuance of the credit, the settlement process is conducted to collect payment for the seller's assumed credit debt. In certain embodiments, the provider conducts the settlement process, using, for example a credit reconciliator and/or a settlement system. In some embodiments, the credit reconciliator comprises the settlement !0 system and is configured to affect the credit upon payment. In embodiments, the reconciliator settles the credit. In other embodiments, the reconciliator sends one or more signals to a settlement system, which can be, for example, a bank, computer, person, etc., that settles the credit debt.
In some embodiments, the settlement process is conducted by one or more third parties, such as banks, financial institutions, and the like, as would be understood to one skilled in the art. In these embodiments, the settlement process includes the submission by the credit issuing bank of the credit for clearance to the seller's debtor's) bank. Settlement is facilitated and payment is made to the service provider.
The Issuing System, as used herein preferably includes the functionality related to issuing credit to the seller and is preferably controlled by the provider to issue credit the credit associated with a VAN) to a party, such as the seller. In preferred embodiments, a VAN is 9 DC:486379.2 s0 used as a form of payment to use the credit to expedite financial settlement between sellers and 0 O end service providers, by for instance, facilitating the transfer of funds to an end service provider
C,
for goods/services purchased by the seller is provided. The Issuing System may create the VAN 0 S preferably upon the receipt of an incoming request from the Integrated System. The benefits and e 5 functionality provided by the present invention are enhanced by communication between the Cl Issuing System and the Integrated Systems.
00 Additionally, in some variations, the Issuing System may handle multiple functions. For example, according to some embodiments of the invention, the Issuing System Cl can provide one or more of the following features: 1) a system that allows for the registration, 0 creation and storage of client profiles which contain information related to all parties and S systems that need a credit profile or distribute the provider's goods/services; 2) a verification method that ensures that all Integrated Systems, processes and transaction parties that are used and/or referenced within the request messages can be validated and are, in fact, authorized to communicate with the Issuing System; 3) a credit management system to act as a control that provides for a validation check capable of ensuring that a VAN can only be issued for transactions in which the payer has sufficient available funds to complete the transactions; 4) a system capable of generating a virtual credit card number and associated account information that conforms to standard credit card account issuing requirements; and 5) a clearance system capable of generating the necessary output data files, which are used to ensure that transactions !0 are processed and funds are cleared to end service providers.
The implementation of the Issuing System preferably considers the risks associated with issuing credit to the seller. In some embodiments, the terms of credit are preferably expressed as a value (the total amount of funds up to which the end service provider will allow the seller to defer payment) and a time period (which defines the length of time over which payment may be deferred). For example, the Issuing System may be configured so that the issuance of credit is predicated upon the availability of funds to the seller. Thus, according to this embodiment, the provider may set a requirement that the total value of credit issued may be limited in some way, for example to a certain aggregate value. In this instance, the credit, and an associated VAN, would be issued if the seller has enough credit (available funds) remaining against the seller's account.
DC:486379.2 0 The processes controlling and confirming the security associated with the
O
O issuance of credit are collectively referred to herein as "validation." Validation may involve one C"l or more levels of clearance or security, including confirmation of credit status, account 0 S confirmation, and risk assessment. Certain aspects of the Issuing System are preferably e 5 responsible for the registration and ongoing management of authorized parties. A registered entity database according to this aspect of the invention may perform various useful functions.
For example, it may verify that all parties requesting credit and the generation of a corresponding VAN are appropriately authorized.
C"l Figure 2 describes an exemplary validation process upon receipt of the incoming Cl 0 request by the Issuing System and the generation of VAN corresponding to the credit issued, as
O
S shown in system 400. The first action to be taken is referred to in the diagram as I Level validation, as shown by step 401. This step includes a series of checks against information stored on the database and validates the origin and syntax (format and content), of the incoming message, as shown in step 402. Once the syntax of the message is validated, a check is made to ensure the request has been made from an authorized system. According to this embodiment of the invention, all incoming credit request messages contain a set of data used to identify the Integrated System responsible for making the request for issuance of credit and generation of a corresponding VAN. The same data string is stored in the Issuing System database and an attempt to match the two values would be made to ensure that the system sending the message !0 does exist and has supplied the correct credentials within the request message. If a match is not found and validation at this point fails, as shown in step 405, a detailed error message is returned and the request ignored without any further processing. If 1 st level validation is successful, as shown in step 403, then the system will proceed to 2 nd level validation which is referred to as Credit Management, as shown in step 404.
The second validation, for example, includes a check that the information supplied in the credit request message matches the information stored on the database. More specifically a validation takes place to ensure that the seller responsible for paying the end service provider is defined to the Issuing System and that sufficient funds are available.
In this example, sufficient funds exist only when the purchase amount contained in the incoming request message when added to the total credit already issued to the seller in certain embodiments does not represent an amount greater than the credit limit amount set by 11 DC:486379.2 S the end service provider which is stored on the database. Accordingly, only if the system 0 O ascertains that the seller has sufficient funds will a one-time use VAN be generated, as shown in step 407. If it is determined that the seller does not have sufficient funds then a detailed error
O
message is returned to the Integrated System and the request for issuance of credit is ignored M 5 without any further processing, or returned with an error signal in certain variations.
Only after successful validation at the first and second level will a new VAN be created. At a base level in yet other embodiments, this involves the creation of a virtual credit card account conforming to the standards outlined in ISO standard 7812, as encompassed by step C"l 408. The standard dictates that all credit card numbers contain a certain amount of internal 0 structure, and share a common numbering scheme. As such, all VANs created by the Issuing
O
S System contain a six-digit issuer identifier number (IIN), an account number, and a single digit checksum or check digit. The check digit, as it is commonly referred to, is derived by employing the Luhn algorithm to ensure that the string created represents what is known as a MODI 0 compliant number. The present invention provides a system under which the generation of such a number is automated.
VANs, which are associated with the credit issued, are generated from a procedure stored on the Issuing System which involves the usage of specific account number parameters stored on the Issuing System database. The information stored on the database contains a record of all possible IIN/check digit combinations available for use (the IIN being !0 first 6 digits making up the VAN and the check digits being the final digit in the VAN to be generated (numbers Also stored against each IIN/check digit combination is the last conforming nine digit account number generated. The last account number fills the space between the IIN and the check digit.
According to one embodiment of the invention, the method employed by the system responsible for VAN generation calls for an available BIN and check digit combination to be selected at random from the database. The system then generates the next available and valid number for the selected IIN/check digit combination. This is done by adding 1 to the last Account Number value and running the Luhn algorithm to verify the IIN-ACCOUNT NUMBER-CHECK DIGIT combination is valid and that the MOD10 is compliant.
If the number is not valid, the Issuing System increments the last account number attempted by a factor of one and re-runs the Luhn algorithm to satisfy the requirement for the 12 DC:486379.2 number to be MOD 10 compliant. This process is repeated until a valid combination is found, at 0 O which point it is stored in the Account Number field ready to be incremented by one and used as C"l the starting point for the next request.
O
z Once a valid 16 digit VAN has been generated, an expiry date is then generated en 5 and expressed as MM/YY where MM equals month and YY equals the year. This represents the time after which the card is no longer able to be used.
0Lastly, a cardholder name is assigned and a series of restrictions added to the account created which ensure that the card is unable to be used for any other purpose outside of the intended transaction that is to be completed between the seller and end service provider as 0 defined in the incoming VAN generation and credit request message, as described generally by S step 408.
Such an approach provides significant advantages. For example, in preferred embodiments, the credit and associated VAN are only issued based on an incoming request, which details the conditions under which it can be used. Thus, the VAN is electronically generated with specific attributes including, but not limited to, the locking of the card limit to the total value of the transaction between the seller and the end service provider. Additionally, any attempt to process the transaction is limited to paying only the end service provider or merchant as nominated within the original request message.
Once the VAN has been created, the next step requires that a pre-authorization !0 code is generated, as shown in step. This step further ensures that the card is rendered inactive or "dead" before it is even known to exist by any other party. A valid authorization code is a six digit numeric string and is commonly used in credit processing as proof that the required funds are available on a credit card and furthermore ensures that a block has been placed on the card for the required amount so that they it may be captured at a later date. The amount for which the pre-authorization code is generated according to this embodiment of the invention will equal the total amount of funds available on the card. The advantage being that any subsequent transaction attempt on the newly issued VAN would be declined on the basis of insufficient funds being available for any subsequent purchase.
Upon completion of virtual account creation and the generation of the Authorization code, a new transaction record is inserted into the database, as shown in step 410.
The record consists of the virtual account details, as shown in step 411, the authorization code 13 DC:486379.2 ,0 and the transaction specific information such as the seller details, the end service provider details 0 O and the amount of the transaction. Once stored, the interaction between the Issuing System and the Integrated System is completed with a detailed confirmation response message being sent 0 S back the Integrated System, as shown in step 412.
e 5 In some embodiments, pending successful validation, there is a trigger for the generating of a VAN that is treated thereafter as a traditional credit card and is then used as the method of payment and the financial instrument responsible for ensuring funds are processed to the end service provider without having to effect a transaction from the seller at the same time.
C"l In these embodiments of the invention, apart from the single permitted use, the issued VAN is 0 inactive from the moment it is created. In other words, from the moment it is created, the issued O VAN is unable to be used to make any other purchase except that for which it was created. This provides increased security and provides a considerable and immediate level of fraud prevention.
In preferred embodiments, the issuance of the credit and the corresponding VAN is based on the originating transaction. In preferred embodiments, therefore the VAN may be issued for the exact amount due to be paid from the seller to the provider, and thus, it can not be used to make subsequent purchases. Moreover, in preferred embodiments, the VAN can be "locked" so that it may only be used to pay a single pre-defined merchant, and thus, the VAN cannot be used to pay anyone but the end service provider. Additionally, at the time the credit is issued, the VAN is pre-authorized. Thus, any funds available on the VAN are already claimed !0 (or "frozen") and may only be used to balance the value of the originating transaction. As the credit is tied to a single transaction and also includes a future expiry date, all VANs can be issued in a unique fashion, thereby ensuring that each VAN is unique (non repeated) and generated in a seemingly random fashion.
Additionally, the system provides a method for affecting payment between the seller and an end service provider which expressly observes the settlement timing requested by the end service provider, the "predetermined time period," as typically specified in the credit terms between the provider and seller under the trade agreement. Accordingly, embodiments of the present invention may include any suitable time period for payment, as agreed upon by the contracting parties. In some embodiments, a daily cut off time is set, as shown in step 301 of Figure 3. The daily cut off time is determined by the provider typically, and initiates the start of the daily settlement process when a predetermined time period is over. That is, if a 14 DC:486379.2 0 predetermined time period ends on October 25t for example, the daily cut off time on 0 th O October 25 officially ends the predetermined time period.
In accordance with step 302 in Figure 3, the Issuing System provides a method for
O
S generating a series of data output files, which, according to one embodiment of the invention, e 5 ensures all VAN accounts are submitted in to clearing and settlement networks via third party card processing systems. According to another embodiment of the invention, at any given point, a procedure stored on the Issuing System may be triggered to generate a series of files for uses other than that of clearance and settlement. Such uses may, for example, include providing C"l reconciliation data to banking institutions for import into existing physical card Issuing Systems.
0 According to one embodiment, step 303 in the settlement billing) procedure S is to review and scan the registration and profile data stored on the database to ascertain which end service providers are due to receive funds according to rules previously configured and stored on the Issuing System. Once step 303 has been completed, existing transaction records are searched for payments in which the end service provider (requiring settlement) has been nominated as the payee the provider is owed money). For each matching payment identified, the data record is then updated with a series of settlement particulars including, but not limited to, a settlement ID and the date and time at which the settlement was run, as illustrated in step 304. Additionally, as shown in step 305, a new status for the transaction record is also inserted into the data record to designate that the record is not to be reprocessed under any !0 circumstance and payment processing is complete.
A procedure contained within the Issuing System is invoked to create and write a portion of the transaction records identified to new output file(s) which are stored within the Issuing System and may subsequently be transferred into the credit card clearing and settlement system or made available to other authorized recipients, as shown in step 306. In this example, the file is submitted into the clearing and settlement network, which facilitates a transaction between the issuing bank and the acquiring bank to settle the transactions. The acquiring bank may concurrently credit the provider's designated bank account.
The present invention may be implemented using hardware, software, or a combination thereof and may be implemented in one or more computer systems or other processing systems. In one embodiment, the invention is directed toward one or more computer DC:486379.2 S0 systems capable of carrying out the functionality described herein. An example of such a
C
O computer system is shown in Figure 4.
Computer system 200 includes one or more processors, such as processor 204.
O
S The processor 204 is connected to a communication infrastructure 206 a communications e 5 bus, cross-over bar, or network). Various software embodiments are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the invention using other computer systems and/or architectures. t"-l Computer system 200 can include a display interface 202 that forwards graphics, 0 text, and other data from the communication infrastructure 206 (or from a frame buffer not S shown) for display on the display unit 230. Computer system 200 also includes a main memory 208, preferably random access memory (RAM), and may also include a secondary memory 210.
The secondary memory 210 may include, for example, a hard disk drive 212 and/or a removable storage drive 214, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive 214 reads from and/or writes to a removable storage unit 218 in a well-known manner. Removable storage unit 218, represents a floppy disk, magnetic tape, optical disk, etc., which is read by and written to removable storage drive 214. As will be appreciated, the removable storage unit 218 includes a computer usable storage medium having stored therein computer software and/or data.
!0 In alternative embodiments, secondary memory 210 may include other similar devices for allowing computer programs or other instructions to be loaded into computer system 200. Such devices may include, for example, a removable storage unit 222 and an interface 220.
Examples of such may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an erasable programmable read only memory (EPROM), or programmable read only memory (PROM)) and associated socket, and other removable storage units 222 and interfaces 220, which allow software and data to be transferred from the removable storage unit 222 to computer system 200.
Computer system 200 may also include a communications interface 224.
Communications interface 224 allows software and data to be transferred between computer system 200 and external devices. Examples of communications interface 224 may include a modem, a network interface an Ethernet card), a communications port, a Personal 16 DC:486379.2 Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and 0 O data transferred via communications interface 224 are in the form of signals 228, which may be
C,
electronic, electromagnetic, optical or other signals capable of being received by 0 S communications interface 224. These signals 228 are provided to communications interface 224 e 5 via a communications path channel) 226. This path 226 carries signals 228 and may be Cl implemented using wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link and/or other communications channels. In this document, the terms "computer program medium" and "computer usable medium" are used to refer generally to media such as a removable storage drive 214, a hard disk installed in hard disk drive 212, and signals 228. These Cl 0 computer program products provide software to the computer system 200. The invention is 0 S directed to such computer program products.
Computer programs (also referred to as computer control logic) are stored in main memory 208 and/or secondary memory 210. Computer programs may also be received via communications interface 224. Such computer programs, when executed, enable the computer system 200 to perform the features of the present invention, as discussed herein. In particular, the computer programs, when executed, enable the processor 204 to perform the features of the present invention. Accordingly, such computer programs represent controllers of the computer system 200.
In an embodiment where the invention is implemented using software, the !0 software may be stored in a computer program product and loaded into computer system 200 using removable storage drive 214, hard drive 212, or communications interface 224. The control logic (software), when executed by the processor 204, causes the processor 204 to perform the functions of the invention as described herein. In another embodiment, the invention is implemented primarily in hardware using, for example, hardware components, such as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s).
In yet another embodiment, the invention is implemented using a combination of both hardware and software.
As shown in Figure 5, in an embodiment of the present invention, the multimedia application operates, for example, on a network. A user 40, such as an applicant or application 17 DC:486379.2 processor inputs information, via a terminal 41, such as a personal computer (PC),
C
O minicomputer, mainframe computer, microcomputer, telephone device, personal digital assistant (PDA), or other device having a processor and input capability.
O
z As further shown in Figure 5, in one embodiment, the terminal 41 is coupled to a e 5 server 43, such as a PC, minicomputer, mainframe computer, microcomputer, or other device having a processor and a repository for data or connection to a repository for maintained data, via a network 44, such as the Internet, via couplings 45, 46, such as wired, wireless, or fiber optic connections.
The specification and figures are to be regarded in an illustrative manner, rather 0 than a restrictive one, and all such modifications are intended to be included within the scope of S present invention. Although preferred embodiments of the invention have been described in the foregoing description, it will be understood that the invention is not limited to the specific embodiments disclosed herein but is capable of numerous modifications by one of ordinary skill in the art. It will be understood that the materials used and technological details may be slightly different or modified from the descriptions herein without departing from the methods and compositions disclosed and taught by the present invention. Many variations and modifications will be apparent to those of ordinary skill in the art. Benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as critical, required, or essential features or elements of any !0 or all the claims.
18 DC:486379.2

Claims (11)

  1. 2. The method of claim 1, wherein the request for the credit is for the determined amount.
  2. 3. The method of claim 1, wherein the originating transaction comprises a limited 0 number of transactions.
  3. 4. The method of claim 3, wherein the limited number of transactions are substantially concurrent.
  4. 5. The method of claim 3, wherein the originating transaction comprises one transaction.
  5. 6. The method of claim 1, wherein the credit only applies to the provider issuing the credit and the credit is issued corresponding only to the originating transaction. DC:486379.2 s0 7. The method of claim 1, wherein the credit available to the seller is a credit limit 0 O assigned to the seller minus any cumulative credit that is outstanding from the provider to the seller when the request is validated. O z e 5 8. The method of claim 1, wherein settling comprises: identifying the seller provided with the credit; 00 determining the amount of the credit due to the provider; and Ocollecting payment to the provider for the amount of the credit due within a C"l predetermined time period. 0 O 9. The method of claim 1, wherein the transaction item is in inventory of the provider at the time of the originating transaction. The method of claim 1, wherein a first bank in which the provider has an account conducts the receiving, the validating and the issuing.
  6. 11. The method of claim 1, further comprising generating an identifier that uniquely identifies the credit issued corresponding to the originating transaction. !0 12. The method of claim 11, wherein the identifier conforms to ISO standard 7812.
  7. 13. The method of claim 11, wherein the identifier is not used for any transaction or credit issuance other the originating transaction and the credit issued thereto.
  8. 14. The method of claim 1, wherein the request for credit is transmitted substantially concurrent with the originating transaction. The method of claim 1, wherein the request is transmitted over a first communication network and the issuing of the credit is transmitted to the seller on a second communication network. 2 DC:486379.2 0 16. A financial transaction system for conducting financial transactions, comprising: O O a receiving network for communicating a credit request from a seller to a provider, wherein the credit is specifically for an amount corresponding to a originating 0 S transaction between the seller and a buyer; e 5 a credit processor connected to the network and configured for identifying the seller and assessing the credit available to the seller when the request is received; a credit issuer connected to the processor and configured to issue the credit to the seller; C"l a credit reconciliator configured for enabling the settlement of the credit upon 0 payment of an incurred debt based on the credit issued; and O o a settlement system for settling credit;
  9. 17. The system of claim 16, wherein the credit processor is connected to communicate with a plurality of computers to receive credit requests from a plurality of sellers.
  10. 18. The system of claim 16, wherein the provider is a bank.
  11. 19. The system of claim 16, wherein the credit processor, the credit issuer, and the credit reconciliator are stored on a computer readable medium. !0 The system of claim 16, further comprising a processing system configured and adapted to communicate with a plurality of computers, wherein the process system is arranged to accept communication from a plurality of sellers. 3 DC:486379.2
AU2006241298A 2006-09-29 2006-11-23 Financial Transaction Processing Method and System Abandoned AU2006241298A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2006241298A AU2006241298A1 (en) 2006-09-29 2006-11-23 Financial Transaction Processing Method and System
PCT/AU2007/001395 WO2008036998A1 (en) 2006-09-29 2007-09-22 Financial transaction processing method and system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
USUNKNOWN 2003-08-06
AU2006241298A AU2006241298A1 (en) 2006-09-29 2006-11-23 Financial Transaction Processing Method and System

Publications (1)

Publication Number Publication Date
AU2006241298A1 true AU2006241298A1 (en) 2008-04-17

Family

ID=39338355

Family Applications (1)

Application Number Title Priority Date Filing Date
AU2006241298A Abandoned AU2006241298A1 (en) 2006-09-29 2006-11-23 Financial Transaction Processing Method and System

Country Status (1)

Country Link
AU (1) AU2006241298A1 (en)

Similar Documents

Publication Publication Date Title
US20190333034A1 (en) Transaction validation using transaction instructions linked to a token id
US7213750B1 (en) Spending account systems and methods
US7726561B2 (en) System and method for reconciling credit card payments with corresponding transactions
AU2007295102B2 (en) A method and system for managing purchase transactions between a customer and a merchant
US20120072349A1 (en) Authorization refresh system and method
KR101791470B1 (en) Method of transaction for supplier's account receivable
US20110004552A1 (en) Method and system for conducting a commercial transaction between a buyer and a seller
JP2005530234A (en) Integrated electronic invoice issuance and payment system and method
JP2008511085A (en) Method and system for automated payment authentication and settlement
US20180025357A1 (en) System and method for preventing multiple refunds and chargebacks
AU2002340294A1 (en) Method and system for conducting a commercial transaction between a buyer and a seller
KR102160676B1 (en) Card sales win-win managing and calculating system for small business owners
JP2002189862A (en) Device and method for settlement
US20200219153A1 (en) Transaction Model for Bank Balance Sheets
US20140006192A1 (en) Selective escrow of funds based on transaction receipts
WO2008036998A1 (en) Financial transaction processing method and system
AU2006241298A1 (en) Financial Transaction Processing Method and System
KR20060107969A (en) Method for selling the goods of card issuer, the server of card issuer and recording medium
JP2004094390A (en) Payment processing method and program
KR101129166B1 (en) Method and system for mediating payment
KR100832780B1 (en) Method for Selling the Goods of Card Issuer
KR100832778B1 (en) Method for Selling the Goods of Card Issuer
KR20120075449A (en) Method for certificating a payment
KR20090129684A (en) Method for the payment to invoice under cleaning and security franchise system for members
KR20060009800A (en) Method for transferring payroll deduction of card payments on line, recording medium

Legal Events

Date Code Title Description
MK1 Application lapsed section 142(2)(a) - no request for examination in relevant period