Credit card payment processing system and method

• US 20050049974A1
• Filed: 05/17/2004
• Published: 03/03/2005
• Est. Priority Date: 08/29/2003
• Status: Abandoned Application

• Current Assignee: iCode Inc.
• Original Assignee: iCode Inc.
• Inventors: Jani, Ali, Vadher, Nayan
• Application Number:
  US10/847,769
• Publication Number:
  US 20050049974A1
• Time in Patent Office: Days
• US Class Current: 705/64
• CPC Class Codes: G06Q 20/02 involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• CPC Class Codes: G06Q 20/04 Payment circuits
• CPC Class Codes: G06Q 20/12 specially adapted for electronic shopping systems
• CPC Class Codes: G06Q 20/24 Credit schemes, i.e. "pay after"
• CPC Class Codes: G06Q 20/382 insuring higher security of transaction
• CPC Class Codes: G06Q 20/403 Solvency checks

Abstract

Business Software Systems that process credit card transactions interface with another payment processing software or payment gateway to process the transactions. For a Business Software System to directly interface with payment processing software or payment gateway, the Transaction Requests have to be formulated in the format mandated by the payment gateway or payment processing software. The Transaction Request has to be conveyed to the payment gateway using the communication protocol that is stipulated by the payment gateway or Payment Processor. An Intermediary Payment Processor allows a Business Software System to interface with another payment processing software or payment gateway although the format and communication protocol used by the Business Software System is different from the format and protocol required by the payment gateway or Payment Processor. The intermediary processing system is setup to contain definitions for the format used by the Business Software System, the equivalent definitions for the format used by the payment gateway and the communication protocols used by both. The intermediary reads the Transaction Request in the format generated by the Business Software System, translates it into the format required by the payment gateway, receives the response and the transaction result; and translates the response into the format that is understood by the Business Software System.

Claims

1. An intermediate payment processor for processing payments between a business software system and a payment processor, the system comprising:

a database containing one or more definitions wherein each definition is a definition for communication protocols including one of a specified port and folder, transaction requests from the business software system in the formats understood by each payment processor, and the formats for the data format supported by a payment server of the payment processor; and

a payment processing module further comprising a means for monitoring the specified ports or folders for a transaction request in a format published by the payment processor, means for translating the transaction request into a format published by the payment server based on the definition for the payment server in the database and a means for translating a response from the payment server into a format of the payment processing module so as to enable the business software system from which the request has originated to decipher the response and carry out further actions based on the type of response.

2. The system of claim 1, wherein the payment processing module further comprises means for setting up a merchant account information for each merchant account with the corresponding payment server, means for identifying an output mode of the transactions requests for each merchant account as a request file or through a port, means for identifying a folder in which the request file is to be placed or the port to which the request is to be sent, and a means for specifying the maximum number of transactions that the intermediary is allowed to process concurrently and in each step, updates the database with the setup data.

3. The system of claim 2, wherein the payment processing module further comprises means for intercepting a transaction request from the business software system and assigning the transaction request to a particular payment processor based on the definitions contained within the database, means for monitoring the transaction request based on the definition associated with that transaction request, means for generating a repository of the processor templates objects based on the number of concurrent transactions specified, and a means for creating workers threads based on the configuration settings and create the number of workers available.

4. An intermediate payment processor for processing payments between a business software system and a payment processor, the system comprising:

a database containing one or more definitions wherein each definition is a definition for communication protocols including one of a specified port and folder, transaction requests from the business software system in the formats understood by each payment processor, and the formats for the data format supported by a payment server of the payment processor; and

a payment processing module comprising a computer program wherein the computer program further comprises instructions that monitor the specified ports or folders for a transaction request in a format published by the payment processor, instructions that translate the transaction request into a format published by the payment server based on the definition for the payment server in the database and instructions that translate a response from the payment server into a format of the payment processing module so as to enable the business software system from which the request has originated to decipher the response and carry out further actions based on the type of response.

5. The system of claim 4, wherein the payment processing module further comprises instructions that set up a merchant account information for each merchant account with the corresponding payment server, instructions that identify an output mode of the transactions requests for each merchant account as a request file or through a port, instructions that identify a folder in which the request file is to be placed or the port to which the request is to be sent, and instructions that specify the maximum number of transactions that the intermediary is allowed to process concurrently and in each step, updates the database with the setup data.

6. The system of claim 5, wherein the payment processing module further comprises instructions that intercept a transaction request from the business software system and assigning the transaction request to a particular payment processor based on the definitions contained within the database, instructions that monitor the transaction request based on the definition associated with that transaction request, instructions that generate a repository of the processor templates objects based on the number of concurrent transactions specified, and instructions that create workers threads based on the configuration settings and create the number of workers available.

7. A payment processor comprising:

a piece of software wherein the software further comprises one or more sets of instructions;

wherein a first set of instructions further comprise instructions to format transaction data based on a type of payment processing software, instructions to set up a merchant account information for each merchant account with a corresponding payment server, instructions to identify an output mode of each transactions request for the merchant account as one of a request file and through a port, instructions to identify a folder in which the request file is to be placed or the port to which the request is to be sent, instructions to specify a maximum number of transactions that the intermediary is allowed to process concurrently and instructions to update a database; and

wherein a second set instructions further comprises instructions to process a payment request further comprising instructions to identify a source of the request and a format in which the request has been sent, instructions to identify a payment processor to which the request should be directed, instructions to assign the request to a processor object and a thread, instructions that process the request when a free processor object and thread are available by translating the request from a current format to a format in which the payment processor requires the requests to be transmitted and instructions to transmit the request after due validation, instructions to redirect the response from the processor to the format recognized by the source of the request, or in case the processor object and the thread are not free send it to the queue.

8. An intermediate payment processing method for processing payments between a business software system and a payment processor, the method comprising:

providing a database containing one or more definitions wherein each definition is a definition for communication protocols including one of a specified port and folder, transaction requests from the business software system in the formats understood by each payment processor, and the formats for the data format supported by a payment server of the payment processor;

monitoring the specified ports or folders for a transaction request in a format published by the payment processor;

translating the transaction request into a format published by the payment server based on the definition for the payment server in the database; and

translating a response from the payment server into a format of the payment processing module so as to enable the business software system from which the request has originated to decipher the response and carry out further actions based on the type of response.

9. The method of claim 8 further comprising setting up a merchant account information for each merchant account with the corresponding payment server, identifying an output mode of the transactions requests for each merchant account as a request file or through a port, identifying a folder in which the request file is to be placed or the port to which the request is to be sent, and specifying the maximum number of transactions that the intermediary is allowed to process concurrently and in each step, updates the database with the setup data.

10. The method of claim 9 further comprising intercepting a transaction request from the business software system, assigning the transaction request to a particular payment processor based on the definitions contained within the database, monitoring the transaction request based on the definition associated with that transaction request, generating a repository of the processor templates objects based on the number of concurrent transactions specified, and creating workers threads based on the configuration settings and create the number of workers available.