CN101010687A - Method and system for automated payment authorization and settlement - Google Patents

Abstract

The present invention provides a system and method to enable a third party service provider of EIPP services (120a) to initiate authorization and settlement of payment card payments with invoice line item data (Level III data), on behalf of either Buyer/Payers (110) or Supplier/Payees (130) to credit card acquirers (160) and/or transaction processors (160). Payment initiation (550) is based on submission of either a pre-approved invoice or order confirmation validated against a purchase order, or an invoice approved by the Buyer/Payer organization (110) and scheduled for payment (665).

Description

The method and system of automated payment authorization clearance

The cross reference of related application

The application requires to submit in the U.S. Provisional Application NO.60/604 on August 25th, 2004, and 215, be entitled as the priority of " automated payment authorization and clearance " (Automated Payment Authorization and Settlement). This U.S. Provisional Application requires to submit in the U.S. Patent application NO.10/465394 on June 18th, 2003, is entitled as the priority of " system and method that the integrated electronic invoice is cashed and paid the bill " (System and Method for Integrated Electronic Invoice Presentment and Payment). Above-mentioned two parts of applications all are incorporated herein by reference. The application has required to submit the U.S. Provisional Application NO.60/623 on October 29th, 2004 simultaneously, 656, be entitled as the priority of " method and system of automated payment authorization clearance " (Method and System For Automated Payment Authorization and Settlement), its integral body is incorporated herein by reference.

Background technology

The application relates to the method and system for automated payment authorization and clearance.

Make trial, carried out the automation of invoicing and course of payment by using third party service provider (3PSP). 3PSP comprises such as Ariba^TME-procurement provider, such as Xign^TMElectronic invoice (EIPP) provider that cashes and pay the bill, and such as Oracle^TMEnterprise Resources Planning (ERP) provider. These early stage 3PSP solutions are conceived to supplier/payee/book keeping operation person's needs, and enough satisfying are not accomplished in buyer/payment person/payment human needs. For example, many early stage 3PSP solutions can't solve buyer/payment person/payer's the demand relevant with payment, such as the efficiently and generation of control payment with producing effect, the clearance of deferred payment, and payment is met and be integrated in buyer/payment person's the financial sector.

In addition, existing 3PSP solution does not have study plot that Payment Card (such as credit card, debit card, company's card or purchase card) is used the payment means to businessman as businessman. Also have, these 3PSP solutions do not allow to use time limit of payment of being associated with the payment of being undertaken by Payment Card or to buyer/payment person's the regular checking of cashing before the payment of being undertaken by Payment Card.

In addition, existing 3PSP solution can not be integrated into the Payment Card data built-in system (such as, ERP or account payable (A/P) system) of tissue automatically. Therefore, these tissues are forced to manually re-enter invoice data, are checked account with this in they and card transaction coupling, and manually enter data into subsequently among the ERP or A/P system of tissue. This process expends time in and mistake occurs easily.

Some existing 3PSP solutions can be used Electronic Finance exchanges data (EDI) or other electronic payment techniques. Yet these modes of payment will need the considerable cost (comprise built-in system and process are carried out costly change) of setting up, and may need the banking relation is changed.

Therefore, need a kind of have cost-efficient, be integrated into existing process and system and allow effective payment of financial records and the automatic EIPP method and system of accounting checking easily.

In U.S. Patent application NO.10/465394, MasterCard has proposed a kind of autoelectrinic invoice and has cashed and payment system and method, can use and buy card as a kind of possible payment means. The present invention improves in first to file at this piece of writing. According to the present invention, provide the 3PSP of e-procurement and/or invoicing can allow their the client clearance of in the MasterCard credit card, automatically concluding the business, therefore make their client carry out purchase order (PO) or based on the purchase of invoice based on the bank credit clause. The disburser returns the sharp chance from defer payment clause and credit card issuer and makes a profit. Supplier's benefit is in electronic cash receipt (comparing with the cost of processing check) and do not need the additional investment of hardware or software and transmit the chance (with the lower discount rate of acquisition) of LEVEL-III data. Financial institution and their processor make a profit from a large amount of processing transaction. Acquirer and trading processing person's example is the Citibank (Citibank), First Data Corp. (FIRST DATA COPORATION), whole world payment (GLOBAL PAYMENTS) and Bank of America (Bank of America).

Summary of the invention

The invention provides a kind of 3PSP of making and to represent buyer/payment person/payer or supplier/payee/book keeping operation person initiate the Payment Card payment with the capable project of invoice (line item) data (LEVEL III data) to credit card acquirer and/or trading processing person mandate and clearance. Payment start be based on submit following any one: the invoice of approval or confirm the effective acknowledgement of orders letter of purchase order in advance, or organize invoice affirmation and that arrange to be used for payment by buyer/payment person/disburser.

Description of drawings

Fig. 1 shows the block diagram that is started the example system of the automated payment authorization of payment card transaction of payment and clearance by the payer;

Fig. 2 shows the flow chart that is started the illustrative methods of the automated payment authorization of payment card transaction of payment and clearance by the payer;

Fig. 3 shows the block diagram that is started the example system of the automated payment authorization of payment card transaction of payment and clearance by the payee;

Fig. 4 shows the flow chart that is started the illustrative methods of the automated payment authorization of payment card transaction of payment and clearance by the payee;

Fig. 5 shows the flow chart of the immediate clearance of the payment card transaction that the order of one exemplary embodiment according to the present invention starts;

Fig. 6 shows the flow chart of the extension clearance of the payment card transaction that the order (PO) of one exemplary embodiment according to the present invention starts;

Fig. 7 shows the flow chart of the extension clearance of the non-PO payment card transaction of one exemplary embodiment according to the present invention;

Fig. 8 shows the flow chart according to the example process of the mandate of MS of the present invention critical point and clearance; And

Fig. 9 shows the flow chart of the example process for the treatment of in accordance with the present invention MS authorization failure.

The specific embodiment

Fig. 1 and 3 shows the block diagram of the example system of the automated payment authorization of payment card transaction and clearance. In exemplary embodiment shown in Figure 1, start payment by the payer, and in exemplary embodiment shown in Figure 3, start payment by the payee. With reference to figure 1 and Fig. 3, buyer/payment person 110 is sides that buy product or service from supplier/payee 130. Preferably, each among buyer/payment person 110 and the supplier/payee 130 comprises respectively ERP system 110a and a 130a. Software supplier 120 provides e-procurement, invoicing, cash and/or the 3PSP of payment service, such as, the 120a of EIPP system. For instance, software supplier 120 can provide MasterCard e-P3^TMThe XignCoporation of EIPP solution^TM。

Acquirer/processor 160 is financial institution or the trading processing persons that process payment card transaction. Payment network 170 is Payment Card networks, such as MasterCard^TMThe payment network. Commerce services (MS) payment critical point 170a is the critical point of preferably processing payment card transaction mandate and clearance. Credit card issuer 140 is the banks to buyer/payment person's 110 distribution Payment Cards. MIS 150 is management information systems of credit card issuer 140. POS equipment 310 among Fig. 3 is point-of-sale terminal points, or any similar conventional system, it obtains finance data on supplier/payee 130 position or near it, and these data are sent to the payment network with report (transaction) behavior, mandate and transaction login.

Fig. 2 shows the flow chart of the illustrative methods of the automated payment authorization of payment card transaction and clearance, wherein starts payment by buyer/payment person 110. With reference to figure 1 and Fig. 2, in the payment of the buyer of step 210 place/payment person's ERP 110a approval and arrangement invoice. In this embodiment, buyer/payment person's ERP 110a can be, for example, and Oracle Payables system. In step 220, software supplier 120 extracts payment document from buyer/payment person's ERP 110a, and this payment document is sent to acquirer/processor 160, to carry out payment authorization and clearance. For example, payment document can be by Oracle iPayment^TM(MasterCard e-p3^TMProvider) extracts from the Oracle Payables financial sector of buyer/payment person's ERP 110a.

Payment document comprises the ID of trade company, payment card account information, is used for unique transaction id of ERP invoice reconciliation, and can comprise the capable project data of invoice (LEVEL III data). The ID of trade company can obtain in supplier/payee 130 enrollment process. Software supplier 120 is (such as Oracle iPayment^TM) can obtain payment card account information from buyer/payment person's ERP 110a (such as, Oracle Payables) or from the payment interface 120a of software supplier 120.

In step 230, buyer/payment person's 110 Payment Card payment request is submitted to payment network 170 (such as, MasterCard payment network for example) and authorizes and clearance being used for. In step 240, Payment Card statement of account data communication device is crossed credit card issuer MIS application program 130 or directly is provided for buyer/requestee 110 from payment network 170. These Payment Card statement of account data preferably comprise the unique transaction id (referring to step 220) from payment document.

In step 250, software supplier 120 provides payment to pay to data (comprising unique transaction id) to supplier/payee 130, checks account with the bank statement that is used for providing with acquirer/processor 160. For example, payment pay to data can be by such as Oracle iPayment^TME-P3^TMProvider and be provided for supplier/payee 130 and check account with their bank statement being used for. In step 260, buyer/payment person 110 is at the end of term in book keeping operation cycle and the clearance that credit card issuer 140 carries out payment card transaction at last.

Fig. 4 illustrates the flow chart that is started the illustrative methods of the automated payment authorization of payment card transaction of payment and clearance by supplier/payee 130. With reference to figure 3 and Fig. 4, in step 410, the payment of buyer/requestee's ERP 110a approval and arrangement invoice. In step 420, software supplier 120 extracts payment document from buyer/requestee's ERP system 110a, and this payment document is sent to (for example, passing through email) supplier/payee 130, to be used for payment authorization and clearance. Payment document comprises the ID of trade company, payment card account information, is used for unique transaction id of ERP invoice reconciliation, and can comprise the capable project data of invoice (LEVEL III data). The ID of trade company obtains in supplier/payee 130 enrollment process. Software supplier 120 obtains payment card account information from buyer/payment person's ERP 110a or from the payment interface 120a of software supplier 120.

In step 430, supplier/payee 130 is submitted to acquirer/processor 160 by POS equipment 310 with Payment Card and other Transaction Information, to be used for mandate and clearance. Acquirer/processor transmits by payment network 170 and authorizes and clearance information. In step 440, software supplier 120 directly sends to payment network 170 with the capable project data of invoice (comprising unique transaction id), to be used for coupling.

In step 450, Payment Card statement of account data communication device is crossed credit card issuer MIS application program 150 or directly is provided for buyer/requestee 110 from payment network 170. Payment Card statement of account data preferably comprise the unique transaction id (referring to step 420) from payment document. In step 460, payment is paid to data communication device and is crossed acquirer/processor 160 and be provided for supplier/payee 130, to be used for accounting checking. At last, in step 470, buyer/requestee 110 is at the end of term in book keeping operation cycle and the clearance that credit card issuer 140 carries out payment card transaction.

The below will describe other exemplary embodiment of the present invention. Although relating to using, these exemplary embodiments buy card, such as the P-Card of MasterCard^TM, but other Payment Card also can be used as substitute. The present invention helps to provide the software supplier 120 of EIPP platform 120a and acquirer/processor 160 to set up following function: automation and integrated supplier/payee's 130 registrations, payment authorization and/or clearance request and response and abnormal work flow process notice.

Describing in the exemplary embodiment at this, preferably using commerce services (MS) payment critical point 170a (Fig. 1 and 3). MS critical point 170a preferably processes the mandate of payment card transaction and the critical point of clearance. This processing may be implemented as batch mode, and in this pattern, accumulation LEVEL III concludes the business and it is sent to MS critical point 170a with normal data DIF (for example, 810EDI form) with the periodicity time interval. MS critical point 170a preferably comes split transactions based on merchant identifier (ID of trade company), transaction is forwarded to suitable position. MS critical point 170a preferably responds with normal data DIF (for example, 824EDI form) return authorization. For the transaction that has been authorized to, MS critical point 170a preferably uses the LEVEL III data that provide to clear processing.

Fig. 5 shows the flow chart of the immediate clearance of the payment card transaction that the order (PO) of one exemplary embodiment according to the present invention starts. In step 505, buyer/requestee 110 will send to electronically from the PO of ERP system 110a the 120a of EIPP system of software supplier. In step 510, in case the PO file is sent to the 120a of EIPP system with the form that requires, just calls the PO loading processing and change, resolve and load PO in the 120a of EIPP system.

In step 515, in case PO is loaded into the 120a of EIPP system and is verified at form and structure, the 120a of EIPP system just starts the rear loading (post-load) of PO and analyzes. Rear loading analysis comprises a series of basic checkings, such as, (i) determine about supplier/payee 130 and buyer/requestee's 110 information whether in the head of PO; (ii) determine and purchase card information that checking provides as mode of payment; (iii) determine whether it is new PO, copy PO or change PO, and it is carried out suitable mark to be used for later processing; (iv) determining the time limit of payment, that is, is immediate or extension PO.

In step 520, after finishing, load after PO analyzes, preferably determine this PO whether this be marked as a new PO still to change PO, to be used for later processing. In abnormal conditions, this PO is marked as one with the mistake of suitable reason, and is distributed to unusual formation in step 523. In step 525, if being marked as, PO changes PO, the 120a of EIPP system starts " changing PO " to be processed. Based on the rule whether original PO is satisfied and defines based on the relation between buyer/requestee 110 and supplier/payee 130, system is applied to change this PO and generates PO history.

In the situation of changing PO, in case finished suitable processing in step 525, preferably just determine in step 530 whether this change is effective. If it is invalid to change, this PO just is marked as a mistake and is distributed to unusual formation in step 523. If change effectively, the one or more agents that just use supplier/payee's 130 configuration informations of from this PO, obtaining and/or Merchant ID/clients account number this PO to be transmitted to supplier/payee 130. Preferably send email to supplier/payee 130 and notify to inform its this PO.

In step 535, supplier/payee 130 agent can preferably check the summary of all PO that are forwarded to it. If this PO has purchase account number associated with it, then the summary line of this PO is just preferably pointed out this situation. Simultaneously, the summary line of this PO will point out whether immediate the time limit of payment is. Supplier/payee 130 agent can select to check the details of PO. To show subsequently the PO detail view. The purchase card information of hiding also will appear in the PO detail view.

In step 540, from the PO summary or from the PO detailed view, supplier/payee 130 agent can browse (flip) this PO. The editable interface (defined according to buyer/requestee 110) that shows the PO details to the agent. In this step, buy the card number code and remain hiding equally. Supplier/payee 130 agent selects and will be included in element in the acknowledgement of orders letter with quantity. When agent's execution of supplier/payee 130 is browsed (partially or completely), system generates an acknowledgement of orders letter of drawing up. The acknowledgement of orders letter of drawing up has editable territory, is used for tax and free on board (FOB), and numerical value (if providing in PO) has been provided in advance for these. Supplier/payee 130 agent can not consider these elements, and can not consider the invoice number that generates, and continues to generate the acknowledgement of orders letter.

In step 545, the state of PO is changed into " process payment " and EIPP 120a and is generated an one number and this number is associated with the acknowledgement of orders letter. In step 550, whether receive list from supplier/payee 130 based on the MS critical point, start suitable payment relevant treatment. In step 555, single if MS critical point 170a does not also receive from supplier/payee 130, the acknowledgement of orders letter that then is displayed to supplier/payee 130 just contains an option, processes for startup means payment authorization.

In step 560, when having selected the means option, just provide the view of an acknowledgement of orders letter to supplier/payee 130, include editable territory and be used for input authorization code and trade date (extending this as system data in advance). Also provide described one number at this screen. In this stage, buy the card number code and do not hide. Supplier/payee 130 authorize by outside POS equipment 310 and when for example being prompted customer code in POS equipment 310 the described one number of input.

In step 565, if authorize, then supplier/payee's 130 use authority numbers and trade date upgrade the acknowledgement of orders letter, and and then this acknowledgement of orders letter are labeled as " received payment ". If payment authorization is rejected or failure, then both notify this situation by email to buyer/requestee 110 and supplier/payee 130, and invoice is marked as " failure " and is placed in " unsuccessfully mandate " summary view or the basket.

If in step 550, supplier/payee 130 has been received single by MS critical point 170a, then the 120a of EIPP system proceeds to step 570, carries out the mandate of MS critical point and clearance and processes. Authorize at the MS critical point and inventory processing (step 570) is preferably a batch processing, authorizes thus/clear file to generate and be sent to MS critical point 170a by the 120a of EIPP system. This document comprises LEVEL III clearance data. In step 575, the 120a of EIPP system receives the response comprise authorization code from MS critical point 170a, and and then the acknowledgement of orders letter be labeled as authorize, that is, and " received payment ", and authorization code is associated with the acknowledgement of orders letter. If payment authorization is rejected or failure, then notify to buyer/requestee 110 and supplier/payee 130 by email, and mark invoice and placing it in " unsuccessfully authorize " summary view or the basket. For the mandate based on MS, transaction preferably comprises suitable justification identification code.

Supplier/payee 130 also can have the option of checking the different acknowledgement of orders letters that generate in a certain summary rank and selecting to check in detail a certain specific indent confirmation. Supplier/payee 130a (non-MS) can select some acknowledgement of orders letter for not take any action in browsing (flip). These orders will be marked as " wait manual authorisation ".

In step 580, in case the acknowledgement of orders letter is marked as " received payment ", relevant information just is marked with specific XML pattern, and is affixed to the XML file of the EIPP 120a that will derive. Simultaneously, the acknowledgement of orders letter also is forwarded to buyer/requestee 110 based on the forwarding rule that defines among the EIPP 120a. One designator with invoice/acknowledgement of orders letter summary line project is preferably arranged, and indication the document is an acknowledgement of orders letter. Buyer/requestee 110 can check acknowledgement of orders letter details and buy card details (purchase card details are hidden, but show the last 4-digit number of account number). Buyer/requestee 110 does not preferably further process the acknowledgement of orders letter, except it being derived to be integrated into the accounts payable system.

Fig. 6 shows the flow chart of the extension clearance of the payment card transaction that the PO of one exemplary embodiment according to the present invention starts. In step 605, buyer/requestee 110 will send to electronically from the PO that ERP 120a comes the 120a of EIPP system of software supplier. In step 610, in case the PO file is sent to EIPP 120a with the form that requires, just calls the PO loading processing and change, resolve and load PO in the 120a of EIPP system.

In step 615, in case PO is loaded into the 120a of EIPP system and is verified at form and structure, the 120a of EIPP system just starts the rear loading analysis of PO. Whether rear loading analysis comprises a series of basic checkings, determine about supplier/payee 130 and buyer/requestee's 110 information in the head of PO such as (i); (ii) determine and purchase card information that checking provides as mode of payment; (iii) determine whether it is new PO, copy PO or change PO, and it is carried out suitable mark to be used for later processing; (iv) determining the time limit of payment, that is, is immediate or extension PO. In this exemplary embodiment, extension PO had such as the following time limit of payment: " clean 15 days ", " clean 30 days " (net 15, and net 30) etc. Also can not have the time limit of payment fully, this preferably is considered the special circumstances of extension PO.

In step 620, after finishing, load after PO analyzes, preferably determine this PO whether this be marked as a new PO still to change PO, to be used for later processing. In abnormal conditions, this PO is marked as one with the mistake of suitable reason, and is distributed to unusual formation in step 623. In step 625, if being marked as, PO changes PO, the 120a of EIPP system starts change PO to be processed. Based on the rule whether original PO is satisfied and defines based on the relation between buyer/requestee 110 and supplier/payee 130, system 120a and then change is applied to this PO and generates PO history. In the situation of changing PO, in case finished suitable processing in step 625, preferably just determine in step 630 whether this change is effective. If it is invalid to change, this PO just is marked as a mistake and is distributed to unusual formation in step 623. If change effectively, just use supplier/payee's 130 configuration informations and/or the Merchant ID/clients account number that preferably from this PO, obtain that this PO is ticked to be used for or to be transmitted to one or more agents of supplier/payee 130. Preferably send email to supplier/payee 130 and notify to inform its this PO.

In step 635, supplier/payee 130 agent can preferably check the summary of all PO that are forwarded to it. If this PO has purchase account number associated with it, then the summary line of this PO is just preferably pointed out this situation. Simultaneously, the summary line of this PO will point out whether immediate the time limit of payment is. Supplier/payee 130 agent can select to check the details of PO. To show subsequently the PO detail view. The purchase card information of hiding also will appear in the PO detail view.

In step 640, from the PO summary or from the PO detailed view, supplier/payee 130 agent can select to browse (flip) this PO. The editable interface (defined according to buyer/requestee 110) that shows the PO details to the agent. In this step, buy the card number code and remain hiding equally. Supplier/payee 130 agent selects and will be included in element in the acknowledgement of orders letter with quantity. When agent's execution of supplier/payee 130 is browsed (partially or completely), the EIPP system generates an invoice of drawing up in step 645. The invoice of drawing up has editable territory, is used for tax and free on board (FOB), and numerical value (if providing in PO) has been provided in advance for these. Supplier/payee 130 agent can not consider these elements, and can not consider the invoice number that generates, and generates invoice in step 645.

In step 645, the invoice that generates is forwarded to suitable buyer/requestee 110 agent, is used for confirming and arranging. Forwarding is to be determined by buyer/requestee 110 forwarding setting and any other relevant information relevant with the clients account number with buyer/requestee 110 ID of obtaining from original PO.

In step 650, buyer/requestee 110 agent can check the summary of all invoices that are sent to buyer/requestee 110 ID. The PO summary preferably uses special identifier for example to point out to have any PO of purchase card transaction associated with it. Buyer/requestee 110 agent can select to check the details of invoice. Buying card information also is presented in this detail view. Buy the card number code and remain hiding, last 4 except it.

In step 655, buyer/requestee 110 agent can transmit this invoice to be used for affirmation. Buyer/requestee 110 agent can confirm this invoice and/or use the workflow as the definition of buyer/requestee 110 tissue that it is transmitted to other agent. In step 660, determine whether this PO is attached with any time limit of payment, if having, then be what time limit. If this PO has the deferred payment time limit that clearly presents, the invoice that just arranges and confirm to generate in step 665 based on these time limits. For example, if time limit of payment indication " clean 15 days ", then preferably this invoice is arranged to payment in 15 days after its date that can check for buyer/requestee 110 begins. Yet if lack the time limit of payment, buyer/requestee can be arranged to this invoice in step 667 and confirm in certain date in future and payment. In step 655, in case confirmed this invoice, the invoice of confirming just is forwarded to supplier/payee, to check in step 665.

In step 670, when having arrived the date that arranges, the state of invoice just is changed to " processing payment ". Preferably generate an one number and it is associated with invoice. In step 670, whether received list by MS critical point 170a based on supplier/payee, start suitable payment relevant treatment. If it is single that supplier/payee 130 has been received by MS critical point 170a, then EIPP120a proceeds to step 675, carries out MS critical point 170a mandate and clearance and processes.

MS critical point 170a authorizes and the clearance processing is preferably a batch processing, authorizes thus/clear file to generate and be sent to MS critical point 170a by the 120a of EIPP system. This document preferably comprises LEVEL III clearance data. EIPP 120a receives the response comprise authorization code from MS critical point 170a, and is labeled as in step 680 and then with the acknowledgement of orders letter and authorizes, that is, be labeled as " received payment ", and authorization code is associated with this invoice.

If payment authorization is rejected or failure, then notifies to buyer/requestee 110 and supplier/payee 130 by email, and carry out suitable mark at step 680 pair invoice, and place it in " unsuccessfully authorizing " summary view or the basket. For the mandate of MS critical point 170a, transaction preferably comprises suitable justification identification code.

If in step 670, when invoice arrives the date arrange and during at " processing payment " state, determine trade company also received single, namely, determine that supplier/payee 130 is marked as " wait manual authorisation ", just trigger manual authorisation in step 685 and process. When supplier/payee 130 checks the details of the invoice of waiting for manual authorisation, just present one to supplier/payee 130 and start the option that payment is processed. When having selected this option, but just provide the view of the invoice with edit field to supplier/payee 130, be used for input authorization code and trade date (extending this as system data in advance). Also present described one number at this screen. In this stage, buy the card number code and do not hide. Supplier/payee 130 authorizes and inputs described one number when being prompted (for example, prompting input customer code) by outside POS equipment. In case authorize, supplier/payee 130 upgrades invoice with regard to use authority number and trade date, and and then this invoice is labeled as " received payment ".

If payment authorization is rejected or failure, then both notify this situation by email to buyer/requestee 110 and supplier/payee 130, and at this invoice of step 690 mark and place it in " unsuccessfully authorize " summary view or the basket. If the payment authorization success is marked as " received payment " at this invoice of step 690, and relevant information is affixed to for the EIPP XML file of deriving in step 695.

Fig. 7 shows the flow chart of the extension clearance of the non-PO payment card transaction of one exemplary embodiment according to the present invention. In this exemplary embodiment, be not loaded into PO among the 120a of EIPP system. At this, in step 710, electronically invoice is sent to software supplier 120 by supplier/payee 130. At software supplier 120 places, invoice is loaded into EIPP 120a in step 715. In the invoice loading processing, EIPP 120a preferably identifies supplier/payee 130 and whether will buy card and be accepted as the payment means. In addition, if buy the default payment means that card has been defined as the specific consumers account (concern in rank define buyer/requestee one supplier/payee), the 120a of EIPP system just is associated it with invoice.

Buyer/requestee 110 can arrange and comprise a plurality of agential user's groups, and a plurality of agents can be authorized to be to use to buy to block and pay the bill. Buyer/requestee 110 manager can input and buy the card details, such as holder's name, card number code, due date, CVC2 code, and should buy to block to organize with one or more users and will be associated. Buyer/requestee 110 manager can think that also buying card will only be used for some specific supplier/payee 130.

In step 715, invoice be loaded and based on invoice can with forwarding information be forwarded to suitable buyer/requestee 110 group. Forwarding can be finished based on transmitting ID or clients account number. In step 720, buyer/requestee 110 agent can check the summary of all invoices that are forwarded to this ID. In step 725, buyer/requestee 110 agent can confirm this invoice and/or use as buyer/requestee 110 and organize defined workflow that it is transmitted to other agent. Buyer/requestee 110 agent can select the payment means to be " buying card ", or " buying card " has been defined as the default payment means for the specific consumers account in advance, in this case, the 120a of EIPP system should buy to block and be associated with this invoice.

In step 730, in case " buying card " is set up as Payment Options, invoice just automatically is arranged in the date in future and pays the bill, or is manually arranged by the agent of the buyer/requestee 110 with " arranger " authority. In step 735, buy the card details and automatically be associated with this invoice. In step 740, invoice is identified for payment, and is forwarded to supplier/payee 130 for checking in step 745.

In step 750, when having arrived the date that arranges, the state of invoice just is changed to " processing payment ". Generate a unique transaction number and it is associated with invoice. In step 755, whether received list by MS critical point 170a based on supplier/payee, start suitable payment relevant treatment. In step 760 and 765, single if supplier/payee 130 has been received by MS critical point 170a, then the 120a of EIPP system carries out the mandate of MS critical point and clears and process. Authorize at the MS critical point and the clearance processing is preferably a batch processing, authorizes thus/clear file to generate and be sent to MS critical point 170a by the 120a of EIPP system. Authorize/clear file preferably to comprise LEVEL III clearance data.

In step 770, the 120a of EIPP system receives the response comprise authorization code from MS critical point 170a, and and then invoice be labeled as authorize (received payment), and authorization code is associated with this invoice. If payment authorization is rejected or failure, then notify to buyer/requestee 110 and supplier/payee 130 by email, this invoice of mark, and place it in " unsuccessfully authorizing " summary view or the basket. For the mandate of MS critical point 170a, transaction will comprise suitable justification identification code.

If in step 755, determine that trade company is also single by receipts, that is, determine that supplier/payee 130 is marked as " wait manual authorisation ", just trigger manual authorisation in step 775 and process. When supplier/payee 130 checks the details of these invoices (" wait manual authorisation "), just present one to supplier/payee 130 and start the option that payment is processed. When having selected this option, but just provide the view of the invoice with edit field to supplier/payee 130, be used for input authorization code and trade date (extending this as system data in advance). Also show described one number at this screen. In this stage, it is hiding that purchase card number code is preferably. Supplier/payee 130 authorizes by outside POS equipment 310 and is being prompted (for example, prompting input customer code) described one number of lower input.

In step 780, in case authorize, supplier/payee 130 upgrades invoice with regard to use authority number and trade date, and and then this invoice is labeled as " received payment ". In step 780, if payment authorization is rejected/failure, then both notify this situation by email to buyer/requestee 110 and supplier/payee 130, and this invoice of mark and placing it in " unsuccessfully authorize " summary view or the basket. In step 785, in case invoice is marked as " received payment ", relevant information just is labeled and is affixed to the XML file of EIPP 120a, to be used for derivation.

In connection with Fig. 8 MS mandate and clearance are described in more detail now. Fig. 8 shows the flow chart according to the example process of the mandate of MS of the present invention critical point and clearance. MS authorizes and clearance is preferably a combination batch processing, all is independent processing although do not need to authorize and clear. MS authorizes and clearance also is preferably a back-end processing, that is, processing execution is invisible to the user.

In step 820, create mandate/clearing transactions record based on the triggering in step 810. Triggering is preferably and generates an acknowledgement of orders invoice and this invoice when arriving " processing payment " state. When having activated triggering, just preferably create a basic document at the arrangement benchmark that only comprises infrastructure elements. When in the transmission that exists to MS, also create a new file. When in the 120a of EIPP system payment transaction occuring, preferably record is added in this document. Predetermined time this document preferably be sent to MS critical point 170a and restart with post processing.

Mandate/clearing transactions is preferably with 810 EDI forms, and comprises LEVEL III clearance data. The part that the coupling that unique transaction number, EIPP generate and customer code also are preferably this transaction. The data of these mandate/clearing transactionses (LEVEL III) are preferably from such as lower acquisition: the data element that (a) exists invoice; (b) buy the card related data; (c) MS trade company critical point 170s configuration information. Mandate/clearing transactions preferably is extracted with the time interval of rule, and is affixed to subsequently batch authorization/clearance file. Backup file also preferably is updated.

In step 830, with the predetermined time interval, will authorize/clear file to send to MS critical point 170a by the 120a of EIPP system, with for the treatment of. MS critical point 170a shines upon mandate/clearance file based on the mapping settings that is defined to software supplier 120. MS critical point 170a is to single those transaction of land identification of suitable receipts. Based on this identification, mandate/clearance file is divided and be sent to corresponding platform to be used for further processing. MS critical point 170a can be divided into mandate/clearing transactions a plurality of transaction, to adapt to the restriction to the value of total liquidation quantity.

In step 840, authorize to respond to be returned to EIPP 120a from MS critical point 170a. The response that returns to EIPP 120a is 824 EDI forms. In step 850, EIPP 120a receives to authorize and responds transaction, and assesses each and respond record. Based on this response (failure or other), the invoice that system update is corresponding. May be in the situation of successfully authorizing, continue clearance by MS critical point 170a and process, and need to be from any further action of software supplier 120. Process for clearance, do not expect any response from MS critical point 170a.

If authorize successfully, be marked as " authorizing " at step 855 invoice, and its state is upgraded suitably. In step 860, the invoice details also are associated with authorizing details. This comprises supplier/payee's 130 visible authorization codes, trade date etc. Buyer/requestee 110 will only can see trade date. Other Payment Records details that comprise unique transaction number, debit/credit side etc. also will be associated with invoice. In step 865, send email to supplier/payee 130 and notify to indicate the mandate to particular invoice successful. In step 870, generate EIPP XML file relationship trading, being used for the record purpose, and preferably be exported as required.

If authorize unsuccessful, at step 875 invoice by suitably mark and its state are updated. In step 880, by email buyer/requestee 110 and supplier/payee's 130 agent is suitably notified. At last, in step 885, transaction is placed in the suitable failed mandate unusual " basket ".

Now the processing of MS authorization failure will be described according to Fig. 9. Fig. 9 shows the flow chart of the example process for the treatment of in accordance with the present invention MS authorization failure. In step 905, the MS authorization failure is processed preferably triggering when the authorization requests relevant with invoice or acknowledgement of orders letter refused by following arbitrary main body: (i) conduct is authorized the MS critical point 170a of the part in the clearance processing at the MS critical point, or (ii) clears the POS equipment 310 of the part of processing as manual authorisation. Can respond or never be obtained to explain in detail the single supplier/payee's 130 of MS critical point 170a receipts the agential manual input from the mandate of MS critical point 170a the data of mandate reason for rejection. The 120a of EIPP system preferably will authorize reason for rejection to be associated with invoice information.

In step 910, invoice or acknowledgement of orders letter state be changed to " authorization failure ". In step 915, the email notice is sent to buyer/requestee 110 and is sent to supplier/payee 130, and is failed for the payment authorization of particular invoice or acknowledgement of orders letter with prompting. In step 920, buyer/requestee 110 and supplier/payee 130 can select the details of checking particular invoice or acknowledgement of orders letter from " unsuccessfully authorize " summary view, and this invoice is marked as " authorization failure " in this view. When doing like this, will to buyer/requestee 110 and/or supplier/payee 130 show obtained by 170a place, MS critical point or by the reason for rejection (as the part of invoice or acknowledgement of orders letter detailed view) of supplier/payee's 130 inputs and explain reason and the additional information of the guide of this reason for rejection of solution.

Part as the detailed view of the invoice of " authorization failure " state or acknowledgement of orders letter also provides the selection of " again submitting same as before " or " ignoring the payment means " to buyer/requestee 110. Buyer and supplier confer between also can selecting mutually, to assess possible reason and remedying " authorization failure ".

In step 925, buyer/requestee 110 can select " again submitting same as before " this particular invoice or acknowledgement of orders letter, processes to be used for payment. If this obtain from EIPP 120a or be contingent when having caused this trend from the reason for rejection that outside information obtains. In step 930, invoice or acknowledgement of orders letter state are changed to " payment is processed " subsequently. If it is single that supplier/payee 130 has been received by MS critical point 170a, then call mandate and the clearance processing of MS critical point 170a in step 935. If it is single that supplier/payee 130 is not received by MS critical point 170a, then invoice is labeled as " wait manual authorisation " in step 940, and in step 945, send email indicating this invoice just waiting for manual authorisation to supplier/payee 130, and call manual authorisation and process.

In step 925, buyer/requestee 110 can select to ignore the payment means that are used for this invoice or acknowledgement of orders letter that have been associated with original authorization requests. If this obtain from EIPP 120a or be contingent when having caused this trend from the reason for rejection that outside information obtains. If selected " ignoring the payment means " option, then in step 950, preferably provide a view one or more payment means to select to substitute to buyer/requestee 110. Buyer/requestee 110 can select related any available payment means (comprising other purchase card). After having selected the payment means, in step 955, buyer/requestee 110 can submit this invoice or acknowledgement of orders letter, with for the treatment of. In step 960, this invoice or acknowledgement of orders letter state are changed to " payment is processed " subsequently.

If in step 950, selected mode of payment is not a purchase card, then processes and will preferably carry out in the mode that defines in " same as before " system. If selected mode of payment is one to buy card, and if supplier/payee 130 received singly by MS critical point 170a, then in step 935, call that MS critical point 170a authorizes and clearance is processed. If it is single that supplier/payee 130 is not received by MS critical point 1 70a, then this invoice is labeled as " wait manual authorisation " in step 940. In step 945, send email indicating this invoice just waiting for manual authorisation to supplier/payee 130, and call manual authorisation and process. In step 925, when checking invoice or acknowledgement of orders letter refusal details, buyer/requestee 110 can select to conclude the business to change the purchase card information that is associated with invoice by changing PO. If this wishes to make this change be reflected in all invoices that are associated or acknowledgement of orders letter buyer/requestee for example 110, if or not have other payment means can be provided for buyer/requestee 110 be contingent in situation lower time for you to choose. Preferably, if this only occurs over just in the situation that has the PO that is associated with invoice among the EIPP 120a.

In step 965, buyer/requestee 110 sends " changing PO " or " change and buy card information " request. In step 970, upgrade the purchase card information that is associated with this PO with the information that changes in the PO request subsequently. In step 975, this information is delivered to invoice or the acknowledgement of orders letter that generates for the invoice that also is not in " received payment " state. In step 980, be in the invoice of " authorization failure " state for those, state is reset to " processing payment ". If it is single that supplier/payee 130 has been received by MS critical point 170a, then call mandate and the clearance processing of MS critical point 170a in step 935. If it is single that supplier/payee 130 is not also received by MS critical point 170a, then this invoice is labeled as " wait manual authorisation " in step 940. In step 945, send email indicating this invoice just waiting for manual authorisation to supplier/payee 130, and call manual authorisation and process.

Following table is how to come to the example of the transmission mandate of MS critical point and clearing transactions with EDI 810 forms.

		The territory is described	Data type	Length	Request	Acquiescence/form	Note
								Head begins
This is to force part for ISA exchange control head
								ISA01	The authorization message qualifier		C	2	M	“00”
ISA02	Authorization message		AN	10	M	The space
								ISA03	The security information qualifier		C	2	M	“00”
ISA04	Security information		AN	10	M	The space
								ISA05	Exchange transmit leg ID qualifier		C	2	M		If there is no, then specified by MS
ISA06	Exchange transmit leg ID		AN	15	M		If there is no, then specified by MS
								ISA07	Exchange recipient ID qualifier		C	2	M	09
ISA08	Exchange recipient ID		AN	15	M	" MSSTEST " represents test;

					" MSSPROD " representative products; " MSNTEST "; " MSNPROD "
									ISA09	The exchange date	DT	6	M	YYMMDD
ISA10	Swap time	TM	4	M	HHMM
									ISA11	Exchange control ID	C	1	M	“U”
ISA12	Switch version number	C	5	M	“00410”
									ISA13	The exchange control number	N	9	M			Transmit leg is specified
ISA14	Request is confirmed	C	1	M	“1”
									ISA15	Test indicator	C	1	M	" T " represents test; " P " representative products
ISA16	The daughter element separator	C	1	M	“＞”
									This is to force part, indication beginning function group for GS function group head
GS01	The function identifier code	C	2	M		“IN”
									GS02	Application program transmit leg code	AN	15	M				Transmit leg ID
GS03	Application program recipient's code	AN	15	M		Consistent with ISA08

GS04	Date		DT	8	M	CCYYMMDD
								GS05	Time		TM	6	M	HHMM
GS06	The group control number		N	9	M		By transmit leg specify and safeguard number
								GS07	The agent code of being responsible for		C	2	M	“X”
GS08	Version/distribution/industrial identifier code		AN	12	M	“00401”
								Head part-circulation ID-SE begins
ST transaction set head is forced, indication beginning transaction set
								ST01	The transaction set identifier code		C	3	M	" 801 "-invoice
ST02	The transaction set control number		AN	9	M	From " 0001 "	By transmit leg specified order number
								Force BIG invoice beginning
BIG01		Invoice sends day	DT	8	M	CCYYMMDD
								BIG02		Invoice number	AN	22	M		Maximum 17 bit digital
BIG03		Date	DT	8	O	CCYYMMDD	The original PO date
								BIG04		Purchase order number	AN	22	O
BIG07		The type of transaction code	C	2	M	" DI "-debit " CN "-credit side

BIG09	Action code	C		2		M	" SE " clears invoice: " 7 "-mandate invoice		Be generally for EIPP trade company " 7 "
											The REF reference identifier
REF01	The reference identifier qualifier	C		3		M		“E4”	Credit card number
											REF02	Reference identifier	AN		30		X			Maximum 16
REF03	Describe
											The optional part of REF reference identifier
REF01	The reference identifier qualifier	C		3		M		“EM”	The electronic cash reference number
											REF02	Reference identifier	AN		30		X			＜MasterCard need to provide essential part＞
REF03	Describe								Head part-circulation N1 begins
											Head part-circulation ID-SE finishes
Head part-circulation N1 begins
											Buyer's beginning that circulates
N1 title buyer circulation
											N101	Entity recognition symbol code		C		3	M		" BY "-buyer
N102	Title		AN		60
											The N3 address information
N301	Address information		AN		55	O				20 of purchaser's street addresses-maximum

The N4 geographical position
									N401	City name	AN	30	O				Maximum 13
N402	The state or province code	C	2	O
									N403	Postcode	C	15	O	Without dash			9
N404	Country code	C	3	O	Allow			Maximum
									The REF reference
REF01	The reference identifier qualifier	C	3	M		“CR”
									REF02	Reference identifier	AN	30	O				Client's reference number (can be PO number or some other numbers based on GL) will be determined when client realizes
Buyer's end that circulates
									Sellers' beginning that circulates
N1 title sellers circulation
									N101	Entity recognition symbol code	C	3	M		" SE "-sellers
N102	Title	AN	60
									The REF reference
REF01	The reference identifier qualifier	C	3	M			“VR”
									REF02	Reference identifier	AN	30	O				Trade company's number of MS appointment
The REF reference
									REF01	With reference to identification	C	3	M			“CA”

	The symbol qualifier
							REF02	Reference identifier	AN	30	O		One number
The REF reference
							REF01	The reference identifier qualifier	C	3	M	“TJ”
REF02	Reference identifier	AN	30	O		Sellers' federal taxation ID
							The REF reference
REF01	The reference identifier qualifier	C	3	M	“ZA”
							REF02	Reference identifier	AN	30	O	1000	The merchant type code. If there is not numerical information to be provided, then this numerical value is provided as " 1000 "
Sellers' end that circulates
							Head part-circulation N1 finishes
The reference of DTM date/time
							DTM01	The date/time qualifier	C	3	M	“036”	The numerical value of indication DTM06 is the due date of credit card
DTM05	Time cycle on date formal qualification symbol	C	3	M	“YM”

DT02	Time cycle on date	AN			35	M		YYMM	Credit card due date
											Head finishes
											Details begin
Details part-circulation ID-IT1 begins
											It is according to a plurality of projects that IT1 baseline project data has a plurality of records of a plurality of records in this part
IT102	The quantity of drawing a bill	N		10		X
											IT103	Measurement unit's code	C		2		X	" EA " one each
IT104	Unit price	N		17		X	Comprise the decimal system
											IT108	Product/service ID qualifier	C		2		X	" PN "-company's identification symbol; " MG "-manufacturer's part number
IT109	Product/service ID qualifier	AN		48		X				Maximum 12, if there is not usable levels, can be defaulted as " 99999 "
											This part of TX1 tax revenue information is optional and MasterCard plan (unless providing buyer/requestee to specify requirement) is provided
TX101	The tax type code		C		2	M	" VA "-value-added tax

TX102	Force quantity	N		18	X
										TX103	Percentage	N		10	X
The PID beginning that circulates
										The PID product item is described
PID01	The item description type	C		1	M		" F "-free form is described
										PID02	Describe	AN		35	X			For maximum 35 of MasterCard
The PID end that circulates
										The SAC beginning that circulates
SAC service, sales promotion, subsidy, or cost information is not because it is the part of requirement that discount is processed, this part is not used
										SAC01	Subsidy or expense designator		C	1		" A "-subsidy; " C "-expense
SAC02	Service, sales promotion, subsidy or expense code		C	4		" C310 "-discount; " D240 "-freight charges; " D500 "-administrative expenses
										SAC03	Act on behalf of the qualifier code		C	2
SAC04	Agency service, sales promotion, subsidy or expense code		AN	10
										SAC05	Quantity		N	15		2 decimal systems

SAC06	Subsidy/expense percentage qualifier		C		1
												SAC07	Percentage		N		6
The SAC end that circulates
												Details part-circulation ID-IT1 finishes
Details finish
												Summary begins
TD5 all forces the numerical value summary
												TAS01	Quantity	N		15		M				The total quantity of invoice comprises tax revenue, freight charges and a small amount of discount
TXI tax revenue information is optional
												TXI101	Tax type	C		2		M		" TX "-all tax revenues; " VA "-value-added tax; " OH "-other tax revenue
TXI02	Force quantity	R		18		X					Tax revenue quantity corresponding to TXI01 (makes decimally
												CTT transaction total amount is optional
CTT01	Row project number	N		6		M					The total number of capable project in the transaction set
												Gather end
This part of SE transaction set afterbody is compulsory

SE01	The quantity of included part		N	10	M		The sum that comprises the part of ST and SE transaction set partly
									SE02	Transaction set control number		AN	9	M		Must be consistent with ST02
This part of GE function group afterbody is compulsory
									GE01	The quantity of included transaction set		N	6	M
GE02	Transaction control number		N	9	M		Must be consistent with GS06
									This part of IEA exchange control afterbody is compulsory
IEA01	The quantity of included function group	N		5	M			The sum of the function group in exchange
									IEA02	Exchange control number	N		9	M			Must be consistent with ISA13

M=forces

X=is with good conditionsi

O=is optional

Following table provides a MS critical point 170a how to send the example of authorizing response to software supplier 120 with the EDI824 form. In this example, EDI997 will send to confirm whether the form of asking is appropriate by MS critical point 170a.

	Region description	Data type		Length	Request	Acquiescence/form		Note
This is to force part for ISA exchange control head
									ISA01	The authorization message qualifier	C	2		M	“00”
ISA02	Authorization message	AN	10		M	The space
									ISA03	The security information qualifier	C	2		M	“00”
ISA04	Security information	AN	10		M	The space
									ISA05	Exchange transmit leg ID qualifier	C	2		M	“09”
ISA06	Exchange transmit leg ID	AN	15		M	" MSSTEST " represents test; " MSSPROD " representative products; " MSNTEST " " MSNPROD "
									ISA07	Exchange recipient ID qualifier	C	2		M		If there is no, then specified by MS
ISA08	Exchange recipient ID	AN	15		M		If there is no, then specified by MS
									ISA09	The exchange date	DT	6		M	YYMMDD
ISA10	Swap time	TM	4		M	HHMM
									ISA11	Exchange control ID	C	1		M	“U”

ISA12	Switch version number	C	1	M	“00401”
							ISA13	The exchange control number	N	9	M		Transmit leg is specified
ISA14	The affirmation of request	C	1	M	“0”
							ISA15	Test indicator	C	1	M	" T " represents test; " P " representative products	Must be consistent with ISA06
ISA16	The sub-project separator	C	1	M	“”
							This is the beginning of forcing part deixis group for GS function group head
GS01	The function identifier code	C	2	M	“AG”
							GS02	Application program transmit leg code	AN	15	M	Consistent with ISA06
GS03	Application program recipient's code	AN	15	M		Recipient ID
							GS04	Date	DT	8	M	CCYYMMDD
GS05	Time	TM	6	M	HHMM
							GS06	The group control number	N	9	M		By transmit leg specify and safeguard number
GS07	The agent code of being responsible for	C	2	M	“X”

GS08	Version/distribution/industrial identifier code		AN	12	M		“004010”
									ST transaction set head is forced, the beginning of indication transaction set
ST01	The transaction set identifier code	C		3	M	The suggestion of " 824 "-application program
									ST02	The transaction set control number	AN		9	M			Serial number by the transmit leg appointment
Head begins
									Force the BGN beginning
BGN01	The transaction set function code	C		2	M	" 00 "-original
									BGN02	With reference to identification	AN		30	M			Follow the tracks of number
BGN03	Date	DT		8	M	CCYYMMDD		File creation date
									Head finishes
Details begin
									The details ID-OTI that partly circulates begins
The original transaction identification of OTI is forced
									OTI01	Application program is confirmed code		C	2	M	" TA "-transaction set is accepted; " TR "-transaction set refusal		If TA-detail records Authorized Domain=6 characters; If this territory of TR-=4 characters

OT102	With reference to the identification qualifier	C	3	M		" TV " sellers' invoice number
								OT103	Reference identifier	AN	30	M			Invoice number
This is that optional part is with the circulation of OTI to REF with reference to identification. Only as OT101=" TA " time mapping
								REF01	With reference to the identification qualifier	C	3	M		" BB "-authorization number
REF02	Reference identifier	AN	30	X			Authorization number
								REF03	Describe	AN	80	X			The CVV2_ designator, CVV2_Value, CVV2_Result (if existence)
It is optional circulation with OTI that AMT forces this part of quantity
								AMT01	Quantity qualifier code	C	3	M
AMT02	Force quantity	N	18	M			The invoice total amount
								The details ID-OTI that partly circulates finishes
The details ID-TED that partly circulates begins
								It is optional section that the TED error of performance is described this
TED01	The application error CC condition code	C	3		M	" other unlisted reason of 024-	20 of purchaser's street addresses-maximum

TED02	Free form message	AN		60	O		The reason for rejection code, the product code of the blank and coupling of heel, heel space, and by holder's number of " X " representative is except last 4 of will show
								TED03	The copy of bad data element	AN		99	O
The optional circulation with TED of NTE note/special instruction
								NTE01	The note identifying code	C		3	O	" TRS " quality information
NTE02	Describe	AN		80	M		If there is the swindle score, then from MSFTEST or MSFPROD
								The RED related data is optional, with the circulation of TED
REF01	Describe		AN	80	M	The MasterCard suggestion
								REF02	The related data cognizance code		C	3	X	The identifier that " AI " one is specified
The details ID-TED that partly circulates finishes
								Details finish
This part of SE transaction set afterbody is compulsory

SE01	Included part number	N	10	M		The total number that comprises the part in ST and the SE transaction set partly
							SE02	Transaction set control number	AN	9	M		Must be consistent with ST02
This part of GE function group afterbody is compulsory
							GE01	Included transaction set number	N	6	M
GE02	Transaction set control number	N	9	M		Must be consistent with GS06
							This part of IEA exchange control afterbody is compulsory
IEA01	The number of included function group	N	5	M		The sum of the function group in exchange
							IEA02	Exchange control number	N	9	M		Must be consistent with ISA13

Following table has provided the overview according to exemplary MS of the present invention critical point 170a response/justification identification code. In following table, the response that " * * " expression MS critical point 170a generates.

MS responds code/justification identification code

Respond code	Justification identification code
		1. ND-refuses
2. dishonest	3．    01
		4. there are not enough funds	5．    02
6. transaction does not allow	7．    03
		8. exceed drawing quantity	9．    07

10. exceed the counting of withdrawing deposit	11. 08
		12. non-existent account	13. 09
14.NC﹠FI-extract
		15. extract	16. 01
17. lose card	18. 02
		The card 19. be stolen	20. 03
21. extract special	22. 04
		23.NR-referral
24.** overtime	25. 01
		26. consult publisher	27. 02
28. system can't operate	29. 03
		30. invalid transaction	31. 04
32. invalid quantity	33. 05
		34. invalid card number code	35. 06
36. invalid publisher	37. 07
		38. invalid trade company	39. 08
40. overdue card	41. 09
		42. limited card	43. 11
44. system mistake	45. 12
		46. can't transmitted transaction	47. 19
48. format error	49. 20
		50. dual trading	51. 21
52.NS-invalid
		53.** bad trade date	54. 01
55.** bad quantity	56. 02
		57.** number of transaction equals 0	58. 03
59.** Invalid Account Number code length	60. 04

61.** bad Card Type code	62. 05
		63.** bad check numerical value	64. 06
65.** invalid CVC2 code	66. 07
		67.** Unidentified response	68. 10
69.** non-numeric account number	70. 11
		71.** invalid due date	72. 12
73.** Unidentified transaction	74. 14
		75.** invalid extension name/prefix	76. 15
77.** trade company is not in the program of terminating an agreement	78. 16
		79 ** invalid EC indicator	80. 17
81 ** invalid indicator merchant transactions	82. 18
		83. ** SE numbers not found	84. 19
85.NE-expired card
		86. ** Expired card	87. 01
88.NZ-soft refused to reauthorize
		89 ** initial soft refused access to reauthorize	90. 00
91 ** first transaction cycle	92. 01
		93 ** second transaction cycle	94. 02
95 ** The third transaction cycles	96. 03
		97. ** Fourth transaction cycles	98. 04
99. ** Fifth transaction cycles	100. 05
		101. ** Sixth transaction cycles	102. 06
103. ** Seventh transaction cycles	104. 07
		105 ** eighth transaction cycles	106. 08
107. ** Ninth transaction cycles	108. 09

While the invention has particular reference to the above described preferred embodiments. But the skilled Person will recognize that various modifications, alterations, and substitutions without departing from the invention of the appended claims Book from the spirit and scope defined.

Claims (4)

1 An electronic bill payment and payment through (EIPP) system between buyers and suppliers A purchase card transactions, the method comprising:

In the buyer's enterprise resource planning (ERP) systems confirm the purchase card transaction invoice;

In the buyer's ERP system arrangement invoice payment;

From the buyer's ERP system extracts including transaction associated with the unique transaction identifier Payment documents;

Will include the unique identifier of the payment transaction files from the buyer's ERP system sends to the receiving Receipt, for payment authorization and settlement;

Provided to the purchaser of the ERP transaction data including a description of the purchase card statements, statement number It includes the unique transaction identifier; and

Purchased by the purchaser and the issuer of the card transaction settlement.

(2) as claimed in claim 1, characterized in that, further comprising:

To the supplier remittance data for said vendor reconciliation accounts, the Remittance data including said unique transaction identifier.

3 An electronic bill payment and payment through (EIPP) system between buyers and suppliers into OK purchase card transactions, the method comprising:

In the buyer's enterprise resource planning (ERP) systems confirm the purchase card transaction invoice;

In the buyer's ERP system arrangement invoice payment;

From the buyer's ERP system extracts including transaction associated with the unique transaction identifier Payment documents;

Will include a unique transaction identifier describing the transaction data submitted to a point of sale (POS) devices for authorization and settlement;

Will describe the details of the transaction line item data from said EIPP system sends to the purchase card payment Networks for matching the line item data includes said unique transaction identifier;

Provided to the purchaser of the ERP transaction data including a description of the purchase card statements, statement number It includes the unique transaction identifier, and

Purchased by the purchaser and the issuer of the card transaction settlement.

4 as claimed in claim 2, characterized in that, further comprising:

To the supplier remittance data for said vendor reconciliation accounts, the Remittance data including said unique transaction identifier.

Images